Elasticsearch on EKS から Amazon OpenSearch Service にダウンタイムなしで移行した話

OpenSearch Tokyo meetup #2 で話した資料です。
https://www.meetup.com/ja-jp/opensearch-project-tokyo/events/316849624/

Elasticsearch on EKS の運用はつらい話と、ゼロダウンタイムで移行するための簡単な工夫について紹介しています。

Transcript

1. OpenSearch Tokyo meetup #2 から に ダウンタイムなしで移行した話 Elasticsearch on EKS Amazon OpenSearch Service Oct.21 2026 - Hayato Kawai (@fohte) © 2026 Wantedly, Inc.
2. 自己紹介 名前 ふぉーて) 川井 颯人 (Hayato Kawai) Fohte ( 所属 • ウォンテッドリー株式会社 、前 Infra Squad • Visit Recommendation Squad (MLOps) アカウント •   @fohte © 2026 Wantedly, Inc.
5. 持ち帰ってほしいこと • OpenSearch への移行は、思っているほど難しくない クエリの書き換えはほぼ機械的で、コーディングエージェントに任せられる ◦ 読み書きを段階的に切り替えれば、ES への書き込みを止めるまではいつでも戻せる ◦ • index ◦ のデータは、DB からいつでも作り直せるようにしておく 何らかの理由で index のデータが失われても復旧でき、移行のときもデータをコピーせずに 済む © 2026 Wantedly, Inc.
6. CONTENTS なぜ Amazon OpenSearch Service に移行するのか 02 ダウンタイムなしで移行する戦略 03 アプリケーションで OpenSearch 移行に追従する 04 (余談) Blue/Green 時に障害が起きた話 01 © 2026 Wantedly, Inc.
7. 01 なぜ Amazon OpenSearch Service に 移行するのか © 2026 Wantedly, Inc.
8. OpenSearch は、Wantedly のさまざまな検索に使っている • Wantedly Visit ◦ 企業が、スカウトを送りたい候補者を条件で絞り込んで探す機能 • Wantedly Visit ◦ のスカウト検索 のユーザー検索 名前などからユーザーを探す機能。つながりのある人を優先して表示する © 2026 Wantedly, Inc.
9. Elasticsearch を EKS 上で自前運用するつらみ を使わず、StatefulSet の manifest を自前で書いて 動かしていた • EKS の Node を入れ替えるたびに、shard の再配置を数時間待つ 必要があった • operator © 2026 Wantedly, Inc.
10. Node を入れ替えるたびに、shard を移し切るまで数時間待っていた primary Pod 1 Pod 2 Pod N replica shard をコピー 他の Pod 停止 C A C 再作成 コピーに時間がかかる Pod 1 A 停止不可 A の replica を保持 止めると replica が減る 停止不可 shard をコピー 他の Pod 停止 B A B 再作成 Pod 2 A C 全 Pod を入れ替え終えるまで 3〜6 時間 © 2026 Wantedly, Inc. shard をコピー 他の Pod 停止 B C B 再作成 Pod N
11. 02 ダウンタイムなしで移行する戦略 © 2026 Wantedly, Inc.
12. 構成図の上で変わったのは、クラスタの置き場所と IAM の署名だけだった 移行前 EKS クラスタ 移行後 EKS クラスタ アプリ アプリ 読み書き 読み書き 自前 ES StatefulSet IAM (SigV4) Amazon OpenSearch Service EKS © 2026 Wantedly, Inc. の外 (マネージド)
13. ES のデータは、毎日動いている全件バッチで DB から作り直せた アプリ DB 全件読み出し 全件再送バッチ 更新のたび 毎日実行 書き込み経路 Pub/Sub 全件送信 購読 subscriber © 2026 Wantedly, Inc. 書き込み ES
14. ダウンタイムなしで切り替えるために dual write shadow read アプリ アプリ write write read ES write read OpenSearch ES 切替 ES write しばらくこの状態 アプリ write write shadow OpenSearch 戻せる範囲 (ES も最新) © 2026 Wantedly, Inc. read アプリ write write read ES 停止 OpenSearch read ES OpenSearch
15. dual write: ES/OS 両方に書き込み、read は従来どおり ES から は従来どおり Elasticsearch から • OpenSearch にも裏で同じデータを 書き込んでおく • OpenSearch への書き込みは非同期にし、 失敗してもエラーを返さないので、read には 影響しない ◦ 書き込めなかったデータは 全件再送バッチで補う • この書き込みの処理はアプリケーション側で 実装した • read アプリ write write read ES OpenSearch © 2026 Wantedly, Inc.
16. shadow read: 負荷検証のために本番の検索を OpenSearch にも流す アプリ write write read ES 検索結果をキャッシュしているサービスなどで 負荷検証が難しかった ◦ OpenSearch に対して直接リクエストを 投げても、本番の負荷は再現できない • そこで、本番の read のリクエストを裏で OpenSearch にも送るようにした • shadow OpenSearch © 2026 Wantedly, Inc.
17. read 切替: OpenSearch に切り替え、ES への書き込みは続ける アプリ を OpenSearch に切り替える • 障害時に Elasticsearch へ戻せるよう、 Elasticsearch への書き込みは dual write と 同じ方式で続ける • read write write read ES OpenSearch © 2026 Wantedly, Inc.
18. ES への write 停止: OpenSearch だけを使う アプリ 十分な期間をおいてから、ロールバック用に 残していた Elasticsearch を止める • ここで OpenSearch への移行が完了 • write read ES OpenSearch © 2026 Wantedly, Inc.
19. ゼロダウンタイムでの移行が成功した要因 • ウォンテッドリーでは、Elasticsearch のデータはすべて DB から 構築していたことも、今回の移行が簡単に済んだ理由のひとつ ◦ • これがなければ、たとえば Elasticsearch のデータを OpenSearch にコピーする仕組みを 作る必要があるなど困難だったはず 全データを DB から作り直すバックフィルがあったので、dual write では OpenSearch への書き込みの失敗を無視できた バックフィルがあれば、何らかの理由で index のデータが失われても、DB から作り直して 復旧できる ◦ 失敗してもバックフィルで補え、サービス特性上リアルタイム性は求められなかったことも 移行を容易にした ◦ © 2026 Wantedly, Inc.
20. 03 アプリケーションで OpenSearch 移行に 追従する © 2026 Wantedly, Inc.
21. アプリの書き換えは、ほとんどが機械的な置き換えで済んだ クライアント実装を OpenSearch の公式ライブラリに置き換える 程度だった • 置き換える量は多くなく、コーディングエージェントにも 任せられたので、負担は小さかった • dual write や shadow read の切替と、認証認可の変更は、 アプリケーション側で実装した • © 2026 Wantedly, Inc.
22. fine-grained access control では、ロールごとに触れる index を決められる ネットワーク ドメインのアクセスポリシー fine-grained access control IAM アプリ ロールで署名 © 2026 Wantedly, Inc. IAM ロール 対応付け OpenSearch 読み書き ロール index A 例 ( ) 拒否 index B
23. 余談) Blue/Green 時に障害が起きた話 04 ( © 2026 Wantedly, Inc.
24. マネージドサービスでは定期的なクラスタ更新がある いままでの Elasticsearch on k8s の構成では、自分たちで クラスタ更新のタイミングを決められた • 一方で Amazon OpenSearch Service では、クラスタ更新の タイミングは不定期かつ頻度も高い • ◦ 更新の時間帯は指定できるが、選べるのは 1 日 10 時間の枠の開始時刻だけ © 2026 Wantedly, Inc.
25. クラスタ更新では Blue/Green デプロイが行われる デプロイでは、旧クラスタを残したまま新しい クラスタを作り、DNS を切り替えてトラフィックを新クラスタに 流す • Blue/Green デプロイはメンテナンスウィンドウ中に行われ、 ユーザーは基本的に意識しなくてよい • Blue/Green © 2026 Wantedly, Inc.
26. Blue/Green • の最中に、Go のアプリから OpenSearch が数分間応答しなくなった ところが、Go で OpenSearch にアクセスしている アプリケーションだけ、Blue/Green の最中に検索が 数分間応答しなくなった © 2026 Wantedly, Inc.
27. Blue/Green の最中に、Go のアプリから検索が数分間応答しなくなった Go アプリ エンドポイント opensearch-go AWS が管理する DNS 旧クラスタ blue 新クラスタ作成 DNS 張ったままのコネクション) timeout: リクエストのみ取消 コネクションは残る retry (同じコネクション) 新クラスタ を新クラスタに切替 request ( コネクション切断 DNS 引き直し 応答なし 旧クラスタ削除 新クラスタに新しいコネクション © 2026 Wantedly, Inc. green
28. AWS に相談し、opensearch-go に修正が入った のスペシャリストと、隔週で定例ミーティングをしている • そこで相談したところ、ソリューションアーキテクトの山崎さんに opensearch-go へ issue を起票していただき、修正が入った • AWS ◦ issue: opensearch-project/opensearch-go#1121 ◦ PR: opensearch-project/opensearch-go#1134 • Special Thanks to © 2026 Wantedly, Inc. 疋田 宗太郎さん、山崎 宏紀さん
29. opensearch-go v4.8.0 Go アプリ opensearch-go から、タイムアウトした接続を使わずにつなぎ直すようになった エンドポイント AWS 旧クラスタ が管理する DNS blue 新クラスタ作成 DNS 新クラスタ green を新クラスタに切替 request timeout (RequestTimeout) 次のリクエストの後に閉じる retry 1: 同じコネクションで送る 応答なし timeout (RequestTimeout) コネクションを閉じる retry 2: DNS 引き直し 新クラスタの IP 新しいコネクション 旧クラスタ削除 © 2026 Wantedly, Inc. deadline
30. 持ち帰ってほしいこと • OpenSearch への移行は、思っているほど難しくない クエリの書き換えはほぼ機械的で、コーディングエージェントに任せられる ◦ 読み書きを段階的に切り替えれば、ES への書き込みを止めるまではいつでも戻せる ◦ • index ◦ のデータは、DB からいつでも作り直せるようにしておく 何らかの理由で index のデータが失われても復旧でき、移行のときもデータをコピーせずに 済む © 2026 Wantedly, Inc.
31. We're hiring! を支える技術基盤をつくる インフラエンジニア / SRE 募集 Wantedly wantedly.com/projects/522096 © 2026 Wantedly, Inc.