Comment Uber construit des clusters OpenSearch résilients à la panne de zone

Uber publie sa recette pour tenir OpenSearch quand une zone AZ tombe. Pas d'IA magique - de la topologie, du placement de shards et du drill régulier.

Le fait

InfoQ publie (17 juillet 2026) un retour d'expérience d'Uber sur la construction de clusters OpenSearch résilients aux pannes de zone (AZ). L'article détaille les patterns de placement, de failover et de test - et précise qu'Uber empile un système « isolation-group » maison sur la plateforme d'orchestration conteneurs Odin au-dessus des primitives OpenSearch.

Notre lecture

Deux points à retenir. Le placement zone-aware est un travail d'ingénierie, pas une case à cocher. OpenSearch ne redistribue pas magiquement les shards après une panne d'AZ - la topologie doit être pensée en amont (allocation awareness, forced awareness, réplicas par zone). Uber détaille les hooks concrets, avec l'apport de son propre système d'isolation-groups posé sur Odin - ce qui manque à 90 % de la doc en circulation.

La discipline du drill fait la différence. Prévoir la panne est facile ; la répéter en pré-prod, moins. C'est ce que la vague harness/plateforme (voir #1211 sur QCon AI Boston) ramène côté IA : le drill continu, appliqué à l'infra recherche depuis dix ans, devient la norme pour les agents en prod.

À surveiller

L'approche Uber (OpenSearch + isolation-groups + Odin) est transposable à d'autres data stores distribués (Cassandra, Kafka). Pour les équipes qui bâtissent la couche RAG/vector au-dessus d'OpenSearch : la résilience zone se joue en amont de l'embedding - la couche IA hérite du plancher que sa base pose.