こんにちは、プロダクト開発部でバックエンドエンジニアをしている望月です。

Classiのサービスでは、先生や生徒がアップロードしたコンテンツファイルやWebテストなどの検索システムにおいてAmazon OpenSearch Service（以下、OpenSearch）を利用しています。
コンテンツファイルのメタデータやWebテストのデータ等はRDBでも保持しているのですが、以前検索におけるパフォーマンスが課題になった際にOpenSearchが導入されました。ユースケースとしては、Webテストの文章からの全文検索や、ファイル名・（オーナーの）ユーザー名等でのキーワード検索、カテゴリや属性ごとの検索などがあります。

今回はこのOpenSearchのアップグレード実施で行ったことや学びになったことをお話ししていきます。

アップグレード方法

AWSがマネージドサービスとして提供しているインプレースアップグレードがありますが、当時のOpenSearchのバージョンが古く対応していなかったため、新しくOpenSearchドメインを立てて移行する形を取りました。また、同時にOpenSearchを配置するネットワークの移行も実施しました。

今回、新旧OpenSearch間で移行したドキュメント数は約572万件でした。Classiの中でも比較的データ量の多いシステムで、移行に30時間程度必要という見積もりだったため、定期深夜メンテナンス（5時間）の中でデータ移行を含めた作業を完結させるのは厳しいという判断になりました。

新旧OpenSearchを並行稼働させて両方に書き込みを行う期間をもった上で切り替えるという案もありましたが、この登録処理でパフォーマンスに課題があり、処理を増やしたくないという理由で今回は採用に至りませんでした。

最終的に実施したのは、事前にデータ同期済みの新しいOpenSearchドメインをスタンバイさせ、定期夜間メンテナンスでは新旧OpenSearchの切り替えと、アップグレードに対応したクライアントアプリケーションのリリースのみを行う、という方法でした。

本番オペレーションの手順を詳細に書いてデモンストレーション

本番オペレーションは、以下のような手順で進めました。

新しいOpenSearchへ、事前に既存のデータを取り込む
- RDBのデータをもとに、クライアントアプリケーションから新しいOpenSearchへデータを再登録するスクリプトを実行
定期深夜メンテナンスまでは通常通りユーザーがサービスを利用しているため、新旧OpenSearch間で発生するデータ差分を定期的に同期
- RDBのデータの更新履歴をもとに、クライアントアプリケーションから新しいOpenSearchへデータを更新するスクリプトを定期的に実行
定期深夜メンテナンスで新旧OpenSearchを切り替え
- 新しいOpenSearchのバージョンに対応したクライアントアプリケーションのリリース
- クライアントアプリケーションが新しいOpenSearchへアクセスするよう切り替え
- QAの実施

大量のデータを扱うことには個人的にこれまで苦手意識があり、検証段階ではデータ再登録・更新時のスクリプトで意図しないタイムアウトが発生するなど苦労もありましたが、本番のオペレーションは大きな問題もなく終わらせることができました。

前述の通り、今回のOpenSearchアップグレードは定期深夜メンテナンスで作業を行う必要がありました。そして、定期深夜メンテナンスはおおむね月に一度の実施となっているため、本番でチャレンジできるタイミングが限られていました。
そのため、事前にオペレーション手順（データ移行・新旧OpenSearch切り替え・クライアントアプリケーションのリリース・ロールバック）をすべてチェックリスト形式で詳細に記述しておき、ステージング環境にてQAを行う際に何度かオペレーションの練習をしました。AWS環境に反映してみて初めて表出した事象もいくつかあったため、都度対応しながらオペレーション手順へ取り込んでいきました。

結果的にロールバックは実施しませんでしたが、手順を詳細に書いておくことで当日に落ち着いて作業を進められました。また、移行後のデータに追加で処理を走らせる際にも役立ちました。

システムと組織の依存関係に合わせてメンバーを巻き込む

今回最も難しかったのは、OpenSearchからユーザーまでの間に複数の機能コンポーネントが存在していて、それぞれ担当するチームが異なっていたことでした。大規模なシステムの場合、機能コンポーネントを複数扱うプロジェクトを進めていくのは技術的にも困難ですが、関係するメンバーの意向を確認しつつ進めていくことも大きな課題となるのではないでしょうか。

今回のケースですと、各機能コンポーネントを担当するチームは以下の通りでした。

OpenSearchを管轄するチーム
OpenSearchのクライアントアプリケーションを管轄するチーム
ユーザーから見える機能を管轄するチーム

最初私は1のチームメンバーとして作業を進めていましたが、検証環境を作るにあたっては2のチームメンバーに相談相手やレビュワーになってもらいました。また、リリースするにはユーザーから見える機能がちゃんと動いているかどうか確認するプロセスが必要だと思い、3のチームメンバーに協力をお願いしたり、自分がチーム移籍したりして作業を進めました。
また、OpenSearchの切り替え後に発覚したデータ不整合において今回の移行が起因であるかどうかの調査を行うことがあり、こちらもチーム間で連携して過去の経緯を追いつつ調査を行いました。