re:Invent 2024: AWSがECSとFargateの特徴と使い分けを解説
はじめに
海外の様々な講演を日本語記事に書き起こすことで、隠れた良質な情報をもっと身近なものに。そんなコンセプトで進める本企画で今回取り上げるプレゼンテーションはこちら！
📖 AWS re:Invent 2024 - Navigating the cloud compute landscape with Amazon ECS (SVS327)
この動画では、Amazon ECSとAWS Fargateの特徴や使い分けについて詳しく解説しています。新規AWSユーザーの65%がAmazon ECSを選択し、そのうち78%がAWS Fargateを採用している現状や、毎週24億のタスクを起動している規模感に触れながら、セキュリティ、コスト最適化、オブザーバビリティの観点から両者の違いを説明しています。特にAWS Fargateの100%の利用率や、Service Connectによるマイクロサービス間の接続性の向上、Container Insightsによる拡張オブザーバビリティ、Seekable OCIによるタスク起動の高速化など、最新の機能についても具体的に言及しています。
※ 動画から自動生成した記事になります。誤字脱字や誤った内容が記載される可能性がありますので、正確な情報は動画本編をご覧ください。
※ 画像をクリックすると、動画中の該当シーンに遷移します。
re:Invent 2024関連の書き起こし記事については、こちらのSpreadsheet に情報をまとめています。合わせてご確認ください！
本編
Amazon ECSとAWS Fargateの概要
簡単なアンケートをさせていただきます。AWSで稼働しているアプリケーションをお持ちの方は何人いらっしゃいますか？ECSで稼働しているワークロードをお持ちの方は？Fargateについてはいかがでしょうか？Fargateアプリケーションを使用している方は？近い将来Fargateへの移行を検討している方は？Fargateに完全に移行できると考えている方は？ありがとうございます。
皆様、こんにちは。Amazon ECSを使用したクラウドコンピューティングの世界を探る、このセッションにご参加いただき、ありがとうございます。私はAlexandr Morozと申します。Amazon ECSとFargateを担当するプロダクトマネージャーです。 そして私はRe Alvarez Parmarと申します。AWSのプリンシパルコンテナスペシャリストソリューションアーキテクトを務めております。本日は皆様にお会いできて大変嬉しく思います。
このセッションでは何を重点的に取り上げるのでしょうか？Amazon ECSだけでなく、ECSがAWSエコシステム全体とどのように連携し、他のAWSサービスとどのように協調するのかについてお話しします。コンテナは確かにアプリケーションをシンプルにし、アジリティや開発スピードなど、多くの素晴らしいメリットを提供します。しかし、コンピューティング部分だけでなく、AWSの他の部分をどのように活用してアプリケーションを構築するかを理解することは、時として難しい課題となります。また、コンテナを実行する適切な方法を選択することも、時として困難です。このセッションでは、これらの課題の解決方法をご紹介します。セッションの終わりには、セルフマネージド型かAWSマネージド型か、コンテナ実行モードの選択方法について明確な理解が得られます。また、ECSの仕組みやAWS全体との統合方法について理解を深め、アーキテクチャやアプリケーションについても説明します。
Amazon ECSの特徴とコンピューティングオプション
まずは、Amazon ECSとは何かという単純な質問から始めましょう。ECSは、高性能、スケーラビリティ、そして幅広いコンピューティングオプションを提供する、サーバーレスのコンテナオーケストレーターです。 いくつかの数字を見れば、ECSが現在主要なオーケストレーターであることがわかります。新規のAWSユーザーの65%がアプリケーションの実行にAmazon ECSを選択しています。これは文字通り、多くのお客様にとってAWSでの第一選択肢となっています。毎週24億のタスクを起動しており、これは非常に大きな数字です。アプリケーションを迅速かつ効率的にスケールできる、真にスケーラブルなソリューションです。さらに、Amazon ECSを選択したお客様の78%が、AWS Fargateでアプリケーションを実行することを選んでいます。
AWS FargateはAWSが完全に管理するサーバーレスコンピュートモードです。この数字は重要な意味を持っています。なぜなら、ECSの全体的な価値提案はシンプルさ、セキュリティ、効率性にあるからです。このシンプルさの多くは、サーバーレスな運用モードから生まれています。まず第一に、コントロールプレーンについて考える必要がありません - ECSではコントロールプレーンを管理する必要がないのです。Fargateを選択すると、データプレーンの管理やコンテナ化されたアプリケーションを実行するためのインフラストラクチャの管理についても考える必要がなくなります。これがECSの大きな利点です。次にセキュリティについてですが、ECSはAWSネイティブサービスであり、AWSで利用できるベストプラクティスとセキュリティプリミティブを活用することができます。文字通りAWSエコシステムにネイティブなのです。本日のセッションでは、この点について詳しく掘り下げていきます。
そしてもちろん、効率性についてもお話しします。アプリケーションをいかに迅速にスケールできるか、レジリエントで耐障害性のあるアプリケーションをどのように構築できるか、そして今日のセッションで取り上げる、適切なコンピュートプリミティブとスケーリング戦略の選択によってコンピュート料金をどのように削減できるかについて説明します。Amazon ECSについて話す際、通常はAWS FargateとAmazon ECS について触れます。しかし実際にはそれほど単純ではありません。AWSがハードウェア、データプレーン、コントロールプレーンを管理する完全マネージド型のAWSから、インフラストラクチャは自身で管理しながらAWS上で実行するAmazon ECSまで、より幅広い選択肢があります。Local Zones、Wavelength Zones、AWS Outpostsで実行することも可能です。さらに、Amazon ECS Anywhereを使用すれば、自社のデータセンターにある自社のハードウェア上でコンテナを実行しながら、Amazon ECSのコントロールプレーンを使用してコンテナのオーケストレーションを行うこともできます。
これらすべてのオプションがAmazon ECSで利用可能です。今日のセクションでは、主にAWS FargateとAmazon ECS on に焦点を当てて説明します。これが今回の議論の中心となります。 AWS FargateとAmazon ECSを見ると、どちらも素晴らしいメリットがあります。Amazon ECSでは、インフラストラクチャを完全にコントロールできます。インフラストラクチャの管理に精通している場合は、これは優れた選択肢となります。Amazon EC2インスタンスタイプを正確に選択したり、特定のバージョンのオペレーティングシステムを実行する必要がある場合や、セキュリティチームが特定のエージェントをインスタンスに組み込むことを要求する場合に、カスタムAMIを構築したりできます。また、キャパシティ不足エラーに遭遇するリスクを減らすためのCapacity Reservationsなど、Amazon EC2の機能への完全なアクセスが可能です。On Demand Capacity Reservationsを使用したり、Savings PlansやReserved Instancesでより大きな割引を受けることもできます。
Amazon EC2上でAmazon ECSを選択する理由は数多くありますが、それでもAmazon ECSユーザーの78%が、シンプルさを理由にAWS Fargateを選択しています。インフラストラクチャの運用について全く考える必要がなく、マネージド型のセキュリティとコンプライアンスが提供されるため、監査担当者にインフラストラクチャがAWSによって管理されていることを説明できるのは大きな利点です。AWS Fargateはスマートな方法でその選択を行ってくれるため、Amazon EC2インスタンスタイプについて考える必要がなく、キャパシティの選択がはるかに容易です。最後に、従量課金制の料金体系は、幅広いAmazon EC2インスタンスについて考え、それらのインスタンスの使用率を管理することと比べて、通常はるかに理解しやすいものとなっています。両者には数多くのメリットがあり、今日のセッションでは、Well-Architected Frameworkのレンズを通して、アプリケーションや特定のユースケースに適したコンピュートモードの選び方を見ていきます。各セクションで、これらのユースケースを検討し、アプリケーションにとってAmazon EC2上のAmazon ECSとAWS Fargateのどちらが適切な選択かを判断していきます。セキュリティはAWSにおける最優先事項です。
Amazon ECSのセキュリティと共有責任モデル
セキュリティについて議論する際、共有責任モデルを理解することが重要です。 このモデルは、お客様の責任とAWSの責任を理解するためのガイドとなります。Amazon EC2インスタンスの世界での運用に慣れている方にとって、このモデルは非常に馴染み深いものでしょう。これは開発者、SRE、プラットフォームエンジニアにとって有益です。なぜなら、アプリケーションをEC2からAmazon ECSに移行する際に、コンテナオーケストレーションに付随する機能を活用するために、大規模な学習を必要としないからです。
Amazon ECSの共有責任モデルは、EC2の世界での運用と似ています。お客様は、コードやワークロードを含むアプリケーション自体の管理に責任を持ちます。AWSは、ワークロードを実行するデータセンターやハードウェアのセキュリティを含むインフラストラクチャに責任を持ちます。Amazon ECSのデータプレーンは、ECSをEC2で使用する場合、EC2インスタンスで構成されます。データプレーンとEC2インスタンスのパッチ適用、アップグレード、そしてスケーリングがシステムのセキュリティに影響を与える場合は、適切なスケーリングの確保に責任を持つ必要があります。
ECS AgentはAmazonがEC2インスタンスの標準機能に追加して提供するコンポーネントです。このAgentは、EC2インスタンス上で実行されるサービスで、インスタンス、コンテナランタイム、そしてECSコントロールプレーンの間の橋渡し役を果たします。Amazon ECSの利点は、コントロールプレーンの管理が不要な点です。クラスターのスケーリングやセキュリティについてはAWSが担当するため、お客様はアプリケーションとデータプレーンに専念できます。
AWS Fargateでは、共有責任モデルが大きく変わり、お客様のセキュリティに関する責任が軽減されます。Fargateでは、AWSが管理するインスタンス上でワークロードを実行し、ハードウェアの管理やコンテナを実行するEC2インスタンスのセキュリティ確保、パッチ適用はAWSが行います。重要な違いは、Fargateがホストオペレーティングシステムに関連するすべての作業とECS Agentの管理を担当する点です。さらに、Fargateはログ記録を自動的に設定するため、お客様が対処する必要のあるセキュリティ関連のタスクが減少します。
コンテナのセキュリティ確保には、3つの層を考慮する必要があります。第一の層はコンテナイメージで、通常はコンテナレジストリレベルで静的スキャンが実施されます。このスキャンは、コンテナイメージを保存している場所で行われます。
スキャンのプロセスでは、更新が必要な脆弱なパッケージ、古いパッケージ、バイナリ、またはライブラリを見つけることを目的としています。Amazon Elastic Container Registry（ECR）を使用する場合、拡張スキャン機能により、イメージの一部として更新が必要なパッケージを自動的に検出することができます。これは、コンテナイメージのセキュリティを向上させる非常に簡単な方法です。
コンテナを実行する際には、適切な実行方法を確保することも重要です。実行時に実装すべき推奨設定が多数存在します。例えば、コンテナをrootユーザーとして実行したり、ホスト自体で特権的な権限を得られる特権コンテナとして実行したりすべきではありません。これは、コンテナがシステムに悪影響を及ぼさないようにするためです。コンテナが他のコンテナと並行して実行される可能性があるため、あるコンテナが誤動作したり侵害されたりした場合でも、その影響がそのコンテナのみに限定されるようにする必要があります。
最優先事項は、脆弱性が存在しないことを確認することです。つまり、コンテナイメージに古いパッケージやCVEが含まれていないことを確認する必要があります。しかし、そのイメージを実行している際には、たとえ誰かが未知の脆弱性を悪用できたとしても、悪意のある攻撃者がそのコンテナから脱出してさらなる被害を及ぼすことができないようにする必要があります。このような被害を軽減するために、ここに挙げられているものを含む（ただしこれらに限定されない）ベストプラクティスに従う必要があります。
さらに、Amazon ECSは、コンテナのベストプラクティスや12-Factor Appパターンで示されているベストプラクティスを採用しやすくする機能を提供しています。例えば、トラフィックをセグメント化する必要がある場合、追加の学習なしにSecurity Groupsの概念を再利用できます。AWSを使用している場合、トラフィックのセグメント化にSecurity Groupsが何のために使われるかを既に理解しているので、コンテナ化されたアプリケーションを実行する際にも同じ仕組みを使用できます。これは、モノリスをマイクロサービスに分割する際に特に役立ちます。異なるサービス間の通信パターンが大きく異なる可能性がありますが、Security Groupsを使用することで、どのアプリケーション同士が通信できるかを非常に簡単に指定できます。
Amazon ECSが支援してくれるもう一つの点は、シークレット管理です。これもコンテナのセキュリティベストプラクティスの一つで、機密性の高いデータをコンテナイメージに含めてはいけないというものです。パスワードやAPIキーを使用する必要がある場合、通常は環境変数として設定や実行時の引数として提供されます。コンテナアプリケーションはそれを使用できますが、どこにも保存されることはありません。Amazon ECSでは、AWS Secrets Managerのような場所にこれらのシークレットを保存することができます。データベースのパスワード、APIキー、証明書などをSecrets Managerに安全に保存し、タスク定義でそれらを参照できます。非常にシンプルで、シークレットを作成してSecrets Managerに保存し、タスク定義でそのシークレットのIDを渡すだけです。Amazon ECSがアプリケーションを起動する際に、自動的にそのシークレットを注入し、アプリケーションは環境変数としてそれを受け取ります。
Amazon ECSのキャパシティ管理とスケーリング
他のAWSサービスと通信する必要があるアプリケーションの場合、例えばAmazon S3にデータを書き込むアプリケーション（これはよくあるケースです）では、通常は何らかのオープンなアクセスを提供する必要があります。しかしAmazon ECSでは、非常に細かく制御できるIAMロールを使用できます。特定のS3バケットに書き込む必要があるコンテナを実行している場合、非常に制限された特定のロールを作成し、それをコンテナに関連付けることができます。
誰かがこのコンテナやこのロールにアクセスできたとしても、彼らができる最大の被害は、その特定のS3バケットへの書き込みだけであり、新しいEC2インスタンスを作成して暗号通貨のマイニングを始めることはできません。
他のAWSサービスへのAPIアクセスが必要な場合、Amazon ECSではIAMロールを使用するため、とても簡単に実現できます。Amazon ECSのタスクにIAMロールを割り当てるだけです。コンテナログに関しては、本番環境のワークロードを実行する場合、監査やセキュリティ目的でコンテナログを保持することが強く推奨されます。これもAmazon ECSでは非常に簡単で、設定を1つ変更するだけで、すべてのログをAmazon CloudWatchや、お好みのプロバイダーにストリーミングできます。
Amazon EC2と AWS Fargateの主な違いは、EC2では同じノード上の同じEC2インスタンスで複数のタスクを実行できることです。これはビンパッキングや、同じワーカー上での複数タスクの共存と呼ばれています。各タスクは複数のコンテナを持つことができますが、重要な違いは、AWS Fargateでは各タスクが独自のハードウェア上で実行されるということです。
最も重要な利点は、コンテナは仮想マシンのような明確な分離境界を提供しないという点です。コンテナは基盤となるオペレーティングシステムのメモリやリソースを共有します。そのため、同じノード上で実行される2つのコンテナは同じメモリ空間にアクセスできます。コンテナの悪用、コンテナからの脱出、メモリの悪用を防ぐための対策は可能ですが、同じノード上で実行されているコンテナAがコンテナBに影響を与えないことを完全に保証することはできません。AWS Fargateでは、2つのタスクは2つの異なるノードで実行されるため、メモリ、CPU、ネットワーク、ストレージを共有することがなく、これを保証できます。
これは非常に大きな利点です。なぜなら、デフォルトで分離が実装されており、AWS Fargateで実行される各タスクは独自のマイクロVM内で実行されるからです。もし誰かがAWS Fargateで実行されているコンテナにアクセスできたとしても、そのコンテナ自体への被害に限定されます。環境内の他のコンテナには影響を与えることができません。EC2と比較すると、EC2で実行されているコンテナにアクセスされた場合、理論的には、そのEC2インスタンス上で実行されている他のコンテナにも影響を与える可能性があります。
AWS Fargateを使用する場合、同じタスクの新しいレプリカを作成する時や、複数のサービスや複数のタスクがある場合、それらは常に分離されたマイクロVM内で実行されることを覚えておいてください。基本的に、実質的にはそれぞれが別のEC2インスタンスのようなものです。これらのタスクは共通のものを何も共有しません。AWS Fargateを使用すると、自動的に AWS Fargateに実装されている多くのセキュリティベストプラクティスを継承することができます。
例えば、AWS Fargateでは、タスクは常に分離されています。EC2でも同じことは可能ですが、同じノード上で実行されているコンテナを分離する方法を実装する必要があります。SELinuxやAppArmorなどのセキュリティツールを使用する必要があるかもしれません。しかし、AWS Fargateではデフォルトでこれが提供されます。また、Amazon ECSエージェント、コンテナランタイム、ホストオペレーティングシステム上で実行されている各種デーモンのパッチ適用や更新の責任も負わなくて済みます - それはAWSの責任です。そして特権コンテナの実行もできません。これは諸刃の剣で、時には特権コンテナが必要な場合もありますが、標準の実装では特権コンテナを実行できないようになっています。これは一般的に良いことです。というのも、ほとんどのアプリケーションは、基盤となるホストオペレーティングシステムへのアクセスや特権アクセスを本当に必要としないからです。
また、ノードへのSSH接続もできません。これはアプリケーションをハックするもう一つの方法です。もしコンテナをハックできない場合でも、基盤となるホストに何らかの方法でアクセスしてそのコンテナにアクセスすることができますが、AWS Fargateではそのようなオプションはありません。タスク自体を実行している基盤のハードウェアに接続することはできないのです。
トラブルシューティングが必要な場合、実行中のタスクに接続してログを取得したり、他のトラブルシューティングプロセスを実行したりする必要がある場合、Amazon ECSではコンテナへのexecが可能です。ECS Execは、ラップトップやターミナルから実行中のコンテナに接続してシェルアクセスを得ることができる機能で、トラブルシューティングに最適です。ただし、これも悪用される可能性があります。良いニュースは、これもAWS Identity and Access Management（IAM）ロールを使用するため、実行中のコンテナへの接続アクセスを制限できることです。これはAWS Systems Manager（SSM）を通じて行われるため、かなり安全です。ポートを開放したり追加の設定を行ったりする必要はありません。必要なのは、タスク定義で特定のタスクへのexecを許可することを指定するだけです。コンテナが実行時にスクラッチベースとして使用するエフェメラルストレージは、FargateではデフォルトでAES-256で暗号化されています。これも自動的に行われる追加の機能です。
PCI、HIPAA、SOCなどの特定のコンプライアンス基準に準拠する必要があるワークロードがある場合、Amazon ECSは非常に魅力的なオプションとなります。なぜなら、ECSはこれらすべてのコンプライアンス基準の認証に含まれているからです。Fargateではさらに簡単になります。Fargateでは、基盤となるオペレーティングシステムとホスト自体のセキュリティの管理が不要になるためです。つまり、コンプライアンス基準を満たすためにやるべきことが1つ減るということです。
Amazon ECSのネットワーキングとサービス接続
ここで問題となるのは、いつFargateを選び、いつAmazon EC2を選ぶべきかということです。私たちには両方を使用している顧客がいます。確かに100％Fargateで運用できる状況もありますが、EC2インスタンスが必要になるエッジケースもあります。EC2を使用しなければならない理由の1つは、アプリケーションがカスタムAMIを必要とする場合です。ほとんどの場合、コンテナはそのような依存関係を持つべきではありませんが、カスタムAMIやカスタムオペレーティングシステムを必要とするレガシーアプリケーションのエッジケースは常に存在します。もう1つの理由は、特権アクセスを必要とするソフトウェアエージェント、典型的にはセキュリティエージェントを実行している場合です。Crowdstrikeやその他のサードパーティのアドオンを実行してセキュリティのためのテレメトリデータを収集するためにすべてのEC2インスタンスをスキャンする必要があり、Fargateが要件を満たさない場合は、おそらくEC2を使用する必要があります。
お客様がEC2を選択する別の理由として、プロセスや人材に既に多大な投資をしているため、Fargateが提供する機能は自分たちで既に実現できているというケースがあります。その場合、優れたプロセスがあれば、自動化によってEC2を継続して使用し、EC2に標準化することも可能です。しかし、そのような自動化と投資がない限り、大多数のアプリケーションにとってはFargateの方が適切な選択肢となるでしょう。
キャパシティ予約について話しましょう。キャパシティのプロビジョニングは、私たちが触れたいもう一つのトピックです。Fargateを選択すれば非常にシンプルになりますが、それでも非常に重要な話題です。なぜなら、ほとんどの場合、アプリケーションは負荷やトラフィックの変化に応じてスケールアウトやスケールインする必要があるからです。これは最も興味深い部分の一つです。Amazon ECSはAWS Application Auto Scalingと統合されており、レイヤーの動作を制御することができます。
CPU負荷、メモリ使用率、サービスに接続されているロードバランサーのリクエスト数など、特定のメトリクスに対して閾値を定義できます。これらの閾値に達した時の対応方法を指定することができます。より多くのタスクを追加して負荷を分散させたり、アラームが解除されて閾値を下回った時にスケールインしてタスクの数を減らしたりできます。これはTarget Trackingと呼ばれています。また、Scheduled Scalingも可能です。例えば、午前9時の業務に備える必要があり、午後5時以降はユーザーが少なくなることがわかっている場合、午前8時45分にスケールアウトし、午後5時30分にタスク数を減らすことができます。
これが実際の動作の別のアプローチです。Amazon ECSはメトリクスをCloudWatchに送信し、Auto ScalingがCloudメトリクスを追跡して、ECSに対してアクションを指示します。しかし、実際の裏側では、Amazon ECSはCapacity Providersという概念を使用しています。Capacity Providersは、キャパシティをプロビジョニングする、つまりEC2インスタンスを提供したり、AWS Fargateの場合はワークロードを実行するワーカーノードを提供したりするものです。Capacity Providersの使用は、単にデフォルト設定で1つ作成して必要なタスク数を指定するだけのシンプルなものから、Auto Scalingと統合して、その時点でアプリケーションが必要とする正確なタスク数を提供する非常にスマートなものまであります。
2つのCapacity Providersを使用する場合は特に興味深くなります。というのも、多くのオプションが用意されているからです。Amazon ECSに対して、コストを削減したいので、できるだけ少ないインスタンス上にタスクを最も効率的にパックしてほしいと指示することができ、私たちはまさにそのとおりに実行します。あるいは、可用性を優先したいので、異なるアベイラビリティーゾーンでタスクを起動したいと指示することもでき、その場合は3つの異なるアベイラビリティーゾーンで少なくとも3つのインスタンスを実行して、より高い可用性を提供します。これらの制御はすべてCapacity Providersで可能です。AWS Fargateの場合はもっと単純です。Fargate On DemandやSpotを使用するポリシーを定義できますが、実際にはすべてが裏側で統合されており、実際の制御はありません。Fargateは常に、異なるアベイラビリティーゾーンの個別のインスタンス上で新しいタスクを起動し、ユーザーに代わって可用性を優先します。
AWS Fargateのメリットには、インフラストラクチャの抽象化が含まれます。タスクに必要なvCPU数とメモリ量という2つの情報だけを指定すれば、私たちがそれらのパラメータに基づいて正確にタスクを起動します。スケールアップとスケールダウンは、お客様の指定または Application Auto Scaling に基づいて行われます。Fargateの見落とされがちな利点の1つは、非常に幅広いインスタンスタイプから選択できることです。タスクは複数の異なるインスタンスタイプで起動できるため、キャパシティの起動成功率が高くなり、AWSでCapacity Reservationsを使用していない場合に発生する可能性のある、キャパシティ不足エラーに遭遇する可能性が大幅に低くなります。
このような幅広いインスタンスタイプの選択肢は、アプリケーションの可用性を高めるFargateの大きな利点です。一般的に、Amazon ECSワークロード用に幅広いインスタンスタイプを維持しない限り、AWS Fargateはより高い可用性を提供します。同じレベルの可用性を達成することは可能ですが、非常に幅広いインスタンスタイプを用意するか、AWSにキャパシティ管理を任せる必要があります。一般的に、これは非常にうまく機能します。
本日ご紹介したい新機能の1つは、Amazon ECSが Predictive Auto Scaling と統合されたことです。 この機能により、アプリケーションの可用性を高めつつコストを削減するための新しいオプションが提供されます。機械学習を使用して過去14日間のデータを収集し、予測に基づいてワークロードのスケールアウトとスケールインを行います。さらに、複数のポリシーを組み合わせることができます。例えば、営業時間中は20タスク、営業時間外は2タスクというスケジュールポリシーを設定できます。もし Predictive Auto Scaling が過去14日間の特定のメトリクスに基づいて、午後3時から4時の間に実際に24タスクが必要だと判断した場合、自動的にタスク数を増やし、アプリケーションの可用性を高め、顧客トラフィックへの対応力を向上させます。また、Forecastモードで実行して、この機能が自分に適しているかどうかを確認することもできます。Forecastモードの予測ポリシーは、タスクを起動する必要があると判断したタイミングを示すだけで、実際の起動は行いません。Provisioningモードで有効にする前に、この機能が自分に適しているかどうかを評価するための指標を提供します。これは、機械学習を活用してアプリケーションのパフォーマンスを向上させ、コストを削減する非常に強力な方法です。
ここで、Amazon ECS on EC2とAWS Fargateの比較について説明します。Amazon ECS on EC2は、アプリケーションに特定のパフォーマンスプロファイルを保証する必要がある場合に適しています。例えば、高いネットワークスループットが必要で、より高いネットワークパフォーマンスを持つm5nなどの特定のインスタンスタイプを使用する場合、Amazon ECS on EC2の使用が望ましいでしょう。Fargateは汎用インスタンスタイプを幅広く提供しますが、パフォーマンスや特定のパフォーマンスプロファイルに関する保証は提供しません。これは、インフラストラクチャを制御する際に選択できる要素であり、Amazon ECSはそのための優れた方法です。
On-demand Capacity Reservationsは、キャパシティ不足の例外やエラーの可能性を減らすのに非常に効果的ですが、完全に防ぐことはできません。アプリケーションのスケールアウトができない状況に陥ることもあります。特定のアプリケーションやワークロードが重要で、常に一定のキャパシティを確保する必要がある場合は、On-demand Capacity ReservationsまたはReserved Instancesを使用してください。これはAmazon ECS on EC2で利用可能な機能です。繰り返しになりますが、使用する際は、アプリケーションの可用性にとって非常に重要なので、幅広いインスタンスタイプを使用するようにしてください。
Amazon ECSのモニタリングとオブザーバビリティ
それでは、アプリケーション同士の接続について説明しましょう。特にモノリスアプリケーションからマイクロサービスへ移行する際によく直面する課題の一つは、これまで単一のモノリスアプリケーションで様々な機能を処理していたものを、異なるマイクロサービスで個別の機能を担当するように分割することです。例えば、複数のレプリカでバックアップされた認証サービスと、Card Serviceと呼ばれる別のサービスを持つウェブサイトがあるとします。
これは典型的なマイクロサービスのパターンですが、この2つのサービスをどのように接続するかが課題となります。これまでは、間にロードバランサーを置くか、サービスレジストリやサービスディスカバリーのような仕組みを使用する必要がありました。
Amazon ECSは、Service Connectを標準で提供しており、これによってアプリケーションの登録が簡単になります。クラスター内で実行されているすべてのサービスをこのレジストリに登録できます。あるサービスが別のサービスと通信する必要がある場合、エイリアスを使用するだけで通信が可能です。例えば、Card ServiceがAuthentication Serviceと通信する必要がある場合、このAuthentication Serviceのエイリアスだけを知っていれば良いのです。エイリアスを作成して「auth」と名付ければ、アプリケーションAからアプリケーションBへの通信に必要なのはそのエイリアスだけです。Amazon ECSは、特に複数のレプリカを持ち、複数のコンテナでバックアップされているマイクロサービスアプリケーション環境において、このようなサービスレジストリの作成を容易にします。
Service Connectは、クラスター内で実行されているサービス同士の接続を非常に簡単にします。さらに、接続性も単純化します。必要なのは、接続したい下流のサービスの名前を知っているだけです。Service Connectを有効にすると、バックグラウンドでアプリケーションの横にプロキシが注入されます。このプロキシの役割は、2つのアプリケーション間の接続性を改善することです。コードで暗号化と復号化を処理する必要なく、トラフィックを透過的に暗号化できます。暗号化と復号化の機能は、完全にService Connectによって処理され、コードの中では処理されません。
モノリスからマイクロサービスに移行する際には、分散コンピューティングのベストプラクティスを実装する必要があります。これには、リトライ、指数バックオフ、タイムアウト、サーキットブレーカーなどの導入が含まれます。Amazon ECS Service Connectは、これらを自動的に処理します。私のアプリケーションで2つのマイクロサービスがある場合、コードで実装することなく、サービス間の接続にリトライメカニズムを確保できます。これにより、開発者は接続の複雑さを理解する必要がなく、ネットワークトポロジーを気にすることなく、純粋にアプリケーションコードに集中できるため、認知的な負荷が大幅に軽減されます。
Service Connectはマイクロサービス間の信頼性の高い接続を保証し、すべてのトラフィックがプロキシを通過するため、この接続からメトリクスを抽出することができます。トラフィックパターンの把握や、ボトルネックの特定、改善が必要な領域の発見が可能です。最近では、Amazon ECSサービスをAmazon VPC Latticeと接続できる新機能も発表しました。VPC Latticeをご存じない方のために簡単に説明すると、VPC Latticeは異なるコンピューティングプラットフォーム上で実行されている複数のサービスを接続することができます。AWS Lambda、Amazon ECS、Amazon EC2で実行されているアプリケーションがあった場合、これらのアプリケーションを接続してメッシュを作成し、相互に簡単に通信できるようにすることができます。
Amazon VPC Latticeのさらなる利点として、本当に素晴らしいのは、VPCピアリングやトランジットゲートウェイを使用せずに、アカウントやVPCを越えてアプリケーションを接続できることです。マルチアカウント環境をお持ちの場合、VPC Latticeは、Amazon ECSで実行されているか、複数のVPCや複数のアカウントのECSで実行されているかに関係なく、複数のサービスを接続するための非常に魅力的な選択肢となります。これにより、AWSのベストプラクティスに従ってアプリケーションを適切に管理・整理することができます。
どのオプションを選択するかを検討する際は、非常にシンプルです。特殊なネットワーク機能が必要な場合や、ホストネットワークへのアクセスが必要な場合、またはNATの背後で実行している場合は、おそらくAmazon EC2を選択することになるでしょう。基盤となるホストのENIへのアクセスが必要な場合も、EC2を選択する理由となります。2024年にはもう使用すべきではないDockerリンクへの依存関係がある場合は、EC2から始めることになるかもしれませんが、それらのリンクを排除するためにECSの構成要素を使用することを強くお勧めします。
モニタリングについて話しましょう。オブザーバビリティには通常、ロギング、モニタリング、トレーシングという3つの柱があります。トレーシングは完全にアプリケーションレベルで行われるため、今日はトレーシングについては触れませんが、ロギングとモニタリングについて説明しましょう。Amazon ECSでEC2を使用している場合、実行しているアプリケーションに加えて、ホストもモニタリングする必要があります。ホストでは通常、Amazon CloudWatchで簡単に利用できるログとメトリクスという2つの要素をモニタリングします。サードパーティのプロバイダーやパートナー製品を使用している場合は、それらを使用してホストをモニタリングすることもできます。
アプリケーションについては、VPC Flow Logsを使用してマイクロサービス間のトラフィックパターンを把握することができます。また、CloudWatchを使用して集中ログ管理を行うことができ、CloudWatchとうまく連携する他のツールを使用して、内部の状況を把握し、改善が可能な領域を特定することができます。Amazon ECSでのログルーティングには、FluentdやFluent Bitを使用でき、Fargateでは簡単な設定変更だけですべてのログを送信することができます。
選択肢の間にそれほど大きな違いはありません。EC2を選ぶ唯一の理由は、ログやメトリクスを収集するために特権コンテナなどの特権が必要なパートナー製品を使用する場合です。ただし、CloudWatchを使用している場合は、Fargateでも同様に簡単に実行できます。アプリケーションが詳細なホストモニタリングを必要とする場合や、それに依存している場合（これは非常に特殊なユースケースです）を除いて、実際のところ選択の余地はあまりありません。
Container Insightsで最近リリースした機能の1つに、Amazon ECSの拡張オブザーバビリティがあります。これは多くのシチュエーションで非常に役立ちます。お客様がマイクロサービスを採用すると、大量のメトリクスデータに圧倒されがちで、何に注目すべきで何を安全に無視できるのかが分からない方も多いのです。拡張オブザーバビリティには、多くのお客様との対話を通じて構築された、優れたキュレーションされたダッシュボードが付属しています。SRE、DevOpsエンジニア、プラットフォームエンジニア、開発者の方々が、特定の障害の根本原因を簡単に見つけたり、システムの問題を特定したりできるように設計されています。ダッシュボードはそのような目的で構築されており、アプリケーションを詳しく調査して問題を特定することができます。素晴らしいのは、同じアカウントで実行されているかどうかに関係なく、ECSで実行されているすべてのワークロードを1つの画面で確認できることです。つまり、拡張オブザーバビリティを使用して、マルチアカウント・マルチクラスターのモニタリングが可能になります。
ここで2つのポイントを振り返りましょう：Amazon ECS内の複数のリソースを1つの画面でモニタリングできること、そしてダッシュボードの構築やメトリクスの特定、監視項目の選定を自分で行う必要なく、問題が発生している可能性のある領域を素早く特定できることです。これを効果的な出発点として使用し、カスタム要件がある場合は、これらのダッシュボードを基にカスタムダッシュボードを作成することもできます。
Amazon ECSのコスト最適化戦略
次は、私の心に非常に近く、皆様も気にかけているであろうコスト最適化というトピックに触れていきましょう。AWSでは、コスト最適化戦略を4つの視点から検討することを推奨しています：ハードウェアから始まり、購入オプション、そしてスケーリングと最適化、そしてオブザーバビリティです。すでに、不要な時に多くのリソースを実行することで無駄を生まないようにすることで、コンピューティングの料金を削減できるスケーリングについて話しました。また、これらのメトリクスの取得方法や処理方法を理解するオブザーバビリティについても触れました。
ここでは、ハードウェアと購入オプションに焦点を当てましょう。現在、EC2とAWS Fargateの両方で実行されるAmazon ECSでは、 Intel Xeon Scalable Processors、AMD EPYCプロセッサー、そして 価格性能の面で大きな利点を提供するAWS Gravitonプロセッサーを使用できます。第4世代の導入により、 純粋なパフォーマンス面でのメリットも得られます。異なるアーキテクチャであり、Arm上で実行するためにはアプリケーションを再コンパイルする必要がありますが、これは優れた選択肢であり、同じ計算に対してエネルギー消費が大幅に少ないため、地球にもやさしい選択肢です。これは非常に理にかなった選択肢であり、多くのお客様がAWS Gravitonプロセッサーへの移行により大きなコスト削減を実現していることから、需要も非常に高まっているため、皆様にもぜひ検討をお勧めします。
コンピュートキャパシティの購入オプションについて見ていきましょう。一般的に、コンピュートキャパシティを確保する方法は3つあります。1つ目は、最も一般的な方法であるOn-demandで、これは基本的な開始点となります。使用した分だけ支払う方式で、変動の大きいワークロードや、ステートフルなワークロード、あるいは完全には予測できないワークロードに最適な選択肢です。Savings plansは、1年または3年の期間にわたって特定のコンピュート時間を消費することを約束する、異なる形態の調達方法です。この約束により、大幅な節約が可能になります。つまり、アプリケーションの特性をよく理解している場合や、将来のアプリケーションのスケールを予測できる場合は、特定の使用量にコミットすることで費用を節約できます。これらのSavings plansは、Amazon ECSとAWS Fargateの両方で利用できますが、それぞれ異なるプランとなっています。最後に、Spotは異なるキャパシティ起動方法です。定義上、これはAWSが割引価格で提供する余剰キャパシティで、On-demand価格の10%程度まで下がることもあります。ただし注意点があります：AWSはいつでもそのキャパシティを回収する可能性があり、その場合、タスクを停止してすべてのプロセスを終了するまでに2分間の猶予が与えられます。これは、障害に強く、中断を処理できるアプリケーションを構築する場合に最適なオプションです。
今年9月、私たちはFargate Graviton CPUでのSpotサポートを開始しました。これにより、ARMベースのGraviton CPUを搭載したFargateをSpotモードで起動できるようになり、コンピュート費用を削減するこれら2つの方法を組み合わせることが可能になりました。
Fargateには、 ECS on EC2では実現できない追加のコスト最適化機能がいくつかあります。定義上、Fargateは100%の利用率を提供します - リクエストした分だけ支払えばよいのです。各インスタンスで起動されているタスクの数や利用率を追跡する必要はありません。確かに、FargateはEC2と比べて若干価格が高めですが、リクエストした分に関して常に100%の利用率が得られることを考慮すると、多くの場合、実際にはFargateでワークロードを実行する方が安くなります。これは見落とされがちな点です。多くの人がこのことを考慮していませんが、多くのお客様にとってこれは事実であり、ECS on EC2からFargateに移行して即座にこれらの節約を実感されるお客様を数多く見てきました。なぜなら、私たちはより良い利用率を実現する異なるアプローチを提供しているからです。
触れておきたい他の2つの点として、タスクの起動を高速化するためのSeekable OCIと、Fargateと統合してサイズ最適化の推奨を提供し、現在ではアイドルタスクの推奨も行うAWS Compute Optimizerがあります。SOCIが実際に何を意味するのか、簡単に説明しましょう。通常、タスクを開始するには、コンテナレジストリからコンテナイメージをダウンロードする必要があり、これは平均してタスク開始時間の76%を占めています。つまり、これらのイメージをダウンロードして待機している時間に対して料金を支払っているわけです。しかし実際には、研究によると、タスクを開始するために必要なコンテナイメージの部分はわずか6.4%だということがわかっています。
SOCIを使用すると、コンテナのインデックスを作成し、起動に必要な部分を指定することができます。タスク開始時には、これらの必要不可欠な部分のみをダウンロードしてタスクを開始し、残りのイメージは並行してダウンロードを続けます。これにより、複雑なタスクの場合、コンテナの起動が大幅に高速化されます。ワークロードによって効果は異なりますが、複数のコンテナを持つ大規模で複雑なタスクでこのような効果が見られます。これは、アプリケーションの応答性を向上させ、コンピュート料金を削減するための優れた方法です。
最後に、AWS Compute Optimizerは素晴らしいツールです。このツールはワークロードとメトリクスを分析して、調整が必要かどうかを教えてくれます。例えば、タスクに2 vCPUと8GBのメモリを要求しているけれど、使用率が低いため1 vCPUと4GBの方が適しているといったアドバイスをしてくれます。単に推奨サイズを提示してくれるだけです。逆に、CPUが80%で高負荷になっている場合は、レスポンス性とアベイラビリティを向上させるためにサイズアップを推奨します。この2週間で、AWS Compute Optimizerはアイドル状態のタスクに関する推奨事項も提供するようになりました。過去14日間を分析して、CPU使用率が1%未満の場合、そのワークロードは遊休状態で価値が低い可能性があるため、見直しを推奨してくれます。
Reserved InstancesとSavings Plansは、ECS on EC2の明確なメリットです。Bin Packingの方法を知っていて、そのような制御を望むなら、それが最適な選択です。とはいえ、Fargateも魅力的なオプションであることには変わりません。短時間のタスクについては、課金の仕組みの特性上、ECSもFargateも1秒単位で課金されますが、最小課金期間は60秒です。つまり、Fargateで60秒未満のタスクを実行する場合、常に1分間分の料金が発生します。一方、ECS on EC2では、複数のタスクを配置するため、インスタンスは通常もっと長く稼働します。そのため、短時間のワークロードではECS on EC2を使用することで大幅なコスト削減を実現できます。
以上で本日のセッションは終了です。このQRコードをスキャンしてAmazon ECSの入門ガイドをご覧いただくことで、さらに学習を続けることができます。本日は皆様の貴重なお時間をいただき、ありがとうございました。アプリケーションでセッションのアンケートへのご回答もお忘れなくお願いいたします。重ねて御礼申し上げます。
※ こちらの記事は Amazon Bedrock を利用することで全て自動で作成しています。
※ 生成AI記事によるインターネット汚染の懸念を踏まえ、本記事ではセッション動画を情報量をほぼ変化させずに文字と画像に変換することで、できるだけオリジナルコンテンツそのものの価値を維持しつつ、多言語でのAccessibilityやGooglabilityを高められればと考えています。
Discussion