CLF / ドメイン3 クラウドテクノロジーとサービス
Amazon ECS (Elastic Container Service)
は、多数のの配置、管理、スケーリングを自動化する、フルマネージドなコンテナサービスです。 アプリケーションを「タスク」や「サービス」という単位で動かし、コンテナ運用の手間を大きく減らせます。
CLF では、コンテナの基本概念、 起動タイプと の違い、・・ との使い分けを判断できることが重要です。
Point
- ECS = Elastic Container Service の略です。
- Container(コンテナ) は「入れ物」という意味で、アプリケーションと実行に必要な部品をひとまとめにした軽量なパッケージを指します。
- Orchestration(オーケストレーション) は「指揮・調整」という意味です。オーケストラの指揮者のように、多数のコンテナの起動・配置・監視をまとめて調整するイメージで覚えます。
- 和訳
- Orchestration: 編成、組織化
- Weblio英和辞書「orchestration」
概要
は、アプリケーション本体と、その実行に必要なライブラリや設定をひとまとめにした実行環境です。 どのサーバーでも同じように動くため、「開発環境では動いたのに本番では動かない」という問題を減らせます。 Docker は、このコンテナを作成・実行するための代表的なツールです。
コンテナが数個であれば手動でも管理できますが、数十、数百になると、どのサーバーで動かすか、停止したらどう復旧するか、負荷が増えたらどう増やすか、といった管理が人手では追いつきません。 この管理を自動化するのがサービスであり、AWS では がその代表です。
代表的な用途は、Web アプリケーションや の実行、バッチ処理、(小さなサービスの組み合わせでシステムを作る方式)の運用です。
試験では、「コンテナをどのサービスで動かすか」「サーバー管理をなくしたい場合に何を選ぶか」「Kubernetes が要件に含まれる場合はどうするか」を判断します。
主要技術
①コンテナと仮想マシンの違い
と のようなは、どちらもアプリケーションの実行環境を分離する技術ですが、分離の単位が異なります。 仮想マシンは ごと丸ごと分離するのに対し、コンテナは OS を共有したまま、アプリケーションの実行環境だけを分離します。
| 項目 | コンテナ | 仮想マシン(EC2 など) | 判断ポイント |
|---|---|---|---|
| 分離の単位 | アプリケーションと実行環境 | OS を含むマシン全体 | 軽量さを求めるならコンテナです。 |
| 起動時間 | 秒単位で高速 | OS の起動を含むため比較的長い | 素早い起動・停止の繰り返しに向くのはコンテナです。 |
| 移植性 | イメージがあればどこでも同じ動作 | 環境ごとの構築・調整が必要 | 「環境差をなくしたい」はコンテナです。 |
Point
- Docker(ドッカー) はコンテナを作成・実行するための代表的なツールで、ECS は Docker 形式のコンテナをサポートします。
- コンテナイメージ は、コンテナの元になる設計図付きのパッケージです。イメージから同じコンテナを何個でも起動できます。
- 「イメージ = 金型、コンテナ = 金型から作った製品」のイメージで覚えます。
②タスク定義・タスク・サービス・クラスター
では、次の用語での実行を管理します。 公式ドキュメントでは、タスク定義は「アプリケーションの設計図」と説明されています。
| 用語 | 役割 | 判断ポイント |
|---|---|---|
| タスク定義 | 使用するイメージ、・メモリなどを記述した設計図です。 | 「何をどう動かすか」の定義が必要なときに使います。 |
| タスク | タスク定義から起動された実行中のコンテナのまとまりです。 | バッチ処理のように、実行して終了する用途に向きます。 |
| サービス | 指定した数のタスクを維持し続ける仕組みです。 | Web アプリのように動き続ける用途に向きます。 |
| クラスター | タスクやサービスを動かす基盤のまとまりです。 | 実行環境全体のグループ分けに使います。 |
サービスはタスクが異常停止した場合に自動で置き換え、 と連携してトラフィックを複数のタスクへ分散できます。
③起動タイプ: EC2 起動タイプと Fargate ⚠️ 頻出
では、を動かす基盤(キャパシティ)を選択できます。 CLF で最も問われるのは、 起動タイプと の違いです。
| 項目 | EC2 起動タイプ | AWS Fargate | 判断ポイント |
|---|---|---|---|
| サーバー管理 | 利用者が EC2 インスタンスを管理します。 | 不要です()。 | 「サーバー管理をなくしたい」なら Fargate です。 |
| インフラの制御 | や を細かく選べます。 | 基盤は AWS が管理し、利用者は意識しません。 | 細かい制御やカスタマイズが要件なら EC2 です。 |
| 料金の考え方 | 起動した EC2 インスタンスに対して支払います。 | タスクが使用した vCPU とメモリに対して支払います。 | 使った分だけ支払いたいなら Fargate です。 |
| パッチ適用 | 利用者の責任範囲が広くなります。 | 基盤のパッチ適用は AWS が行います。 | の範囲が変わる点に注意します。 |
ECS 自体には追加料金がなく、コンテナを動かすために使用した EC2 インスタンスや Fargate などのリソースに対して支払います。
Point
- Fargate(ファーゲート) は、サーバーの管理なしでコンテナを実行できるサーバーレスのコンピューティングエンジンです。
- サーバーレスは「サーバーが存在しない」のではなく、「利用者がサーバーを管理しなくてよい」という意味です。
- Fargate は ECS と EKS の両方で利用できます。
- このほか、オンプレミスのサーバーを ECS に登録して使う ECS Anywhere という選択肢もあります。
⚠️ 頻出: 「コンテナを実行したいが、サーバーのや管理をしたくない」という問題文は、Fargate が答えになります。
④Amazon ECR との関係
(Elastic Container Registry)は、イメージを保存・管理するフルマネージドなレジストリサービスです。 開発者が作成したイメージを ECR にプッシュ(アップロード)し、 がそのイメージをプル(ダウンロード)してコンテナを起動する、という流れで連携します。
ECR は でアクセス制御でき、イメージの脆弱性スキャンや、古いイメージを自動削除するライフサイクルポリシーも提供します。 料金は、保存したデータ量とデータ転送などに対するです。
Point
- ECR = Elastic Container Registry の略です。
- Registry(レジストリ) は「登録簿」という意味で、コンテナイメージ版の S3 のような保管庫とイメージすると覚えやすいです。
- 役割分担は「ECR = イメージを保管する」「ECS = イメージを実行する」です。
- 和訳
- Registry: 登記所、登録簿
- Weblio英和辞書「registry」
⚠️ 頻出: 「コンテナイメージを保存・管理する場所」は ECR、「コンテナを実行・管理するサービス」は ECS です。名前が似ているため役割で区別します。
⑤Amazon EKS との違い ⚠️ 頻出
(Elastic Kubernetes Service)は、のオープンソースソフトウェアである Kubernetes を、AWS がマネージドで提供するサービスです。 と EKS はどちらもコンテナオーケストレーションサービスですが、使う技術と向いている場面が異なります。
| 項目 | Amazon ECS | Amazon EKS | 判断ポイント |
|---|---|---|---|
| オーケストレーションの方式 | AWS 独自の方式です。 | Kubernetes を使用します。 | 「Kubernetes」という言葉が要件にあれば EKS です。 |
| 学習・運用のしやすさ | AWS に統合されておりシンプルです。 | Kubernetes の知識が必要です。 | シンプルさ重視なら ECS です。 |
| 移植性・既存資産 | AWS 上での利用が中心です。 | Kubernetes 標準のツールや既存のマニフェストを活用できます。 | の Kubernetes からの移行なら EKS です。 |
| 追加料金 | ECS 自体は追加料金なしです。 | クラスターごとの料金がかかります。 | どちらも実行リソースの料金は別途かかります。 |
Point
- EKS = Elastic Kubernetes Service の略です。
- Kubernetes(クバネティス、K8s) は、コンテナオーケストレーションの事実上の標準となっているオープンソースソフトウェアです。
- EKS は Kubernetes 認定準拠(certified Kubernetes-conformant)で、標準の Kubernetes ツールをそのまま使えます。
- 試験では「Kubernetes と書いてあったら EKS」と覚えます。
⚠️ 頻出: 問題文に「Kubernetes を使いたい」「Kubernetes 互換が必要」とあれば EKS、単に「コンテナを AWS でシンプルに動かしたい」なら ECS が基本です。
⑥AWS Lambda との使い分け
は、イベントをきっかけに関数単位のコードを実行するコンピューティングサービスです。 と同じくサーバー管理は不要ですが、実行の単位と向いている処理が異なります。
| 項目 | (Fargate 含む) | AWS Lambda | 判断ポイント |
|---|---|---|---|
| 実行の単位 | (タスク・サービス) | 関数(コード) | コンテナが前提なら ECS です。 |
| 実行時間 | 長時間動き続けるアプリに対応します。 | 1 回の実行は最大 15 分です。 | 長時間処理や常駐アプリは ECS です。 |
| 起動のきっかけ | サービスとして常時稼働、またはタスクとして実行します。 | へのアップロードなどのイベントで起動します。 | 「で短い処理」なら Lambda です。 |
| 料金の考え方 | 使用した vCPU・メモリ(Fargate の場合)に支払います。 | リクエスト数と実行時間に支払います。 | 実行頻度が低い短時間処理は Lambda が有利になりやすいです。 |
⚠️ 頻出: 「ファイルがアップロードされたら数秒の処理を実行する」は Lambda、「コンテナ化した Web アプリを常時稼働させる」は ECS(+ Fargate)が基本の判断です。
試験対策
CLF の問題では、まず「」という言葉が問題文にあるかを確認します。 コンテナが前提なら ・・・ のいずれかを軸に考え、次に「Kubernetes の要否」と「サーバー管理の要否」で絞り込みます。
| 問題文のキーワード | 優先して考える機能・サービス | 理由 |
|---|---|---|
| コンテナを・大規模に管理 | Amazon ECS | AWS のフルマネージドなコンテナオーケストレーションサービスです。 |
| サーバーを管理せずにコンテナを実行 | AWS Fargate | でコンテナを実行できます。 |
| や を細かく制御してコンテナを実行 | ECS の 起動タイプ | 基盤となる EC2 を利用者が選択・管理できます。 |
| コンテナイメージを保存・管理 | Amazon ECR | フルマネージドなコンテナイメージレジストリです。 |
| Kubernetes を使いたい・Kubernetes 互換が必要 | Amazon EKS | マネージドな Kubernetes サービスです。 |
| イベントをきっかけに短時間のコードを実行 | 関数単位のサーバーレスコンピューティングです。 | |
| のサーバーでもコンテナを管理 | オンプレミスの環境を ECS クラスターに登録できます。 |
よくある誤答のパターンは次のとおりです。
- ECS と ECR の混同です。ECS は「実行・管理」、ECR は「イメージの保管」であり、役割が異なります。
- 「サーバーレスでコンテナ」という要件に EC2 起動タイプを選ぶことです。サーバー管理をなくすなら Fargate です。
- 「Kubernetes」という指定があるのに ECS を選ぶことです。Kubernetes が要件に含まれる場合は EKS を選びます。
- 「コンテナ化されたアプリ」という要件に Lambda を選ぶことです。Lambda は関数単位のサービスであり、コンテナのオーケストレーションが要件なら ECS・EKS を優先します。
また、の観点では、Fargate を使うと基盤サーバーの管理が AWS 側に移るため、利用者の運用負荷と責任範囲が小さくなる、という整理も押さえておきます。