こんにちはプロダクト基盤本部 SREの藤原です。
STORES のID基盤は2023年5月末にEC2ベースからECS（Fargate）ベースに移行しました。
ID基盤では踏み台、APIサーバー、バッチサーバーなどをすべてECSのタスクへと移行しました。 本エントリでは、移行対象のうち、APIサーバー部分に絞って切り替えを進める上でのアーキテクチャ上の検討ポイントや切り替え手順を検討する際の考慮事項を解説します。
切り替え前の構成
STORES のID基盤のAPIサーバーのインフラ構成は下図のとおり非常にシンプルな構成です。
フロントエンドのホスティングにAmplifyホスティングを利用し、バックエンドとしてアプリケーションロードバランサー、EC2インスタンス、データベースにAmazon Auroraを利用しています。
今回は、EC2インスタンスをECS（Fargate）に切り替えました。
ECS移行にあたっての制約事項
STORES のID基盤は、さまざまな商いをされている多くの方に重要なものです。 ID基盤が停止してしまうと、それらの方々の業務を止めてしまうことにも繋がります。
このような理由から、可能な限りシステムとしての停止時間を短くする必要があります。 また、移行作業に問題が発生した場合、確実な切り戻しができなければいけません。
つまり、重視すべきポイントは以下の2つです。
- 切り替えに伴う停止時間は可能な限り短くすること
- ECS環境に問題が見つかった場合、容易にEC2環境へ切り戻せること
上記を前提としておきつつ、ECS環境への移行に向けた構成や手順を考えました。
構成上の考慮ポイント
EC2環境からECS環境に移行する際、重要なポイントはどこで切り替えるかです。 切り替えるポイントの選択次第でできることが大幅に変わります。
今回切り替える対象はEC2インスタンス群です。 これをECSタスクに置き換えます。
切り替えのポイントとしては2つの候補が上がりました。
それぞれの方法について具体的に解説します。
案1. ロードバランサー配下で切り替える
最初の案はロードバランサーに紐づけられているコンピューティングリソースをEC2からECSへと切り替えてECS環境への切り替えを実現する方法です。 イメージ的には次に挙げる図のようになります。利用者発のリクエストはロードバランサーまでは同じところにアクセスし、その後のリクエストの転送先が変わる形になります。
DNSの操作といったストレスフルな作業がない点などがメリットと言えるでしょう。
もう少し具体的に解説します。 AWSのアプリケーションロードバランサーにおけるリクエストの転送先設定は、リスナーで定義します。 EC2インスタンスやECSタスクにリクエストを転送する際は、それらを束ねるターゲットグループをリスナーの転送先として定めます。 本案では、既設のEC2を束ねているターゲットグループをECSタスクを束ねているターゲットグループに置き換えることでEC2環境からECS環境への切り替えます。
ただしこの方法では、ID基盤の利用者のリクエストが動作確認をする間もなく即座に流れ込んできてしまう点に注意が必要です。 リスナールールを作り込めば回避可能ですが、リスナー設定が複雑になること、作業手順が煩雑になることなどに留意しなければいけません。
案2. DNSレコードを修正して切り替える
もうひとつの案は、Route 53のレコードを修正して切り替える方法です。
先の案とは異なり、ECSタスクだけでなく、ロードバランサーも含めて準備します。 Route 53のレコードを修正してリクエストの向きを変更してリクエストの処理を行っている環境をEC2からECSへと切り替える方法です。
切り替え後はID基盤の利用者から届くリクエストは、新規構築したロードバランサーにルーティングされる点で案1とは大きく異なります。
どちらを選択するか
今回の切り替えに際しては案2、つまりDNSレコードを利用して切り替える方式を選択しました。 主な理由としては、以下の2つです。
- 切り替え前の動作確認をより安全に実施できる
- IaCで管理されている領域とそうでない領域を可能な限り混在させたくない
もう少し掘り下げてそれぞれの理由を解説します。
1については、ロードバランサーをEC2環境とECS環境で共有しないことがポイントです。 利用者からのリクエストを処理しているEC2環境向けのロードバランサーとは別にECS環境のロードバランサーが存在しています。 つまり、切り替えの瞬間までは利用者からのリクエストはEC2環境で処理をしつつ、その裏側でECS環境の動作確認を実施できます。
2については、コンピューティング環境に限らない周辺的な事情です。 ID基盤ではインフラストラクチャについても、なるべくコード管理する方向で対応を進めています。 EC2環境はサービスリリース初期から存在しているものであり、TerraformやCDKなどのIaCツールの管理配下にはありません。 よって、ロードバランサーもIaCツールの管理配下にはありません。
EC2環境をIaCツール管理配下に含めたのち、ECS移行することも考えました。 しかし、将来的に除却予定のリソースをツールの管理配下に含めることは、かけた手間に対してメリットが小さいと判断しました。 また、ロードバランサーのみを改めてIaCツール管理配下に入れた上で管理することもあまりメリットがないかつ、切り替えに伴う作業設計が複雑になることもありデメリットが目立ちます。
DNSレコードを利用しての切り替え詳細
DNSレコードを利用して切り替える際の手順についてもう少し掘り下げて見ましょう。
EC2環境でID基盤利用者からのリクエストを処理しつつ、切り替え作業者はその裏側で、curlなどのコマンド1を使って動作確認をしました2。
このような形で、動作確認を実施することでID基盤利用者のリクエストはEC2環境に流しつつ、別経路でECS環境の動作確認が十分に時間をかけて実施できます。 じっくりと時間をかけて動作確認を実施てきたため、DNSのレコードを修正してID基盤利用者のリクエストをECS環境に流す際もうまくいくであろう確信をもって切り替えることができました。
また、ECS環境に問題が発生した場合もDNSレコードを元に戻すだけで、EC2環境に再度リクエストを流すようにすることで対処できる点も安心して切り替えを実施できます。
補足: 切り替え作業時の注意点(WAFの取扱い)
WAFを活用する上で入れておきたいファイアウォールのルール定義にもあるとおり、 STORES のID基盤ではホスト名が意図したものでない場合はアクセスをブロックするようにしています。
したがって、そのままではAWSがALBに割り当てたFQDNを使って動作確認するにはWAFを取り外す3必要があります。
つまり、動作確認中はWAFでAPIは保護されておらず、少ないながらもリスクが高まっている状態です。 したがって、動作確認中は切り替え作業者のみがECS環境にアクセスできるよう、インターネット向けに全体公開するのではなく作業実施者のみがアクセスできるよう制限した上で動作確認を実施しました。 もちろん動作確認の完了後には、WAFを再度取り付け、インターネット向けに全体公開してから切り替えを実施しています。
まとめ
今回のECS環境への切り替えに際して、以下のようなポイントを重視しました。
- 切り替えに伴う停止時間は可能な限り短くすること
- ECS環境に問題が見つかった場合、容易にEC2環境へ切り戻せること
さらに、切り替えポイントとして、ロードバランサーの設定変更ではなく、DNSレコードの修正を選択することで確実な動作確認を実施できるようにしました。
こういったコンピューティング環境の切り替えなど大きめの変更作業は精神的に大きなストレスを伴うものです。 今回のような構成をとることで、十分な時間を動作確認のために確保できました。 作業時の精神的なストレスも減らすことができ、精神的な余裕から作業の品質も高まったのではないかと考えています。
本エントリはEC2からECSへの切り替えに限った例ですが、環境構成を変更するための手段として、いくつかの候補があった場合にどう選択するのかという部分でも参考にしていただけると幸いです。
