はじめに
こんにちは、狩野と申します。 平沢進 氏の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点について記載します。
- サービス無停止でのバージョンアップが可能なリリース方式の検討
- 切り戻しを含めた詳細なリリース手順の作成とリハーサル
🦍 サービス無停止でのバージョンアップが可能なリリース方式の検討
MisocaではAmazon Elasticsearch Serviceを利用しています。 リリース方式の策定のために2つの方法を検討しました。
- Amazon ESの「サービスソフトウェア更新」機能を利用する方式
- 新旧クラスタを準備し切り替える方式
今回は「新旧クラスタを準備し切り替える方式」を採用しました。選んだ理由としては
- elastic/elasticsearch-ruby gemのメジャーバージョンとESクラスタのメジャーバージョンを一致させる必要があるため
- サービス無停止リリース
- 何かあったときの切り戻しが容易
「サービスソフトウェア更新」機能を利用する場合ESクラスターがアップグレードされるタイミングはAWS側に委ねられてしまいます。アプリケーションのGemバージョンとESクラスターのバージョンを一致させつつサービス無停止を実現するには「新旧クラスタを準備し切り替える方式」が必要という結論になりました。
🔄 新旧クラスタを準備し切り替える
リリース方式をかいつまんで説明します。リリース前の状態が下図になります。
リリース事前準備として、通常時の検索であればElasticsearchからデータを取得しますが、一時的にMySQLを参照する機能をfeature flagによって実現しました。
feature flagの説明はこちらのMisocaのブログ記事をぜひ御覧ください!
またES6.xのクラスタを準備し事前に同期できるデータについては同期を実施しました。
Elasticsearch側の準備はできたのでアプリケーションサーバ側の更新を行います。 またサーバ更新中に発生した差分を同期させます。
feature flagによって一時的に検索参照先をMySQLにしていたのを元に戻すことでバージョンアップ完了です。
上記の作業では5から6へアップグレードしていますが、同様のことを6から7へとアップグレード時にも実施し、現状ではAmazon Elasticsearch Serviceが提供している7系の最新に更新できました 🎉
📑 切り戻しを含めた詳細なリリース手順の作成とリハーサル
上記の方式ではリリースフェーズ毎にどちらのESクラスターにアプリが接続しているかや不整合なデータをユーザーに表示させていないかが分かりづらくなります。
なので当たり前のことですが入念に作業手順書をしっかりと書いておきリハーサルも行いました。
リリース時に想定しなかったエラーが起こってしまいましたので切り戻しを行いました。*1
作業手順書には切り戻し時の対応も準備しておきましたし、切り戻しのリハーサルも行っていたためユーザーへの影響無く切り戻しできました。
🌈 現状と今後
Amazon ESは今後のESバージョンのリリース予定日や古いバージョンのEOL日を提供していないため、Elastic社側のEOLやAmazon ESが新しいバージョンを提供したかを確認する日を半年に1回のペースでカレンダーで登録し、人力で気付けるようにしました。
ただもっと良い方法があると嬉しいな〜というきもちです。情報いただければ幸いです 🙏
今後は、よりよいチューニングやログ監視をしたいね、Amazon ESの「サービスソフトウェア更新」機能使えるなら使いたいね、という計画をしています。
📡 宣伝
Misoca開発チームではElasticsearchのことなら俺に任せろ!なエンジニアを募集しています! https://www.wantedly.com/projects/28443
*1:切り戻しの原因としては、インデックスへのデータインポート時にTimeoutエラーを起こしてしまうことでした。データインポート処理のバッチサイズを削減したり、非推奨とされているT2インスタンスを使わずT3インスタンスに切り替えることで解決しました。