こんにちは。朝から晩までAWS検証中の黒川です。
ECSとFargateの違い分かりますか？
私は昔、コンテナをEC2タイプかFargateタイプが選べると知り、「どっちがどう違うんじゃい？」と出鼻をくじかれました。
また、複雑なマイクロサービスに向いているのはどっち？など双方のメリットとデメリットが理解できていないと感じたので改めて整理しようと思います。
☑️本記事のテーマ
☑️結論
☑️理由
Fargateとは？これってECSのサービスの1つですよね？
ECSサービスの定義
「イケてる設計」を目指すエンジニアは、（何故か）コンテナサービスをクラウドで動かすことを選択しますよね。設計が複雑だったり、環境変化のスピードに対応するマイクロサービス型のビジネスに向いていたり。。
さて、ここでECSサービスをちょっくら分解してみることにしてみましょう。
・コンテナを実行するサービスである
・タスクを管理するサービスである
例えば、nginxのコンテナとphp-fpmのコンテナをひとつのタスクにまとめる、とか。
ECSはコンテナを実行するわけではなく、タスクを管理するコントロールプレーンを用意してくれるという点に注意。
それじゃあ、一体コンテナを実行しているのは誰だ？
コンテナを実行しよう
コンテナを実行したいのなら、次の2つのオプションが用意されているので選択しましょう。
・ECSコンテナインスタンスを使用する
・Fargateを使用する
次の図は両者の違いを示したものです。
あれ？「ECS」のサービスに「EC2」と「Fargate」っていうスタイルがあるんだっけ？
そう、つまり「コンテナインスタンス vs Fargate」という記事のタイトルであるべきでしたね。
きのこたけのこ言ってる場合じゃないよ、全く。。
ECSコンテナインスタンスは「ECSコンテナのエージェントを持っているEC2インスタンス」ってこと以外は普通のEC2と何ら変わりないですね。
他のEC2インスタンスと同様に「インスタンス」画面に並んで動いているし。
上司 「ってことで、もちろんEC2インスタンスの監視、パッチ、セキュリティ面の配慮は君の仕事だから、後はよろしく頼んだよ。」
部下 「（えー。。。サーバー管理は骨が折れるから好きじゃ無いけど、、）」
コンテナインスタンスとはつまりそういうこと。
EC2の管理が面倒なんですよね。
あと、インスタンスタイプ（t2.microとか）を適切に選ぶって結構ハードル高いですよね。
Fargateの料金とEC2インスタンスタイプの弱点
上述の管理面と同様に、EC2インスタンスタイプは弱点がいくつかあります。
コンテナインスタンスのクラスターは通常、オートスケーリンググループ内で実行することかと思いますが、スケーリングは簡単じゃ無いですね。
なぜなら
・タスクの配置がよろしく無く、キャパシティ関連の問題でエラーとなった場合でもスケールをする明確なメトリックの基準がない
・Cloudformationでクラスターをスケールアップする際、オートスケーリングやECSって連動して認識しない
・長時間実行しているタスクをkillしないでスケールダウンってめちゃくちゃ難しい
Fargateの圧勝です
Fargateはタスクの実行を管理してくれるもので、EC2インスタンスを管理する必要は一切無いです。お金はvCPUとメモリーの量で決まり、タスクの実行時間で決まるから凄く簡単そうに聞こえる。
Fargateで実行するタスクは、専用のプライベートIPアドレスを持ったENIで動いています。
同一タスク上のコンテナ同士はlocalhostを通じてお互いに通信することができるし、ENIを通して外とインバウンド、アウトバウンドの通信がとれるってこと。
もちろん、パブリックIPアドレスについても同様です。
| ECS | Fargate | |
| 料金 | 高い | 安い |
| 運用難易度 | 高い | 低い |
| EFSとの統合 | 難しいが可能 | 無理 |
| EBSとの統合 | 難しいが可能 | 無理 |
| NWオプション | 複数選択可能 | ENI |
まとめ
ECSかFargateかどっちが良いの？っていうのは適切な質問ではないですね。
ECSは両方含んでいるので、正しくは「コンテナインスタンスとFargateどっちが良い？」っていうことです。
確かに、EC2インスタンスを手中で管理したいって企業も多いと思うが、マイクロサービスをするのなら圧倒的にFargateに軍配が上がります。
コンテナインスタンスをスケーリングすることは難しいので、Fargateをオススメします。
Fargateは運用するのが楽なので、もし可能なら試してみて下さい。