オンプレのアンケートシステムからクラウドへの切り替えをいい感じにデプロイした話

こんにちは、エムスリーエンジニアリングGの佐々木です。

BIRというチームでアンケートシステム周りの開発を担当しています。

BIRでは新規のアンケートシステムを作ったりする傍、昔から稼働しているオンプレ上のアンケートシステムのクラウド移行を進めています。今日は、昔に作られたレガシーなアンケートシステムをオンプレからクラウド移行する際に少し工夫をしたことで安全にリリースできた話をしたいと思います。

システム構成

参考までに、システム構成です（利用言語やFWは参考で、今回の話とはあまり関係ありません。。）

移行前のシステム
- オンプレのアプリケーションサーバ（Java, Spring Boot）
- DB: RDS （DirectConnectでオンプレと接続）
移行後のシステム
- AWS上のアプリケーションサーバ（サーバサイドKotlin, Quarkus）
- DB: RDS

また、移行前、移行後共に認証はチーム内のチャネルシステムを利用しています。

JWTをチャネルシステムが発行し、M3の認証から切り離す方式を取っている。
JWTを受け取ったあとはページ単位でアプリケーションサイドでセッションを維持
チーム内のシステムは全てその構成を取っている

やったこと

この構成の場合、通常だと

新システムをデプロイする
チャネルシステムを切り替えることでリリースする

という手順をとると思います。チャネルシステムが認証を担当しているので、そこを切り替えなければシステムとして動作（今回の場合はアンケートの回答）ができないためです。一方で今回の場合既に利用ユーザが多数存在しているサービスであったため、なるだけ小さな単位でリリースを進めて行きたいという思いもありました。そこで、チャネルシステムの向き先を変更するのではなく、

新システムをデプロイする
オンプレのシステムのhtmlを返すエンドポイントにクラウド側のシステムへのリダイレクトの追加をリリース（※ここでオンプレシステムへのリクエストに含まれるJWTトークンもリダイレクトのリクエストに含めるようにする）
2のリリース後落ち着いたタイミングでチャネルシステムの向き先を変更する

といった手順でリリースを実施しました。JWTトークンの検証をオンプレ・クラウドで同じ公開鍵を用いて行なっているため、この方式でも認証を行うことができました。以下の図は2番の工程の実施の前後を表しています。

f:id:i-ssk-m3:20210330110116p:plain

よかったこと

正直間に工程が一個増えるだけで、チャネルシステムの向き先を直接変更するのとそれほど変わらなくない？と思われるかもしれないですが、以下のような利点があったと思います。

リリース後に障害があった場合の切り分けが容易
チャネルシステムを切り替えるのに比べ、一度に本番に出る新しい変更が少ないためリリース後の切り分けが容易となります。
QA環境での切り替えも範囲が少ないためQAの実施がスムーズ
- M3にはQA環境が存在し、リリース前にそこでQAを行うのですが、チャネルシステムの変更は多システムに影響があるため順番待ちが発生することがありました。
- 今回の方法をとる場合、チャネルシステムには変更が入らないため順番待ちが発生せず、オペレーションをスムーズに進めることができました。

また、以下の利点はチャネルシステムを切り替える方法でも同様ですが、アプリケーションに大きく手を入れることなくこのリリースを実施できます。