概要
ECS Fargateがリリースされてから検証・導入を進めています。
インスタンスの管理をする必要がなくなり非常にメリットを感じている一方、本番環境で使う上で注意すべき点もあるのでそこをまとめます。
環境
- Fargateプラットフォーム 1.2.0
問題点
dev, stg環境で検証してみて、現状感じている問題点を挙げていきます。
同一タスク内のコンテナの起動順序を制御できない
通常のECSではTask Definitionにあるlinks機能によって起動順序をある程度制御できます。
例えば
コンテナA links コンテナB
だとすると、コンテナBの方を先に起動してくれます。
しかしFargateではlinks機能がそもそもないので、こういった起動順序を制御することができません。
例えばConsul agentを先に起動してアプリケーションサーバはそのConsulから別のマイクロサービスのIP群を取得しようと考えても起動順序が制御できないためアプリケーションサーバが先に起動してしまい失敗する、ということが起きます。
もちろんアプリケーション側で起動を待つといったハンドリングすることはできますが、できればビジネスロジック以外の要素は省きたいものです。
SIGKILLの発火タイミングを調整できない
のユースケースでも述べたように、アプリケーションサーバはコネクションの適切に切断するなどの後処理をしてから終了する必要があります。
通常のECSの場合はECS_CONTAINER_STOP_TIMEOUTという環境変数によって設定ができましたが、Fargateではそれが使えずデフォルト値の30秒後にSIGKILLが呼ばれます。
なのでもし後処理に時間がかかったとしても強制的に終了してしまいます。
通常のECSよりも起動がやや遅い
各コンテナがIPを持つ＝各コンテナにENIがプロビジョニングされてから起動するので、予めENIが作成されている通常のECS（awsvpcモードでない）の方が起動が早かったりします。
ただしこれはインスタンス側のスケールアウトを待つ必要がないので、それを含めて考えれば誤差程度かもしれません。
ただやはりFargateの触れ込みがコンテナだけ考えればいい！ということだと即時起動・即時スケールアウトをイメージしてしまうので、ここも改善されると嬉しいですね。
まとめ
Fargateはインスタンスの管理をせずに済むため非常にメリットの大きい機能ですが、まだリリースしたばかりで足りない機能があるのも事実です。
メリットを享受するために開発環境への導入自体は全く問題ないですし、本番環境については前述した問題点などを許容できるかで判断すると良いと思います。
