📦

AWS Fargateのアーキテクチャ探訪

2024/04/20に公開

AWS

はじめに

AWS Fargate セキュリティホワイトペーパーを確認し、Fargateの仕組みについて少しだけ詳しくなります。

AWS Fargateとは

AWS FargateはAWSのFAQによると以下のとおりです。

AWS Fargate は、Amazon Elastic Container Service (ECS) と Amazon Elastic Kubernetes Service (EKS) の両方で動作する、コンテナのためのサーバーレスコンピューティングエンジンです。

AWSで利用可能なコンテナオーケストレータ（コントロールプレーン）はAWS独自のECSとkubernetesのマネージドサービスであるEKSの2種類ありますが、コンテナを実行する方式（データプレーン）としてはEC2か、Fargateを選択することができます。

EC2を選択する場合は自分でコンテナを実行するためのEC2を作成しそのOSの運用保守も行いつつ、オートスケールをしたい場合はEC2のオートスケールと、コンテナのオートスケールの双方を自分で設定する必要があります。

Fargateの場合は、コンテナを実行するための環境をAWSがマネージドで提供してくれるため、EC2の運用から開放され、オートスケールにおいてもコンテナのことだけを意識しておけばよい状態にできます。

このように大きなメリットがあることからここ数年はECSを利用する際にはFargateしか利用しなくなっています。

Fargateの仕組みについて

EC2の場合はEC2にECS Agentというエージェントをインストールし、OS上でdockerを使ってコンテナが起動されます。コンテナの実行はECS Agent(これ自体もコンテナ)がECSと連携しながら自動的に実施します。

Fargateの場合はそもそもEC2がないため、利用する側としてはコンテナの実行をECSに指示するだけです。

そのためFargateのインフラについてどうなっているのかは基本的にはブラックボックスなわけですが、FargateのFAQに AWS Fargate セキュリティホワイトペーパー へのリンクが掲載されており、その中にFargateのアーキテクチャの説明が記載されていました。
本記事ではその内容をかいつまんでご紹介します。

なおこの資料自体はSecurity Overview of AWS Fargateとあるとおり、Fargateの仕組みを説明するためのものではなく、Fargateがどのようにワークロードを分離しているか、といったセキュリティのための情報を提供するものです。

アーキテクチャ概要

Fargateでコンテナを実行するアーキテクチャはホワイトペーパーの記載によると（つまり2022年4月時点では）、EC2による方式と、Firecrackerによる方式の2種類があるようです。（後述）

マネージドサービスであるために我々利用者からはどちらが利用されるかはもちろんわかりませんが。

以下は方式に関わらない全体の概念を示す図です。

コンテナの起動シーケンス

ECSタスクの起動開始時にFargateエージェントがVM上でコンテナを実行するまでのイベントの大まかな流れです。

Fargate エージェントは、タスクを開始する必要があるというメッセージを受け取ります。
このメッセージには、タスク用にプロビジョニングされた Elastic Network Interface (ENI) に関する詳細も含まれています。
次に、新しいネットワーク名前空間を作成し、この新しく作成されたネットワーク名前空間にネットワークインターフェイスをプロビジョニングすることで、そのタスクのネットワークをセットアップします。

次に、ENIを使用して、コンテナをブートストラップするために必要なコンテナーイメージ、Secret、設定を取得します。
最後にコンテナがContainerd APIを使用して起動されます。
Containerd は、コンテナの親プロセスとして機能するshimプロセスを作成します。
これらのshimプロセスは、runC を使用してコンテナを起動します。

Fargateのコンポーネント

下図はFargateのコンポーネントを表した図です。

図から、向かって左側のFargateデータプレーンとされているnamespaceはコンテナのホストインスタンス(VM)のENIを通してFargate AgentがAWS管理のVPCに接続されており、向かって右側のECSタスク用のnamespaceでは利用者のVPCに接続されたENIを通してコンテナイメージやSecretが取得され、runcによりコンテナが起動されることがわかります。

Fargateのセキュリティ

設計による分離

最初にアーキテクチャはEC2による方式と、Firecrackerによる方式があると言いましたが、それが以下です。

EC2

EC2による方式の場合、図のように普通のEC2の上でそのままコンテナが実行される形式、つまりFargateではなくECSインスタンス(EC2)を利用する方式と同じ方法でコンテナが起動されるようです。
ECSタスクとECSタスクの間の分離はcgroupsなどやはり従来の方法でなされるわけですが、これはコンテナ実行環境内のバグや脆弱性により境界を突破されるリスクがあると考えられます。
そのためFargateでは、1つのECSタスクにつき必ず1つのEC2という形で配置されるようにしていると記載されています。
これは同じ顧客のECSタスクであっても、です。
これはとても物理リソースの利用効率が悪そうですね。

Firecracker

FirecrackerはAWS(Amazon)がサーバーレスサービスを提供するために開発しているOSSです。

軽量のマイクロ仮想マシン（microVM）を数秒で起動することができるもので、Lambdaでも利用されているそうです。
Firecrackerの方式では、図のようにFirecrackerのmicroVMによりECSタスクの実行環境を分離するもののようです。
前述のEC2の方式では1EC2=1ECSタスクとなっており、実はその方式と同じではありますがFirecrackerによるmicroVMという超軽量のVMによって分離することで、物理リソースのリソース効率を最大限に高めているものと考えられます。
コンテナ実行環境のVMごと分離しているため、コンテナがブレイクアウトされたとしても影響は該当のECSタスク内に収まります。

おわりに

普段利用するにあたって意識する必要のないFargateによるコンテナ実行の仕組みについて、少しだけ詳しくなれたと思います。
リソース効率からしておそらくFirecrackerによる方式が主流なのだろうなと推測しますが、EC2でもFirecrackerのどちらの方式にしてもVMレベルでECSタスクの分離が行われており、いずれにしても堅牢なセキュリティが確保されていると言えます。

今後も安心してFargateにタスク実行を依頼し続けていこうと思います。