実践！AWSネットワーク構築・運用30日チャレンジ: Day 24

Posted at 2025-07-26

Day 24: コンテナネットワーク（ECS/EKS）：マイクロサービス時代のネットワーク

皆さん、こんにちは！「実践！AWSネットワーク構築・運用30日チャレンジ」のDay 24へようこそ！

昨日はAmazon Route 53の高度なルーティングポリシーについて学び、グローバルなDNS管理と高可用性確保の重要性を理解しました。これで、あなたのWebサービスやAPIの「入り口」は、DNSレベルでも非常に柔軟かつ堅牢になりました。

今日のテーマは、現代のアプリケーション開発とデプロイの中心となっている「コンテナ」に焦点を当てます。特に、AWSが提供するコンテナオーケストレーションサービスである「Amazon ECS」と「Amazon EKS」におけるネットワークの概念、そしてマイクロサービス時代におけるコンテナ間の通信について深く掘り下げていきます。

1. コンテナとマイクロサービス時代のネットワーク課題

アプリケーションをコンテナ化し、マイクロサービスアーキテクチャで開発することは、開発速度の向上、スケーラビリティ、耐障害性といった多くのメリットをもたらします。しかし、これによりネットワークの設計と管理は新たな課題に直面します。

動的なIPアドレス: コンテナは頻繁に起動・停止・再起動され、そのたびにIPアドレスが変更される可能性があります。これにより、従来の静的なIPアドレス管理が困難になります。
サービスディスカバリ: 多数のマイクロサービスが連携する場合、それぞれのサービスがどこで実行されているかを動的に発見する仕組み（サービスディスカバリ）が必要になります。
コンテナ間の通信: 同じホスト上、あるいは異なるホスト上のコンテナ間で、セキュアかつ効率的に通信させる必要があります。
ロードバランシング: コンテナアプリケーションへのトラフィックを効率的に分散させる仕組みが必要です。
ネットワークポリシー: 特定のコンテナやサービスグループ間の通信のみを許可する、きめ細やかなネットワークセグメンテーションが求められます。

これらの課題に対応するために、ECSやEKSはVPCと密接に統合された独自のネットワークモデルを提供しています。

2. Amazon ECS (Elastic Container Service) のネットワーク

Amazon ECS は、Dockerコンテナを簡単にデプロイ、管理、スケーリングできるフルマネージドのコンテナオーケストレーションサービスです。ECSでは、コンテナが動作する単位を「タスク」と呼び、タスクに複数のコンテナを含めることができます。

ECSのネットワークモードは、タスクのネットワークインターフェース（ENI）の割り当て方法と、コンテナがネットワークに接続する方法を定義します。主なネットワークモードは以下の通りです。

awsvpc ネットワークモード:
- 推奨されるモード。ECSタスク（タスク内のすべてのコンテナ）ごとに専用のElastic Network Interface (ENI) が割り当てられます。
- このENIは、タスクが起動されるVPC内のサブネットからプライベートIPアドレスを取得します。
- 各タスクは、独自のセキュリティグループを持ち、VPC内の他のEC2インスタンスやサービスと直接通信できます。
- メリット:
  - VPCネイティブな通信: タスクがVPC内のリソースとして扱われるため、EC2インスタンスと同様にセキュリティグループやNACL、ルートテーブルを適用できます。
  - きめ細やかなセキュリティ: タスクレベルでセキュリティグループを割り当てられるため、最小権限の原則に基づいたネットワークセキュリティを実現できます。
  - ALB/NLBとの統合: Application Load Balancer (ALB) やNetwork Load Balancer (NLB) のターゲットグループにタスクのENIを直接登録できます。
- 考慮事項: ENIの数にはVPCの制限があるため、大量のタスクを起動する際はサブネットのIPアドレス枯渇に注意が必要です（IPアドレスの割り当てが不足しないようサブネットを設計するか、AWS IPAMなどを活用）。
bridge ネットワークモード (Fargateでは非対応):
- ECSコンテナインスタンス（EC2）上で実行されるDockerブリッジネットワークを使用します。
- コンテナはDockerデーモンによって割り当てられたプライベートIPアドレスを取得し、ホスト（EC2インスタンス）のポートを介して外部と通信します。
- メリット: シンプルな設定。
- デメリット: ホストのポート競合、タスクごとのセキュリティグループ制御が困難、Fargateでは利用不可。
host ネットワークモード (Fargateでは非対応):
- コンテナがホスト（EC2インスタンス）のネットワーク名前空間を共有します。コンテナはホストのIPアドレスとポートを直接使用します。
- メリット: ネットワークパフォーマンスが高い。
- デメリット: ホストのポート競合、セキュリティ上のリスク、Fargateでは利用不可。

ECSとロードバランサーの統合

ECSタスクは、Application Load Balancer (ALB) やNetwork Load Balancer (NLB) のターゲットとして登録できます。

ALB: HTTP/HTTPSトラフィック向け。パスベースルーティング、ホストベースルーティング、スティッキーセッションなどの高度なルーティング機能を提供。awsvpcモードのECSタスクと連携し、ポートマッピングを動的に行えます。
NLB: 高いスループットと低レイテンシが必要なTCP/UDP/TLSトラフィック向け。コンテナのENIに直接トラフィックをルーティングできます。

3. Amazon EKS (Elastic Kubernetes Service) のネットワーク

Amazon EKS は、KubernetesをAWS上で実行するためのフルマネージドサービスです。EKSはKubernetesのネットワーキングモデルに従いますが、AWSのVPCと統合するためにAWS独自のCNI (Container Network Interface) プラグインを使用します。

EKSの主要なネットワーク概念

VPC CNI プラグイン:
- EKSクラスターは、AWSが提供するVPC CNIプラグインを使用して、Kubernetes PodにVPCのプライベートIPアドレスを直接割り当てます。
- 各Podは専用のElastic Network Interface (ENI) とプライベートIPアドレスを取得し、VPC内の他のリソースやオンプレミスのリソースと、まるでEC2インスタンスのように直接通信できます。
- これにより、Podレベルでセキュリティグループを割り当てることが可能になり、非常にきめ細やかなネットワークセキュリティを実現できます。
- メリット:
  - VPCネイティブなルーティング: Pod間の通信がVPCルーティングテーブルとセキュリティグループで制御されるため、既存のVPCネットワークインフラとシームレスに統合されます。
  - セキュリティの向上: Podごとにセキュリティグループを設定できるため、マイクロサービスごとの最小権限のネットワークポリシーを適用できます。
  - シンプルなIPアドレス管理: PodがVPCのIPアドレスを持つため、VPC Flow LogsでPodレベルの通信を可視化できます。
- 考慮事項: awsvpcモードのECSと同様に、大量のPodを起動するとサブネットのIPアドレスが枯渇する可能性があります。IPアドレスプレフィックスの割り当て（WARM_POOL）やAWS IPAMの活用が重要です。
Service (Kubernetes Service):
- Kubernetesの「Service」は、Podの集合体に対して安定したネットワークアクセスを提供します。PodのIPアドレスは動的ですが、ServiceのIPアドレスは静的です。
- EKSでは、ClusterIP、NodePort、LoadBalancer、ExternalNameなど、様々なタイプのServiceを利用できます。
- 特にLoadBalancerタイプのServiceは、ALBやNLBを自動的にプロビジョニングし、Podにトラフィックを分散します。
Ingress (Kubernetes Ingress):
- 外部からクラスター内のServiceへのHTTP/HTTPSルーティングを管理します。
- ALB Ingress Controllerを使用することで、ALBを自動的にプロビジョニングし、高度なルーティング（パスベース、ホストベースなど）やTLS終端を管理できます。
Network Policy (Kubernetes Network Policy):
- Pod間の通信を制御するためのKubernetesリソースです。
- KubernetesのNetwork Policyは、Podのラベルに基づいて、どのPodがどのPodと通信できるかを定義します。
- EKSでは、Calicoのようなサードパーティ製のCNIプラグインや、AWS VPC CNIの拡張機能としてNetwork Policyを適用できます。これにより、きめ細やかなマイクロサービス間通信制御が可能になります。

4. コンテナネットワークのベストプラクティス

awsvpcモード（ECS）/ VPC CNI (EKS) の活用:
- タスク/PodごとにVPC IPアドレスとセキュリティグループを割り当てることで、最もセキュアでVPCネイティブな統合を実現します。
適切なサブネット設計:
- コンテナインスタンスとタスク/Podが使用するIPアドレスの数を考慮し、十分なCIDRブロックを持つサブネットを設計します。大規模な環境では、IPAM（IP Address Manager）の導入も検討します。
ロードバランサーの活用:
- ALB/NLBをコンテナサービスの前段に配置し、トラフィックを効率的に分散し、高可用性を確保します。ALB Ingress Controller (EKS) の利用も検討します。
サービスディスカバリ:
- AWS Cloud MapをECSのサービスディスカバリに利用したり、KubernetesのDNSを利用したりして、動的なコンテナサービス間の通信を可能にします。
ネットワークポリシーの適用:
- Kubernetes Network Policy (EKS) やセキュリティグループを適切に設定し、マイクロサービス間の通信を最小限に制限します。
VPC Flow LogsとCloudWatch Logs:
- コンテナタスク/PodのENIからのフローログをキャプチャし、CloudWatch Logs Insightsや外部のログ分析ツールで分析することで、コンテナ間の通信を可視化し、トラブルシューティングやセキュリティ監査に役立てます。

5. コンテナネットワークの仕組み（概念的な理解）

コンテナネットワークのハンズオンは、ECSクラスターやEKSクラスターの構築が必要となるため、このチャレンジシリーズの範囲では実践しません。しかし、その概念的な仕組みを理解することは非常に重要です。

ECS (awsvpc モード) の概念図

+-----------------------------------------------------------------------------------------+
| VPC (e.g., 10.0.0.0/16)                                                                 |
|                                                                                         |
|  +--------------------------------+   +--------------------------------+                |
|  | Public Subnet (my-public-a)    |   | Private Subnet (my-private-a)  |                |
|  |                                |   |                                |                |
|  |           +---------+          |   |      +---------------------+   |                |
|  |           |   ALB   |          |   |      | ECS Task (Service A)|   |                |
|  |           +----+----+          |   |      | (ENI with 10.0.1.10) |   |                |
|  |                |               |   |      | SG: SG-Task-A       |   |                |
|  |                |               |   |      +---------------------+   |                |
|  |                |               |   |                 ^              |                |
|  |                |               |   |                 |              |                |
|  |                v               |   |                 |              |                |
|  |           +----+----+          |   |      +---------------------+   |                |
|  +-----------| Internet|----------+   +------|  ECS Task (Service B)|   |                |
|              | Gateway |                     | (ENI with 10.0.1.11) |   |                |
|              +---------+                     | SG: SG-Task-B       |   |                |
|                                              +---------------------+   |                |
|                                                                         |
+-----------------------------------------------------------------------------------------+

この図では、ALBがパブリックサブネットにデプロイされ、外部からのトラフィックを受け付けます。ALBのターゲットグループには、プライベートサブネットにデプロイされたECSタスクが登録されます。各ECSタスクはawsvpcモードでENIを持ち、プライベートIPアドレスと独自のセキュリティグループが割り当てられます。これにより、ALBからタスクへのトラフィックはVPC内で直接ルーティングされ、タスク間の通信もVPCネットワークで制御されます。

EKS (VPC CNI) の概念図

+-----------------------------------------------------------------------------------------+
| VPC (e.g., 10.0.0.0/16)                                                                 |
|                                                                                         |
|  +--------------------------------+   +--------------------------------+                |
|  | Public Subnet (my-public-a)    |   | Private Subnet (my-private-a)  |                |
|  |                                |   |                                |                |
|  |           +---------+          |   |      +---------------------+   |                |
|  |           |   ALB   |          |   |      | EKS Worker Node (EC2)|   |                |
|  |           +----+----+          |   |      | (ENI with 10.0.1.x) |   |                |
|  |                |               |   |      |                     |   |                |
|  |                |               |   |      | +-----------------+ |   |                |
|  |                v               |   |      | | Pod A (10.0.1.y)| |   |                |
|  |           +----+----+          |   |      | | (SG: SG-Pod-A)  | |   |                |
|  +-----------| Ingress |----------+   +------| +-----------------+ |   |                |
|              | (ALB)   |                     |                     | |   |                |
|              +---------+                     | +-----------------+ | |   |                |
|                                              | | Pod B (10.0.1.z)| |   |                |
|                                              | | (SG: SG-Pod-B)  | |   |                |
|                                              | +-----------------+ |   |                |
|                                              +---------------------+   |                |
|                                                                         |
+-----------------------------------------------------------------------------------------+

EKSの場合、ALB (Ingress経由) がトラフィックを受け付け、プライベートサブネット内のEKSワーカーノード（EC2インスタンス）に転送します。VPC CNIプラグインにより、各PodはVPCのIPアドレスを直接取得し、独自のセキュリティグループを割り当てることができます。これにより、PodはVPC内の他のリソースと直接通信でき、Pod間の通信もVPCのネットワーク機能によって制御されます。

6. AI時代におけるコンテナネットワークの活用シナリオ

AI/MLワークロードでは、マイクロサービスアーキテクチャで推論APIやデータ処理パイプラインを構築することが増えています。コンテナネットワークは、これらの環境で高いパフォーマンス、スケーラビリティ、セキュリティ、そして管理の容易さを提供します。

リアルタイム推論APIのデプロイ:
- ECS FargateやEKSに、低レイテンシが求められるML推論APIをデプロイします。awsvpcモード/VPC CNIにより、各推論Pod/タスクがVPC IPアドレスを持ち、ALB (Ingress) 経由でトラフィックをルーティングすることで、高可用性とスケーラビリティを実現します。
分散学習ジョブの最適化:
- EKSクラスター上でTensorFlowやPyTorchなどの分散学習フレームワークを実行する場合、VPC CNIによってPodがVPC IPアドレスを持つため、ノード間・Pod間のデータ転送がVPC内で直接行われ、ネットワークパフォーマンスが向上します。Network Policyを使用して、学習ジョブに関連するPod間の通信のみを許可し、セキュリティを強化します。
データ前処理パイプラインの構築:
- KinesisやKafkaなどからデータを取り込み、特徴量エンジニアリングを行うマイクロサービス群をECS/EKS上にデプロイします。各マイクロサービスを独立したPod/タスクとして運用し、Cloud Mapなどのサービスディスカバリを利用して効率的に連携させます。
モデルサービングのエッジデプロイメント:
- AWS OutpostsやAWS Local ZonesにEKS/ECSクラスターをデプロイし、VPCと統合されたコンテナネットワークを利用することで、ユーザーに近い場所でML推論をオフロードし、レイテンシを最小限に抑えます。
GPUインスタンスの効率的な利用:
- EKSワーカーノードとしてGPUインスタンスを利用し、VPC CNIによってGPUを必要とするPodにVPC IPアドレスを割り当てます。Podごとにセキュリティグループを設定することで、GPUリソースへのアクセスをきめ細やかに制御できます。

本日のまとめと次へのステップ

今日は、コンテナベースのアプリケーションを支える「Amazon ECS」と「Amazon EKS」のネットワークについて深く掘り下げました。

ECSのawsvpcモードとEKSのVPC CNIプラグインは、コンテナにVPCのプライベートIPアドレスを直接割り当て、VPCネイティブな通信とセキュリティを実現する。
ロードバランサー（ALB/NLB）、サービスディスカバリ（Cloud Map、Kubernetes DNS）、およびネットワークポリシーは、マイクロサービス間の効率的でセキュアな通信に不可欠。
コンテナネットワークのベストプラクティスを理解し、IPアドレス管理、サブネット設計、セキュリティグループ設定の重要性を再確認した。

コンテナは、AI/MLワークロードにおいて、スケーラビリティとデプロイの柔軟性を提供する上で非常に重要な技術です。そのネットワークの仕組みを理解することは、高性能でセキュアなAIシステムを構築するために不可欠です。

明日のDay 25では、「サーバーレスネットワーク（Lambda/API Gateway）：イベント駆動型アーキテクチャの裏側」と題して、コンテナとは異なるアプローチであるサーバーレスサービス（Lambda、API Gatewayなど）がどのようにVPCと連携し、ネットワークを構築するのかを学びます。

今日のコンテナネットワークの学習、新しい発見はありましたか？マイクロサービス時代のネットワーク設計は奥が深いですね！ぜひ「いいね」👍で教えてください！

You get articles that match your needs
You can efficiently read back useful information
You can use dark theme

What you can do with signing up