Uberはどのようにしてゾーン障害に耐性のあるOpenSearchクラスターを構築しているか

UberはAZ障害時にOpenSearchを維持するレシピを公開。魔法のAIではなく、トポロジー、シャード配置、定期的なドリル。

事実

InfoQが（2026年7月17日）Uberによるゾーン障害（AZ）に耐性のあるOpenSearchクラスター構築のケーススタディを発表。記事では、配置、フェイルオーバー、テストのパターンを詳述し、UberがOdinコンテナオーケストレーションプラットフォーム上に独自の「isolation-group」システムをOpenSearchのプリミティブに重ねていることを明記。

考察

注目すべき2点。

ゾーン認識配置は、チェックボックスではなく、エンジニアリングの成果物。OpenSearchはAZ障害後にシャードを自動再配置しない。トポロジーは事前に設計する必要があり（allocation awareness、forced awareness、ゾーンごとのレプリカ）。UberはOdin上に構築したisolation-groupシステムを通じて具体的なフックを提供しており、これは流通しているドキュメントの90%で欠けている部分だ。

演習の disciplina が差を生む。障害を想定するのは簡単だが、それを前提環境で繰り返すのは難しい。QCon AI Bostonの#1211でも触れたように、波及するハーネス/プラットフォームは、AI分野にこの考え方を持ち込む。10年以上にわたり検索インフラに適用されてきた継続的な演習が、プロダクションのエージェントにとっても標準となる。

見逃せない

Uberのアプローチ（OpenSearch + isolation-groups + Odin）は、他の分散データストア（Cassandra、Kafka）にも転用可能。OpenSearch上にRAG/ベクトル層を構築するチームへ：ゾーン耐性は埋め込み処理よりも上流で決まる。AI層は基盤が築く土台を継承する。