【CNDW2024】ECSとCloud Runの設計思想を比較し理解を深める

CloudNative Days Winter 2024において、「Amazon ECSとCloud Runの相互理解で広げるクラウドネイティブの景色」と題するセッションが開催された。登壇者は株式会社Synspectiveの新井雅也氏。AWSとGoogle Cloudの両方に精通した氏が、自身の知見をもとに両サービスの設計思想や技術的特徴を比較し、参加者に相互理解を促すものであった。既存の知識を活かし、もう一方を学ぶことでクラウドネイティブエンジニアとして成長するための具体的なヒントが示された。
ECSとCloud Runを通じた相互理解を促す
本セッションは、クラウドネイティブ領域において代表的な存在であるAmazon ECSとGoogle CloudのCloud Runを取り上げ、両者の比較・評価ではなく、相互理解を深めることを目的としている。登壇者の新井雅也氏は、両サービスについて「それぞれのクラウドで最も受け入れられているコンテナサービスだからこそ、学びを広げるきっかけにしてほしい」と語った。
セッションは、すでにECSもしくはCloud Runの利用経験を持つエンジニアに向けて構成されており、自身の経験や知識をベースにもう一方のサービスを学ぶことで、新たな視点を得ることを狙っている。解説はAWS FargateをデータプレーンとしたECSを前提に進められ、あくまで汎用的なアーキテクチャを例示しているが、個別ビジネス要件に応じた最適解が存在することも前提としている。
また「本発表はサービスの優劣を論じるものではなく、クラウドネイティブの視野を広げ、柔軟な設計力を培うための場である」という発言が、冒頭で強調された。新井氏自身がAWS Container HeroやGoogle Cloud Champion Innovatorといった両陣営での称号を持つことも、その中立的なスタンスを裏付けていると言える。
コンポーネント構造と実行環境から見た両サービスの差異
最初に新井氏は、Amazon ECSとCloud Runの基本的なコンポーネント構造と、技術面での特徴について体系的に整理した。新井氏は「最初に両サービスの設計思想の差異を理解しておくことが、後段のアーキテクチャ設計に必ず生きてきます」と語り、基礎固めの重要性を強調した。
まずECSはクラスター、サービス、タスク、コンテナという階層的構造を持つ。タスクは1つ以上のコンテナを束ね、サービスはタスク群を管理して起動数を維持し、クラスターは複数サービスを論理的にまとめる役割を果たす。ジョブ用途では、ECSタスク単位での実行も可能である。一方、Cloud Runはよりシンプルな構成となっており、サービス、リビジョン、インスタンス、コンテナの順で構成され、クラスターという概念は存在しない。さらにCloud RunはWebサービス用途だけでなくジョブ用途にも対応しており、タスクやジョブ単位で高い並列実行性能を発揮できることが特徴である。
VPCの扱いにおいても両者は大きく異なる。ECSはリージョン内に閉じるVPC内でリソースを展開し、サブネットやセキュリティグループの設計が必須となる。可用性を確保するためにはマルチAZ対応も必要だ。一方のCloud Runは、リージョンをまたぐVPC上に構成され、リソースはVPC外にデプロイされる。透過的にゾーンを跨いでデプロイされるため、マルチAZ設計をユーザーが意識する必要がないことが大きな利点である。
アクセス制御についても両者のアプローチが異なる。ECSはセキュリティグループを用いたTCPレベルでのアクセス制御を行うのに対し、Cloud RunはIngress制御とIAM認証の組み合わせによりHTTP(S)リクエストを制御する。IAM認証の有無、Ingress設定の内容によってアクセス可否が細かく分岐する構造は、Google Cloudらしい柔軟性を感じさせるものだと新井氏は言う。
最後に、コンテナの実行環境についても興味深い説明があった。ECSではFirecrackerというmicroVM技術を利用し、同一マシン上でも高い分離性を確保している。これはGoogleが開発したcrosvmをフォークして生まれたものであり、「ここにもクラウド技術のクロスオーバーがあるのです」と新井氏は語った。一方のCloud Runは世代によって実行環境が異なり、第1世代ではgVisor、第2世代ではmicroVMを採用している。第2世代ではLinuxシステムコールと完全互換を保ち、パフォーマンス向上も実現している。
このように、両サービスは「コンテナ実行基盤」という同じカテゴリーに属しながら、構成要素や制御手法、実行環境において大きな違いを持つ。これらの差異を理解することこそが、複雑化するクラウドネイティブ環境を適切に設計・運用するための第一歩である。
ネットワーク設計と内部通信でわかる思想の違い
続いて新井氏は、一般的なWebアプリケーション構成を例に取り、ECSとCloud Runにおけるアーキテクチャデザインの違いについて説明した。ここで重要なのは、両者が共通点を持ちながらも、設計思想において異なるアプローチを取っている点である。
まずインターネットアクセスに関しては、どちらもWeb Application Firewall(WAF)とロードバランサーを用いてセキュリティと可用性を担保する設計を基本としている。AWSではロードバランサーとAWS WAFを用い、必要に応じてAmazon Verified Accessを組み合わせることで特定のフェデレーティッドIDのみアクセスを許可するようにできる。一方Google Cloudでは、ExternalロードバランサーやCloud Armorを配置し、Googleアカウントによる認証制御を実現するIdentity-aware Proxy(IAP)と組み合わせることで同様の要件に対応している。「それぞれのクラウドで利用するサービス名は違いますが、設計パターンの根幹は共通しています」と新井氏は語った。
次にサービス間の内部通信においては両者の違いが際立つ。ECSはELBやECS Service Discovery、さらにECS Service Connectなど複数の接続方法を用意し、用途や運用に応じて選択可能である。対してCloud RunはIngress制御とIAM認証の設定により通信パターンを管理するが、内部通信を行う際はVPC経由でアクセスする必要がある。この違いはインフラレイヤーの管理範囲と思想の差異を示している。
また外部サービスへの通信についても違いがある。ECSはNAT Gatewayを経由して外部サービスにアクセスし、セキュリティ上もグローバルIPアドレスの固定化が容易であるのに対し、Cloud Runは直接グローバルIPを用いて通信することが可能だ。しかしIP制限が必要なケースではCloud NATを通してVPCを経由させるという設計が推奨される。
最後にジョブ実行のアーキテクチャについて説明があった。ECSではEventBridgeでスケジュールを設定し、Step Functionsを通じてジョブ実行をトリガーする。一方Cloud RunではCloud SchedulerとCloud Workflowsを組み合わせてジョブを実行する。「この部分は両者非常に似ています。どちらのクラウドを選んでも迷わずに実装できるはずです」と新井氏は自信をもって語った。
運用や非機能要件比較から学ぶ設計力向上のヒント
最後に新井氏は非機能要件という観点からECSとCloud Runを比較し、運用設計やパフォーマンス、セキュリティ、コスト最適化といった側面での違いと共通点を解説した。両クラウドには、それぞれWell-Architected Frameworkが用意されており、運用上のベストプラクティスに従うことが推奨されている。
CI/CDにおいては、ECSはCodePipelineやCodeBuildを組み合わせ、承認プロセスも含めたパイプライン設計が可能である。一方Cloud Runは、Cloud BuildとCloud Deployを用い、YAMLで柔軟にワークフローを定義できる。新井氏は「どちらも最終的には同じことが実現できますが、運用の思想に違いがあります」と補足した。
ログ運用についても両者に差がある。ECSはFluent Bitなどをサイドカーとして用いることでログ出力先を柔軟にコントロールできるのに対し、Cloud RunはすべてCloud Loggingに集約され、Log Sink機能で転送先を定義する仕組みとなっている。これにより、Cloud Runは一元管理を志向している点が明確に示されている。
セキュリティに関しては、ECSはAWS Secrets ManagerやSSM Parameter Storeと連携し、Cloud RunはSecret Managerを用いて環境変数として機密情報を渡す設計となる。選択肢の幅はAWSに軍配が上がるが、Google Cloudはシンプルで迷いにくい設計となっている。
パフォーマンスとスケールアウトの挙動も印象的であった。ECSは条件ベースの細やかなスケール設定が可能であるのに対し、Cloud Runはリクエスト量に応じて自動的にスケールし、最大インスタンス数を設定することができる。「手動で細かく制御したいならECS、自動スケールに委ねたいならCloud Runという選択肢になります」と新井氏は語った。
最後に両者の特徴を振り返りつつ、新井氏は次のようにまとめた。「クラウドサービスは常に進化しています。どちらか一方を知っているだけでは足りません。相互理解こそが、クラウドネイティブエンジニアとして成長する最大の武器になると信じています」と語って、セッションを締めくくった。
連載バックナンバー
Think ITメルマガ会員登録受付中
全文検索エンジンによるおすすめ記事
- 【CNDW2024】金融システムにおけるクラウドネイティブ化を実現するEKSの最前線
- コンテナは場所を選ばない!「オンプレ or クラウド × コンテナ」(前編)
- Linux Foudationの2020年上半期の動きを振り返る(2)
- 3日目はクラウド+コンテナに加え、セキュリティやAIといったキーワードも話題に
- 【CNDW2024】東京ガスの内製開発チームが挑むKubernetesの未来
- 「Cloud Native Trail Map」の10ステップを紐解く(ステップ8~10)
- CI/CD Conference 2023から、アルファドライブ/ニューズピックスのSREがAWS CDKを活用したCI/CD改善を解説
- コンテナは場所を選ばない!「オンプレ or クラウド×コンテナ」(後編)
- CloudNative Days Tokyo 2023から、クラウドネイティブセキュリティの脅威や論点を紹介
- 【CNDW2024】DeNAがECSを選択した理由と、GitHub Actionsセルフホストランナーの大規模運用