SREチームの長田です。 Advent Calendar Migration Track 22日目の記事です。
今回は弊社で運用しているLobiというサービスの、Webブラウザ版(Web版)をECSに移行したはなしです。
なぜ移行したのか
おなじみ、Amazon Linux1 EoL対応です。 すべてのアプリケーションをEC2から移行するプロジェクトの一環です。
移行前
LobiのWeb版はNuxtJSを使って実装されています *1。 各APIにリクエストし、サーバーサイドレンダリング(SSR)した結果を、Webブラウザに返しています。 NuxtJSアプリは他のアプリケーションも同居するEC2インスタンスで実行していました。
(実際にはクライアントで動的にコンテンツを更新するためのAPIリクエストも発生しますが、今回の話題には関わってこないので省略しています)
移行
設定値の切り分け
ECSに移行するにあたり、本番環境でも開発環境でも、同じコンテナイメージを使うというルールにしていました。 環境ごとにイメージを用意するのは管理コストがかかりますし、「本番環境と同じものが手元でも動く」(=デバッグしやすい)というコンテナの旨味が半減してしまいます。 どの環境でもイメージは同じものを使い、環境依存の値は実行時に環境変数として与えています。
NuxtJSはデプロイ前にアプリケーションをビルドする必要があります。 ビルド後の成果物をコンテナイメージに含めることになるのですが、nuxt.config.js内に環境変数を参照する設定値を書いてしまうと、 ビルド時点での環境変数が成果物に埋め込まれてしまいます。 EC2インスタンス上で動かしているうちは、
実行環境上でビルド → 成果物を配布してアプリケーション再起動
という手順をとっていたため、問題になっていませんでした。
環境変数を参照するということは、サーバーサイドレンダリング時に実行されるコードということです。 nuxt.config.jsに書く代わりに、Server Middleware内で環境変数を参照することで、アプリケーション実行時に設定値を渡すようにしています。
具体的には、SSR時にAPIリクエストするドメインがこれにあたります。 APIリクエスト先は環境によって異なるので、ビルド時に埋め込まれてしまっては困るというわけです。
デプロイの仕組み
EC2時代の手順は、以下のようになっていました。
- Github上でデプロイ対象のPull Requestをmasterにmergeする
- デプロイサーバー上でリポジトリをpullする
- デプロイサーバー上でNuxtJSアプリをビルドする
- アプリケーションサーバーにビルド成果物を配布し、アプリケーションを再起動する
(成果物の配布にはstretcherを使っているので間にS3 Bucketがいたりconsulがいたりするのですが、本筋ではないので省略しています)
ECSに移行することで、以下のように変わりました。
- Github上でデプロイ対象のPull Requestをmasterにmergeする
- CircleCIがmergeを検知してgit pull
- CircleCI上でNuxtJSアプリをビルドする
- CircleCI上でコンテナイメージをビルドしECRにpushする
- Task Definitionを更新しECS Serviceに反映する
手順が増えたように見えますが、CircleCIが行おう処理は自動で行われるので、人間が行う作業としてはほとんど変わりありません。
canaryデプロイの仕組み
少量のタスクを試験的にデプロイするcanaryデプロイの需要がありました。 EC2時代には、1インスタンスにのみデプロイ操作を行うことで実現していました。
ECSにはcanaryデプロイの仕組みはありません。 ひとつのECS Serviceについて、複数のTask Definitionを混在させることはできません。
そこで、1Taskしか起動しないECS Serviceを別途用意し、 それに対してデプロイを行うことでcanaryデプロイを実現しました。 メインのECS Serviceと同じTarget Groupに入れることで、全体の1/nのリクエストをcanaryタスクに回すことができます。
ちなみに、現在はALBでWeighted Target Groupsが使えるので、 canary用のTarget Groupを別途用意することで任意の割合だけリクエストを流すことができるようになりました。
メモリリーク問題
未解決の問題です。
ある時期から、NuxtJSアプリのメモリ使用量が上昇し続けるようになってしまいました。 一定を超えるとGCが走るのですが、実行コストが高く、HTTPリクエストに対するレスポンスに如実に現れてしまっていました。
根本的な解決方法としては、メモリリークの原因を突き止めて解消することなのですが、 これがどうにも解決できなかったので、「対処療法としてメモリ使用量が一定を超えたらECS Taskを入れ替える」という方法をとっています。
対象ECS ServiceのMemoryUtilizationメトリクスを元に、Alarmを発火させます。
発火情報はSNS Topicに送信されるので、Bash Layerで動いているLambda functionがそれを受け取り、
ECS Serivceに対して aws ecs update-service コマンドを実行しています。
おかげでメモリ使用量のグラフがこんな感じになってしまいましたが、現状致し方無いといった状況です・・・。
移行後
コンテナイメージをビルドする時点でつまずき、デプロイしてからもメモリリーク問題に苦しみ・・・と苦労が多かったプロジェクトでした。
副作用として良い効果もありました。 EC2インスタンス上で動かしていた頃は、「Googlebotの訪問が多すぎて同居している他のアプリケーションまでパフォーマンスが悪化する問題」があり、 botの訪問頻度を制限していました*2。 ECS Serviceとして独立してスケールするようになったことで制限を解除することができました。
Amazon Linux1 EoL対応はまだまだ残っています。 それらについてもいずれ本ブログで紹介する予定です。
*1:実はこの直前にAngularJSからNuxtJSに移行しているのですが、それはまた別の機会に・・・
