AWSコンテナの基礎と実行サービスの選び方
コンテナイメージの仕組みと、Amazon ECR・ECS・EKS、EC2・Fargate、ECS AnywhereなどAWS上の保管・管理・実行先の選び方を整理します。
AWSコンテナの基礎と実行サービスの選び方
コンテナは、アプリケーションとその実行に必要なユーザー空間のファイルをひとまとまりにし、ホストOS上で隔離して動かす仕組みです。たとえば、画像変換アプリケーションと必要なランタイム、ライブラリ、設定ファイルをイメージに含めておけば、開発用・検証用・本番用の各環境へ同じ実行単位を配布できます。環境ごとの差を小さくし、同じ手順で起動・停止できることがコンテナの大きな利点です。
仮想マシンは通常、それぞれがゲストOSを起動します。コンテナはホストOSのカーネルを共有し、プロセスやファイルシステム、ネットワークなどを分離します。このため、ゲストOS全体を含む仮想マシンより起動が速く、同じホスト上で使うリソースを抑えやすくなります。一方、カーネルを共有するため、コンテナは仮想マシンと同じ種類の境界ではありません。OSカーネルの選択や更新を含むホスト管理が必要な構成では、実行基盤が誰の責任範囲にあるかを確認します。
イメージ、コンテナ、Docker
コンテナイメージは、実行時に使うファイルシステムのレイヤーやメタデータをまとめたテンプレートです。イメージそのものがCPUやメモリを抱えているわけではありません。イメージから起動した実行中のインスタンスをコンテナと呼びます。同じイメージから複数のコンテナを起動し、それぞれに異なる環境変数やリソースを与えることもできます。
Dockerは、コンテナイメージを構築し、コンテナを実行・配布するために広く使われるツール群です。イメージにアプリケーションの依存関係を含め、Dockerfileなどで構築手順をコード化すると、チームやパイプラインが同じ手順で成果物を作れます。ただし、「Dockerを使うならECS」「Kubernetesを使うならEKS」と機械的に決まるわけではありません。Dockerなどで作成したOCI互換イメージを、ECSやEKSを含む複数の基盤で実行できます。どのオーケストレーターを採用するかは、Kubernetes APIとの互換性、既存の運用知識、AWSサービスとの統合要件で判断します。
イメージの移動だけで実行環境が完全に同一になるわけではありません。CPUアーキテクチャ、ホストカーネル、環境変数、IAM権限、ネットワーク、外部ストレージなどは実行先ごとに確認が必要です。秘密情報をイメージ内へ焼き込まず、実行時に適切な仕組みから渡すことも重要です。
AWSコンテナ環境の役割分担
AWSでコンテナを使うときは、イメージを置く場所、コンテナの起動を調整するサービス、実際に処理を動かす計算資源を分けて考えます。
| 役割 | 主なサービス | 担当すること |
|---|---|---|
| イメージレジストリ | Amazon ECR | コンテナイメージを保管し、認証・アクセス制御やライフサイクル管理を行う |
| オーケストレーター | Amazon ECS、Amazon EKS | コンテナの定義、配置、起動数、ヘルス状態などを管理する |
| コンピューティング基盤 | Amazon EC2、AWS Fargate | コンテナのプロセスが実際に動くCPU・メモリなどを提供する |
この関係を、ビルドから実行までの流れで示します。
イメージを保管するAmazon ECR
**Amazon Elastic Container Registry（Amazon ECR）**は、コンテナイメージ用のマネージドレジストリです。ビルドしたイメージをリポジトリへプッシュし、ECSやEKSなどが実行時にそのイメージを取得します。Amazon ECRはプライベートリポジトリに加えてパブリックリポジトリも提供します。どちらを使う場合も、イメージを取得・登録する主体とアクセス範囲を適切に管理します。
ECRの主な役割は保管と配布です。ECRがコンテナを起動したり、タスク数を調整したりするわけではありません。古いイメージの整理にはライフサイクルポリシーを利用でき、脆弱性検査などの機能も構成できます。保存容量やデータ転送などの料金要素は利用形態により異なるため、必要なときはAmazon ECR料金ページで確認します。
コンテナを管理するECSとEKS
Amazon ECS
**Amazon Elastic Container Service（Amazon ECS）**は、AWSが提供するコンテナオーケストレーションサービスです。AWSのネットワーク、ロードバランサー、IAM、ECR、監視サービスなどと統合し、コンテナアプリケーションの実行とスケーリングを管理します。
ECSの構成を考えるときは、クラスター、サービス、タスク、タスク定義を区別します。コントロールプレーンとデータプレーンという見方をすると、ECSがクラスターやタスクの配置を管理する部分がコントロールプレーン、タスクのコンテナが実際に動作する計算資源がデータプレーンに当たります。これは役割を整理するための考え方です。利用者が「コントロールプレーン用のホスト」を作るわけではありません。
クラスター：タスクをまとめて管理する範囲
クラスターは、ECSのサービスや単独で実行するタスクをまとめて管理する論理的な境界です。複数のサービスを一つのクラスターに配置できます。クラスターという名前から、クラスター自体がサーバーの集合だと考えがちですが、ECSでは実行対象を整理し、キャパシティプロバイダーなどの実行資源と結び付けるための管理単位です。
EC2起動タイプでは、ECSコンテナエージェントを実行するEC2インスタンスをクラスターに登録し、コンテナを実行するキャパシティとして使います。インスタンスを複数のアベイラビリティゾーン（AZ）のサブネットに用意しておけば、サービスの配置先を複数AZに広げられます。ただし、クラスターに複数AZのインスタンスが存在するだけで、全サービスのタスクが自動的に均等配置されるわけではありません。サービスのネットワーク設定、配置戦略、利用可能なCPU・メモリ、各AZのキャパシティがそろっていることが必要です。
Fargate起動タイプでは、タスクの実行ホストを利用者が管理したりクラスターへ登録したりしません。ECSのクラスターやサービスでタスクを管理しつつ、Fargateがタスクを動かす基盤を提供します。複数AZにまたがるサブネットをネットワーク設定に含めると、ECSはその範囲でタスクを配置できます。外部インスタンスを使う構成では、オンプレミスなど利用者が管理するサーバーをECSへ登録する方法もあります。
サービス：必要なタスク数を維持する
サービスは、指定したタスク定義を使って、望ましい数（desired count）のタスクを継続稼働させる管理単位です。一つのサービスから、同じタスク定義の同じリビジョンを使う複数タスクを起動できます。稼働中のタスクが異常終了したり、基盤障害で停止したりすると、ECSサービススケジューラは実行中の数と望ましい数の差を検知し、必要なタスクを起動して数を保とうとします。
サービスはロードバランサーとの連携も設定できます。Application Load Balancer（ALB）やNetwork Load Balancer（NLB）のターゲットグループへタスクを登録すると、ヘルスチェックに合格したタスクへリクエストを振り分けられます。ECSはタスクの起動・停止に合わせてターゲット登録を管理します。
タスク：実行中のコンテナ群
タスクは、タスク定義を基に起動されたコンテナ群の実行単位です。一つのタスクにメインのアプリケーションコンテナだけを置くことも、ログ転送やプロキシなどを担う補助コンテナと一緒に置くこともできます。同一タスク内のコンテナは、タスク定義で指定したネットワークやストレージの構成を共有します。タスク内のコンテナ同士は連携しやすい一方、独立してスケールさせる単位ではありません。
同じEC2インスタンス上では、リソースに余裕があり配置条件を満たせば、異なるサービスに属するタスクを同時に実行できます。Fargateの場合、実行ホストの選定や管理は利用者から隠蔽されます。バッチ処理など一度実行すればよい処理では、サービスを作らずにタスクを直接起動する選択肢もあります。
タスク定義とコンテナ定義
タスク定義はタスクの起動方法を記述する設計図です。タスク定義を登録するたびにリビジョンが作成され、サービスやタスクは利用するリビジョンを指定します。新しい設定やコンテナイメージへ更新するときは、新しいリビジョンを登録してサービスのデプロイ対象を更新します。定義を変更しても、既存のサービスが自動的に新しいリビジョンへ切り替わるわけではありません。
タスク定義では、コンテナ定義のほか、タスク全体のCPU・メモリ、ネットワークモード、ボリューム、実行時のプラットフォームなどを構成します。ログ設定は各コンテナ定義に記述します。IAMロールは用途が二つに分かれます。
- タスクロールは、アプリケーションコードがAWS APIを呼び出すときに使う権限です。たとえば在庫更新タスクがDynamoDBへ書き込む場合、その操作を許可する権限をタスクロールに与えます。
- タスク実行ロールは、ECS/FargateエージェントがイメージをECRから取得したり、ログをCloudWatch Logsへ送ったり、Secrets Managerのシークレットを起動時に取得したりするための権限です。アプリケーションコードへ渡す権限ではありません。
起動タイプやキャパシティプロバイダーの選択は、タスク定義のロールやコンテナ設定とは別に、タスク実行・サービスの設定で指定します。EC2とFargateのどちらを使うかという実行基盤の選択を、コンテナごとのCPU・メモリ設定と混同しないようにします。
コンテナ定義はタスク内の個々のコンテナを設定します。コンテナイメージ、コンテナ単位のCPU・メモリ、ポートマッピング、環境変数、ログ設定、ヘルスチェック、コンテナ間の起動依存関係などを指定できます。アプリケーション本体と補助コンテナで必要な設定が異なる場合、それぞれ別のコンテナ定義を用意します。パスワードやAPIキーなどの秘密情報は、平文の環境変数やイメージへ固定せず、Secrets ManagerやSystems Manager Parameter Storeなどから安全に渡す方法を検討します。
ネットワークモードとロードバランサー
awsvpcネットワークモードでは、各タスクにElastic Network Interface（ENI）が割り当てられ、タスクはVPC内のIPアドレスを持ちます。タスクごとにセキュリティグループを適用でき、VPC内の独立したネットワークエンドポイントとして扱えます。このモードを使うタスクをALBやNLBのターゲットにする場合は、ターゲットグループのターゲットタイプをipにします。Fargateタスクはawsvpcを使用します。
一方、EC2起動タイプでbridgeなどのネットワークモードを選ぶと、タスクに個別のENIを割り当てない構成も取れます。その場合は、ターゲットグループでEC2インスタンスをターゲットにし、コンテナのポートへ転送する設定を使います。したがって「ECSのタスクは常にIPターゲット」というわけではなく、ネットワークモードと起動基盤に合わせてターゲットタイプを選びます。
タスク数と実行キャパシティのスケーリング
ECSでは、アプリケーションのタスク数と、それを実行する計算資源の量を別々に考えます。Application Auto ScalingによるサービスのService Auto Scalingは、CloudWatchメトリクスなどを条件にサービスの望ましいタスク数を増減します。たとえばリクエストが集中してCPU使用率が高まったときにタスク数を増やし、負荷が下がったら縮小できます。
サービスの望ましいタスク数を増やしても、配置先のキャパシティが足りなければタスクは起動待ちになることがあります。EC2起動タイプでは、Auto Scaling グループやキャパシティプロバイダーのマネージドスケーリングを使って、クラスター内のEC2インスタンス数を増やす構成を検討します。つまり、タスク数のスケーリングとホスト台数のスケーリングは別の制御です。Fargateではホスト台数を利用者が調整する必要はありませんが、クォータ、サブネットのIPアドレス、サービスのタスク数上限などは考慮が必要です。
Amazon EKS
**Amazon Elastic Kubernetes Service（Amazon EKS）**は、Kubernetesを使ってコンテナ化アプリケーションを管理するマネージドサービスです。KubernetesのAPIやエコシステム、既存のKubernetes運用との共通性が必要な場合に適します。AWSはKubernetesコントロールプレーンを管理しますが、ワーカーノード、アドオン、ネットワーク、ワークロードの設計など、利用者が選び構成する領域は残ります。マネージドサービスであっても、クラスタ全体の運用がなくなるわけではありません。
AWS中心のシンプルなコンテナ運用とサービス統合を優先するならECS、Kubernetesとの互換性や標準API・エコシステムを必要とするならEKSが判断の出発点です。どちらでも、イメージの保管先やコンピューティング基盤を要件に応じて組み合わせます。
実行基盤：EC2とFargate
ECSやEKSがコンテナを管理しても、コンテナを動かす計算資源は別に必要です。AWSでは、EC2インスタンスを使う方法と、AWS Fargateへ基盤管理を任せる方法が代表的です。
| 選択肢 | 利用者が管理するもの | 向いている要件 |
|---|---|---|
| EC2 | インスタンスの種類・台数、OS、パッチ、キャパシティなど | ホストを細かく制御したい、特定のインスタンス機能が必要、基盤を継続利用して費用を管理したい |
| Fargate | タスクやPodに必要なCPU・メモリ、実行設定など | ホストのプロビジョニングやOS運用を減らし、アプリケーションの実行単位で管理したい |
Fargateはコンテナのオーケストレーターではなく、コンテナを実行するサーバーレスのコンピューティング基盤です。ECSまたはEKSと組み合わせて利用します。したがって「ECSかFargateか」という二者択一ではなく、「ECSかEKSか」と「EC2かFargateか」は別の選択軸です。料金は割り当てるリソースや稼働時間などに基づきます。EC2ではインスタンスなどの基盤リソース、Fargateではタスクに割り当てたリソースが主な比較対象となるため、AWS Fargate料金ページとAmazon ECS料金ページで現在の課金条件を確認します。
AWS内の標準的な実行先以外を選ぶ
ECS AnywhereとAmazon ECS Distro
コンテナをAWS外のサーバーで実行する場合も、ECSによる管理を使いたいならAmazon ECS Anywhereが選択肢になります。ECS Anywhereは、オンプレミスや他クラウドなどの顧客管理インスタンスをECSへ外部インスタンスとして登録し、AWS上のECSコントロールプレーンから管理する仕組みです。登録対象にはECSコンテナエージェントやAWS Systems Manager Agentなどの準備が必要です。外部インスタンス自体の調達、OS、ネットワーク接続、パッチ適用などは利用者が管理します。単に「コンテナを外で動かす」ことと「AWS上のECSから外部インスタンスを管理する」ことは区別します。
Amazon ECS Distroは、ECSを構成するコンポーネントを利用者が取得・構築できるオープンソースのディストリビューションです。ECS Anywhereのように外部インスタンスをECSサービスへ登録する機能と同じものではありません。ECS Distroを使った独自運用では、コンポーネントを組み合わせる基盤や保守を利用者が担うため、AWSのECSコントロールプレーンを使うECS Anywhereとは運用モデルが異なります。
Elastic Beanstalk
AWS Elastic Beanstalkは、アプリケーションのデプロイと環境管理をまとめて簡素化するマネージドサービスです。Docker対応プラットフォームを使うと、アプリケーションとコンテナイメージをデプロイし、環境に必要なAWSリソースのプロビジョニングやヘルス監視をサービスに任せられます。ECSやEKSのようにコンテナ配置の詳細を直接設計・管理するよりも、Webアプリケーションの環境全体を手早く用意したい場合に向きます。
抽象化が高い分、基盤を細かく制御する余地はECSでEC2を直接選ぶ構成などより限られます。ホストやコンテナ実行の構成を自在に制御する必要がある場合は、その要件を満たせるかを先に確認します。
AWS Lambdaのコンテナイメージ
AWS Lambdaはコンテナイメージをデプロイパッケージとして利用できます。一般的なDockerイメージをそのまま長時間動かすコンテナ基盤ではなく、Lambdaの実行モデルに適合したイメージを使い、イベントやリクエストに応じて関数を呼び出します。イメージはAmazon ECRに置き、Lambdaランタイムとの連携要件を満たす必要があります。
Lambda関数は、実行時間やメモリなどにサービス上の上限があります。標準の関数タイムアウトは最大15分です。そのため、短時間で完了するイベント駆動処理には適しますが、上限を超えて動き続ける常駐プロセスや長時間ジョブの実行先にはなりません。コンテナ化されていることだけでECS/Fargateのような長時間実行ができるわけではありません。最大イメージサイズを含む要件は更新されることがあるため、Lambdaのコンテナイメージに関する公式ガイドで確認します。
AWS Batch
AWS Batchは、バッチ処理やジョブ指向のワークロードをスケジューリングし、必要な計算資源上で実行するサービスです。コンテナイメージを含むジョブ定義、実行待ちジョブを管理するキュー、処理を実行するコンピューティング環境などを使います。単発または並列化できる大量のジョブを、キューの優先度や必要なリソースに応じて処理する用途に適します。
AWS Batchはジョブのスケジューリングと計算資源の調整を行うサービスであり、ECRのようなイメージレジストリではありません。ジョブ定義で参照するイメージを用意し、キューと実行環境を構成します。常時稼働するWebサービスならECSやEKS、イベントごとに短時間処理を実行するならLambda、キューに蓄積するジョブをまとめて効率よく処理するならAWS Batch、というように処理形態で比較します。
要件から構成を選ぶ
| 要件 | 検討する構成 |
|---|---|
| AWS内でDocker/OCIイメージを保管・配布する | Amazon ECR |
| AWSネイティブなオーケストレーションでサービスやタスクを管理する | Amazon ECS |
| Kubernetes API、既存クラスタとの共通性、Kubernetesエコシステムが必要 | Amazon EKS |
| EC2ホストの種類やOSを制御する | ECSまたはEKSとAmazon EC2 |
| ホストのプロビジョニング・管理を減らしてコンテナを動かす | ECSまたはEKSとAWS Fargate |
| AWS上のECSからオンプレミス等の顧客管理サーバーを管理する | Amazon ECS Anywhere |
| Webアプリの環境構築とデプロイをまとめて簡素化する | AWS Elastic Beanstalk |
| 最大15分以内のイベント駆動処理を関数として実行する | AWS Lambdaのコンテナイメージ |
| キューに基づいて大量・並列のバッチジョブを実行する | AWS Batch |
サービス名を暗記するだけでなく、「イメージをどこに置くか」「何が実行数や配置を管理するか」「ホストを誰が運用するか」「処理が常駐型・イベント駆動・ジョブ型のどれか」を順に整理すると、選択肢を比較しやすくなります。
参考資料
重要ポイント
- ▸コンテナイメージはアプリケーションと依存ファイルをまとめた実行用テンプレートで、実行時にはホストOSのカーネルを共有する
- ▸ECRはイメージの保管場所、ECSとEKSは実行を管理するオーケストレーター、EC2とFargateは主なコンピューティング基盤
- ▸ECSはAWSネイティブなコンテナ管理、EKSはKubernetesとの互換性やエコシステムが必要な場合に選ぶ
- ▸クラスターはECSの論理的な管理範囲、サービスは望ましいタスク数を保つ管理単位、タスクは実行中のコンテナ群
- ▸タスク定義は起動設定、コンテナ定義はタスク内の個別コンテナ設定であり、タスクロールとタスク実行ロールの用途も異なる
- ▸サービスのタスク数とEC2起動タイプのホスト台数は別々にスケーリングし、実行キャパシティも確保する
- ▸Fargateはサーバー管理をAWSへ任せる実行基盤で、ECSまたはEKSのオーケストレーションと組み合わせる
- ▸ECS Anywhere、Elastic Beanstalk、Lambda、AWS Batchは実行場所や処理形態に応じた異なる選択肢
このトピックの学習を完了しますか？
完了状態はいつでも切り替えられます