徹底討論！ECS vs EKS！

Transcript

1. 徹底討論！ECS vs EKS！ AWS Summit Japan Builder Community Loungeチョークトーク 2026年6月26日 株式会社 野村総合研究所 マルチクラウドインテグレーション事業本部 金融基盤サービス部 エキスパートアーキテクト 高棹 大樹
2. 1 Copyright （C） Nomura Research Institute, Ltd. All rights reserved. 高棹 大樹 – Daiki Takasao NRI 金融基盤サービス部 • Amazon Elastic Kubernetes Service (EKS) を用いた金融機関様向けマイクロサービス共通基盤 のインフラ担当 主な仕事 趣味 最近の困り事 • キャンプ • 筋トレ • 子供と遊ぶ(相手をしてくれる内に。。) • 飼っている猫が懐いてくれない
3. 2 Copyright （C） Nomura Research Institute, Ltd. All rights reserved. 今日話すことをざっくり 私はEKSの運用を5年ぐらいやっており、 EKSに色々詳しくなりました 一方Amazon ECSはそこまで深入りしておらず、 正直知識が浅いです EKSのできること/しんどいことを紹介するので、 それに対してECSはこうだ！を突っ込んでください
4. 3 Copyright （C） Nomura Research Institute, Ltd. All rights reserved. 今日話すことをざっくり 私はEKSの運用を5年ぐらいやっており、 EKSに色々詳しくなりました 一方ECSはそこまで深入りしておらず、 正直知識が浅いです EKSのできること/しんどいことを紹介するので、 それに対してECSはこうだ！を突っ込んでください けっしてECSとEKSの対立を 煽っている訳ではありません!! 適しているユースケースを議論したいです
5. 4 Copyright （C） Nomura Research Institute, Ltd. All rights reserved. アジェンダ コンテナオーケストレーション/Kubernetes/EKSとは？ 01 EKSだとこうやってますけど、ECSだとどうなります？ 02
6. 5 Copyright （C） Nomura Research Institute, Ltd. All rights reserved. Copyright （C） Nomura Research Institute, Ltd. All rights reserved. 5 1. コンテナオーケストレーション/Kubernetes/EKSとは？
7. 6 Copyright （C） Nomura Research Institute, Ltd. All rights reserved. コンテナオーケストレーションの役割①: コンテナの配置管理 1. コンテナオーケストレーション/Kubernetes/EKSとは？ サーバ コンテナA サーバ サーバ コンテナB コンテナA コンテナをどのサーバ上で稼働させるのかを判断・管理する コンテナC 障害が発生してもコンテナの機能提供を継続するために、同一種類のコンテナを複数稼働させる Kubernetes
8. 7 Copyright （C） Nomura Research Institute, Ltd. All rights reserved. コンテナオーケストレーションの役割②: 障害発生時の退避・自動復旧 1. コンテナオーケストレーション/Kubernetes/EKSとは？ コンテナA コンテナB コンテナA コンテナC 障害が発生したコンテナを復旧する コンテナB コンテナA サーバに障害が発生した際、そのサーバ上で稼働していたコンテナを他のサーバに退避する Kubernetes サーバ サーバ サーバ
9. 8 Copyright （C） Nomura Research Institute, Ltd. All rights reserved. コンテナオーケストレーションの役割③: リソース拡張・アップデート管理 1. コンテナオーケストレーション/Kubernetes/EKSとは？ コンテナA コンテナB コンテナA 問合せ量の増加等を契機として、コンテナのリソースを自動拡張する コンテナC コンテナのローリングアップデートのために、一連のコンテナの停止とデプロイの作業を、順序を守って実施する コンテナB NEW Kubernetes サーバ サーバ サーバ
10. 9 Copyright （C） Nomura Research Institute, Ltd. All rights reserved. コンテナオーケストレーションの役割③: リソース拡張・アップデート管理 1. コンテナオーケストレーション/Kubernetes/EKSとは？ コンテナA コンテナB コンテナA 問合せ量の増加等を契機として、コンテナのリソースを自動拡張する コンテナC コンテナのローリングアップデートのために、一連のコンテナの停止とデプロイの作業を、順序を守って実施する コンテナB NEW Kubernetes サーバ サーバ サーバ コンテナ数が少なければ手動作業できるが、 増えると困難。。 コンテナオーケストレーションは 自動で実施してくれる!
11. 10 Copyright （C） Nomura Research Institute, Ltd. All rights reserved. Kubernetesって何？ 1. コンテナオーケストレーション/Kubernetes/EKSとは？ ◼コンテナ化されたアプリケーションを自動で配置・スケーリング・管理するためのオーケストレーション プラットフォーム ◼元々Google で開発され、現在は CNCF（Cloud Native Computing Foundation） が運 営している ◼略してK8s
12. 11 Copyright （C） Nomura Research Institute, Ltd. All rights reserved. Kubernetesの特徴①: 様々な形態で導入可能 1. コンテナオーケストレーション/Kubernetes/EKSとは？ Kubernetes オンプレミス Kubernetes パブリッククラウド 様々なパブリッククラウド、オンプレミスでKubernetesを導入可能 Kubernetes上で構築したコンテナのシステム構成は、 他のパブリッククラウドやオンプレミス環境へ比較的容易に移行・展開が可能 ※クラウド固有のサービスに依存する部分を除く
13. 12 Copyright （C） Nomura Research Institute, Ltd. All rights reserved. Kubernetesの特徴②: マニフェストによるリソース定義 1. コンテナオーケストレーション/Kubernetes/EKSとは？ apiVersion: v1 kind: Pod metadata: name: nginx-pod spec: containers: - name: nginx-container image: nginx:1.25 マニフェスト Kubernetes 適用 K8sリソース 望ましい状態 実際の状態 修 復 比 較 マニフェストをKubernetesに適用することで、K8sリソースが作成される NEW マニフェストで定義した望ましい状態と 実際の状態を継続的に比較し、 差分を検知した場合は自動的に修復する
14. 13 Copyright （C） Nomura Research Institute, Ltd. All rights reserved. Kubernetesの特徴②: マニフェストによるリソース定義 1. コンテナオーケストレーション/Kubernetes/EKSとは？ Kubernetes 比 較 望ましい状態： コンテナ(Pod)が3つ 実際の状態： コンテナ(Pod)が2つ → 1つ追加 誤って 削除 NEW 起 動 Kubernetes利用者が誤って1つのPodを削除 Kubernetesは差分を検知し、 望ましい数に合せる形で自動でPodを1つ起動する
15. 14 Copyright （C） Nomura Research Institute, Ltd. All rights reserved. Kubernetesの特徴③: 高い拡張性 1. コンテナオーケストレーション/Kubernetes/EKSとは？ プロダクト名 用途 主なカスタムリソース名 Istio サービスメッシュ VirtualService, DestinationRule, Gateway Linkerd サービスメッシュ ServiceProfile Argo CD GitOpsによる継続的デリバリー Application Prometheus Operator Kubernetesネイティブな監視 ServiceMonitor, PrometheusRule KEDA イベント駆動のオートスケーリング ScaledObject, TriggerAuthentication Argo Workflows バッチ処理・データパイプライン Workflow, CronWorkflow MongoDB Community Operator MongoDBクラスタ運用 MongoDBCommunity MySQL Operator MySQLクラスタ運用 MysqlCluster Postgres Operator PostgreSQLクラスタ運用 PostgresCluster ◼Kubernetesには豊富な種類のリソースがビルトインで揃っている ◼それらに加えて、独自のリソース(カスタムリソース)を定義できる ◼多数のカスタムリソースが開発されており、Kubernetesを中心とした大きなエコシステムを形成し ている
16. 15 Copyright （C） Nomura Research Institute, Ltd. All rights reserved. Kubernetesクラスタの構成要素 1. コンテナオーケストレーション/Kubernetes/EKSとは？ Kubernetesクラスタ ワーカーノード(データプレーン) ・・・ リソースを稼働させるサーバ群 コントロールプレーン リソースを管理
17. 16 Copyright （C） Nomura Research Institute, Ltd. All rights reserved. Elastic Kubernetes Service(EKS)とは？ 1. コンテナオーケストレーション/Kubernetes/EKSとは？ ◼AWSのマネージドKubernetesサービス ◼コントロールプレーンの管理が不要、 IAMユーザ/ロールによる認証などが主なメリット ワーカーノード(データプレーン) リソースを稼働させるサーバ群 コントロールプレーン リソースを管理 ・・・ コントロールプレーンの 管理が不要 IAMユーザ/ロールによる 認証
18. 17 Copyright （C） Nomura Research Institute, Ltd. All rights reserved. Copyright （C） Nomura Research Institute, Ltd. All rights reserved. 17 2. EKSだとこうやってますけど、ECSだとどうなります？
19. 18 Copyright （C） Nomura Research Institute, Ltd. All rights reserved. いきなり！私が思うECS/EKSのメリット/デメリット 2. EKSだとこうやってますけど、ECSだとどうなります？ ◼このポイントを掘り下げていきますので、随時突っ込みをください！ ECS (Elastic Container Service) EKS (Elastic Kubernetes Service) 利用可能な機能の幅 △ AWSが提供しているサービスの機能のみ 利用可能 AWS提供サービスに加えてKubernetesや その上で稼動するクラウドネイティブOSSを利用可能 マルチクラウド、オンプレミス との相互運用性 △ ECSはAWS独自サービス Kubernetes APIリソースは マルチクラウド、オンプレミスで使用可能 運用コスト クラスタのバージョンアップは実施不要 △ Kubernetesのバージョンリリースに追従して定期的に クラスタのバージョンアップを行う必要がある 今日のポイント 今日のポイント
20. 19 Copyright （C） Nomura Research Institute, Ltd. All rights reserved. ① 多数のコンテナデプロイ/コンテナ間通信 2. EKSだとこうやってますけど、ECSだとどうなります？ ◼多数のコンテナをデプロイする際にどうしている？ ◼EKSだとServiceとPodをセットでデプロイするが、ECSだとコンテナ間の通信はどうやる？ ・・・・・・ EKSワーカーノード(EC2)
21. 20 Copyright （C） Nomura Research Institute, Ltd. All rights reserved. Pod名： mypod IPアドレス：1111.2222.3333.4444 コンテナ ・Pod内には1つ以上のコンテナ ・Pod内のコンテナ間は localhostで通信可能 localhost コンテナ ・ ・ ・ (参考) Pod 2. EKSだとこうやってますけど、ECSだとどうなります？ ヘルス チェック Probe Liveness Probe（コンテナ生存確認） Readiness Probe （コンテナによるサービス提供可否確認） Startup Probe（コンテナ起動確認） Probeは稼働するコンテナのヘルスチェックを行い、 異常検知時に自動修復を行う リソース容量設定 最低保証値 (Requests) 上限値(Limits) コンテナに割り当てるリソース容量は2段階で指定可能
22. 21 Copyright （C） Nomura Research Institute, Ltd. All rights reserved. (参考) Service(ClusterIP) 2. EKSだとこうやってますけど、ECSだとどうなります？ Deployment名： mydeployment Podのラベル： app: myapp ラベル app: myapp ラベル app: myapp ラベル app: myapp Service名：myservice type：ClusterIP 振り分け先のPodのラベル： app: myapp 紐付け 仮想IPアドレス/DNS名 ClusterIPとは、安定した仮想IPアドレスとDNS名を提供し、 一貫したネットワークアクセスを実現する仮想的なエンドポイント ClusterIPに対する問合せはラベルで紐付けられた複数のPodに振り分けられる
23. 22 Copyright （C） Nomura Research Institute, Ltd. All rights reserved. ① 多数のコンテナデプロイ/コンテナ間通信 2. EKSだとこうやってますけど、ECSだとどうなります？ ◼ECSだとどうなる？をAIに聞いたら以下の回答でした。みなさんどれを使っていますかね？ ◼ 別 Task 間でシンプルな内部通信 → AWS CloudMap ⚫ Service 名 → Task IP 群 を DNS で引けるようにする ⚫ ただし、DNS 応答で複数 IP が返るので、実際にどのIPへ送るかはクライアント側挙動に依存 ⚫ ただし、リトライやロードバランシングをアプリ/ライブラリで考慮する必要あり ◼ HTTP API を安定運用したい → 内部向けApplication Load Balancer ⚫ AWS に負荷分散・ヘルスチェックを寄せたい場合に向く ⚫ ただし、サービスごとに ALB設計が必要 ◼ ECS 上でマイクロサービス通信を整理したい → ECS Service Connect 案1 案2 案3
24. 23 Copyright （C） Nomura Research Institute, Ltd. All rights reserved. ② 安全なコンテナ停止 2. EKSだとこうやってますけど、ECSだとどうなります？ ◼EKSはコンテナ(Pod)の停止時、Pod停止とServiceからの切離しが並行・非同期で行われる ◼コンテナの安全な停止のために、EKSではPod停止の前にリクエストの処理が完了する時間分 待つ設定(preStopフック)を入れたりするが、ECSだとどうなる？ Pod停止の前にリクエストの処理が完了する時間分 待つ設定を入れる PreStopフックでsleepコマンド実行 terminationGracePeriodSeconds
25. 24 Copyright （C） Nomura Research Institute, Ltd. All rights reserved. (参考) Podの安全停止設定のイメージ 2. EKSだとこうやってますけど、ECSだとどうなります？ ◼ PreStopフックのSleepコマンド実行とterminationGracePeriodSecondsの関係を図にしたものが以下 Service Pod停止開始 コンテナ強制終了 (SIGKILL) 新規リクエスト 受け入れ終了 コンテナ停止 (SIGTERM) ServiceからPodの切離し 新規リクエストの受け入れ コンテナ 処理してレスポンスを返す 新規リクエストの受け入れ PreStopフックでsleepコマンド実行 余裕値 Pod terminationGracePeriodSeconds 余裕値 apiVersion: apps/v1 kind: Deployment spec: template: spec: terminationGracePeriodSeconds: "180s" containers: - image: <コンテナイメージ名> lifecycle: preStop: exec: command: - sh - -c - "sleep 160" Deploymentマニフェストファイル
26. 25 Copyright （C） Nomura Research Institute, Ltd. All rights reserved. ② 安全なコンテナ停止 2. EKSだとこうやってますけど、ECSだとどうなります？ ◼ECSだとどうなる？をAIに聞いたら以下の回答でした。 ◼ECS でも安全停止のためのケアは必要だが、preStop相当の機能は無い アプリケーションでSIGTERMシグナルを受信した後gracefulに停止する必要がある ◼ALB配下のECS Serviceであれば、ターゲットグループからの切離し時に deregistration delay（接続ドレイニング時間）を効かす事ができる ◼stopTimeoutパラメータで、SIGTERMを送ってから強制停止(SIGKILL)までのタイムアウト を設定する事も重要 Gracefulな停止 気にしています？ ALBのドレイニング設定 使っています？
27. 26 Copyright （C） Nomura Research Institute, Ltd. All rights reserved. ③ コンテナ設定の機械的な違反チェック 2. EKSだとこうやってますけど、ECSだとどうなります？ ◼大量のコンテナをデプロイする場合、それらの設定が正しく行われているのかを人間でチェックする のは大変。ポリシー違反を見逃してしまう恐れあり ◼EKSだとGatekeeperやKyverno等のポリシー管理ソフトを導入してルールで統制できるが、ECS だとどうなる？
28. 27 Copyright （C） Nomura Research Institute, Ltd. All rights reserved. ③ コンテナ設定の機械的な違反チェック 2. EKSだとこうやってますけど、ECSだとどうなります？ ◼ ECSだとどうなる？をAIに聞いたら以下の回答でした。複数サービスを組合せて実現する？ ◼ Kubernetes の Admission Controller のような標準フックは ECS にはありません。そのため、ECS では主に以下の層で実現します。 ◼ つまり、ECS では Gatekeeper/Kyverno の完全な代替というより、CI/CD の事前検査 + AWSネイティブの事後監査 + IAM 制 御の組み合わせで実現するのが一般的です。 1. IaC / CI/CD 上でタスク定義・サービス定義を静的検査する 1. Terraform / AWS CloudFormation / AWS CDK / ecs-task-definition JSON を検査 2. 例: OPA(Conftest), Checkov, tfsec, cfn-guard, CDK Nag 2. デプロイパイプラインで “登録前 / 更新前” にカスタム検査を入れる 1. AWS CodePipeline / GitHub Actions / GitLab CI などでブロック 2. RegisterTaskDefinition や UpdateService 実行前に判定 3. AWS の設定評価系サービスで “デプロイ後” に継続監査する 1. AWS Config/ AWS Security Hub / Amazon Inspector / Amazon EventBridge + AWS Lambda で独自評価 4. IAM / SCP / 権限制御で危険な設定変更そのものを抑止する 1. 特定条件を満たさない操作を禁止 2. ただし ECS の設定内容を細かく Admission 的に判定するのは限定的
29. 28 Copyright （C） Nomura Research Institute, Ltd. All rights reserved. ④ 環境間のアクセス制御/通信制御 2. EKSだとこうやってますけど、ECSだとどうなります？ ◼KubernetesにはNamespace機能があり、論理的な環境を複数作成できる ◼RBACやNetworkpolicyと組合せる事で、環境間のアクセス制御/通信制御を行える ◼この様な制御はECSだとどうなる？ Networkpolicyを使った通信制御 RBACを使ったアクセス制御
30. 29 Copyright （C） Nomura Research Institute, Ltd. All rights reserved. ④ 環境間のアクセス制御/通信制御 2. EKSだとこうやってますけど、ECSだとどうなります？ ◼ ECSだとどうなる？をAIに聞いたら以下の回答でした。これもAWSリソースの組合せで実現ですかね ◼ ECS でも EKS の RBAC / NetworkPolicy に相当する統制は実現できますが、やはり Kubernetes のように「オーケ ストレータ標準機能で namespace を境界に制御する」モデルではありません。 ECS では AWS の IAM / Amazon VPC / Security Group / ECS Service Connect / 複数アカウント構成を組 み合わせて、論理環境間のアクセス制御・通信制御を作ります。 ◼ ECS では次のように考えるのが基本です。 1. EKS namespace の代わり ⚫ ECS cluster/AWS account/VPC/subnet/Service/task IAM role/リソースタグ 2. K8s RBAC の代わり ⚫ IAM/IAM Identity Center/SCP/Permission Boundary 3. K8s NetworkPolicy の代わり ⚫ Security Group/NACL/PrivateLink /VPC Lattice / Service Connect ◼ つまり ECS では、“namespace という論理境界”ではなく、“AWS リソース境界”で分離するのが本質です。
31. 30 Copyright （C） Nomura Research Institute, Ltd. All rights reserved. ⑤ EKSバージョンアップ 2. EKSだとこうやってますけど、ECSだとどうなります？ ◼EKSはバージョン追従が辛い。。。。。年に1～2回はバージョンアップする必要がある。。。 ◼EKS運用されている方は、どの様に対応されています？ ⚫ インラインでバージョンアップしているのか、Blue/Greenで対応しているのか ◼ECSはクラスタのバージョンを意識しなくて良いのは凄いメリットですよね！
32. 31 Copyright （C） Nomura Research Institute, Ltd. All rights reserved. (私なりの) まとめ そこまで大規模でない、プラットフォームチームが 組成できない、であればクラスタのメンテが不要な ECSに軍配がありと思ってます コンテナ数が大量・多種類だと Kubernetes/EKSの機能が活きてくる EKSはプラットフォームチームがクラスタ全体の 制御/統制を効かせやすいと思っています その分、EKSバージョンアップしんどいですね。。。