Lapis Lazuli

technical blog for web developer

Fargateを使ってみた

最近のサーバーレスの流れに乗り、Fargateを導入したので、その時に気がついたことを残しておきます。
まず従来使っていたECSonEC2と比較しての違いを挙げてみます。

ネットワークモードがawsvpcのみ

EC2タイプでしたらbridgeでインスタンスから接続できたのですが、Fargateはawsvpcのみになります。
インスタンスがマネージドなので当然といえば当然ですが・・・
ENIがタスクに直接アタッチされるので、セキュリティグループの設定などもECSのサービス側で設定する必要があります。
ちなみにawsvpcはポート番号がコンテナ側しか設定できません。ターゲットグループから直接ポートフォワーディングする必要があります。

ログドライバがawslogsのみ

設定できるログドライバがawslogsのみなので、必然的にCloudWatchLogsに流す必要があります。
fluentdは対応予定らしいです。

使ってみて感じたこと

一番のメリットはスケールしやすい。これに尽きます。
EC2タイプの場合、タスクのスケールとインスタンスのスケール、両方を意識しないといけなくて結構面倒でした。
スケールアウトする分にはいいのですが、スケールインするときに順番を考えないと思わぬタイミングでタスクが消える。ということになる可能性があります。
動かすアプリケーションによりますが、これだけでもFargateに移行するメリットはあると思います。

デメリットはやはり料金が高いなーというのと、デプロイが遅いという所でしょうか。
オンデマンドインスタンス比較でも高いのに、リザーブインスタンスとなると更に差が開きます。
デプロイはだいたい1.5倍くらいかかってる感じですかね。体感的に。
ホストにキャッシュされないので仕方ないと言えば仕方ないですが・・・今後の改善に期待でしょうか。

あと規模にもよりますが、CloudWatchLogsは意外にコスト源になります。
Logsは容量と書き込みで課金されるので、ライフサイクル設定しないとどんどんお金がかかっていきます。
なので定期的にS3に逃がすとか、必要なさそうなログは短いライフサイクルで消すとかしないと気がついた時には請求が・・・となる可能性はあります。

メリットデメリットありますが、EC2の管理から逃れられるのは非常に大きいメリットだと思います。
ECSの場合、インスタンスタイプ変更したいときにEC2ほど簡単にできないですからね・・・オートスケールを使わないといけないので。
ともあれ今後のサーバーレスの流れからFargateはどんどん改良されていくと思うので、基本的にFargate使う流れにしたいと思っています。
使わないと知見も溜まっていかないので、積極的に使っていきたいですね。