こんにちは！🦸♀️
フリュー株式会社の森田つかさです！
今回は社内サーバで稼働していた複数の社内ツール(Webアプリケーション)を、
ECS on Fargate化した時につまずいたことをまとめてみました。
問題『指定したポート番号でヘルスチェックが通らない』
まず既存の社内ツールをコンテナイメージ化してローカルで起動してみることから始めました。
すでに社内ツールが使用しているアプリケーションポート番号をそのまま使いました。
docker run -d -p 1234:1234 …
特に気にせずコンテナポート番号もアプリケーションポート番号と一緒にしてローカル起動できました。
よし！このコンテナイメージとポート番号を使って起動するように、
タスク定義を作成してECS on Fargateで起動だ！
CloudFormationでリソース作成処理を行っていたのですが、
待てども待てどもスタックステータスがCREATE_COMPLATEになりません。
ECSサービスイベントを確認すると、
ALBのヘルスチェックに何度も失敗してECSのタスクの作成を繰り返していることに気づきました。
調べたところ、Fargateで実行する場合、
ネットワークモードはawsvpc一択で、ポート番号は80固定だそうです！
docs.aws.amazon.com
まじか！！！！！
ということでアプリケーションとコンテナのポート番号を80に統一することで解決しました。
問題『またヘルスチェックが通らない』
問題『指定したポート番号でヘルスチェックが通らない』を解決したのでスムーズに進むと思っていたら、
またALBのヘルスチェックが通らずECSのタスクの作成を繰り返すようになってしまいました。
「ポート番号80にしたのに…」
とりあえず何がなんだかわからないのでCloudWatchログとCloudFormationのイベント履歴を確認しました。
するとアプリケーションの起動が終わる前にALBのヘルスチェックがきてしまっており、
ヘルスチェックが失敗しているではありませんか！
どうやら今回対応した社内ツールは起動完了までに時間がかかってしまう代物だったようです。
調べてみたところ、ECSサービス定義パラメータにhealthCheckGracePeriodSecondsという
「指定した期間はヘルスチェックの結果を無視する」パラメータが存在するのを発見しました。
ということでアプリケーションの起動時間を考慮してhealthCheckGracePeriodSecondsパラメータを設定することで解決しました。
問題『ログインしても未ログイン扱いになってしまう』
※この問題はECSではなくALB設定のお話になります
ログインが必要な社内ツールをECS on Fargate化して動作確認を行うと、
何度ログインしてもログイン後ページに遷移せずログインパスワード入力ページに戻ってきてしまう問題が発生しました。
ログインパスワードを間違えたわけでもなさそうです。
チームメンバーに相談してみたところ、
「セッション情報が共有できていないのでは？」
という仮説が立ちました。
そこで社内ツールのセッション情報保持方法を調べると、オンメモリで保存していることがわかりました。
ECS on Fargate化に伴って必ず2つのコンテナを起動し、ALBでバランシングするようになっていたため
セッション情報のないコンテナにアクセスがふられてログイン後ページに遷移できなかったのです。
社内サーバで稼働していた時はサーバが1台だったのでこのような問題は起きていなかったというわけです。
さすがに社内ツールを改修せずにこの問題を解決する手段はないだろうと思ってましたが
Application Load Balancerのスティッキーセッションを見つけました！
条件に応じて特定のターゲットにアクセスを流してくれるってことですね！素敵！
今回は社内ツールの特徴に合わせて期限ベースのCookieを活用するように設定することで解決しました。
全体をふりかえって
CloudFormationでリソース作成が終わり切っていない状態で、
設定に問題があることに気づいてもリソース作成を停止することができず、
スタックステータスがROLLBACK_COMPLETEになるまでの時間がとても長く感じました。
healthCheckGracePeriodSecondsの時間を調整した時は時間を極端に長くすると、
終わるのが遅く結果を待つのに45分かかることもありました。
適当に長くすりゃいいってもんでもないですね。反省しました。
最後までお読みいただき、ありがとうございました。
