Amazon Web Services ブログ

Amazon ECS がデータ集約型ワークロードのための Amazon EBS ボリュームとのネイティブ統合をサポート

1月11日は、Amazon Elastic Container Service (Amazon ECS) が Amazon Elastic Block Store (Amazon EBS) との統合のサポートを開始し、より広範なデータ処理ワークロードをより簡単に実行できるようになったことを皆さんにお知らせしたいと思います。AWS Fargate および Amazon Elastic Compute Cloud (Amazon EC2) で実行されている ECS タスクに Amazon EBS ストレージをプロビジョニングでき、ストレージやコンピューティングの管理は必要ありません。

コンテナ化されたパッケージとしてアプリケーションをデプロイすることを多くの組織が選択していますが、Amazon ECS の Amazon EBS との統合の導入により、組織はこれまで以上に多くのワークロードタイプを実行できるようになります。

既存のデータをフェッチし、処理を実行して、処理されたデータをダウンストリームでの使用のために保存する必要がある、ビッグデータの抽出、変換、ロード (ETL) ジョブなど、大量のトランザクションと高スループットをサポートするストレージが必要なデータワークロードを実行できます。ストレージライフサイクルは Amazon ECS が完全に管理するため、インフラストラクチャの更新を管理するために追加のスキャフォールディングを構築する必要がありません。その結果、データ処理ワークロードのレジリエンシーが向上すると同時に、管理に必要な労力も軽減されます。

これからは、Amazon ECS で実行されるコンテナ化されたアプリケーションのためのストレージを、さまざまなオプションから選択できるようになります。

  • Fargate タスクには、デフォルトで 20 GiB のエフェメラルストレージが提供されます。大規模なコンテナイメージのダウンロードや、スクラッチ作業のために追加のストレージ容量が必要になるアプリケーションには、Fargate タスク用に最大 200 GiB のエフェメラルストレージを設定できます。
  • 共有データセットに同時にアクセスする必要がある多数のタスクにまたがったアプリケーションの場合は、EC2 と Fargate の両方で実行されている ECS タスクに Amazon Elastic File System (Amazon EFS) ファイルシステムをマウントするように Amazon ECS を設定できます。このようなワークロードの一般的な例には、コンテンツ管理システムなどのウェブアプリケーション、社内 DevOps ツール、および機械学習 (ML) フレームワークが含まれます。Amazon EFS はリージョン全体で利用できるように設計されており、多数のタスクに同時にアタッチできます。
  • タスク全体で共有する必要がない、高パフォーマンスで低コストのストレージを必要とするアプリケーションの場合は、Amazon EBS ストレージをプロビジョニングして、Amazon EC2 と Fargate の両方で実行されているタスクにアタッチするように Amazon ECS を設定できます。Amazon EBS は、アベイラビリティーゾーン内で低レイテンシーかつ高パフォーマンスのブロックストレージを提供するように設計されています。

詳細については、AWS ドキュメントの「Amazon ECS タスクでのデータボリュームの使用」と「Persistent storage best practices」を参照してください。

EBS ボリュームの ECS タスクへの統合の開始方法
タスク定義でコンテナのボリュームマウントポイントを設定し、ランタイムで Amazon ECS タスク用の Amazon EBS ストレージ要件を渡すことができます。ほとんどのユースケースでは、タスクに必要なボリュームのサイズを指定するだけで開始できます。オプションで、すべての EBS ボリューム属性と、ボリュームのフォーマットに使用したいファイルシステムを設定できます。

1.タスク定義を作成する
Amazon ECS コンソールにアクセスし、[タスク定義] に移動してから、[新しいタスク定義の作成] を選択します。

[ストレージ] セクションで [デプロイ時に設定] を選択し、新しい設定タイプとして EBS ボリュームを設定します。Linux ファイルシステムでは、タスクごとに 1 つのボリュームをプロビジョニングしてアタッチできます。

[タスク定義の作成時に設定] を選択する場合は、バインドマウント、Docker ボリューム、EFS ボリューム、Amazon FSx for Windows File Server ボリューム、または Fargate エフェメラルストレージなどの既存のストレージオプションを設定できます。

これで、タスク定義でコンテナとソース EBS ボリュームを選択し、タスク内でボリュームがマウントされるマウントパスを指定できるようになりました。

$aws ecs register-task-definition --cli-input-json file://example.json コマンドラインを使用して、EBS ボリュームを追加するためのタスク定義を登録することもできます。以下のスニペットはサンプルで、タスク定義が JSON 形式で保存されています。

{
    "family": "nginx"
    ...
    "containerDefinitions": [
        {
            ...
            "mountPoints": [
                "containerPath": "/foo",
                "sourceVoumne": "new-ebs-volume"
            ],
            "name": "nginx",
            "image": "nginx"
        }
    ],
    "volumes": [
       {
           "name": "/foo",
           "configuredAtRuntime": true
       }
    ]
}

2.EBS ボリュームでタスクをデプロイして実行する
これで、タスクを ECS クラスターで選択することによって、タスクを実行できるようになりました。ECS クラスターに移動して、[新しいタスクの実行] を選択します。コンピューティングオプション、起動タイプ、およびタスク定義を選択できることに留意してください。

注意: この例では、アタッチされた EBS ボリュームを使用したスタンドアロンタスクのデプロイを説明していますが、必要に応じて設定された EBS ボリュームを使用するように、新規または既存の ECS サービスを設定することも可能です。

追加のストレージを設定できる新しい [ボリューム] セクションが表示されます。ボリューム名、タイプ、およびマウントポイントは、タスク定義で定義したものです。EBS ボリュームタイプ、サイズ (GiB)、IOP、および目的のスループットを選択します。

既存の EBS ボリュームを ECS タスクにアタッチすることはできません。ただし、既存のスナップショットからボリュームを作成する場合は、スナップショット ID を選択するオプションがあります。新しいボリュームを作成する場合は、このフィールドは空白のままにしておくことができます。ファイルシステムのタイプは、Linux の ext3 または ext4 ファイルシステムを選択できます。

タスクが終了すると、Amazon ECS がデフォルトでアタッチされたボリュームを削除します。タスクの終了後に EBS ボリューム内のデータを保持する必要がある場合は、[終了時に削除] のチェックを外します。また、Amazon ECS がユーザーに代わって API コールを実行できるようにするための関連許可が含まれた、ボリューム管理用の AWS Identity and Access Management (IAM) ロールを作成する必要もあります。このポリシーの詳細については、AWS ドキュメントでインフラストラクチャロールを参照してください。

Amazon マネージドキーとカスタマーマネージドキーのどちらかを使用して、EBS ボリュームで暗号化を設定することも可能です。これらのオプションの詳細については、AWS ドキュメントの「Amazon EBS 暗号化」を参照してください。

すべてのタスク設定を完了したら、[作成] を選択してタスクを開始します。

3.EBS ボリュームでタスクをデプロイして実行する
タスクが開始されると、タスク定義の詳細ページでボリューム情報を確認できます。タスクを選択し、[ボリューム] タブを選択することで、作成した EBS ボリュームの詳細情報を表示します。

チームは、EBS ボリュームの開発と運用をより効率的に整理することができます。例えば、アプリケーション開発者は、利用可能なストレージがあることをアプリケーションが想定するパスをタスク定義で設定でき、DevOps エンジニアは、アプリケーションデプロイ時のランタイムで実際の EBS ボリューム属性を設定できます。

これは、DevOps エンジニアが、開発環境の gp3 ボリュームや本番環境の io2 ボリュームなど、異なる EBS ボリューム設定を使用する異なる環境に同じタスク定義をデプロイすることを可能にします。

今すぐご利用いただけます
Amazon ECS の Amazon EBS との統合は、米国東部 (バージニア北部)、米国東部 (オハイオ)、米国東部 (バージニア北部)、米国西部 (オレゴン)、アジアパシフィック (シンガポール)、アジアパシフィック (シドニー)、アジアパシフィック (東京)、欧州 (フランクフルト)、欧州 (アイルランド)、および欧州 (ストックホルム) の 9 つの AWS リージョンでご利用いただけます。お支払いいただく料金は、使用分の料金のみです (EBS ボリュームとスナップショットを含む)。詳細については、「Amazon EBS の料金」ページと、AWS ECS ドキュメントの「Amazon EBS volumes」を参照してください。

この機能をぜひお試しいただき、AWS の Public Roadmap、AWS re:Post for Amazon ECS、または通常の AWS サポートの連絡先を通じてフィードバックをお寄せください。

– Channy

P.S.このブログ投稿の執筆に貢献してくれた AWS のシニアエンタープライズデベロッパーアドボケイトである Maish Saidel-Keesing に心から感謝します。

原文はこちらです。