Amazon Web Services ブログ
AWS Fargate のプラットフォームバージョン 1.4.0 をリリース
AWS Fargate は、コンテナを実行するためのマネージドサービスです。Fargate を使用すると、Amazon Elastic Container Service (ECS) と Amazon Elastic Kubernetes Service (EKS) を使用して、インフラストラクチャの保守、パッチ適用、スケーリング、セキュリティ保護、ライフサイクルなどの未分化の重労働に対処する負担なしに、アプリケーションを起動できます。Amazon EC2 はお客様のハイパーバイザーと物理サーバーを抽象化しますが、AWS Fargate はコンテナランタイムと EC2 インスタンスに対して同じことを行います。コンテナの世界で Fargate が果たす役割について詳しく知りたい場合は、こちらのブログ記事をご覧ください。
Fargate は、お客様がインフラストラクチャについて考える必要がないという意味でインフラストラクチャを非表示にしますが、インフラストラクチャはまだ存在し、AWS が管理しています。今もインフラストラクチャ機能がエンドユーザーに表示されるのは、Fargate プラットフォームバージョンの概念によるものです。詳細については、Fargate のドキュメントをご覧いただくか、Fargate プラットフォームバージョンの入門のブログ記事をご覧ください。 入門のブログ記事では、Fargate プラットフォームバージョンを導入した理由と、たとえば、プラットフォームバージョン 1.4.0 をまだ「LATEST」のものとしてタグ付けしていない実務上の理由について詳しく説明しています。
本日、AWS Fargate のプラットフォームバージョン 1.4.0 をリリースします。
このブログ記事では、今回のリリースで有効にした Fargate 機能の概要と、その中で行った変更の一端をご紹介します。これらの根本的な変更は、必ずしもお客様に表示される新しい機能と直接的な関係があるとは限りませんが、同じくらい重要です。
Fargate プラットフォームバージョン 1.4.0 の新機能
プラットフォームバージョン 1.4.0 では、AWS Fargate の新機能がいくつか導入されています。ブログ記事のこのセクションでその新機能について説明します。
特に明記されていない限り、このブログ記事で説明されている新機能は、ネイティブの Fargate プラットフォームに関連するもので、ECS オーケストレーターで直接利用できます。コンテナの世界で Fargate が果たす役割、特に ECS および EKS との関係について詳しく知りたい場合は、こちらのブログ記事をご覧ください。
EKS 自体には、プラットフォームバージョンという概念があります。これは、EKS でさまざまなクラスター機能と設定を追跡するために使用するメカニズムです。EKS プラットフォームバージョンは、Kubernetes バージョンの追跡にとどまらず、拡張機能や追加機能のサポートなども行います。これには、ネイティブの Fargate プラットフォームによって継承された機能が含まれます。その一部は、このブログでご説明します。
それでは、始めましょう。
Fargate タスクが Elastic File System (EFS) エンドポイントのサポートを開始
プラットフォームバージョン 1.4.0 では、Fargate タスク内に永続的な EFS ストレージをマウントするためのサポートが導入されています。これにより、AWS Fargate のすべての新しいユースケースが有効になります。この機能リクエストは、オープンソースコンテナロードマップで 1000 件以上の反応がありました。「customer obsession」(顧客第一主義) の精神のもと、当社は行動し、お届けしました。
背景として、Amazon ECS のお客様は長年にわたり、カスタムスクリプトとソリューションを実装してきました。これは、ゾーン (EBS など) およびリージョン (EFS など) の永続ストレージを EC2 コンテナインスタンスにプロビジョニングし、タスクを設定してそのストレージを使用するためです。これを機能するようにするための自動化は、未分化の重労働の典型的な例でした。AWS Fargate のお客様には、ステートフルワークロードをデプロイするオプションがありませんでした。これは、Fargate を使用すると、アクセスして設定できる EC2 インスタンスがないためです。
本日より、EC2 タスク定義 (EC2 と Fargate の両方で) が新しい EFSVolumeConfiguration パラメータをサポートします。つまり:
- EC2 起動タイプを使用する ECS のお客様は、EC2 コンテナインスタンスでストレージを設定し自動化するという面倒な作業を行う必要がなくなりました。
- AWS Fargate のお客様は、これまでは不可能だった、Fargate タスク内でステートフルワークロードの実行を開始できるようになりました。
この機能の使用方法の詳細については、こちらのブログ記事をご覧ください。
Fargate タスクが併せて 20 GB の一時ボリュームを持つように
以前のプラットフォームバージョン 1.3.0 までの Fargate には、2 つの一時ローカルボリュームがありました。同じ ECS タスクで実行されているコンテナのステージング一時領域として使用できる 4GB ボリュームと、コンテナイメージをホストする 10GB ボリュームです。
プラットフォームバージョン 1.4.0 では、これらのボリュームを単一の 20GB ボリュームに統合しています。これにより、使用可能なストレージの合計が増えるだけでなく、ユーザーの好みに合わせてこのボリュームを使える柔軟性が高まります。たとえば、この統合された大きなボリュームは、Amazon S3 から大きなファイルをプルして処理するデータ処理アプリケーションに特に有用です。
これらのボリュームは一時的なものであることにご注意ください。つまり、タスクが停止すると、タスクのローカルファイルシステムに保存されたデータは失われ、将来使用できなくなります。永続的なストレージオプションをお求めの場合は、新しく導入された Fargate と EFS の統合をご検討ください。
これは、Fargate で実行されている EKS ポッドに直接適用される数少ない変更点の 1 つです。EKS ポッドが実際に使用できるストレージは 20GB 未満 (約 19GB 程度) になることに注意してください。このスペースの一部は、Kublet や、Fargate にデプロイされたときにポッド内にロードされている他の Kubernetes モジュールが使用しているためです。
タスク Elastic Network Interface (ENI) が追加のトラフィックフローの実行を開始
Fargate タスクは、AWS がお客様に代わって管理する一連の仮想マシン (VM) 上で実行されます。これらの VM は、いわゆる「Fargate ENI」を介して AWS 所有の VPC に接続されます。ユーザーが Fargate でタスクを起動すると、タスクに ENI が割り当てられ、この ENI がお客様所有の VPC に接続されます。この ENI を「タスク ENI」と呼びます。
タスクには、標準のアプリケーショントラフィックに加えて、ログ記録、イメージのプル、AWS Secrets Manager や AWS Systems Manager Parameter Store からのシークレットの取得など、他のタイプのネットワークトラフィックがあります。各トラフィックタイプには、使用する ENI を制御するネットワークパスと、タスク IAM ロールまたはタスク IAM 実行ロールとして指定する必要がある関連する IAM ポリシーの両方があります。
Fargate プラットフォームバージョン 1.4.0 以降は、これらのトラフィックフローの 2 つに変更を加えて、関連するトラフィックがお客様の VPC 内にとどまるようにします。アクセス許可モデルは変更しません。
このテーブルは状況をまとめたもので、Fargate プラットフォームバージョン 1.4.0 で行った変更を示しています。
この変更により、このようなトラフィックフローの可視性が変わります。たとえば、以前は、Secrets Manager および Systems Manager からシークレットをフェッチするために Fargate ENI が使用されていました。ただし、そのトラフィックはお客様の目に見える範囲内にはありません。多くのお客様から、これらのフローをより詳細に管理して可視化して欲しいとの要望がありました。1.4.0 以降、トラフィックはタスク ENI を通り抜けます。タスク ENI は、独自の VPC で有効にしたネットワーク接続パターンを継承します。これは、たとえば、VPC フローログ内の特定のトラフィックが可視的であることを必要とするお客様にとって重要です。
ネットワーク接続の観点から、VPC は、送信トラフィックが同じパブリックエンドポイントに到達することを許可する必要があるか、タスク ENI が VPC 上のエンドポイントに到達できるように上記のサービスのプライベートリンクを設定する必要があります。実際の例としては、以前は Fargate で ECR にプライベートリンクを使用していた場合、ecr.dkr エンドポイントを設定するだけで済みました。プラットフォームバージョン 1.4.0 では、api.ecr エンドポイントも設定する必要があります。
CloudWatch Container Insights でネットワークパフォーマンスメトリクスが利用可能に
2019 年に Amazon CloudWatch Container Insights をリリースしたとき、Amazon ECS、Amazon EKS、および AWS Fargate のサポートを発表しました。プラットフォームバージョン 1.3.0 までは、Fargate タスクはネットワークパフォーマンスメトリクスを Container Insights に報告できませんでした。これは、awsvpc ネットワークモードと ECS エージェントが交わる部分に存在する制限が原因でした。
Fargate プラットフォームバージョン 1.4.0 では、タスクがネットワークパフォーマンスメトリクスを Container Insights に報告できるようにするために、新しいスタック (新しい Fargate エージェントを含む) を出荷しています。
Container Insights が使用できるように有効化した ECS クラスターでこの新しいプラットフォームバージョンを使って Fargate タスクを開始する以外、お客様が行う必要があることはありません。プラットフォームバージョン 1.4.0 を実行している場合、AWS Fargate タスクの CPU、メモリ、ディスク、およびネットワークメトリクスへの完全なアクセス権が付与されます。
Fargate タスクが CAP_SYS_PTRACE Linux 機能のサポートを開始
2017 年 に、ECS タスクに Linux 機能を追加するためのサポートを導入しました。同じ年に AWS Fargate をリリースしたとき、攻撃の対象領域を最小限に抑えて安全なプラットフォームを提供するため、このオプションを無効にすることを決定しました。
それ以来、お客様 (およびセキュリティとコンプライアンスに関心を寄せるパートナー) から、これらの機能の一部 (つまり、CAP_SYS_PTRACE) をうまく活用できるというフィードバックを受けました。必要な可視性を実現するためにコンプライアンスが重要であるお客様を支援することができる監視ツールは数多くあります。たとえば、お客様の一部は、strace などのツールを実行する必要があると表明しています。
このため、Fargate プラットフォームバージョン 1.4.0 の提供開始以降、お客様は Fargate タスク定義でこの特定の機能を (すべての利用可能な Fargate プラットフォームのバージョンで) 有効にできるようになりました。CAP_SYS_PTRACE は、ここに記載されているすべての機能のうち Fargate タスクに追加できる唯一の機能で、EC2 起動タイプで実行されているタスクでのみ使用できることにご注意ください。
これはすでにパートナーコミュニティから大きな反響を呼んでいます。たとえば、Sysdig はすでに Falco 製品でこの機能を利用しています。
ネットワーク統計が、新しいタスクメタデータ v4 を介して Fargate で利用可能に
Fargate プラットフォームバージョン 1.4.0 以降、タスク内のメタデータサービスにクエリを実行すると、ネットワークメタデータとタスク自体のネットワーク統計が返されるようになりました。これは、新しく導入されたタスクメタデータエンドポイントバージョン 4 のタスクメタデータエンドポイントをクエリするだけで行えるようになります。
プラットフォームバージョン 1.3.0 までは、ネットワークメタデータとネットワーク統計はメタデータサービスを介しては利用できませんでした。Fargate をご利用のお客様は、この情報に簡単にアクセスできるようになりました。Fargate タスクで実行されているコンテナから次のコマンドを使用して、メタデータエンドポイント v4 にクエリを送信し、ネットワーク統計を含む統計を抽出できます。
curl ${ECS_CONTAINER_METADATA_URI_V4}/task/stats
このネットワーク統計には、パケットエラーに加えて、タスクネットワークスタックによって送受信されたバイト数とパケット数に関するデータが含まれます。このメトリクスは CloudWatch Container Insights で取得できるものと似ていますが、メタデータエンドポイントを介してこれらのネットワークパフォーマンス統計を利用できるようになったことで、サイドカーとしてデプロイされたサードパーティツールをエクスポートして、さらに分析を行えるようになりました。昨年、Fargate から Datadog にネイティブでログを送信できました。Datadog は本日リリースされたこの新機能を活用して、お客様のネットワーク上の可視性を強化しました。この新しい統合の詳細については、このブログ記事 (更新済み) をご覧ください。
アベイラビリティーゾーン (AZ) 属性がタスクのメタデータで利用可能に
プラットフォームバージョン 1.4.0 を使用する Fargate タスクは、すべてのメタデータバージョンについて、タスクメタデータエンドポイントにクエリを実行することで、デプロイ先の AZ を取得できるようになりました。
バージョン 1.3.0 までは、AZ を指定した属性は、Fargate で実行されているタスクのメタデータクエリによって返された JSON では使用できませんでした。新しいプラットフォームバージョンでは、この制限が解除され、Fargate タスクが実行されている AZ をイントロスペクトできるようになりました。
Containerd は、コンテナランタイムとして Docker を置換
これ自体はお客様が消費できる機能ではありませんが、Fargate がさらに迅速にイノベーションを行えるようにするテクノロジースワップです。現在まで、Docker Engine は事実上の標準のコンテナランタイムとして使用されてきました。長い間、Docker Engine は、単純なランタイムをプラットフォームに変える優れた機能のスタックを構築してきました。けれども、Fargate はその機能のほとんどをネイティブで提供しており、Docker が提供するすべての機能を必要とするわけではありません。このため、以下のランタイムはシンプルなままでよく、Docker Engine の使用は不要であると考えられました。これが、Docker Engine を Containerd にスワップする理由です。興味深いことに、Docker Engine は Containerd の上に構築され、Containerd は Docker Engine が提供するすべての高度な機能を提供します (Fargate には必要ない機能も)。したがって、これは技術的にはスワップではなく、むしろコードフットプリントの削減に似ています。つまり、安全を維持するために必要なものがはるかに少なくなります。
この変更の詳細については、本トピックを詳述したこちらのブログ記事をご覧ください。
Fargate エージェントが ECS エージェントを置換
プラットフォームバージョン 1.3.0 までは、Fargate が使用していたエージェントは標準の ECS エージェントでした。1.4.0 プラットフォームバージョンがご利用いただけるようになったことで、Fargate 環境専用に設計された新しいエージェントが導入され、お客様のためにより迅速にイノベーションを推進できるようになりました。containerd とこの新しいエージェントの組み合わせにより、Firecracker に基づく新しいアーキテクチャも有効になります。
Fargate が内部でどのように進化しているかについて詳しく知りたい場合は、こちらの Fargate エンジニアリングチームによる詳細な説明動画をご覧ください。
一部のエラーメッセージが変化
コンテナランタイムと VM 内で実行されているエージェントの変更により、コンテナとタスクの終了理由に固有の変更を行っています。たとえば、Docker ランタイムを実行しなくなったため、DockerTimeoutError エラーメッセージは意味がなく、ContainerRuntimeTimeoutError に置き換えています。Fargate エラーメッセージの完全なリストについては、ドキュメントを参照してください。
タスク ENI はジャンボフレームをサポートし、ネットワーク効率を向上
ネットワークインターフェイスは、最大伝送ユニット (MTU) で設定されます。これは、単一フレームに収まる最大ペイロードのサイズです。MTU が大きいほど、より多くのアプリケーションペイロードを 1 つのフレームに収めることができ、フレームごとのオーバーヘッドが削減され、効率が向上します。
以前は、タスク ENI は標準のイーサネットフレームサイズ 1500 バイトでトラフィックを送受信していました。PV 1.4.0 以降、タスク ENI は他のすべての VPC ENI と同様にジャンボフレームをサポートします。これにより、VPC 内に残るすべてのトラフィックなど、送信元と送信先の間のネットワークパスがジャンボフレームをサポートする場合は常に効率が向上し、計算のオーバーヘッドが減少します。
まとめ
このブログ記事では、Fargate プラットフォームバージョン 1.4.0 で導入した新機能と変更点をまとめました。
いつものように、当社が構築したものに対するお客様のご意見と、次に何をしてもらいたいかのご要望をお聞かせいただければと思います。Fargate のお客様で Fargate 機能のリクエストを送信したい場合は、パブリックコンテナロードマップでそれを行っていただけます。AWS Fargate を初めてご利用になられる場合は、これが良い出発点になるでしょう。