[レポート] AWS Fargate under the hood #reinvent #CON423

こんにちは。サービスグループの武田です。

CON423 - AWS Fargate under the hood に参加してきましたのでレポートをお届けします。

なおセッションの動画はYouTubeからも視聴できます。

セッション概要

AWS Fargate is a completely serverless, container-native compute experience on AWS. Fargate doesn’t require users to provision, scale, and manage any servers. Under the hood of Fargate, there is a sophisticated architecture where AWS is innovating both vertically to build a container-optimized virtualization platform and horizontally to build the right integrations with surrounding AWS services to take care of undifferentiated heavy lifting for the developer. In this session, learn from senior engineers how AWS Fargate is designed to deliver a scalable, secure, serverless developer experience with containers.

機械翻訳したものも掲載します。

AWS Fargateは、AWSでの完全にサーバーレスのコンテナネイティブコンピューティングエクスペリエンスです。 Fargateでは、ユーザーがサーバーをプロビジョニング、スケーリング、管理する必要はありません。 Fargateの内部には、AWSがコンテナ最適化仮想化プラットフォームを構築するために垂直に、また開発者のために未分化の重荷を処理するために周囲のAWSサービスとの適切な統合を構築するために水平に革新する洗練されたアーキテクチャーがあります。 このセッションでは、上級エンジニアから、AWS Fargateがどのようにスケーラブルで安全なサーバーなしのコンテナエクスペリエンスを提供するように設計されているかを学びます。

スピーカー

• Archana Srikanta
  • Sr. Software Development Engineer, Amazon Web Services
• Onur Filiz
  • Principal Software Engineer, Amazon Web Services

イントロダクション

AWS Fargateの目指すところの確認。ユーザーが基盤となる仮想マシンを管理せずに、コンテナを実行できるようにすることです。

Fargateにおけるカスタマーエクスペリエンスの振り返り。まずタスク定義を登録します。コンテナイメージ、CPU／メモリなどアプリケーションに必要な要素を定義します。次にクラスターを作成します。クラスターはアプリケーションの単なる論理グループです。

Fargateエンジニアリングチームの最初の成果物のひとつは設計原則のリストです。

• セキュリティ
  • 最優先事項。コンテナの基礎となるインフラのスタック全体（ハードウェアとソフトウェア、ネットワークなど）に常にパッチが適用され、セキュリティが確保されていること
• 可用性とスケーラビリティ
  • 稼働中のコンテナおよびプラットフォーム両方を含む。信頼性の高いコンテナの迅速なスケールアップとスケールダウンをサポートする
• 運用効率
  • 基礎となるフリートの高いリソース使用率を維持して、ビジネスの運用コストを削減する。その成果は価格の引き下げという形で顧客に返還される。実際、大幅な価格引き下げおよびSavings Plansを発表した

アジェンダ

• Fargateアーキテクチャ
• 原則をどのように適用したか
  • 可用性とスケーラビリティ
  • セキュリティ
  • 運用効率
• Firecrackerがこれらの原則をどのように促進するのか

Fargateアーキテクチャ

Fargateはタスクの起動を調整するコントロールプレーンと、コンテナを実行するデータプレーンから構成されます。RunTaskを実行したとき、内部で何が行われるのかを確認しましょう。

1. RunTask
   1. RunTaskを呼び出すとまずコントロールプレーンにヒットします
2. Acquire capacity & persist intent
   1. データプレーンにアクセスし、タスクのサーバーキャパシティを取得して予約します
3. Pending Task
   1. Pendingをユーザーに返します
4. Issue launch Instruction
   1. 非同期に制御計画が予約されたサーバーキャパシティに達するとコンテナを起動する指示を発行します
5. Start up containers
   1. データプレーンでコンテナが実行されます
6. Report task as running
   1. コントロールプレーンに対して実行中の報告をします

データプレーンについてもう少し見てみましょう。Firecracker導入前のアーキテクチャであることに注意してください。

• コンテナはどこで実行されるでしょう？もちろんEC2インスタンスです。そのインスタンスはどこにあるでしょう？
  • FargateアカウントのVPCに立っているEC2インスタンスで実行されます
  • タスク実行が要求されてからインスタンスを起動したのでは遅すぎるため、実行中のEC2インスタンスをプーリングしています
  • タスク実行が要求されるとインスタンスを選択して配置します
• データセンターにある一台の物理サーバーから始めてどのような構成をしているのか見てみましょう
  • まずハイパーバイザーがあります。これはEC2チームによって管理されます
  • そしてAmazon Linux 2をゲストOSとしてインストールし、Fargateエージェントとコンテナランタイム（Docker）をインストールします。ここはFargateチームによって管理されます
    • Fargateエージェントはコントロールプレーンとコミュニケーションします
  • これらの上にコンテナが実行されます。これはユーザーの管理範囲です
• EC2インスタンスのプライマリENI（eth0）はFargate VPCにあります
• タスクが実行されるとセカンダリENI（eth1）がアタッチされ、これはあなたのVPCに接続されます

次にコントロールプレーンについて見てみます。コントロールプレーンはマイクロサービスおよび非モノシリックの精神からいくつかの異なるサービスから構成されています。

• フロントエンドサービス
  • タスク実行時に呼ばれるエントリポイント
  • 認証／認可／制限
• クラスター管理サービス（クラスター管理サブシステム）
  • クラスターとクラスターで実行されるタスクを追跡
  • データプレーンとのコミュニケーション
• キャパシティ管理サービス（キャパシティ管理サブシステム）
  • プールされ使用していないインスタンスと実際にタスクをホストしているインスタンスの両方を追跡
  • タスクが実行されるインスタンスの交換やキャパシティの補充なども行う

RunTaskの呼び出しフローを確認してみましょう。

1. RunTask
   1. フロントサービスがヒットし、制限などを適用し、クラスター管理サービスに転送されます
   2. クラスター管理サービスは新しいサービスをDBに登録し、PENDINGにマークします
2. Acquire Capacity
   1. 容量を確保するためにキャパシティ管理サービスを呼び出します
   2. キャパシティー管理サービスは使用可能なインスタンスをピック、タスク用に予約されていることを記録し、キャパシティIDを返します
   3. 返されたキャパシティIDはDBに登録されているタスクに対して記録されます
3. Pending Task
   1. Pendingをユーザーに返します
4. Activate Fargate agent
   1. 非同期にキャパシティー管理サービスは選ばれたインスタンスのFargate ENIを通してFargateエージェントをアクティベートします
5. Agent checks in
   1. クラスター管理サービスにインスタンスを登録します
6. Send task definition and issue instruction to run
   1. コンテナを起動するために必要なタスク定義とその他の情報を送信します
7. Fargate Agent bootstraps task containers
   1. 必要なdockerコマンドを実行しコンテナを起動します
8. Report task as RUNNING
   1. タスクが実行中と報告します
   2. コントロールプレーンはDBに登録されているタスクの状態をPENDINGからRUNNINGに変更します

原則をどのように適用したか

原則1：可用性とスケーラビリティ

Fargateは他のAWSサービスと同様にさまざまなリージョンで提供されています。異なるリージョンでスタックを実行することで可用性を高められます。

AZは独立した障害耐性をもつように設計されており、アプリケーションを複数のAZに分散させることで可用性を高められます。このベストプラクティスはFargateであっても変わりません。

フロントエンドサービスおよびクラスター管理サービスは、論理的にはリージョナルサービスですが物理的にはゾーン全体に分散しています。一方でFargate VPCは個別のAZに存在しています。そのため各AZごとに専用のキャパシティ管理サービスが存在しており、クラスター管理サービスはスプレッドロジックにより呼び出すサービスを決定します。あるひとつのAZに障害が発生した場合、データプレーン側ではそのAZでタスクを起動することはできませんが、他のAZが機能しているため問題になりません。

AZ内のスケーリングについて見ていきましょう。AZのトラフィックは顧客のアクセスパターンに基づくため制御することはできません。また単一のVPCを無限にスケールさせることもできません。

この問題にどう対処するか？単一のVPCを使用する代わりに固定サイズの複数のVPCに分割しました。VPCが埋まったらスケールアウトしてさらに追加します。これがセルラーアーキテクチャの概念です。

セルラーアーキテクチャを適用したコントロールプレーンの外観です。各Fargate VPCだけでなく、クラスター管理サービスにも適用しました。

Firecrakerがどのようにスケーラビリティに役立つのか確認してみましょう。Firecrakerはコンテナワークロード用に設計されたオープンソースの仮想化技術です。従来の仮想マシン同様の強力な分離プロパティが得られ、かつコンテナ同様の迅速な起動時間も得られます。FirecrackerはホストOS上にハイパーバイザーとしてインストールされ、マイクロVMと呼ばれるコンテナワークロードを起動します。

これまでのEC2インスタンスモデルではシングルテナントで実行していました。これは数千万のFargateタスク起動が数千万のEC2インスタンス起動と同じということを意味します。新しいFirecrackerモデルではベアメタルインスタンスにマルチテナントで実行します。つまり数千万のFargateタスク起動は数千万のマイクロVM起動に変わるということです。既存のベアメタルインスタンスがいっぱいになったときは新しいベアメタルインスタンスを起動する必要がありますが、起動率はとても低いです。

図からタスクを消してインスタンスの比重を比較してみると一目瞭然です。シングルテナントでは高く、マルチテナントではとても低いです。その結果、単一のセルでより多くのタスクを実行できます。

原則2：セキュリティ

従来のEC2インスタンスモデルでは、EC2インスタンスはたったひとつのタスクしか実行しません。各コンテナはcgroups、namespaces、seccompなどによって分離境界が設けられていますが、マルチテナントに対して十分にセキュアだとは考えていません。たとえ同じ顧客のタスクであっても、異なるEC2インスタンスで実行します。

シングルテナントでのセキュリティはどうでしょうか。コンテナからゲストOSには到達可能ですが、実行中のタスク以外の状態はありません。つまり攻撃者が得る情報は何もありません。しかし忘れてはならないのが、ENIはFargate VPCと接続されています。つまり他のインスタンスやコントロールプレーンを保護する必要があります。

顧客に推奨しているベストプラクティスを使用してセキュリティを確保しています。Fargate VPCではセキュリティグループによってインスタンス間の通信はブロックされます。Fargateエージェントとコントロールプレーンの通信は必要ですが、権限を絞ることによって他のタスクの情報は取得できません。

新しいFirecrackerを採用したデータプレーンを見ていきましょう。FirecrackerはEC2 Nitroインスタンスが構築されているのと同じハイパーバイザーであるKVMに構築されています。またハードウェア仮想化により、異なる顧客のタスクを同じ物理マシン上で安全に実行できます。その結果、オーバーヘッドを最小限に抑え起動時間を短縮できます。

これが新しいデータプレーンです。物理サーバーはEC2のベアメタルインスタンスです。そこにホストOSとしてAmazon Linux 2をインストールします。そこにFargateエージェント、firecracker-containerd、Firecracker VMMをインストールします。これがFirecrackerマイクロVMと呼ばれるものです。マイクロVMではコンテナ専用のゲストOSが用意されあなたのコンテナが実行されます。Fargate ENIはベアメタルインスタンスにあります。

先ほどと同じシチュエーションで比較してみます。FirecrackerマイクロVMはハードウェアを仮想化し分離境界を提供します。タスクとコンテナの境界は相変わらず信頼できませんが、マイクロVMによって分離されているため安全です。Firecrackerを使用することで、攻撃対象領域を大幅に削減しよりセキュアに構築できます。

原則3：運用効率

タスクは約50種類の異なるCPU／メモリから設定できます。実行するタスクサイズに合わせてEC2インスタンスが選ばれますが、実際のサイズよりも粗いため使用率は低下します。また起動時間を短縮するためプールからインスタンスが選ばれますが、小さいタスクのバーストが発生した場合どうなるでしょうか。より大きなサイズのインスタンスが選ばれることになり、さらに多くの無駄が生じ使用率は低下します。

Firecrackerは先ほどの分離境界に加え、FargateやLambdaなどのプラットフォームにとっても魅力的な機能を提供します。従来のデバイスを気にすることなく、わずか数ミリ秒で実行を開始します。またコンテナに対して正確なサイズのCPUとメモリを提供できます。

Firecrackerのデータプレーンでは、EC2インスタンスの不均質なフリートではなく、EC2ベアメタルインスタンスの均質なフリートで実行できるということです。今年発表した価格引き下げはこのような効率化によって可能となりました。

Firecrackerによってデータプレーンのオーバーヘッドが削減できました。シングルテナントではFargateエージェントが通信をするために、各インスタンスにENIをアタッチする必要がありました。マルチテナントでは1個だけあれば十分です。

Firecrackerがこれらの原則をどのように促進するのか

セキュリティがもっとも重要な原則でありすべての基礎です。次に可用性と信頼性です。Fargateチームではサービスの信頼性とスケーラビリティを確保するために最大限の努力を払い、安全にユーザーのタスクを実行します。最後に効率性です。少ないリソースで優れたパフォーマンスを提供し、より多くの価格引き下げを享受できます。

まとめ

最近Fargateを使う機会がありたしかに便利でした。また価格引き下げなども実施され、どのようなアーキテクチャで動いているのか知りたいと思っていたところのセッションでした。Firecrackerも名前くらいしか認識しておらず、どのような課題感から生まれどういうメリットをもたらしたのかがよくわかりました。