Amazon Web Services ブログ

Amazon EFS を Amazon ECS と AWS Fargate で使用するための開発者ガイド – パート 1



Amazon Elastic Container Service (ECS) と Amazon Elastic File System (EFS) のネイティブ統合が最近導入されました。Amazon ECS は、クラウド専用に構築され、他の AWS のサービスと統合されたフルマネージド型のコンテナオーケストレーターサービスです。ECS は、Amazon EC2 と AWS Fargate の両方で、(いわゆるタスクにラップされる) コンテナのデプロイをサポートしています。Amazon EFS は、ECS や EC2 インスタンスなどの他の AWS のサービスで使用するように設計された、フルマネージド型の柔軟な共有ファイルシステムです。Amazon EFS は透過的にスケーリングし、データをレプリケートし、アベイラビリティーゾーン全体で利用できるようにし、複数のストレージ階層をサポートしています。これにより、大部分のワークロードの要求に対応しています。

この統合は、EC2 インスタンスまたは Fargate を使用するすべての ECS のお客様がご活用いただけます。この統合は、Fargate の、AWS が最近リリースしたプラットフォームバージョン 1.4 で有効になりました。

開始する前に、この統合はオーケストレーター固有であることをはっきりさせておくことが重要です。これは、ECS on EC2 と ECS on Fargate の両方に適用される Amazon ECS タスクレベルの設定だからです。Amazon EKS には、EFS 向けのさまざまな統合メカニズムがあります。EKS on EC2 については、EKS ドキュメントのこのリンクをご確認ください。EKS on Fargate については、こちらの GitHub ロードマップアイテムで足跡をたどれます。これは、この記事の執筆時点ではまだ統合が進行中であるためです。

ECS、EC2、Fargate の相互関係に慣れていない場合は、このブログ記事を読んでしっかりつかむことを強くお勧めします。

この統合はお客様にとって非常にインパクトがあり価値があるため、ブログ記事をシリーズ形式で執筆しました。このブログ記事シリーズは 3 本仕立てで、統合についてさまざまな角度から説明しています。これらのブログ記事は、ECS のお客様がこの統合について詳しく知りたいと思うであろう 3 つの重要な側面をカバーしています。つまり、哲学と適用範囲、テクノロジー、およびハウツーの例です。

  • パート 1: [このブログ記事] EFS サポートの必要性、テクノロジーの基本と統合の範囲、およびこのリリースにより道が開けるお客様のユースケースの概要を示します
  • パート 2: ECS と Fargate に基づきコンテナをデプロイする際の EFS のセキュリティの仕組みの詳細と、リージョンごとの ECS と EFS のデプロイのベストプラクティスに関する高レベルの考慮事項を扱います
  • パート 3: コンテナ化されたアプリケーションの再利用可能なコードとコマンドを含む実用的な例を紹介します。アプリケーションは EFS を使用した ECS タスクにデプロイされたものです

紹介はこれぐらいにして、パート 1 から始めましょう。

ステートレスコンテナとステートフルコンテナに関する哲学

コンテナをステートレスにするかステートフルにするかについて、業界では多くの意見があります。はっきりさせておくと、これまでコンテナストレージと見なされてきたものは一時的なものであり、常にコンテナ自体のライフサイクルにのみ関連付けられているという意味で、コンテナはすべてステートレスです。EC2 インスタンスストアがどのように機能するかについて考えるとよいでしょう。したがって、「ステート」(状態) は常にコンテナの外部に保存する必要があります。このため、ステートレスコンテナの支持者は、これまで、完全に分離された外部サービスを使用して状態とデータを保存することを推奨してきました。これらのサービス間の通信は、典型的なサービス間パターンの API 呼び出しによって実現します。たとえば、Amazon S3、Amazon DynamoDB、Amazon Aurora などを活用するコンテナについて考えてみてください。

けれども、様相は急速に変わってきています。ストレージ管理におけるコンテナランタイムのコンテキストでは、確かな技術進歩が見られます。これにより、元の一時的なコンテナストレージを超える可能性が生まれました。これで、ボリュームストレージの概念を活用したステートフルコンテナを持つことが可能になります。これはより緊密に結合されたアーキテクチャで、コンテナとストレージ間の通信はサービス間ではなく、一般的なストレージプロトコルを通じて実現します。これにより、たとえば、コンテナライフサイクルから切り離されたネットワークボリュームをマウントおよびアタッチできます。ECS と EFS の統合は、完全に伸縮自在な管理ファイルシステムが導入され、これをコンテナで使用できることを表しています。このファイルシステムは「サーバーレスストレージ」と見なすことができ、コンテナを補完して、非常にクラウドネイティブな方法で状態を永続化できます。

明確にしておくと、ステートフルコンテナと外部サービスにアクセスする必要があることの違いは、相互に排他的というわけではありません。ステートフルコンテナを使用していることは、サービス間パターンで外部サービスに接続してはならないことを意味しません。

コンテナは、利便性、アーキテクチャ、またはレガシーの理由から、ローカルの永続性 (ボリュームストレージ を介して) を必要とする場合があり、それを使用して実行する必要があることもあるでしょう。たとえば、/data/server.json というファイルの設定パラメータを永続化する必要があるというだけのスタンドアロンのレガシーウェブアプリケーションがあるとします。そしておそらく必要なのはそのアプリケーションだけでしょう。EFS と ECS をともに使用すると、アベイラビリティーゾーン全体で強力な一貫性を確保できるため、マルチ AZ 配置を簡単かつ透過的に行えます。

ただし、別のステートフルコンテナを外部サービスに接続する必要がある場合もあります。たとえば、スケーラブルで可用性の高い WordPress サイトをセットアップしたいとします。ここでは、WordPress を実行しているコンテナがさまざまなスケールアウト WordPress コンテナにかけて永続的なウェブコンテンツを共有する方法 (これはボリュームストレージでも実現できます) と、バックエンドの Aurora データベースにアクセスする方法の両方が必要になります。

ポイントは、コアアーキテクチャパターン (ステートフルコンテナをセットアップする簡単な方法を含むようになりました) を使用して、必要なものを実現できるようにすることにあります。この一連のブログ記事では、Amazon EFS をボリュームストレージプロバイダーとして使用することに焦点を当てていますが、EC2 インスタンスストアや EC2 EBS などの他のプロバイダーをコンテナ用のボリュームストレージにすることもできる点も気に留めておいてください。

もちろん、エンドソリューションのパフォーマンス、冗長性、可用性、柔軟性のレベルは、選択するボリュームストレージプロバイダーに左右されます。例:

  • EC2 インスタンスストアのボリュームを使用すると、コンテナがその特定の EC2 インスタンスに関連付けられます
  • EC2 EBS ディスクのボリュームを使用すると、コンテナが特定の AZ に関連付けられます
  • EFS ファイルシステムのボリュームを使用すると、クロス AZ で作業できます

興味深いことに、このようなステートレス対ステートフルの議論は新しいものではなく、今日私たちが目撃しているのは新しいパターンというわけでもありません。議論は 10 年以上にわたって続けられたのを見てきました。AWS が 2006 年に EC2 を導入したとき、サポートされていたのは一時的なストレージのみでした。お客様からのフィードバックと高い需要に基づいて、EBS サポートが追加されました。これにより、ローカルの一時的なストレージでは実現できない多数のユースケースの道が開かれました。

そして、お客様から要求があることが機能の有用性の指標であるとすると、この一連のブログ記事で議論している機能に関して AWS の公開ロードマップに数千件を超える機能リクエストの反響がありました。

機会

ここからは、永続的なストレージを必要とするアプリケーションを実行する方法について説明します。そのようなアプリケーションがサービス間のパターンに従って他のバックエンドサービスと通信する必要があるかどうかは問いません。

この機能が導入されるまで、お客様には、ECS タスク内からタスクを実行している仮想マシンのローカルファイルシステム (コンテナストレージとも呼ばれます) を使用するオプションがありました。これは、EC2 または Fargate 上で実行される ECS タスクに当てはまりました。このセットアップは、タスクが使用していたファイルシステムが特定の EC2 インスタンスまたは Fargate フリートが提供する専用の仮想マシンに関連付けられていたことで制限がかかりました。つまり、お客様が保存していたデータは、その時点で使用していたインフラストラクチャに関連付けられていました。EC2 インスタンスが何らかの理由で停止し、タスクを別の EC2 インスタンスで再起動する場合、データは失われます。同様に、Fargate タスクを停止して再起動すると、そのデータは利用できなくなります。

コンピューティングファブリック (EC2 または Fargate) とストレージ間の柔軟性と独立性を高めるために、お客様の中には、コンピューティングプラットフォームを設定して外部ストレージをマップし、タスクがその外部ストレージを使用できるようにした人もいます。これにより、タスクをストレージから切り離し、 (いわゆるボリュームストレージを介して) 高いレベルの柔軟性を実現できました。こちらの記事は、インフラストラクチャを設定してそれを実現する方法の例を示しています。他に、ECS タスクの外部ストレージサービスとして EFS を活用できるようにした例もあります。

これらはすべて、この計算とストレージの独立性を実現するための有効なメカニズムではありましたが、最適ではありませんでした。その理由はいくつかあり、以下にその主なものを示します。

  • これらは、EC2 起動タイプのユースケースで ECS に対してのみ機能しました。Fargate とともに作業することができませんでした。このようなメカニズムでは、特定のこと (ドライバーのインストールやインスタンスレベルでの外部ストレージのマウントなど) を実行するようにデータプレーンを設定する必要があります。基盤となるインフラストラクチャにアクセスできないため、Fargate ではこれを行えません。
  • このようなメカニズムは、インフラストラクチャ設定にまつわる多くの未分化の重労働をお客様に押し付けます。ECS タスクがこの切り離されたストレージを透過的に使用できるようにするために、数多くの設定を行うことが求められます。これは過度に複雑というわけではありませんが、ビジネス価値を直接付加するものでもありません。

以下は、ECS と EFS の統合が利用できるようになる前の状況を視覚的に表したものです。

機会には、EC2 エクスペリエンスの簡素化と AWS Fargate エクスペリエンスの有効化のどちらも含まれていました。

ソリューション

統合自体の詳細とそれによって可能になることを詳しく見る前に、まずその範囲を明確にしましょう。この統合により、ECS タスク内に EFS ファイルシステムエンドポイントをマウントできるようになりました。ECS タスクは、使うことにした起動タイプに応じて、EC2 インスタンスまたは Fargate で実行できます。この選択に関係なく、ECS on EC2 タスクまたは ECS on Fargate タスクは、インフラストラクチャの追加設定なしで、ネイティブに EFS ファイルシステムエンドポイントを透過的にマップできます。これについては後で詳しく説明します。

EFS ファイルシステムが存在すると仮定すると、ユーザーは (EC2 と Fargate のどちらでも) インフラストラクチャレベルで設定することは何もありません。この統合は、タスク定義内で新しい EFSVolumeConfiguration ディレクティブを使用するだけで、ECS タスクと Amazon EFS の間で直接機能します。

以下は、この統合がどのように機能するかを視覚的に表したものです。

ECS ドキュメントのこのチュートリアルは、この統合が実際にどのように機能するかの手引きになります。このチュートリアルは、前述の EFSVolumeConfiguration ディレクティブを使用して EFS ボリュームを作成し、ECS タスク全体でマップする方法を示しています。

Amazon ECS と Amazon EFS の統合で道が開かれるユースケース

お客様からは、この機能により、実装したかったが実装できなかった多くのユースケースで活かす道が開かれるとの声が寄せられています。これは、外部ボリュームのマッピングが面倒なだけでなく単に不可能であった Fargate に特に当てはまります。このようなユースケースは、次の主要なバケットに分類される傾向があります。

  • ファイルシステムの永続性を必要とするワークロードを実行するステートフルタスク
  • 並列コンピューティングのために共有ファイルシステムにアクセスする複数のタスク

ファイルシステムの永続性を必要とするアプリケーションを実行するためのスタンドアロンのステートフルタスク

コンテナは、簡単に水平方向に拡張できる、軽量でステートレスなワークロードに最適なツールです。けれども、お客様が Fargate で実行しようとしている一連のワークロードは、ある程度のストレージの永続性を必要とし、活用することができるものです。多くのお客様が永続的なストレージ機能を必要とする Fargate への移行を希望する、一連のアプリケーションがあります。

これを念頭に、既存のスタンドアロンアプリケーションをサポートする必要があるところを想像してみてください。そのアプリケーションは、たとえば /server/config.json に設定ファイルを永続化し、少量のデータを/data ディレクトリに保持する必要があります。このアプリケーションは、どのタイプのクラスタリングテクノロジーもサポートしておらず、アプリケーションの単一インスタンスを再起動するメカニズムにのみ依存しており、再起動後に/server/config.json と /data のどちらも元の場所で見つけることができると想定しています。

以下に概説するシナリオでは、アプリケーションを実行している Fargate タスクがアセット (/server/config.json および /data) を Amazon EFS に格納しています。このタスクが ECS サービスの一部として実行されると想定し、このタスクが何らかの理由で停止した場合、ECS はおそらく別のアベイラビリティーゾーンでもタスクを再起動し、同じリモートファイルシステムに再接続します。そしてアプリケーションはバックアップされ元の場所でリクエストを処理します。

お客様から寄せられたユースケースの 1 つに、ファイルシステム上の一連のデータにアクセスする必要があるが、常時オンである必要はないアプリケーションがあります。ネットワーク共有上のデータを処理するために、週に 2 回実行するだけでよいアプリケーションを想像してみてください。この統合が導入される前は、そのデータを一時的なコンテナストレージ中に維持するために、Fargate タスクを無期限に実行する必要がありました。アプリケーションが失敗してタスクを再起動する必要がある場合、すべてのローカルデータが失われるため、これは非常に危険でした。また、時間の 30% しかデータを処理しないにもかかわらず、長期実行タスクの料金も発生します。ECS と EFS の統合を活用することで、データセットをタスクのライフサイクルから切り離し、データ損失リスクを軽減し、請求を最適化できるようになりました。

共有ファイルシステムに並行して複数のタスクにアクセスする

この統合によって道が開けるもう 1 つの興味深いユースケースに、並列アクセス用の共通の共有ファイルシステムを、EC2 または Fargate で実行される多数の ECS タスク間で共有できる可能性があるユースケースがあります。チュートリアルの例は、ウェブ企業の観点からこのユースケースを扱っています (提供される HTML コンテンツは一元化され、各タスクで読み取り専用でマウントされます)。これは、可用性の高い WordPress セットアップのフロントエンドをスケーリングする方法に似ています。しかし、S3 でホストされている大規模なデータセットがあり、タスクがそれをプルして操作する必要があるさらに高度なシナリオを想像してみてください。ML トレーニングと推論のユースケースは、この共有ファイルシステムパターンを利用できるもう 1 つの良い例です。この統合を導入する前は、すべてのタスクで S3 からデータをプルし、タスクで使用できる一時ストレージにローカルに保存する必要がありました (適切な場合)。統合したことで、タスクの 1 つが S3 からデータをプルし、それを EFS に配置するオプションが増えます。これにより、他のすべてのタスクが EFS でそのデータにアクセスできるようになります。このユースケースはすでに大きな反響を呼んでいます。

次のイメージは、このフローをまとめてみたものです。

まとめ

これでパート 1 は終了です。これまで、この統合の動機、範囲、および統合により可能になるユースケースについて見てきました。次のパート 2 では、Amazon EFS がどのように機能するか、および EFS、ECS、Fargate に基づいて各リージョンで弾力性のあるデプロイを構築する方法についてさらに詳しく説明します。