はじめに
AWS を使ったシステム設計を進める中で、コンテナ技術は避けて通れない存在になっています。しかし「そもそもコンテナとは何か」「なんとなくわかるけど実際には触ったことない」という人も多いのではないでしょうか。
本記事では、コンテナ技術の基礎概念から始まり、AWSが提供するコンテナサービスの全体像、そして実際のシステム設計における選定指針までを体系的に解説します。
第1章：コンテナ技術の基礎
1-1. コンテナとは何か
コンテナとは、アプリケーションとその実行に必要なライブラリ・設定ファイルなどの依存関係を一つのパッケージにまとめ、どの環境でもほぼ同一の動作を保証する仮想化技術です。
従来の仮想マシン（VM）がハードウェアレベルで仮想化を行い、ゲストOSを含むシステム全体を再現するのに対し、コンテナはホストOSのカーネルを共有しながらプロセスレベルで分離を実現します。
┌─────────────────────────────────┐ ┌─────────────────────────────────┐
│ 仮想マシン (VM) │ │ コンテナ │
├─────────────────────────────────┤ ├─────────────────────────────────┤
│ App A │ App B │ App C │ │ App A │ App B │ App C │
│ Bins │ Bins │ Bins │ │ Bins │ Bins │ Bins │
│ Guest │ Guest │ Guest │ ├─────────┴─────────┴─────────────┤
│ OS │ OS │ OS │ │ コンテナランタイム │
├─────────┴─────────┴─────────────┤ ├─────────────────────────────────┤
│ ハイパーバイザー │ │ ホスト OS │
├─────────────────────────────────┤ ├─────────────────────────────────┤
│ ホスト OS │ │ インフラストラクチャ │
├─────────────────────────────────┤ └─────────────────────────────────┘
│ インフラストラクチャ │
└─────────────────────────────────┘
つまり、従来の仮想マシンは「パソコンの中にもう一台パソコンをまるごと作る」ようなイメージです。OS も含めてすべてを複製するため、起動に時間がかかり、リソースの消費も大きくなります。一方コンテナは「同じ OS の上に、アプリごとの専用の部屋を区切る」ような仕組みです。OS を共有しているため軽量で、数秒で起動でき、同じマシン上により多くのアプリを効率よく動かすことができます。
1-2. なぜコンテナが必要なのか
コンテナ技術が広く採用される背景には、システム開発・運用における以下の課題があります。
環境差異の問題（"It works on my machine" 問題）
開発者のローカル環境では正常に動作するのに、本番環境にデプロイすると動かない——この問題は、OS、ライブラリのバージョン、環境変数など、実行環境の差異に起因します。コンテナはアプリケーションと依存関係をイメージとして固め、どの環境でも同一の動作を保証します。
デプロイの複雑化
マイクロサービスアーキテクチャの普及に伴い、数十〜数百のサービスをそれぞれ独立してデプロイする必要が生じています。コンテナは軽量で起動が速く、サービス単位のデプロイを効率的に行えます。
リソース効率
VMと比較して、コンテナはゲストOSのオーバーヘッドがないため、同一ホスト上でより多くのアプリケーションを稼働させることができます。
スケーラビリティ
コンテナは秒単位で起動・停止が可能なため、需要の変動に応じた水平スケーリングが容易です。
1-3. コンテナの主要概念
コンテナイメージ
コンテナの「設計図」にあたるものです。アプリケーションコード、ランタイム、ライブラリ、環境変数などがレイヤー構造で格納されています。Dockerfile に記述されたビルド手順からコンテナイメージが生成されます。
FROM node:20-slim
WORKDIR /app
COPY package*.json ./
RUN npm ci --production
COPY . .
EXPOSE 3000
CMD ["node", "server.js"]
コンテナレジストリ
ビルドされたコンテナイメージを保管・配布するためのリポジトリです。Docker Hub が代表的ですが、AWSでは Amazon ECR（Elastic Container Registry） が提供されています。
コンテナオーケストレーション
複数のコンテナのデプロイ、スケーリング、ヘルスチェック、ネットワーキングなどを統合的に管理する仕組みです。Kubernetes がデファクトスタンダードとして広く知られていますが、AWSでは Amazon ECS と Amazon EKS の2つのオーケストレーターが提供されています。
1-4. コンテナが解決する従来のインフラ課題
| 課題 | 従来のアプローチ | コンテナのアプローチ |
|---|---|---|
| 環境の一貫性 | 手順書ベースの構築 | イメージによる再現性の保証 |
| デプロイ速度 | 数十分〜数時間 | 数秒〜数分 |
| リソース効率 | VM単位の割り当て | プロセス単位の割り当て |
| スケーリング | 手動 or 分単位 | 秒単位の自動スケーリング |
| 障害分離 | アプリケーション間で影響あり | コンテナ単位で分離 |
| 環境構築コスト | 環境ごとに手作業 | イメージの再利用で即座に構築 |
1-5. コンテナ導入時の考慮点
コンテナはあらゆるワークロードに適しているわけではありません。導入前に以下の点を検討する必要があります。
- ステートフルなワークロード: コンテナは本質的にエフェメラル（一時的）であり、永続的なデータの保持には外部ストレージとの連携が必要です。
- 学習コスト: Dockerfile の記述、ネットワーキング、オーケストレーションなど、新たな技術スタックの習得が必要です。
- セキュリティ: コンテナイメージの脆弱性管理、ランタイムセキュリティ、ネットワークポリシーなど、コンテナ特有のセキュリティ領域への対応が求められます。
- モニタリング・ロギング: コンテナの短命な性質に対応した、集中ログ管理や分散トレーシングの仕組みが必要です。
第2章：AWSのコンテナサービス全体像
2-1. 抽象化レベルの進化
システムインフラは、時代とともに抽象化のレベルが上がってきました。
抽象化レベル（低 → 高）
物理マシン → 仮想マシン → コンテナ → サーバレス
(AWS Fargate) (AWS Lambda)
抽象化のレベルが上がるほど、インフラ管理の負担が軽減され、ビジネスロジックの開発に集中できるようになります。AWS のコンテナサービスは、この「ビジネスロジックへの注力」を実現するための基盤です。
2-2. AWSコンテナサービスのカテゴリ
AWSのコンテナ関連サービスは、大きく4つのカテゴリに分類されます。
┌─────────────────────────────────────────────────────────────────┐
│ AWS コンテナサービス全体像 │
├──────────────────────┬──────────────────────────────────────────┤
│ オーケストレーション │ Amazon ECS │ Amazon EKS │
│ (コントロールプレーン) │ │ │
├──────────────────────┼──────────────┼───────────────────────────┤
│ ホスティング │ Amazon EC2 │ AWS Fargate │
│ (データプレーン) │ │ │
├──────────────────────┼──────────────────────────────────────────┤
│ イメージレジストリ │ Amazon ECR │
├─────────────────────┼────────────────────────────────────────────┤
│ その他 │ AWS App Runner / CloudWatch Container │
│ │ Insights / AWS Cloud Map │
└─────────────────────┴────────────────────────────────────────────┘
オーケストレーション（コントロールプレーン）
コンテナのデプロイ、スケジューリング、スケーリングを管理するレイヤーです。
- Amazon ECS（Elastic Container Service）: AWS 独自のコンテナオーケストレーター。AWSとのネイティブな統合が強みで、シンプルに始められます。
- Amazon EKS（Elastic Kubernetes Service）: マネージド Kubernetes サービス。Kubernetes エコシステムの豊富なツール群やコミュニティリソースを活用できます。
ホスティング（データプレーン）
コンテナの実行環境です。
- Amazon EC2: 従来型のインスタンス上でコンテナを実行。ホストレベルの制御が可能で、GPU利用などの特殊要件にも対応。
- AWS Fargate: サーバレスのコンテナ実行環境。ホストの管理が一切不要で、コンテナのリソース定義だけで実行可能。
イメージレジストリ
- Amazon ECR（Elastic Container Registry）: フルマネージドのDockerコンテナレジストリ。イメージの脆弱性スキャン機能やライフサイクルポリシーによる自動クリーンアップも備えています。
2-3. Amazon ECS vs Amazon EKS：オーケストレーターの選択
両者の特徴を理解し、プロジェクトの要件に合わせて選択することが重要です。
| 観点 | Amazon ECS | Amazon EKS |
|---|---|---|
| 設計思想 | AWS ネイティブ | Kubernetes 標準 |
| 学習コスト | 低い | 高い（Kubernetes の知識が必要） |
| AWS統合 | ネイティブに深く統合 | ACK 等を通じて統合 |
| エコシステム | AWS 中心 | Kubernetes コミュニティの広範なツール群 |
| マルチクラウド | AWS のみ | 他クラウドへの可搬性あり |
| CI/CD連携 | CodePipeline / CodeBuild / CodeDeploy | GitHub, Jenkins, Flux, GitLab など多様 |
| モニタリング | CloudWatch | Prometheus, Grafana + CloudWatch |
| ロードバランサー | ALB | ALB, NLB, NGINX, Traefik など |
| IaC | CloudFormation, Copilot | Terraform, ACK |
ECS を選ぶべきケース:
- AWSに最適化された環境で、スムーズにコンテナ運用を始めたい
- チームにKubernetesの運用経験がない
- AWS のマネージドサービスと緊密に連携したい
- Copilot CLI を使って素早くデプロイ環境を構築したい
EKS を選ぶべきケース:
- 既に Kubernetes の運用経験がある
- マルチクラウドやハイブリッドクラウド環境で運用標準を統一したい
- Kubernetes エコシステムの豊富なツール群（Istio, LinkerD 等）を活用したい
- オンプレミス環境との一貫性が必要（EKS Anywhere）
2-4. Amazon EC2 vs AWS Fargate：実行環境の選択
ECS/EKS いずれを選んだ場合も、コンテナの実行環境として EC2 と Fargate を選択できます。
■ ユーザが管理するレイヤー（★）/ AWSが提供するレイヤー（―）
ECS on EC2 EKS on EC2 ECS/EKS
EKS セルフマネージド マネージドノード on Fargate
─────────────────────────────────────────────────────
アプリコンテナ : ★ ★ ★
エージェント設定 : ★ ★ ―
OS/ライブラリ設定 : ★ ★ ―
ホストスケーリング : ★ ― ―
← ユーザの管理範囲が広い 狭い →
Fargate を活用することで、アプリケーションコンテナの開発に集中できます。
第3章：AWS Fargate 詳解
3-1. Fargate の特長
AWS Fargate はサーバレスのコンテナ実行環境であり、以下の特長があります。
- ホスト管理不要: OSのアップグレード、パッチ適用が対応不要
- キャパシティ管理不要: クラスターのキャパシティ（インスタンス数など）を自分で管理する必要がない
- 設計によるセキュリティ: タスク/Pod ごとに実行環境が分離
- 従量課金: 前払い料金なし、利用リソースに応じた従量課金
- コスト最適化オプション: Fargate Spot（最大70%割引）や Graviton プロセッサの利用が可能
3-2. Fargate と EC2 の5つの違い
AWS Black Belt の資料で紹介されている、Fargate と EC2 で異なる5つの観点を詳しく見ていきます。
① vCPU とメモリ
Fargate では、タスク/Pod に割り当てる 指定可能な vCPU / メモリの組み合わせは限定されており、EC2のように任意構成はできません。
EC2 では任意のインスタンスタイプを選べますが、Fargate はこの範囲内で指定する必要があります。ただし、ほとんどのワークロードはこの範囲でカバーできます。
② ホスト
Fargate ではホストインスタンスが AWS によって管理されるため、以下の制約があります。
- GPU 非サポート: ハードウェアアクセラレーターが利用不可（機械学習推論など GPU が必要な場合は EC2 を選択）
- デーモンスケジューリング不可: ECS のデーモンスケジューリング戦略や EKS のデーモンセットは使用できないため、ログ収集エージェントなどはサイドカーパターンで実装
- イメージキャッシュなし: Fargate はホスト再利用が保証されないためキャッシュ前提設計は不可
起動時間の短縮テクニック:
- イメージサイズの最適化（マルチステージビルド、軽量ベースイメージの使用）
- zstd 圧縮によるイメージの圧縮
- Seekable OCI (SOCI) による遅延読み込み（ECS のみ）
③ ネットワークモード
Fargate では awsvpc モードのみが利用可能です。
| モード | 説明 | Fargate | EC2 |
|---|---|---|---|
| awsvpc | タスクごとに ENI（仮想ネットワークカード）がアタッチ | ✅ | ✅ |
| bridge | 仮想ネットワークブリッジでホスト/コンテナポートをマッピング | ❌ | ✅ |
| host | EC2 の IP/ポートを直接使用 | ❌ | ✅ |
awsvpc モードでは各タスクが独自の ENI と IP アドレスを持つため、セキュリティグループをタスク単位で設定でき、ネットワークレベルの分離が実現できます。
④ データボリューム
| ボリューム種別 | 特徴 | Fargate |
|---|---|---|
| バインドマウント / エフェメラルストレージ | 揮発性。コンテナ停止でデータ削除。20GiBまで無料 | ✅（ECS: Max 200GiB / EKS: Max 175GiB） |
| Amazon EFS | 伸縮自在な共有ファイルストレージ | ✅ |
| Amazon EBS | 高スループットなブロックストレージ | ✅（ECS on Fargate で利用可能、リージョン制限あり） |
⑤ セキュリティ
Fargate はセキュリティの面で EC2 に比べ多くのメリットがあります。
- OS・エージェントのパッチ適用不要: AWS が管理
- タスク/Pod 単位の実行環境分離: 各タスクは Firecracker ベースの軽量マイクロVM上で分離実行される
- 特権モード不可: コンテナに特権モードを付与できない（攻撃面の削減）
- タスク/Pod 単位の ENI・セキュリティグループ: ネットワークレベルの分離
- SSH アクセス不可: ホストへの直接アクセスが不可能（デバッグには ECS Exec を使用）
Fargate の分離モデル EC2 の分離モデル
┌────────────────────┐ ┌────────────────────┐
│ Kernel │ Kernel │ │ Kernel │
│ VM │ VM │ │ VM │
│ Task A │ Task B │ │ Task A │ Task B │
└────────────────────┘ └────────────────────┘
各タスクが個別のVMで分離 同一VM上で複数タスクが稼働
3-3. Fargate Spot によるコスト最適化
Fargate Spot は、AWSの余剰キャパシティを活用して最大70%の割引でコンテナを実行できるオプションです（ECS のみ）。
適しているワークロード:
- バッチ処理
- データ分析
- CI/CD パイプライン
- その他の中断耐性があるワークロード
Capacity Provider 戦略 を使い、FARGATE と FARGATE_SPOT を組み合わせることで、コストとアベイラビリティのバランスを取ることができます。
第4章：AWSにおけるコンテナアーキテクチャの設計
4-1. 典型的なコンテナアーキテクチャ
AWSでコンテナベースのシステムを構築する場合の典型的な構成を示します。
┌──────────────┐
│ Users │
└──────┬───────┘
│
┌──────▼───────┐
│ ALB │
│ (Application │
│ Load │
│ Balancer) │
└──────┬───────┘
│
┌────────────────┼────────────────┐
│ │ │
┌───────▼──────┐ ┌──────▼───────┐ ┌──────▼───────┐
│ Service A │ │ Service B │ │ Service C │
│ (Fargate) │ │ (Fargate) │ │ (Fargate) │
└───────┬──────┘ └──────┬───────┘ └──────┬───────┘
│ │ │
┌───────▼──────────────────────────────────▼───────┐
│ Data Layer │
│ ┌──────────┐ ┌──────────┐ ┌──────────┐ │
│ │Amazon RDS│ │ DynamoDB │ │ElastiCache│ │
│ └──────────┘ └──────────┘ └──────────┘ │
└──────────────────────────────────────────────────┘
4-2. CI/CD パイプラインの設計
コンテナベースのアプリケーションでは、CI/CD パイプラインの構築が不可欠です。
ECS を使用する場合のパイプライン
Developer → CodeCommit/GitHub → CodeBuild → ECR → CodeDeploy → ECS (Fargate)
│
CodePipeline（全体のオーケストレーション）
- ソース管理: CodeCommit または GitHub にコードをプッシュ
- ビルド: CodeBuild で Docker イメージをビルド
- レジストリ: ビルドされたイメージを Amazon ECR にプッシュ
- デプロイ: CodeDeploy（Blue/Green デプロイ）または ECS の Rolling Update でデプロイ
EKS を使用する場合のパイプライン
EKS では Kubernetes エコシステムのツールを活用した、より多様な選択肢があります。
Developer → GitHub/GitLab → Jenkins/CodeBuild → ECR/DockerHub → Flux/ArgoCD → EKS
GitOps アプローチ（Flux, ArgoCD）を採用することで、Git リポジトリの状態とクラスターの状態を宣言的に同期させることができます。
4-3. ネットワーク設計
VPC 設計
コンテナワークロードに適した VPC 設計のポイント：
┌─────────────────────────────────────────────────────┐
│ VPC │
│ ┌───────────────────────────────────────────────┐ │
│ │ Public Subnet │ │
│ │ ┌─────────┐ ┌─────────┐ │ │
│ │ │ ALB │ │ NAT GW │ │ │
│ │ └─────────┘ └─────────┘ │ │
│ └───────────────────────────────────────────────┘ │
│ ┌───────────────────────────────────────────────┐ │
│ │ Private Subnet │ │
│ │ ┌──────────────────────────────────────────┐ │ │
│ │ │ ECS / EKS (Fargate) │ │ │
│ │ │ ┌────────┐ ┌────────┐ ┌────────┐ │ │ │
│ │ │ │ Task A │ │ Task B │ │ Task C │ │ │ │
│ │ │ │ ENI/SG │ │ ENI/SG │ │ ENI/SG │ │ │ │
│ │ │ └────────┘ └────────┘ └────────┘ │ │ │
│ │ └──────────────────────────────────────────┘ │ │
│ └───────────────────────────────────────────────┘ │
│ ┌───────────────────────────────────────────────┐ │
│ │ Isolated Subnet │ │
│ │ ┌──────────┐ ┌──────────┐ │ │
│ │ │ RDS │ │ ElastiC │ │ │
│ │ └──────────┘ └──────────┘ │ │
│ └───────────────────────────────────────────────┘ │
└─────────────────────────────────────────────────────┘
- Public Subnet: ALB と NAT Gateway を配置
- Private Subnet: コンテナタスクを配置。インターネットへの通信は NAT Gateway 経由
- Isolated Subnet: データベースなどのバックエンドサービスを配置
サービスディスカバリ
マイクロサービス間の通信には AWS Cloud Map を活用します。Cloud Map は DNS ベースのサービスディスカバリを提供し、サービス間のエンドポイント解決を自動化します。
ロードバランシング
- Application Load Balancer (ALB): HTTP/HTTPS のレイヤー7ロードバランサー。パスベースルーティングやホストベースルーティングが可能
- Network Load Balancer (NLB): TCP/UDP のレイヤー4ロードバランサー。超低レイテンシが求められるケースに適用
4-4. モニタリングとオブザーバビリティ
コンテナ環境のモニタリングには、以下のサービスを組み合わせて利用します。
| レイヤー | サービス | 用途 |
|---|---|---|
| メトリクス | CloudWatch Container Insights | CPU, メモリ, ネットワーク等のリソースメトリクス |
| ログ | CloudWatch Logs | コンテナログの集約と分析 |
| トレーシング | AWS X-Ray | 分散トレーシングによるリクエストフロー追跡 |
| ダッシュボード | CloudWatch Dashboards | 運用ダッシュボードの構築 |
| アラーム | CloudWatch Alarms | 閾値ベースの通知設定 |
EKS の場合は、Prometheus + Grafana の組み合わせも広く使われています。Amazon Managed Service for Prometheus や Amazon Managed Grafana を利用することで、運用負荷を下げることもできます。
4-5. セキュリティ設計
イメージセキュリティ
- ECR イメージスキャン: プッシュ時に自動で脆弱性スキャンを実行
- ベースイメージの管理: 信頼できるベースイメージを使用し、定期的に更新
- マルチステージビルド: ビルドツールを最終イメージに含めない
- 最小権限: 不要なパッケージを含めず、非rootユーザーでコンテナを実行
ランタイムセキュリティ
- Fargate の選択: タスク単位の VM 分離により、コンテナブレイクアウトのリスクを軽減
- セキュリティグループ: タスク/Pod ごとに最小限の通信ルールを設定
- IAM タスクロール: 各タスクに必要最小限の AWS リソースアクセス権限を付与
- Secrets Manager: データベースパスワードや API キーなどの機密情報を安全に管理
ネットワークセキュリティ
- Private Subnet での実行: コンテナをインターネットから直接アクセスできないサブネットに配置
- VPC エンドポイント: ECR, CloudWatch Logs, Secrets Manager などへの通信を VPC 内で完結
- WAF: ALB と統合して Web アプリケーションファイアウォールを適用
第5章：設計パターンと実践的なユースケース
5-1. Web アプリケーション
最も典型的なユースケースです。フロントエンドとバックエンド API をそれぞれ独立したコンテナサービスとして運用します。
推奨構成:
- オーケストレーター: Amazon ECS（シンプルに始める場合）
- 実行環境: AWS Fargate（運用負荷を最小化）
- ロードバランサー: ALB（パスベースルーティング）
- オートスケーリング: ターゲット追跡スケーリング（CPU使用率やリクエスト数ベース）
5-2. バッチ処理
定期的なデータ処理やレポート生成などのバッチワークロードもコンテナとの相性が良いケースです。
推奨構成:
- オーケストレーター: Amazon ECS
- 実行環境: AWS Fargate Spot（コスト削減のため）
- スケジューリング: EventBridge Scheduler + ECS RunTask
- データストア: S3 + RDS / DynamoDB
5-3. マイクロサービス
多数のサービスが相互に通信するマイクロサービスアーキテクチャでは、サービスメッシュの導入も検討します。
推奨構成:
- オーケストレーター: Amazon EKS（Kubernetes のエコシステムを活用）
- 実行環境: Fargate + EC2 の併用（ワークロード特性に応じて）
- サービスメッシュ: AWS App Mesh または Istio
- サービスディスカバリ: AWS Cloud Map
- CI/CD: GitOps（Flux / ArgoCD）
5-4. 実行環境の選定フローチャート
Q1: GPU やホストレベルのカスタマイズが必要？
→ Yes: EC2 を選択
→ No: Q2 へ
Q2: インフラの運用負荷を最小限にしたい？
→ Yes: Fargate を選択
→ No: Q3 へ
Q3: コスト最適化が最重要課題？
→ Yes: EC2（Spot Instance やリザーブドインスタンスを活用）
→ No: Fargate を選択（運用負荷とのトレードオフで判断）
Q1: Kubernetes の運用経験やエコシステムが必要？
→ Yes: EKS を選択
→ No: Q2 へ
Q2: マルチクラウドやオンプレミスとの一貫性が必要？
→ Yes: EKS を選択
→ No: Q3 へ
Q3: AWS にフォーカスしてシンプルに運用したい？
→ Yes: ECS を選択
→ No: 要件を再整理
第6章：コンテナ移行のステップ
既存のオンプレミスや EC2 上のアプリケーションをコンテナ化する際の一般的なステップを紹介します。
Step 1: アプリケーションの評価
- 現在のアーキテクチャの整理
- コンテナ化の適合性評価（ステートレス化の可否、依存関係の整理）
- 移行の優先順位付け
Step 2: コンテナ化
- Dockerfile の作成
- マルチステージビルドによるイメージ最適化
- ローカル環境での動作確認
- ECR へのイメージ登録
Step 3: インフラ構築
- VPC、サブネット、セキュリティグループの設計
- ECS/EKS クラスターの構築
- ALB / NLB の設定
- IaC（CloudFormation / Terraform）によるインフラのコード化
Step 4: CI/CD パイプライン構築
- ソースリポジトリとの連携
- ビルド・テスト・デプロイの自動化
- Blue/Green デプロイまたは Canary デプロイの設定
Step 5: 運用体制の整備
- モニタリング・アラートの設定
- ログ集約基盤の構築
- 障害対応手順の策定
- オートスケーリングポリシーの調整
まとめ
コンテナ技術は、アプリケーションの開発・デプロイ・運用を根本的に変革する技術です。AWS のコンテナサービスは、この技術を簡単に、安全に、スケーラブルに利用するための基盤を提供しています。
要点の振り返り
- コンテナはビジネスロジックへの注力を実現する手段 — インフラ管理の抽象化により、開発者はアプリケーション開発に集中できます。
- ECS vs EKS は「シンプルさ」vs「エコシステム」のトレードオフ — チームのスキルセットとプロジェクト要件に基づいて選択しましょう。
- Fargate は運用負荷を最小化する最も効果的な手段 — GPU や特殊なホスト設定が不要であれば、まず Fargate を検討しましょう。
- セキュリティは設計段階から組み込む — Fargate のタスク分離、IAM タスクロール、ECR イメージスキャンなど、AWS のセキュリティ機能をフル活用しましょう。
- CI/CD パイプラインは必須 — コンテナの利点を最大限に活かすには、自動化されたデプロイパイプラインが不可欠です。