バックエンド/インフラ担当のパクです。
前回の記事ではS3管理に関するセッションについて振り返りました。
今回は、AWSの代表的なコンテナサービスであるFargateを取り上げたセッションに焦点を当て、振り返りたいと思います。
AWS Fargate or Amazon EC2:Which launch type should be using?
このセッションでは、Amazon Elastic Container Service (ECS) と Amazon Elastic Kubernetes Service (EKS) の両方で動作する、コンテナのためのサーバーレスコンピューティングエンジンであるFargateの特徴とワークロードによるAWSサービスの選択について、以下のように紹介されました。
Fargateの特徴
各タスクをそのタスクのためだけに隔離されたマイクロVMで起動する
Fargateはすべてのタスクとポッドを専用の仮想マシン環境で実行します。
Fargate上で実行されるワークロードは独自の分離境界を持ち、基盤となるカーネル、CPU、メモリリソース、ローカルストレージを別のタスクやポッドと共有することはありません。
Fargateは、コンテナ化されたワークロードを実行するためのセキュアなアプローチで設計されており、タスクとポッドを分離することで攻撃の爆発半径を小さくします。 （Source：AWS Fargate セキュリティホワイトペーパー）
運用オーバーヘッドを削減できる
EC2の場合では、
- OSのパッチやAmazon ECSエージェントのアップデート
- EC2インスタンスの数や起動するEC2インスタンスの世代の管理
- コンテナパッチの適用
などがユーザーの責任範囲に入ります。
一方で、Fargateの場合は、OSのパッチなどの作業がAWSの責任範囲に入ります。そのため、ユーザーはコンテナの適用に注意を払うだけで済みます。
価格モデル：リソースベースの価格設定
価格モデルにおいてもEC2とFargateには違いがあります。
EC2は、コンテナが動作しているかどうかにかかわらず、EC2インスタンスの価格は一律です。
一方で、Fargateはコンテナのサイズ（タスクで使用する vCPU とメモリリソース）に応じて料金を支払い、コンテナが停止した時点で支払いも停止します。
これにより、Fargateはより柔軟な課金モデルを提供しています。
ワークロードによるAWSサービス選択
最後に、ワークロードの安定性（stability）と激しさ（intensity）を基準としたAWSサービス選択マップも紹介されました。
AWS Lambda
- ワークロードの安定性（stability）に関係なく、リクエストが一度に数件しかない場合
- ワークロードの激しさ（intensity）に関係なく、非常にトゲトゲしているか、"オフの時間"がある場合
Fargate、AWS App Runner
- ワークロードがある程度安定しており、予測可能なパターンでありながら常にリクエストが数百から数千の場合
Amazon EC2
- ワークロードが非常に安定しており、予測可能なパターンでありながら常にリクエストが数百から数千の場合
おわりに
今回のセッションを通じて、Fargateのメリットや価格モデルの利点、そしてFargateがどのようなワークロードに最適であるかについて理解することができました。これを踏まえて、今後AWS設計を行う際には、ワークロードの特性やニーズに応じて、より効率的で適切なインフラストラクチャを構築していきたいと考えるようになりました。
