Amazon Web Services ブログ

コンテナの世界での AWS Fargate の役割

2017 年、AWS は、AWS Fargate と呼ばれる大規模なコンテナを実行するサーバーレスサービスを導入しました。今日、お客様は毎週何百万ものコンテナをローンチしています。お客様が Fargate を好むのは、多くのインフラストラクチャにまつわる未分類の重労働から解放してくれるからだと繰り返し伝え聞いています。たとえば、お客様は EC2 フリートまたはコンテナランタイムのサイズ変更、スケーリング、パッチ適用、更新について責任を負う必要がなくなりました。

過去 2 年間で気付いたのは、Fargate は非常に斬新なアイデアであることから、お客様の中には大規模な AWS コンテナポートフォリオの特定のレイヤーに入れるのが難しいと感じていらっしゃる方もおられるということです。当社は、お客様の真の問題を解決する有用なサービスの構築に余念がありません。その一方で、お客様やパートナーが当社が描く軌跡と長期的に構築しようとしているものを簡単に理解できるように当社のサービスを説明し、配置できることが重要だとも考えています。

このブログ記事では、Fargate のアーキテクチャについては詳しく説明しません。詳細よりも、Fargate の「製品」と Fargate の「テクノロジー」の違いと、それがより大きなコンテナエコシステムにどのように適合するかに焦点を当てて、全体像を描くことに紙面を割きたいと思います。AWS Fargate の主要な側面に光を当て、特にこの製品が Amazon Elastic Container Service (ECS) や Amazon Elastic Kubernetes Service (EKS) といった他のコンテナサービスとどのように関係するかを明確にしていきます。

これまでの経緯

これまでの経緯を明確に把握していないと、現在の立ち位置を把握することができません。話は遡りますが、2013 年に Docker が導入されたときに、お客様がコンテナを活用できる方法が様変わりしました。当時、その大部分を「ラップトッププレイ」が占めていました。 言い換えれば、開発者はラップトップでこの技術を活用して、個人の生産性を向上させていました。テクノロジーではさらに多くのことが行えますが、このブログ記事のコンテキストでは、パーソナルコンピューター上のコンテナを「docker run」する機能に焦点を当てます。

時間が経つにつれて、人々はこの技術の力を実感し始め、それを「ラップトッププレイ」 (個人的なテストと開発目的) から本番アプリケーションを実行するための「クラウドプレイ」に進化させました。また、それを達成するためには、単なる「docker run」を超えてラップトップで単一のコンテナを手動で起動するものが必要であることが明らかになりました。

これが、いわゆる「コンテナオーケストレーター」が形になり始めたときです。Amazon ECS は、2015 年に AWS マネージドクラウドサービスとして登場した初期のサービスの 1 つです。Kubernetes は、ほぼ同時に OSS プロジェクトとして出現し始めた対になるテクノロジーでした。

初期の Docker で導入されたものと比較して、コンテナオーケストレーターは何を追加したのでしょうか? コンテナオーケストレーターには主要なロールがいくつかあります。

  1. コンテナオーケストレーターは、お客様が単にコンテナを実行する以上の機能と構成を導入しました。これには、たとえば、コンテナのライフサイクルの自動化、高次の「サービス」や「デプロイ」との関連付け、コンテナが特定のネットワークモデルを使用してクラスタの内外で通信できることなどが含まれます。この頃より、ECS タスクと Kubernetes ポッドがデプロイの最小単位になり始めました。この頃より、ECS タスクと Kubernetes ポッドがデプロイの最小単位になり始めました。
  2. コンテナオーケストレーターにより、コンテナを実行するために必要な容量 (ECS タスクと Kubernetes ポッドの形式) からお客様がサービスとデプロイ (上記の #1 を参照) をデカップリングする機能と構成も導入されました。言い換えると、このオーケストレーターは、仮想マシン上で一緒に実行される一連のコンテナを表すタスクとポッドのスケジューリングを担当します。また、オーケストレーターは、この容量のスケーリングの管理にも積極的に関わっています (担当しないまでも)。

次の図は、「サービス」と「デプロイ」の概念を持つ高次の定義 (ノースバウンド) と、仮想マシン上のタスクとポッドのスケジューリングによる容量の抽象化 (サウスバウンド) というコンテナオーケストレーターに関連付けられた 2 つのディメンションをキャプチャしようとしたものです。

サービスの抽象化とインフラストラクチャの抽象化

上の図からわかるように、オーケストレーターは標準のコンテナデプロイワークフローの多くの可動部分を担当します。特に ECS のコンテキストでは、さまざまな機能の豊富さをマッピングする 2 つの API を考えることができます。その 2 つとは、「RunTask」API と「CreateService」API です。

「RunTask」 API は、アカウント内の EC2 インスタンスの分散フリート上で、1 つ以上のコンテナを持つタスクを実行する機能 (サウスバウンドの機能) と考えることができます。これは、ラップトップでコンテナを実行する代わりに、ECS クラスターを構成する仮想マシンの 1 つでタスクを実行する場合の新しい「docker run」です。

一方、「CreateService」API は、ロードバランサーを介してアプリケーションサービスを公開するように構成された多数のタスクをグループ化するノースバウンドの機能を表現したものと考えることができます。「CreateService」API はオーケストレーターによって導入された高次の抽象化であるため、実際にマッピングできる Docker プリミティブはありません。「CreateService」API は、「RunTask」API を使用して、アプリケーションの目的の状態が確実に達成されるようにします。

もちろん、ECS はより多くの機能と API を提供します。ただし、このブログ記事のために、「CreateService」API と「RunTask」API を使用して、オーケストレーターの以下のレイヤーを表現します。レイヤーの 1 つは、高レベルのアプリケーション抽象化に近いもので、もう 1 つは、低レベルのインフラストラクチャ抽象化に近いものです。

たとえば、「CreateService」API について言えば、アトミックタスクを調整するすべてのメカニズムを含めることを意味します。これには、サービスごとに一定量のタスクを実行するディレクティブ、クラスター内のすべての仮想マシンで単一のタスクを実行するディレクティブ、サービス内のタスクをスケールインおよびスケールアウトする設定が含まれます。

一方、「RunTask」API について言えば、クラスター内の仮想マシンに特定のタスクを配置するための洗練されたスケジューリングアルゴリズムと、クラスターを構成する仮想マシンの数をスケールインおよびスケールアウトするすべてのメカニズムを含めることを意味します。これらのクラスタースケーリングアルゴリズムの一部が、労働集約的で設定が重いことは驚くべきことです。

AWS Fargate へ

新しい AWS のサービスを導入する場合、通常、新しい API と新しいコンソールを導入することで行います (該当する場合)。Fargate サービスを導入したとき、新しいコンソールも新しい API も導入しませんでした。これはおそらく、ユーザーが消化して頭の中に入れるのに時間がかかった点かと思われます。これはおそらく、ユーザーが「製品」と「テクノロジー」の違いについて考え、理解する必要がある点でもあります。

Fargate は、コンテナを実行するためのサーバーレス環境であり、ユーザーはコンピューティングインフラストラクチャのライフサイクルを所有、実行、管理する必要性を完全に排除できます。これは、サーバーの境界を意識せずにタスクやポッドを実行できるクラウド規模の弾力的なコンピューティング能力と考えてください。

つまり、Fargate は、従来のコンテナオーケストレーターが通常解決するサウスバウンド機能の大部分 (すべてではないにしても) を提供します。それは、個別の仮想マシンを特定のニーズに基づいてスケールインおよびスケールアウトできるフラットなリソースプールに変換し、その上でタスクとポッドをスケジュールする方法です。

この時、当社は曲り角を迎えました。当社には「テクノロジー」があり、多くの可能性があるように見えました。「製品」を構築するにはどうすればよいだろうか? お客様がそれを消費し、Fargate が提供する (サウスバウンドの) 機能を利用できるように、Fargate をどのように実現したらよいだろうか?

ECS RunTask API にすべての意味および目的で (高レベルのポジショニングで) 似ている新しい専用の Fargate API (たとえば RunFargateContainerGroup) を導入することもできました。

または、RunTask API が Fargate を包含し、「Fargate API」にすることもできたでしょう。

お気づきかもしれませんが、当社は後者のオプションを選択しました。実際、今日では、RunTask API を "-launch-type" フラグとともに使用して、お客様のアカウントの EC2 インスタンスで、または AWS が所有および管理する Fargate フリートで、タスクの起動を差別化できます。以下は、Fargate の考え方を視覚的に表したものです。

これが舞台裏でどのように機能するかについてさらに詳しく知りたい場合は、この re:Invent 2019 セッションをご覧になることを強くお勧めします。このセッションでは、Fargate を深く掘り下げて、これがどのように機能するかをさらに詳しく説明しています。

RunTask API を利用して Fargate「製品」を構築する利点の 1 つは、Fargate が ECS が提供する高レベル (ノースバウンド) の機能をすぐに利用できることです。

お客様の問題を解決することが重要であると考えていますが、Fargate「テクノロジー」と Fargate「製品」の間のこの二分法が議論で誤解を招く可能性があることも認識しています。

「当社は ECS ではなく Fargate を使用しています」と言ったり、「Fargate と ECS のどちらを使用するかを決定する必要があります」と言ったりするのは、理に適っているでしょうか? そうと言える部分もあるし、そうとは言えない部分もあります。

一部の人たちは、Fargateの「製品」とそれがサウスバウンドに解決する問題を過剰に反応する傾向があり、Fargate が提供するものの自然な拡張として、高レベルのノースバウンドアプリケーション抽象化（それを使用する場合）を認識しています。個別の EC2 コンテナインスタンスで構成される ECS クラスターを扱う仕組みとは対照的です。このようなお客様は、このスタックと「Fargate」として使用しているものについて考える傾向があります。

けれども、お客様の一部はノースバウンド ECS サービス定義レイヤーが解決する問題についてより過剰に反応する傾向があり、使用しているスタックを「ECS」だと捉えています。 この場合、Fargate「テクノロジー」は多くの場合、EC2 の代替案に関する議論になり、タスクを実行する追加のデータプレーンとして位置付けられます。ちなみに、当社は EC2 ベースのクラスターを可能な限り管理しやすくするように引き続き取り組んでいます。ECS は最近 ECS Capacity Providers を導入しました。これにより、お客様が管理する EC2 インスタンスの管理がより効率的になり、ECS と統合されるようになります。これらの機能について詳しく知りたい場合は、この re:Invent 2019 ディープダイブをご参照ください。

Amazon EKS と Fargate の統合

re:Invent 2019 で、AWS は Amazon Elastic Kubernetes Service (EKS) と AWS Fargate の統合を発表しました。これは、特にユーザーが「FargateとECS」を比較するのと同じ様に「FargateとKubernetes」をすでに比較しているため、業界に興味深い変化球を投げかけています。

当社は仮想 kubelet プロジェクトを活用してこの統合を達成できると当初考えていました。けれども、このまま進むと Kubernetes をアップストリームで使用するというコミットメントを守れなくなることにすぐに気付きました。その後、この統合を「机上で」構築し、Kubernetes 内に存在する標準拡張メカニズムを活用することにしました。これには、Webhook とカスタムスケジューラの変更が含まれます。

この場合、Kubernetes にはサーバーレスの概念がなく、常にノードがあると想定しているため、Fargate は AWS が所有および管理するコンピューティング能力の自動販売機として機能します。Fargate は Kubernetes のコンテナデータプレーンになります。Fargate は、仮想マシンの形でインフラストラクチャの容量を EKS クラスターに提供します。必要なさまざまな Kubernetes エージェントを備えたこれらの仮想マシンは、オンザフライでクラスターに接続され、Fargate で実行するように構成された K8s ポッドのスケジュールに使用します。そのため、Fargate で K8s ポッドを起動すると、Fargate が提供した専用の「ワーカーノード」が EKS クラスターで利用できるようになります。

そのため、この場合「Fargate」を使用しているとお客様から言われることはほとんどありませんが、「Fargate データプレーンで EKS」を使用すると言うことでしょう。 以下は、このプロセスの詳細な視覚的表現です。

EKS で実行されている Kubernetes カスタムスケジューラは、アップストリーム Kubernetes クラスターをコンテナサーバーレスデータプレーン (Fargate) の AWS 固有の実装からデカップリングします。上の図からわかるように、EKS にデプロイするカスタム Fargate スケジューラは、ポッドをスケジュールするために「RunTask」API を呼び出します。

以下の図は、この統合に関する re:Invent 2019 ディープダイブで使われたものの一部で、このデカップリングの詳細を示しています。それに加えて、この図は、標準ポッド定義が Kubernetes API エンドポイントに送信され、そこで変更され、カスタムスケジューラに送信されて、Fargate でインスタンス化されるとどうなるかを示しています。

ステップ 4 は、外部「RunTask」API 呼び出しが行われているときの手順です。

一般に、「RunTask」API は、ビルダーが Fargate と直接統合して、サーバーレスコンテナのコアランタイム機能をサービスとして使用する方法として残ります。これにより、たとえば、EKS チームは Fargate を EC2 に加えて Kubernetes データプレーンとして活用しています。

認識したことが現実

冒頭で触れたように、このブログは、EKS、ECS、Fargate について当社がどのように考えているかについての内部情報を提供することを目的としています。これらの技術をどのように位置付け、考えるかについての誤解を晴らしてくれることを願っています。これまでご理解されてきたように、これは認識の問題でもあります。この特定のケースでは、問題に対する独自の認識とそれに関連する解決方法により、これらのテクノロジーをどのように位置付けるかの精神モデルを推し進める可能性があります。

Fargate を問題の解決方法と捉え、複数のアプリケーション定義セマンティクス (ECS および Kubernetes) をサポートする際の多言語性を歓迎するユーザーも見てきました。このようなユーザーは、Fargate を、使用している製品であると捉える傾向があります。

また使用している製品というより、コンテナオーケストレーターのノースバウンドの機能が実際の問題を解決する鍵であると捉える人もいます。このようなユーザーは、Fargate をより多くの代替データプレーンテクノロジーとして捉える傾向があります。

諺にあるように、「認識したことが現実」です。上記の 2 つの図は、非常に異なる方法で、まったく同じテクノロジー能力に光を当てています。そして、何も間違っているところはありません。

まとめ

このブログ記事では、AWS Fargate の背後にあるテクノロジーの背景と製品の選択の一部、特に AWS コンテナポートフォリオ (ECS および EKS) に存在するさまざまな隣接テクノロジーとの関係について詳細に説明しました。上記のように、実際の問題を解決することが当社の優先事項ですが、スタックを分解し、スタックの各部分が何を担当しているかを明確にできるようにするために、基盤となる詳細を理解することが重要です。これは最終的に、これらのピースを別の方法で再統合できるというコンテキストにおいて非常に重要になってきます。たとえば、AWS テクノロジーパートナー (または一般的なビルダー) であれば、Fargate と統合するには、Fargate が何であるかを理解することが重要です。ともあれ、共通の言語を持つことでこの議論を進めやすくなります。このブログ記事はその点が明瞭になればという思いから執筆されたものです。AWS Fargate を初めてご利用になられる方は、こちらをクリックしてご利用開始してください。