Amazon DOP-C02: コンテナとサーバーレスオペレーション — 学習ガイド

By Laurynas Brazys · 4 August 2026 · #amazon #dop-c02 #certification #exam-prep #study-guide

こちらの一部です： AWS DevOps Engineer Professional DOP-C02 — 学習ガイド. 検証済みの解答で練習： Amazon試験ハブ, または時間制限付き模擬試験に挑戦： ExamRoll.io.

概要

コンテナとサーバーレスは、AWS上でのアプリケーションの運用、スケーリング、リリース方法を変革します。このセクションでは、Amazon ECS、AWS Fargate、Amazon EKS、Amazon ECR、AWS Lambda、Amazon API Gatewayにわたる運用プリミティブを関連付け、安全なデプロイの設計、イメージガバナンスの強制、同時実行数のチューニング、EC2ベースとFargateベースのキャパシティ間での一貫した選択ができるようにします。タスクとPodのスケジューリングモデル、ヘルスチェックとデプロイメント制御、トラフィックシフト、アカウント間のイメージ配布、APIキャッシングやLambdaのプロビジョニング済み同時実行などのパフォーマンス機能に焦点を当てます。

Amazon ECS and AWS Fargate

ECSのタスク定義は、1つ以上のコンテナと、スケジューラが必要とするすべてのランタイム設定を宣言します。主要な要素には、CPU/メモリの予約と制限、portMappings、環境変数とシークレット（AWS Secrets ManagerまたはSystems Manager Parameter Storeから）、Linuxパラメータとulimits、logConfiguration（awslogs、firelensなど）、ephemeralStorageサイズ（Fargateの場合、20～200 GB）、ボリューム（EFSを含む）が含まれます。イメージのプルとログドライバーにはタスク実行ロールを使用し、アプリケーションのAWS APIアクセスにはタスクロールを使用します。コンテナのhealthCheckは、コマンド、間隔、タイムアウト、リトライ、startPeriodを定義します。dependsOn（condition=HEALTHY）と組み合わせることで、ヘルスチェックはサイドカーの起動順序を強制します。

ECSサービスは、望ましいタスク数を維持し、オプションでタスクをALB/NLBに登録します。サービスのdeploymentConfigurationは、minimumHealthyPercentとmaximumPercentでローリングアップデートを制御します。デプロイメントサーキットブレーカー（enabled/rollback）は、タスクがヘルスチェックに失敗した場合に、失敗したロールアウトを自動的に元に戻すことができます。サービスのオートスケーリングは、Application Auto Scalingと統合され、CPU/メモリベースのターゲット追跡やALBのRequestCountPerTargetに対応します。サービスディスカバリ（AWS Cloud Map）とECS Service Connectは、サービス間のトラフィックを簡素化します。

クラスタータイプとキャパシティ：

• EC2起動タイプは、自己管理のEC2インスタンス上でタスクを実行します。Auto Scalingグループ、配置制約/戦略、および任意のnetworkMode（bridge/host/awsvpc）を使用します。デーモンタスクや特殊なAMI（例：Bottlerocket）がサポートされています。
• Fargate起動タイプは、コンテナ向けのサーバーレスコンピューティングです。awsvpcネットワークモードのみを使用し、各タスクに独自のENIとセキュリティグループを付与します。デーモンタスクはなく、サイドカーやサービスネイティブの統合（例：FireLens）に依存します。プラットフォームバージョンが機能をゲートします（EFS、エフェメラルストレージ、execサポートについてはリリースノートを確認してください）。Fargate Spotは、中断可能なタスクのコストを削減します。サポートされているペア（例：0.25 vCPU/0.5–2 GBから16 vCPU/120 GBまで）でCPU/メモリを選択します。プライベートサブネットで実行する場合、ECR（apiおよびdkr）、CloudWatch Logs用のVPCインターフェイスエンドポイントと、S3ゲートウェイエンドポイントを追加して、NATなしでイメージをプルし、ログを転送します。

FargateとEFS：タスク定義でEFSボリュームを定義し、TLSでマウントします。最小権限とID強制のためにEFSアクセスポイントの使用を推奨します。これにより、共有設定、モデルの重み、中間ファイルなどのステートフルなニーズを、イメージに焼き込むことなくサポートします。

コンテナのヘルスチェック、ローリングアップデート、ブルー/グリーン：

• ヘルスチェックは複数のレイヤーで行われます：コンテナ（CMDベース）、ECSタスク（集約されたコンテナのステータス）、ロードバランサーのターゲットヘルス（HTTP/TCP）。ALBがターゲットを登録解除する前にECSが不健全なタスクを正常に置き換えられるように、間隔としきい値を調整します。
• ローリングアップデートはECSのデフォルトです。minHealthy/maxPercentを調整して、サージとキャパシティの安全性を制御します。
• ブルー/グリーンは、ECSでCodeDeployを使用します（deploymentControllerタイプは⟦CODE_DEPLOY⟧）。CodeDeployはALBの背後にある2つのターゲットグループを管理し、テストトラフィックをグリーンセットにシフトし（AfterAllowTestTraffic）、自動チェック（例えばLambda経由）を実行した後、本番トラフィックをシフトします。5XXの急増やレイテンシー、カスタムメトリクスに基づいてロールバックするためにCloudWatchアラームを関連付けます。このパターンは障害を隔離し、ほぼゼロダウンタイムでの迅速な復帰を提供します。

ECRによるイメージガバナンス：

• スキャン：プッシュ時のスキャンを有効にし、Amazon Inspectorの拡張スキャンを採用して、継続的なCVEカバレッジとSBOMを実現します。パイプラインチェックを使用して、脆弱性の重大度に基づいてデプロイを制御します。
• ライフサイクルポリシーは、数/期間とタグプレフィックスによって古いイメージタグを失効させます。タグの不変性と組み合わせて、偶発的な上書きをブロックします。
• 暗号化：ECR管理の暗号化または適切なキーポリシーを持つカスタマー管理のKMSキーを使用します。
• アカウント間：リポジトリのリソースポリシーをアタッチして、他のアカウントやCIロールからのプル/プッシュを許可します。ECRレプリケーションルールを使用して、リージョン/アカウント間でイメージをコピーし、ローカリティと爆発半径を縮小します。PrivateLink（VPCエンドポイント）により、インターネットなしでイメージをプルできます。

Amazon EKS のコンピューティングモデル

EKS は、マネージドコントロールプレーンと、ユーザーが選択するデータプレーンを分離します:

マネージド型ノードグループ (MNG) は、EC2 ワーカーノードのプロビジョニングとライフサイクル管理を行います。起動テンプレートと統合されており、AMI (Amazon Linux 2, Bottlerocket)、インスタンスタイプ、ブートストラップパラメータを選択できます。MNG は、サージキャパシティを伴うローリングアップデートと、自動化されたコーディング/ドレインを処理し、中断を最小限に抑えます。ノードのテイント/容認 (taints/tolerations) を使用して、特定のワークロードを誘導します。Cluster Autoscaler (または Karpenter) と組み合わせることで、ペンディング中のポッドに基づいてノードキャパシティを適正化します。

セルフマネージド型ノードは、ブートストラップと OS を完全に制御できますが、運用上のオーバーヘッドが増加します。通常、特殊なカーネルやニッチなハードウェア向けに利用されます。

EKS on Fargate は、ノードを管理することなくポッドを実行します。Fargate プロファイルは、名前空間/ラベルを Fargate にマッピングします。各ポッドは独自の ENI (awsvpc) を取得し、ネットワーク分離を簡素化します。制限事項として、DaemonSet やホストネットワーキング/ボリュームが利用できず、特権ワークロードにも制約があります。可観測性エージェント (例: Fluent Bit) は、サイドカーとして実行するか、マネージドログ収集を使用する必要があります。このモデルは、ポッドごとの分離とポッド単位の課金モデルの恩恵を受ける、スパイク的、小規模、またはマルチテナントのワークロードに最適です。

運用アドオン:

• VPC CNI、CoreDNS、kube-proxy はマネージドアドオンです。クラスターバージョンと互換性のあるバージョンに固定し、意図的にアップグレードします。
• IAM Roles for Service Accounts (IRSA) は、ポッドごとに最小権限の AWS アクセスを強制し、ノードロールによる認証情報共有を置き換えます。
• AWS Load Balancer Controller によるロードバランシングは、Service と Ingress に対する ALB/NLB をサポートします。特に MNG と Fargate を混在させる場合は、適切な IAM とセキュリティグループルールを確認してください。
• CSI ドライバによる永続ストレージ (ポッドごとのブロックには EBS、共有 POSIX には EFS)。Fargate の場合、共有ステートには EFS が一般的な選択肢です。

AWS Lambda の運用と同時実行性

パッケージングと設定:

• デプロイパッケージは、ZIP アーカイブ (言語ランタイムを含む) または最大 10 GB のコンテナイメージが使用できます。ZIP は小規模なコードに対して軽量であり、イメージはコンテナベースのビルドでツールを統一します。
• レイヤーは、複数の関数で共有されるライブラリをカプセル化します。最小限に抑え、バージョニングしてください。1つの関数には最大5つのレイヤーを含めることができます。
• バージョンは不変のスナップショットです。エイリアスはバージョンへの安定したポインタであり、トラフィックシフトのための重みを持つことができます。
• エフェメラルストレージはデフォルトで 512 MB で、ビルド、一時ファイル、ML 推論キャッシュのために最大 10,240 MB まで増やすことができます。コストとパフォーマンスのトレードオフに応じて x86_64 または arm64 を選択します。設定には環境変数を使用し、Secrets Manager または Parameter Store と統合します。

トラフィックシフトと安全性:

• CloudWatch アラーム (例: 5XX、レイテンシー、カスタムアプリケーションメトリクス) に基づく自動ロールバックを伴うカナリア/リニアシフトには CodeDeploy を使用します。あるいは、単純な A/B ルーティングのためにエイリアスの重みを直接設定することもできます。
• CloudWatch Logs への構造化ロギングを使用し、メトリクスフィルターを作成して、メトリクスの計装を変更することなく、オペレーション/バージョン/コードでディメンション化されたメトリクスを導出します。エンドツーエンドのレイテンシートレーシングには X-Ray を有効にします。

同時実行数の制御:

• 予約されていない同時実行数は、アカウントのリージョンごとのプールから使用されます。スパイク的なトラフィックは、他の関数を枯渇させる可能性があります。
• 予約された同時実行数は、関数の最大同時実行数に上限を設定し、リージョンのプールから容量を確保することで、そのキャパシティを保証します。これにより、ノイジーネイバーからの分離が提供されます。
• プロビジョニングされた同時実行数は、バージョン/エイリアスの実行環境を初期化された状態に保ち、コールドスタートを実質的に排除し、レイテンシーを安定させます。Application Auto Scaling を使用して、時間帯やメトリクスに基づいてプロビジョニングされた同時実行数をスケーリングします。
• スロットリングは、関数が同時実行数の上限に達したときに発生します。同期呼び出し元は 429 エラーを受け取りますが、非同期呼び出しは指数関数的バックオフで再試行され、設定された試行回数の後にデッドレター化される可能性があります。SQS のようなポーリングベースのソースの場合、Lambda はキューの深さに応じて同時実行数を増やします。バックログの増加を避けるために、予約/プロビジョニングされた同時実行数とダウンストリームのキャパシティが、処理中の最大メッセージ数と一致するようにしてください。

API Gatewayの設計とECRのクロスアカウントアクセス

API Gateway REST APIとHTTP APIの比較：

• REST APIは最も豊富な機能セットを提供します：リクエスト/レスポンスマッピング (VTL)、使用量プランとAPIキー、オーソライザー、WAF、ステージレベルのキャッシュ。高度な変換、クォータ付きのAPIキー、または成熟したエコシステムとの統合が必要な場合は、REST APIを選択します。
• HTTP APIは、より低レイテンシーかつ低コストで、LambdaやHTTPバックエンド (ALB/NLB/プライベート統合を含む) へのルーティングがよりシンプルです。JWTオーソライザーとIAMをサポートしますが、ステージレベルのキャッシュやVTL変換など、REST APIの多くの機能がありません。オーバーヘッドを最小限に抑えた単純なプロキシ処理には、HTTP APIを選択します。

ステージとスロットリング：

• ステージは、特定のデプロイをURLパスにバインドします。ステージ変数、ロギング、スロットリングをステージで設定します。使用量プラン (REST) を適用して、APIキーごとのスロットルとクォータを強制します。スロットリング設定にはレートとバーストが含まれ、これらはアカウントレベルの制限と組み合わされるため、総トラフィックがリージョンごとのクォータを超えないように注意してください。構造化JSONによるアクセスロギングを有効にし、WAFを統合して悪意のあるリクエストを検査・ブロックします。

キャッシュ (REST APIのみ)：

• ステージレベルのキャッシュは、バックエンドの負荷とレイテンシーを削減します。メソッドごとにTTLを設定し、暗号化を有効にし、正確性のためにキャッシュキーのパラメータ/ヘッダーを検討します。レスポンスの形状や動作を変更するデプロイの後は、キャッシュを無効化します。

プライベート接続：

• エンドポイントタイプを選択します：エッジ最適化 (REST、CloudFront経由でグローバル)、リージョン、またはプライベート (VPCエンドポイント)。VPC Linkを使用したプライベート統合は、VPC内のNLB/ALBバックエンドにパブリックに公開することなく接続します。

ECRのクロスアカウントアクセス：

• リポジトリのリソースポリシーを使用して、他のアカウントのプリンシパル (CI/CDやランタイムロール) にpull/pushを許可します。カスタマーマネージドKMSキーを使用している場合は、それに応じてキーポリシーを拡張します。マルチアカウントでの配布には、ECRのレプリケーションルールを定義して、宛先のアカウント/リージョンをターゲットにし、タグの不変性とデプロイでのダイジェストの固定によってイメージの整合性を検証します。

実践的な問題シナリオ

Spotify社は、ピークリリース時のレイテンシー変動を低減し、複数のAWSアカウントにまたがるイメージサプライチェーンを強化するために、プレイリストマイクロサービススタックをモダナイズしています。

1. イメージのビルドとガバナンスの標準化

• scan-on-pushとAmazon Inspectorの拡張スキャンを備えたECRリポジトリを実装します。タグの不変性とライフサイクルポリシーを追加して、ブランチごとに最新のNバージョンを保持し、ドリフトを整理します。ビルドアカウントから本番およびステージングアカウントへのクロスリージョン/アカウントレプリケーションを設定します。 理由：Inspectorは継続的なCVEカバレッジを保証し、不変性はタグのハイジャックを防ぎ、レプリケーションはプルをローカライズしてデプロイのレイテンシーと影響範囲を縮小します。

2. Fargate上のECSでステートレスAPIを提供

• awslogsとFireLensを使用して、構造化ログとメトリクスのためのECSタスク定義を定義します。コンテナのhealthCheckを有効にし、ALBターゲットグループのヘルスチェックと連携させます。アクセスポイントを介して、共有の読み取り専用設定のためにEFSボリュームをマウントします。FargateとFargate Spotを組み合わせたキャパシティープロバイダーストラテジーを使用して、Fargate上でサービスを実行し、コスト効率を高めます。 理由：Fargateはノード管理を不要にし、タスクをENIごとに分離します。EFSは設定をイメージに焼き付けることを避け、設定のアトミックなロールバックをサポートします。

3. ブルー/グリーンと自動テストによる安全なデプロイ

• ECSサービスをCodeDeployのデプロイメントコントローラーに切り替えます。ALBに2つのターゲットグループを設定します。AfterAllowTestTrafficでカナリアシフトを使用し、5分以内に重要なエンドポイントを実行するLambdaテストランナーを呼び出します。5XXエラーとp90レイテンシーに関するCloudWatchアラームをアタッチして、ロールバックをトリガーします。 理由：CodeDeployのブルー/グリーンはリスクを分離し、テストフックは完全な切り替え前にグリーン環境を検証し、アラームは自動的で客観的なロールバックを提供します。

4. コールドスタートを安定させたLambdaでのレイテンシーに敏感なオペレーション

• トークン化ヘルパーAPIのために、関数をスリムな依存関係を持つZIPとしてパッケージ化します。バージョン/エイリアスを作成し、ピーク時に合わせてサイズ設定されたプロビジョンドコンカレンシーを有効にします。リリースウィンドウを追跡する日次スケジュールで、Application Auto Scalingを介してプロビジョンドコンカレンシーを駆動します。CloudWatchアラームに連動したエイリアスベースのトラフィックシフトのために、CodeDeployのカナリア (10%/15分) を使用します。 理由：プロビジョンドコンカレンシーは急増時のコールドスタートを排除し、エイリアスのカナリアは迅速なロールバックを伴う段階的な公開を可能にします。

5. API Gateway経由で外部APIを公開し、プライベートバックエンドを保護

• LambdaとECSのALBの前面にAPI Gatewayを配置します。LambdaプロキシにはHTTP APIを使用してコスト/レイテンシーを最小限に抑えます。リクエスト/レスポンスマッピングと読み取りの多いエンドポイントのステージキャッシュが必要なECS ALBパスにはREST APIを使用します。WAFのWeb ACLとステージのスロットリングを適用し、構造化されたアクセスログを有効にします。 理由：ニーズに合わせてAPIタイプを使い分けることで、コストと機能を最適化し、キャッシュは負荷を軽減し、WAFとスロットリングはイベントスパイク時の保護を強化します。

6. インターネットなしでのクロスアカウントのランタイムプル

• ランタイムVPCに、ECR (api, dkr) とCloudWatch Logs用のインターフェイスエンドポイント、およびS3ゲートウェイエンドポイントを追加します。ECRリポジトリのリソースポリシーをアタッチして、本番アカウントのタスク実行ロールにプルを許可します。イメージの保管時の暗号化には、クロスアカウントのキーポリシーを持つカスタマーマネージドKMSキーを使用します。 理由：プライベートなイメージプルはNATコストとアウトバウンドのリスクを回避し、明示的なリソース/キーポリシーは最小権限のクロスアカウントアクセスを強制します。

この設計により、運用上の手間 (管理するノードがない) が削減され、プロビジョンドコンカレンシーとALBのヘルスチェックに連動したロールアウトによって決定論的なレイテンシーが提供され、ECRのスキャン、レプリケーション、および不変性によってイメージの来歴がエンドツーエンドで強制されます。

← セキュリティ、コンプライアンス、ガバナンス · すべてのドメイン · 高可用性、レジリエンス、災害復旧 →

これらの問題を練習する → · ExamRoll.ioで時間制限付き練習 →

Amazonを閲覧 →