クラスターのバージョンアップを実施しましたはじめにこんにちは、狩野と申します。氏の24曼荼羅(不死MANDALA)ライブ開催が決定されました。第9曼荼羅のライブDVDの発売決定しましたので、ありがたく発売日を待っております。EOLなElasticsearchのバージョンアップ先日Misocaで利用しているElasticsearchクラスターのバージョンアップと関連Gemのアップデートをリリースしました。それまでのMisocaではEOLとなってしまった5系のバージョンを使用しておりました。最新に追従できていない現状と、今後の機能追加・改善にElasticsearchを採用しにくくなっている懸念があったためElasticsearchのメジャーバージョンアップと関連Gemのアップデートを行いました。アップグレード方針として5系から7系に直接上げず、一旦6系の最新にアップグレードしてから7系に上げました。これはGemとElasticsearch本体のChangelogを調査した時に想像以上に変更が多く、問題発生時の原因切り分けが難しくなることが予想できたためです。結果的な話ではありますが、6から7へアップグレードする際に切り戻し対応を行いましたので、その際に原因究明のスコープが小さくなり早急な対処に繋がったため良い方針だったと感じました。本記事ではバージョンアップに際して工夫した以下の2点について記載します。Serviceを利用しています。リリース方式の策定のために2つの方法を検討しました。今回は「新旧クラスタを準備し切り替える方式」を採用しました。「サービスソフトウェア更新」機能を利用する場合ESクラスターがアップグレードされるタイミングはAWS側に委ねられてしまいます。アプリケーションのGemバージョンとESクラスターのバージョンを一致させつつサービス無停止を実現するには「新旧クラスタを準備し切り替える方式」が必要という結論になりました。新旧クラスタを準備し切り替えるリリース方式をかいつまんで説明します。リリース前の状態が下図になります。flagによって実現しました。flagの説明はこちらのMisocaのブログ記事をぜひ御覧ください!またES6.xのクラスタを準備し事前に同期できるデータについては同期を実施しました。Elasticsearch側の準備はできたのでアプリケーションサーバ側の更新を行います。サーバ更新中に発生した差分を同期させます。flagによって一時的に検索参照先をMySQLにしていたのを元に戻すことでバージョンアップ完了です。切り戻しを含めた詳細なリリース手順の作成とリハーサル上記の方式ではリリースフェーズ毎にどちらのESクラスターにアプリが接続しているかや不整合なデータをユーザーに表示させていないかが分かりづらくなります。当たり前のことですが入念に作業手順書をしっかりと書いておきリハーサルも行いました。リリース時に想定しなかったエラーが起こってしまいましたので切り戻しを行いました。*1作業手順書には切り戻し時の対応も準備しておきましたし、切り戻しのリハーサルも行っていたためユーザーへの影響無く切り戻しできました。ESが新しいバージョンを提供したかを確認する日を半年に1回のペースでカレンダーで登録し、人力で気付けるようにしました。良い方法があると嬉しいな〜というきもちです。ESの「サービスソフトウェア更新」機能使えるなら使いたいね、という計画をしています。https://www.wantedly.com/projects/28443*1:切り戻しの原因としては、インデックスへのデータインポート時にTimeoutエラーを起こしてしまうことでした。データインポート処理のバッチサイズを削減したり、非推奨とされているT2インスタンスを使わずT3インスタンスに切り替えることで解決しました。