Vault lent sur les read au dela de 10k req/s

Question

Salut la team j'ai un souci avec vault j'ai l'impression qu'il galère grave dès qu'on monte en charge sur les reads de secrets. Au dela de 10k req/s le p99 monte à 500ms voire plus c'est injouable.
L'infra c'est du k8s avec un backend consul sur ec2. Les instances sont pas saturées en cpu/mem.

# config vault simplifiée
storage "consul" {
  address = "127.0.0.1:8500"
  path    = "vault/"
}
listener "tcp" {
  address     = "0.0.0.0:8200"
  tls_disable = true
}

Des idées sur ce qui pourrait ralentir les reads à ce point ?

guichard-victor · Answer

yo. 10k req/s c'est pas rien. t'as checké le réseau entre tes pods vault et tes serveurs consul ? un p'tit iperf histoire de voir la latence brute et le débit max.

gauthier-zacharie · Answer

salut. regarde aussi les metrics consul côté serveur. cpu, mem et surtout disk iops. si consul galère à stocker/récupérer les données sur le disque ça va impacter vault direct.

guichard-victor · Answer

ouais et vault est-ce que t'as activé le caching local ? des fois ça aide énormément sur les reads si les secrets sont souvent les mêmes. et la réplication raft est bien syncro partout ?

osanchez · Answer

y'a pas un plugin particulier que vous utilisez ? un custom auth method ou un secrets engine qui pourrait être mal optimisé ? on a eu un souci similaire avec un secrets engine maison qui faisait trop d'appels externes synchrones.

gauthier-zacharie · Answer

côté consul les journaux d'audit et les snapshots peuvent aussi foutre le bordel en iops si mal configurés. c'est quoi le type d'instance ec2 pour consul ? du gp2/gp3 ? provisioned iops ?

edith18 · Answer

ok merci pour les pistes. j'ai run iperf c'est bon pas de souci réseau. par contre consul c'est du gp2 par défaut on a jamais touché. je vais regarder les iops on dirait qu'on est capsé à fond dessus

guichard-victor · Answer

ah gp2 par défaut sur de la forte charge consul c'est un classique. t'as ptete des bursts capacity qui s'épuisent. passe en gp3 avec des iops provisionnés ou de l'io1/io2. ça coute mais ça scale.

gauthier-zacharie · Answer

ouais +1 pour le gp3/io1. et n'oublie pas de monitorer les latences de consul lui-même, pas juste les iops brutes. il a ses propres métriques de performance.

edith18 · Answer

bon c'était bien ça les iops de consul. on est passé en gp3 avec 10k iops et le p99 est redescendu à 50ms. énorme merci la team vous m'avez sauvé la journée

Vault lent sur les read au dela de 10k req/s

9 commentaires

Laisser une réponse

Invitation à l’AWS Summit 2019

Utilisation des modules sur Terraform

WebAssembly au-delà du navigateur : Redéfinir l'Edge Computing et le Cloud Natif

L'IA Redéfinit l'Architecture Logicielle : Vers des Systèmes Auto-Conçus en DevOps

Fluid Computing : L'Ère des Architectures Adaptatives DevOps

Rejoindre la communauté