Amazon Web Services ブログ

Fargate プラットフォームバージョンの入門

AWS Fargate は、コンテナを実行するためのマネージドサービスです。これは AWS のマネージドサービスの 1 つで、ユーザーはその中のインフラストラクチャを気にすることなくコンテナを起動できます。別のブログ記事では、AWS Fargate プラットフォームバージョン 1.4.0 で導入した新機能と変更点について詳しく説明しました。一歩下がって、Fargate プラットフォームのバージョンについてもっと全体的な話をしましょう。

ご存知のように、コンテナとコンテナランタイム (Containerd など) の全体的な目的は、コンテナイメージ (ユーザーが提供するもの) を、そのイメージを起動する予定の (AWS Fargate が提供する) オペレーティングシステムから切り離すことです。ただし、これは明確な分離ではなく、これらの 2 つのレイヤーは抽象化の一部をリークしてしまう可能性があります。

リークする抽象化レイヤーは、この業界では新しい出来事ではありません。これは、下のレイヤーで同じデカップリングの目的を果たすハイパーバイザーと VM ではそれほど問題ではありません。とはいえ、これらの 2 つのレイヤー間のインターフェイスは十分に確立されており、相互にリークする可能性は低くても、一方のレイヤーが他方のレイヤーの変更を認識しなければならない状況がありました。たとえば、標準の EC2 インスタンスから Nitro ベースの EC2 インスタンスへの移行と、これが AMI に及ぼす影響について考えてみてください。たとえば、Nitro ベースのインスタンスタイプを使用するには、ドキュメントに記載されているように、AMI に特定のネットワークドライバーを含める必要があります。

上記のため、AWS Fargate で実行されているコンテナに公開しているインターフェイスをより強力に制御する必要がありました。ここで Fargate プラットフォームのバージョンが登場しました。特定のプラットフォームバージョンを選択してそれに固執することにより、開発者は、基盤となるインフラストラクチャとサポートソフトウェアが変更されないようにし、スタック全体で高い忠実度を維持し、抽象化を変更するリスクを軽減できます。

プラットフォームバージョン 1.3.0 をほぼ 1 年前にリリースして以来、かなりの数の新機能を導入してきました。プラットフォームバージョン 1.4.0 の変更点が機能しなくなるとは思いませんが、それが非常に重要な変更であるため、プラットフォームバージョン 1.3.0 に戻ることができる可能性を残しておく方が、新しいプラットフォームバージョンがユーザーにとってより優れたランウェイとなり、採用するリスクが低くなるだろうと判断しました。

Fargate プラットフォームバージョンの消費の基本

プラットフォームバージョンのライフサイクルがどのように機能するかを詳しく説明する前に、いくつかの基本を確認しましょう。

上記で触れたように、プラットフォームバージョンは AWS Fargate の主要な新機能を導入するために使用されます。たとえば、PV 1.1.0 はタスクメタデータエンドポイントを導入しました。機能は通常、Fargate サービスの中で AWS がデプロイおよび管理する新しいソフトウェアで導入されるため、新しいソフトウェアリリースに関連付けられています。このソフトウェアは AMI に組み込まれ、インストールするエージェント、使用するコンテナランタイム、および開発者が透過的に使用する AWS Fargate サービスを提供するために集合的に使用されるその他すべてが含まれます。

ECS を介した AWS Fargate の使用

run-task コマンドまたは create-service コマンドのいずれかを使用して、Fargate 起動タイプで新しい ECS タスクを起動する場合、プラットフォームバージョンを選択するオプションがあります。特定の番号のバージョンにすることも (現在のところ、これは 1.0.0、1.1.0、1.2.0、1.3.0、または 1.4.0 になるでしょう)、LATEST のバージョンにすることもできます。後者の場合、最新の PV が選択されます (これについては後で詳しく説明します)。利用可能なすべての PV の完全なリストについては、Fargate のドキュメントをご覧ください。

たとえば、以下は、LATEST プラットフォームバージョンが使用されている FARGATE 起動タイプを使用した run-task 呼び出しです。

aws ecs run-task --cluster <clustername> \
                 --task-definition <taskdefinition>:<version> \
                 --launch-type FARGATE \
                 --platform-version LATEST 
                 --network-configuration "awsvpcConfiguration={subnets=[<subnet1>,<subnet2>],securityGroups=[<securitygroup>],assignPublicIp=ENABLED}"

同様に、ECS サービスを (create-service を使用して) 作成し、ECS タスクが LATESTを使用する場合、create-service コマンドを実行した時点で利用できる最新のプラットフォームバージョンに解決されることに注意してください。

現在のモデルでは、その後新しいバージョンがリリースされ、LATEST タグが新しいバージョンに移行すると、そのサービスは、LATEST が最初に解決されたときに create-service コマンドの時点で使用されていたプラットフォームと同じ Fargate プラットフォームでタスクをデプロイし続けます。サービスのプラットフォームバージョンを変更するには、update-service コマンドを使用する必要があります。以下、実用的な例を挙げてみましょう。

  • 昨年、Fargate を基盤とする新しい ECS サービスを立ち上げ、プラットフォームバージョンとして LATEST を指定したとします。
  • 当時、LATEST は 1.2.0 に解決されました。そのバージョンが、利用できる最新のプラットフォームバージョンだったためです。プラットフォームバージョン 1.2.0 の Fargate タスクがデプロイされました
  • 以降、1.3.0 がリリースされ、LATEST タグがこのバージョンに移動しました
  • 1.3.0 を起動した後、(まだ LATEST を使用している) サービスのスケールアウトを試みます。この場合、バージョン 1.2.0 が引き続き使用されます。これは、このバージョンが、サービスの開始時に解決された最新バージョンであったためです。
  • サービスを更新する場合 (ECS サービス更新 API や AWS コンソールワークフローなどを使用して)、LATEST タグが再解決され、再デプロイされるすべてのタスクに 1.3.0 が使用されます。

新しいプラットフォームバージョンを導入することに加えて、これらのプラットフォームバージョンを定期的に更新しています。ドキュメントではそれを明確に示していませんが (このブログの記事はそれを明確にするための努力の賜物です)、一般に公開されているバージョン番号のバンプによってトラッキングされない小さなリビジョン、または「更新」(そう呼びたいのであれば) を行っています。バージョン番号をバンプするのではなく、このような更新は、特定のプラットフォームバージョンのメモの形で表示する方法を取っています。そのメモには、“Beginning on <date>, any new Fargate task that is launched supports <new feature>” と記されています。

たとえば、ドキュメントで現在利用できるプラットフォームバージョンのリストを見ると、プラットフォームバージョン 1.3.0 には、経時的にいくつかの変更点が導入されていることがわかります。これらは、多くの場合、修正が必要な CVE や、完全に新しいリリースにする価値のない追加機能です。Fargate プラットフォームのバージョンの使用の観点から、唯一注意が必要なのは、特定のバージョンに到達したとき (明示的に必要になったため、または LATEST によって解決されたため)、その特定のプラットフォームバージョンで最後に利用できるパッチが常に使用される、という点です。リクエストしたプラットフォームバージョン内に、特定のリビジョンをリクエストするためのメカニズムはありません。これは、お客様にとって問題にはならないことがわかりました。これは、コンテナランタイムの分離の約束が守られていることを示しています。

したがって、上記の例を検討すると、初めてサービスを使用開始してプラットフォームバージョン 1.2.0 を使用したときは、プラットフォームバージョン 1.2.0 の最新のパッチがデプロイされることになります。後でサービスをスケールアウトしたとき、バージョン 1.2.0 を使い続けましたが、そのプラットフォームの最新のパッチが変更されている可能性があります。したがって、お使いのサービス中のタスクは、パッチバージョンがわずかに異なる、同じプラットフォームバージョンを使用しています。既存のタスクが再利用されると、それらはすべて、使用する予定のプラットフォームバージョンの最新のパッチバージョンを取得します。

EKS を介して AWS Fargate を使用する

re:Invent 2019 で、AWS Fargate と Amazon EKS 間の新しい統合を開始しました。これで、EKS のお客様は、ECS のお客様が Fargate を利用したのと同様の方法で Fargate サービスをご利用いただけます。

この統合の仕組みについては、こちらのブログ記事で概要を説明しています。AWS Fargate 向けの EKS サポートは re:Invent 2019 で開始されたため、プラットフォームバージョン 1.4.0 で直接起動されました。EKS チームはこのプラットフォームバージョンに早期にアクセスできました。このプラットフォームバージョンは、今回の発表で一般公開されます。

EKS 自体には、プラットフォームバージョンの概念があります。これは、さまざまなクラスターの機能と設定を追跡するために使用するメカニズムです。EKS プラットフォームバージョンは、Kubernetes バージョンの追跡にとどまらず、拡張機能や追加機能のサポートなども行います。

EKS/Fargate のユーザーエクスペリエンスでは、ネイティブの Fargate プラットフォームバージョンの可視性を抽象化し、引き続きEKS プラットフォームバージョンの一部としてのみユーザーに表示されるようにしたいと考えています。

Fargate プラットフォームバージョンの進化

前述したように、Fargate は 2017 年に導入されて以来、1.0.0、1.1.0、1.2.0、1.3.0、および 1.4.0 の 5 つのプラットフォームバージョンを提供してきました。これらのリリースはいずれも非推奨にされておらず、現在のところ、お客様はこれらすべてをご利用いただけます (すべてのタスクの大部分は 1.3.0 で実行されていますが)。これに加えて、通常、すぐに LATEST フラグを変更して、入手できるようにしたリリースを指すようにしました。このアプローチは、これまでのところ当社とユーザーにとってうまく機能しています。

プラットフォームバージョン 1.4.0 の発表に伴い、このモデルを調整することで、ユーザーをより適切に保護し、最終的には表面化する可能性のある互換性リスクをさらに軽減しています。

今回導入する変更は、いくつかの軸をカバーしています。これらの変更を詳しく見てみましょう。

LATEST フラグへのそれほど積極的でない動き

このプラットフォームバージョン (1.4.0) の導入以降、LATEST タグの移動を保留します。追加の予防策として、LATEST を使用するユーザーにランウェイを提供したいと考えています。これは、本日デプロイして、LATEST タグを使用して Fargate プラットフォームのバージョンを識別する場合、システムは今のところプラットフォームのバージョン 1.3.0 を参照し続けることを意味します (ただし、技術的には、今日入手可できる最新のプラットフォームバージョンは 1.4.0 です)。

このようなユーザーも、1.4.0 に明示的にデプロイしてそのバージョンを試してみるか、AWS が プラットフォームバージョン 1.4.0 を指すように LATEST タグを移動するまで待つことができます。2020 年 5 月のタイムフレームでこの変更を行う予定なので、同バージョンに LATEST タグが付けられる前に、約 1 か月間 1.4.0 をテストできます。この変更については、正式な発表をお待ちください。

これは、タグ LATEST を使用している場合、ユーザーに 1.4.0 の使用を強制せずに、 それをテストする時間を与えることを目的としています。混乱するとは予想していませんが、控え目にすることにしました。

AWS Fargate プラットフォームバージョンのライフサイクル

この記事をお読みの間、今後導入予定の内容について、前向きな発表をしたいと思います。古いバージョンの Fargate プラットフォームの非推奨プロセスを、無停止でスムーズに行う予定です。たとえば、プラットフォームバージョン 1.0.0 から 1.2.0 は Amazon Linux 1 (AL1) に基づいており、現在の計画では AL1 は 2020 年末に「サポート終了」になる予定であるため、非推奨は必須です。このプロセスは、お客様の運用を妨げない方法で導入する予定です。

各プラットフォームバージョンを特徴付ける「状態」を付与します。非推奨プロセスの仕組みと各プラットフォームバージョンの状態をより明確にするために、それぞれに新しい状態を付与します。これらの状態は、API の機能強化によりプログラムで検出できるようになります。

付与する状態には、Active、Deprecating、Retired および Recalled があります。「Recalled」状態を除いて、他のすべての状態は実行中のワークロードを妨げることなく、新しい「Active」なファーゲートプラットフォームバージョンへのスムーズな移行が行えるものと考えています。リリース日が近づいたら、これらの変更に関する詳細情報を提供します。Fargate ユーザーにはもちろん、最新のプラットフォームバージョンを使用することをお勧めします。

まとめ

このブログ記事は、AWS の哲学と、AWS Fargate でプラットフォームバージョンを使用する理由を説明する機会にしました。AWS Fargate を初めて使用する場合、試すにはこれが良い出発点であり、インフラストラクチャを気にせずにコンテナを実行することの意味を噛みしめることができます。お客様が AWS Fargate ユーザーである場合、または単に過去に評価したことはあるが、お客様の要件を満たすには足りない部分があると判断していた場合は、新しい Fargate プラットフォームバージョン 1.4.0 で発表した新機能のリストをチェックしてみてください。これらの新機能により、Fargate の使用を検討できる新しいユースケースへの道が開かれるかもしれません。