[AWS] Fargateの使用上の注意点

AWS Fargateって？

AWS Fargate(以下Fargate)は、
AWSが提供するコンテナ実行サービスであるElastic Container Service (以下ECS)のサービスの一種です。

バージニア北部のリージョンでのみ提供されていたサービスですが、
ついに、2018年07月東京リージョンでも提供が開始されました！！

既存のECSの仕組みが、ユーザが管理するEC2のクラスタの上でコンテナが起動されるのに対し、
FargateはEC2の管理をする必要がなく、コンテナが使用するvCPU、メモリを指定するだけでコンテナを実行できます。

冒頭でECSのサービスの一種です、という言い方をしましたが、
基本的には、ECSの仕組みと同じように動作します。

例えば、タスク定義の仕方や、EC2 Contaner Registry(以下ECR)を利用できる点も同じですし、
デーモンとして動かしたいタスクをサービスとして定義するのも同じです。
コンソールのUIもほぼ一緒なので、
ECSを使い慣れている場合は、特に操作に戸惑うことはないでしょう。

AWS Fargateのメリット

Fargateを使うことで
得られるメリットとして、
以下のようなものがあるかと思います。

ホスト機の制限を気にする必要はない

ECSは、例えばNginxのコンテナなど、デーモンとしてタスクを稼働させる場合、
稼働しているべきタスク数(コンテナ数)を定義しておけば、
それに見合うよう、タスク数を調整してくれます。

例えば、EC2を2台用意してNginxのタスクを2つサービスとして動かす設定にしていた場合、
タスク配置戦略をバランススプレッドにしていれば、
それぞれのEC2上にNginxのコンテナを起動してくれます。

この時、片方のEC2が故障などでダウンした場合、
ECSは生きているほうのEC2にNginxのコンテナをもう1個起動しようとします。

ただ、この時に、問題が2つあります。

1つはポートの問題です。
コンテナの仕組み上、一つのホストに同じポートのコンテナは一つしか立てられません。
なので、何らかの理由でALBの動的ポートを使っていないようなケースのばあい、
Nginxのデフォルトである80番ポートのコンテナは1つしか立てられないのです。

2つ目はインスタンススペックの問題です。
Nginxのような軽いコンテナであれば、あまり問題になることはないかと思いますが、
重い処理をさせるコンテナの場合、あらかじめ2つのコンテナが稼働しても
問題ないスペックを確保しておく必要があります。
余分なスペックになってしまいますし、
何より、ECSエージェントの制限としてクラスターを構成するEC2インスタンスのサイズは
一旦決めたら変更できないので、必要に応じてサイズをあげさげすることもできません。

これら2点の問題をFargateを使うことで回避できます。
ポートの問題は、そもそもホストという概念が表面的にはないため、
ポートが被って起動できないということは起こりません。
また、それぞれに指定したvCPU、メモリで起動してくれているので、
インスタンスのスペックを過剰に用意する、といった必要も起きません。

ホスト機のエージェントやミドルウェアを気にする必要がない

ECSクラスタを構成するEC2に使用するAMIとして、
最新のECSコンテナ最適化AMIを使用することが推奨されています。

この最適化AMIは、
ECSエージェントやDockerなどの、
ECSを動かすのに必要なミドルウェアあらかじめインストールされているので、
すぐに使い始めることができます（UserDataなどで、所属するクラスター指定する記述をするだけで使えます）。
また、ECSを動かすには必要ないミドルウェアを絞っているため、
必要ないのに入ってしまっているために、脆弱性の問題などが起こるといった可能性も低くなります。

とはいえ、ホストとして管理してしまっている以上、
ECSエージェントのバージョンの最新化や、
脆弱性が発生してしまったら、ミドルウェアの更新をする必要も利用者側に出てきてしまいます。

Fargateを利用することで、
(少なくともホスト機に関しては)
一切、面倒を見る必要はなくなります。

AWS Fargateのデメリット

ということになるかっていうと、
そうは問屋が卸しません。

Fargateも万能ではなく、
デメリットもあるのです。

docker系のコマンドが叩けない

コンテナのデバックとして、
docker runコマンドで起動してみたり、
docker execコマンドでプロセス内を覗いてみたりといったことができません。
（そもそもホスト機にSSHができません）

CloudWatch Logsに出力されるログが
デバッギングの主力になるので、
デバックしやすいようにログ出力を設計したほうがよいでしょう。

リンク機能が使えない

複数のコンテナを稼働させる場合、
ひとつの方式として、
複数のコンテナをリンク機能で繋ぐ、ということをすることがあると思いますが、
Fargateはリンク機能を使えません。

ElasticIPが割り当てられない

Public IPを割り当てることはできますが、
タスクが起動/停止するたびに、
IPが変わり続けます。

IP制限をしている先への接続や、
メール送信を行う場合など、
固定IPを必要とする場合は
NATの仕組みを別途用意するなどが必要になります。

また、ブラウザでのアクセスなどの際には、
基本的には、ALBを利用して、Endpointを固定化したほうが良いでしょう。
（そうしないと、タスクの起動/停止のたびにDNSの書き換えをする必要が出てきます）

現状、Public IPを割り当てる必要がある

こちらにあるように、現状Public IPを割り当てた上で、
Publicアクセスができるサブネット（NAT,インターネットゲートウェイ）に
コンテナを配置する必要があるようです。
ただ、これば不具合なようなので、
そのうち解消されるかと思います。

つまり、プライベートなコンテナを立てるためには、
セキュリティグループやルートテーブルで別途コントロールしてあげる必要があります。

ログエージェントはAWS CloudWatch Logsのみ

例えば、
Fluentdにログを送信して、S3にログを保存する、といったようなことができません。
CloudWatch Logsには無限に保持できますが、
S3に保存したい、などの場合、
それ用の処理を用意してあげる必要があります。

デプロイに時間がかかる

体感では、
通常のECSに比べて、数倍時間がかかる感じです。
（IPの割り当てなども必要になってくるからだと思われます。）

まとめ

といったように、
Fargate特有の問題点もあります。

とはいえ、
余分なスペックを確保する必要がないという点や、
ホスト機のことを一切気にしなくていいという点は
通常のECSでは得られない、大きなメリットです。

特有の問題点についても解決策がないわけではないので、