はじめに
最近AWS Fargateのバックグラウンドの仕組みが気になったので、これまでに読んだ書籍やAWS公式ドキュメント、個人ブログなどの情報を一旦まとめておこうと思いました。ここに記載する内容は、同じ情報収集を再度やりたくないために書き留めるもので、何かしらの結論があるような内容でもありません。あらかじめご了承ください。
AWS Fargate
言わずと知れたAWSのマネージドなコンテナ向けサーバーレスコンピューティングのサービスです。具体的には、コンテナオーケストレーションのマネージドサービスであるAmazon ECSもしくはAmazon EKSのワーカーノード（データプレーンとも呼ぶ）として実際にコンテナをデプロイして動作させる環境のインスタンスとして利用します。EC2のようなセルフマネージドなインスタンスとは違い、インスタンスそのものの管理（パッチ適用など）の手間をAWSに委ねることで、アプリケーションやシステムの構築に注力することができます。これ以上の詳細は、ここで説明するまでもないと思いますので、AWSの公式サイトをご参照ください。
アーキテクチャに関する情報（時系列）
調査した内容を時系列で昇順（古い→新しい）で以下に記載していきます。
2018/11/27：Firecracker – サーバーレスコンピューティングのための軽量な仮想化機能
こちらはAWS公式ブログの記事としてFirecrackerについて説明されています。
そして、記事では以下のように記載されていました。
Battle-Tested – FirecrackerはBattle-Testedであり、既にAWS LambdaとAWS Fargateを含む複数のハイボリュームなAWSサービスに利用されています。
タイミング的に AWS re:Invent 2018 の直前の記事なので、満を持して発表されたものだと思われますが、Firecrackerは、既に実践でテスト済（Battle-Tested）で実用的であることがアピールされているように読み取れます。
2021/10/21：AWSコンテナ設計・構築［本格］入門
こちらの書籍はAWSでのコンテナ活用を学ぶに当たっての良書であり、巷の評価も高く個人的にも非常に参考になった書籍です。
そして、書籍中で以下のように記載されていました。（P.246）
Fargateでは、コンテナごとにFirecrackerと呼ばれるマイクロVMを起動させ、マイクロVM上でコンテナが稼働します。正確には、「タスク」と呼ばれる複数のコンテナをグループ化した単位ごとにマイクロVMが稼働します。
この記載から、最近のAWS Fargateは、すべからくマイクロVMのFirecrackerで動作しているように記載されています。
2022/04月頃：AWS公式ドキュメント「Security Overview of AWS Fargate」
こちらはAWS公式ドキュメントでAWS Fargateについて説明されています。
https://d1.awsstatic.com/whitepapers/AWS_Fargate_Security_Overview_Whitepaper.pdf
そして、ドキュメント中で以下のように記載されていました。（P.15～16）
EC2： Fargateデータプレーンスタックの最下部にあるEC2ハイパーバイザーは、信頼されたハードウェア仮想化を使用して、同じ物理サーバー上で実行されているインスタンスを分離する。前のセクションで述べたように、EC2インスタンスはAmazon Linux 2、Fargate Agent、コンテナランタイムを実行する。コンテナの分離境界はcgroups、namespaces、seccomp policiesのような抽象化で構成されている。これらはある程度の分離を提供しますが、タスクとインスタンスの1対1のマッピングを実行することで、タスクのコロケーションを避けることにしました。この実行モデルは何層もの分離を提供する。したがって、Fargateは同じEC2インスタンス上で2つのタスクをコロケーションすることはない。各インスタンスで実行されるタスクは1つだけだ。RunTask APIが呼び出されると、新しいEC2インスタンスが使用され、タスクが停止するとインスタンスは終了する。これにより、EC2のデータプレーン上でFargateのタスクレベルの分離が保証される。
Firecracker： FirecrackerマイクロVMはホスト上に配置されたタスクごとに作成される。タスクに属するすべてのコンテナはmicroVM内で実行され、セキュアなタスク境界を促進します。FirecrackerはmicroVMをセキュアにする責任があります。firecrackerプロセス自体は、cgroupsとseccompプロファイルを使ってクイルされる。コンテナ／タスクのクレデンシャルとシークレットは、適切なFirecracker microVMだけが利用できるようにする。したがって、Firecrackerで考慮すべき主なセキュリティは、タスク同士を確実に分離することです。
この記載から、AWS Fargateは、2022年4月の段階においてEC2インスタンスとして動作するパターンとマイクロVMのFirecrackerで動作するパターンの2つあるように読み取れます。
2022/12/12：AWS側がしてきたECS / Fargate のスケーリング速度改善の話
元ネタのAWS公式ブログ記事は上記のAWS公式ドキュメント「Security Overview of AWS Fargate」が発表された頃と同じ2022年4月頃になっていますが、その内容を非常に分かりやすくまとめてくれています。
この記事によると、2020～2022年にかけてFargateのスケーリング速度は大幅に改善されており、これまでEC2に比べて遅いと言われていたFargateのスケーリングが、ことECSにおいてはEC2をベンチマークで大きく逆転するようになっているようです。但しEKSにおいては、そこまで達していないようです。上記ブログ内に元ネタのAWS公式のリンクがありますが、一応以下にも記載しておきます。
2024/02/08：Fargate Is Not Firecracker
そして今年の2月に発表された、この何とも衝撃的なタイトルのこの記事です。
今年の1月までAWSの中の人だったJustin Garrison氏が書いたブログ記事には、以下のように記載されていました。
There was an unspoken policy to never point out that Fargate didn’t actually use Firecracker to create “microVMs” for each container. Just let customers believe what they wanted to. Of course all of the documentation and blog posts make it sound like Fargate uses Firecracker, but you have to read between the lines and know how companies push you to believe something that’s not true.
Fargateが実際にはFirecrackerを使って各コンテナに「マイクロVM」を作成していないことは、決して指摘しないという暗黙のポリシーがあった。ただ、顧客が望むことを信じさせるだけだった。もちろん、すべてのドキュメントやブログ記事は、FargateがFirecrackerを使用しているように聞こえるが、行間を読み、企業がどのように真実ではないことを信じさせるかを知る必要がある。
Justin Garrison氏が本当にAWSの中の人だったのか正確には分かりませんが、2023年4月12日のAWS公式ブログ「Amazon EKS が Kubernetes 1.26 のサポートを開始」の中で氏の名前が何度も登場し、更にAWS のデベロッパーアドボケイトの 1 人として紹介されていました。また、同文中で紹介されているショート動画では、本人（※LinkedInと同一人物に見える）が顔と声を出して自ら語っていることから鑑みても、AWSの中の人だったことは本当だと思われます。
2024/04/20：AWS Fargateのアーキテクチャ探訪
最近の以下のブログ記事でAWS Fargateのアーキテクチャを解説してくれていました。
そして、最後の「おわりに」の中で以下のように記載されていました。
リソース効率からしておそらくFirecrackerによる方式が主流なのだろうなと推測しますが、EC2でもFirecrackerのどちらの方式にしてもVMレベルでECSタスクの分離が行われており、いずれにしても堅牢なセキュリティが確保されていると言えます。
確かに、近年のAWS Fargateのスケーリングの改善の結果を鑑みても、私も同じ所感です。
さいごに
AWS Fargateを支えるアーキテクチャについて気になってしまったので、調べた内容を時系列でつらつらと書き連ねてみましたが、調べる前よりモヤモヤしています（笑）。いずれこのモヤモヤを晴らしたいと思いますが、時間が空いてしまうことで、調べた内容やモチベーションが消えてしまわないよう、一旦ここに吐き出しました。
今回は以上です。
