re:Invent 2024: AWSによるAmazon ECSのObservability強化と活用法
はじめに
海外の様々な講演を日本語記事に書き起こすことで、隠れた良質な情報をもっと身近なものに。そんなコンセプトで進める本企画で今回取り上げるプレゼンテーションはこちら！
📖 AWS re:Invent 2024 - Enhancing observability in Amazon ECS to gain actionable insights (SVS328)
この動画では、Amazon ECSのObservabilityを強化してアクショナブルなインサイトを得る方法について解説しています。Container InsightsやApplication Signals、CloudWatch Log Insightsなどのツールを活用して、パフォーマンス低下やエラー発生時の問題特定と解決方法を、実際のWatch Storeアプリケーションを使った3つの具体的なシナリオで示しています。また、ECS Split Cost AllocationとAmazon QuickSightを組み合わせることで、ECSクラスターのコスト分析や可視化を行う方法も紹介しています。One Observability WorkshopやCDK、Terraformのテンプレートなど、すぐに実践できる具体的なリソースの案内も含まれています。
※ 動画から自動生成した記事になります。誤字脱字や誤った内容が記載される可能性がありますので、正確な情報は動画本編をご覧ください。
※ 画像をクリックすると、動画中の該当シーンに遷移します。
re:Invent 2024関連の書き起こし記事については、こちらのSpreadsheet に情報をまとめています。合わせてご確認ください！
本編
Amazon ECSのObservabilityセッション：概要と目的
re:eventへようこそ。こんにちは。本日のセッション「SV 328: Amazon ECSのObservabilityを強化してアクショナブルなインサイトを得る」にお越しいただき、ありがとうございます。私はAWSのPrincipal Solutions ArchitectのSteven Davidです。そして、共同発表者のLucyをご紹介させていただきます。
みなさん、こんにちは。本日はお越しいただき、大変嬉しく思います。私はAWSのSenior Worldwide BD SpecialistのLucy Hartungです。このセッションのために30分も列に並んでお待ちいただいた方々がいらっしゃると伺い、大変感動しています。これから1時間、Amazon ECSでアクショナブルなインサイトを得る方法について、有意義な情報をお伝えできればと思います。
こちらが本日のアジェンダです。まず、お客様が直面している課題について理解を深め、その後ObservabilityのメリットとECSを観測する必要性について掘り下げていきます。実際のシナリオとデモを用意しており、AWSの機能を活用してアクショナブルなインサイトを得る方法を実践的にご紹介します。最後に、このセッションで学んだ知識を日々の業務に活かせるよう、参考リソースと次のステップをご案内します。
コンテナ技術とECSの利点：Observabilityの重要性
それでは、まず皆様についてお伺いしたいと思います。現在、Amazon ECS上でワークロードやアプリケーションを構築されている方は何人いらっしゃいますか？手を挙げていただけますでしょうか？素晴らしいですね。 コンテナは、お客様のより迅速で効果的なイノベーションを支援しています。なぜそれが可能なのでしょうか？コンテナには移植性があります。アプリケーションのパッケージはすべて1つのコンテナにまとめられ、同じOSで実行されるため一貫性があります。このイノベーション、移植性、一貫性により、自動化をより早く実現でき、ソフトウェアの提供スピードが向上し、リソースのオーバーヘッドが削減されます。
これが、多くの方々が今日ECSでの構築を選択している理由です。お客様からいただいた最も重要なフィードバックは、ECSでの構築のシンプルさです。お客様は、他のAWSサービスとのシームレスな統合が気に入っているとおっしゃっています。 この自動化ワークフローを詳しく見ていきましょう。ECSの一般的なアプリケーションでは、アジリティとスピードを備えたビルドとデプロイパイプラインから始まり、メトリクス、ログ、アプリケーションの健全性の観測まで行います。全体を通して、セキュリティ対策が施されています。そして、自動化における重要な要素であるオーケストレーションも忘れてはいけません。オーケストレーションは、スケジューリングやオートスケーリングなどの重要な側面を処理しながら、ネットワーク、コンピュート、ストレージを自動的に決定するのに役立ちます。
多くの方々が ECS 上でワークロードやアプリケーションを構築することを選択している理由、これが本質的な部分です。ECS の素晴らしさについてすでにご存知の方にとっては、知識の確認になるかもしれません。 おっと、ここで問題が発生していますね。先ほど ECS の素晴らしさについて話したばかりですが、どんなに ECS が素晴らしくても、どれだけ ECS を愛していても、時には問題が発生します。コンテナは時々故障しますし、毎日が晴れて虹が出るわけではありません。問題を修正しなければならない時もあります。私たちの目標は ECS で100%の可用性を約束することではありません。それは皆さんを失敗に導くことになってしまいます。
その代わり、私たちの目標は、コンテナに問題が発生した際にお客様をサポートすることです。問題を特定し解決するために、適切なツールと機能を確実に提供したいと考えています。
Observabilityが重要な理由についてお話ししましょう。 Observabilityは、メトリクスやログを通じてコンテナの可視性を確保することから始まります。これはリアルタイムの問題をトラブルシューティングする際の基盤となります。しかし、Observabilityは根本原因の特定と問題解決だけにとどまりません。さらに進んで、ECS環境での最終ユーザー体験を理解するといったビジネス上のメリットもあります。ECS上でアプリケーションを構築する場合、必ずユーザーとの対話があります。ページの読み込みが失敗していないか、ユーザーが決済を完了できているかを知る必要があります。そのような体験を維持し、問題が発生していないことを確認したいものです。
よく耳にするのは、ページが読み込めない、登録できないというお客様からの苦情です。私たちは、エンドユーザーが問題を経験する前に、情報を理解して問題を解決できるようにしたいと考えています。これもObservabilityの一部です。そして最後に重要なのがコストです。多くの人にとって、これは一見明白ではないかもしれません。アプリケーションの構築コストについて、マネージャーやプロジェクトリーダーから質問されたことは何度ありますか？来年度の予算を立てる際、アプリケーションのコストがどれくらいになるのか、あるいは過剰に拡大していないかを理解する必要があります。これらの側面は、ECS上でワークロードやアプリケーションを構築する際に極めて重要であり、これがObservabilityの全体像です。
シナリオ1：アプリケーションのパフォーマンス問題の特定と解決
ここで、ECSのContainer Insightsについて、私のパートナーのStevenに話を譲りたいと思います。 なぜここにいるのかについて話してきましたが、次はこれにどのようにアプローチするかについて話しましょう。エラーが発生した時、これから4つの異なるシナリオを見ていきますが、クラスターで何が起きているのかを理解するために、どのようにインサイトを得て、利用可能なAWSツールを使用するかを理解する必要があります。 一つのケースとして、複数のアカウントにまたがって展開された複数のアプリケーションがある場合が考えられます。これをよりアプリケーション中心にするにはどうすればよいでしょうか？ECSやその他のサービスにあるリソースを含め、アプリケーション全体でインサイトを得るにはどうすればよいでしょうか？
アプリケーションの健全性と、どのKPIを監視すべきかを理解する必要があります。障害率やレイテンシーなどの一般的なメトリクスを確認していきましょう。 メトリクス、ログ、トレースを見る際には、それらをどのように組み合わせてコードベースに必要な変更を加えるかを理解する必要があります。 最後に、デバッグではなく改善に取り組む場合もあります - アプリケーションの応答性を向上させ、リソースをより効果的に使用するにはどうすればよいでしょうか？
デモで使用するアプリケーションを見てみましょう。 これは基本的に時計店のサンプルアプリケーションで、AWSのコンテナエコシステム全般で多くのデモに使用しているものです。 ホームページを見ると、時計の種類で並び替えができるカタログがあることがわかります。
時計の種類を選択したら、カートに追加して、チェックアウトプロセスに進むことができます。これは複数のステップからなるチェックアウトプロセスで、取引中に様々な問題が発生する可能性があります。 これは私たちが扱うアプリケーションのタイプを視覚的に示すためのものです。
このアプリケーションに関連するインフラの管理者だと仮定してみましょう。 アプリケーションの応答性が期待通りではなく、アプリケーション自体に問題があるという報告を受けています。単に何かがおかしくて、システムに関する苦情が増えているので、デバッグを手伝ってほしいと言われています。コンソールを開いてホームページを見ると、以前には見られなかったものがあります - 「My Applications」ウィジェットです。このウィジェットは、モニタリングからCPU情報、関連するコンピュータまで、アプリケーションに関する様々なリソースを収集するために使用できます。
もう少し詳しく見てみましょう。Watch Applicationをセットアップしており、上部には一般的な情報が表示されています。 その下にはすべてのCompute情報があります。最初にEC2 Computeが強調表示され、関連するアラームがあるかどうかが表示されています。 Lambda Computeもここに表示されています。上にスクロールして戻ると、すぐに分かるのは特に目立つものがないということです - 正常に機能しているだけです。少なくとも、情報を1か所に集めることができます。というのも、ここには確認したい他の情報もあるからです。コスト情報もありますが、この特定のシナリオではコストについて誰も尋ねていません。後で調査したい可能性のあるセキュリティの問題もあります。誰も尋ねてはいませんが、後で確認すべき重要度の高い項目がいくつかあるようです。
下にスクロールしてみると、このケースではアラームが出ていないことに気づきましたので、CloudWatchにアクセスしてみることにしました。ここから直接CloudWatchの情報に進んで、関連するEC2の状況を確認できます。全体的にはあまり目立った動きは見られませんが、このアプリケーションのネットワーキングで大きなスパイクが発生しているのが分かります。ネットワーク側を見てみると、これが最初の手がかりになりそうです。エラーが多発しているという訴えではなく、動作が遅いという訴えなので、ここに何か原因があるかもしれません。
これをより詳しく調べるために、最近アップグレードしたAmazon ECS向けのContainer Insightsを見てみましょう。これが新しくなったContainer Insightsのルック＆フィールです。六角形の要素を使用した新しいデザインになっています。この環境では1つのクラスターしかありませんが、複数のクラスターがある場合は、たくさんの六角形が表示され、確認したいクラスターをクリックして切り替えることができます。これによって、そのレベルで詳しく調査することができます。
Container Insightsの強化されたトップページには、いくつかの主要なメトリクスが表示されています。CPUの使用状況を見ると、特に異常はなく、むしろ全体的にかなり低い状態です。下の方には、より詳細なCPUメトリクスやメモリ情報があり、これらも特に問題なさそうです。重要なのは、すぐに調査できる環境が整っているということです。それでは、関連するパフォーマンスメトリクスをもう少し掘り下げてみましょう。ECSワークロードについて、クラスター単位で情報を分割したり、必要に応じてインスタンスレベル、タスクレベル、あるいはサービス単位で確認したりすることができます。状況を把握するために、さまざまな角度からデータを分析できるわけです。
下の方を見ると、このケースでもレイテンシーが目立っていることがすぐに分かります。アプリケーションのレイテンシーに問題がありそうな気がしてきました。アプリケーションのどのコンポーネントに問題があるのかまではまだ分かりませんが、何かが起きているのは確かです。これらのツールを使って、さらに詳しく調べてみましょう。気になるので他のメトリクスもいくつか確認してみましたが、どれも特に変わった様子はありません。下の方で、アプリケーションを構成する各サービス（青いリンクで表示されているもの）ごとに見てみても、決定的な問題として浮かび上がってくるものは見当たりません。
レイテンシーの問題以外に目立った問題は見当たりません。同じインターフェース内に統合されているApplication Signalsをクリックして確認すると、画面上の最初の赤い表示がまだ見えています。SLIステータスを示すこの赤いテキストは、設定された閾値を持つService Level Indicatorがあり、その閾値を超えるとアラームが発生することを示しています。これは、レスポンスがもっと速くなければならず、システムは現在とは異なる動作をするべきだということを教えてくれています。
何か調査する価値のあることがあると判断したので、Application Signals を確認することにしました。すると、このアプリケーションでは通常見られないような異常な遅延のスパイクにすぐに気付きました。この遅延スパイクを詳しく調べてみると、 カートストアに関連していることがわかりました。ここで強調しておきたいのは、コンポーネントを特定できたということです。最初はアプリケーション全体を調べていましたが、今では問題の原因を特定するために、 アプリケーションの特定のコンポーネントに絞り込むことができました。
また、 どのアクションが問題に関連しているのかも確認できました。これはGETアクションの実行中に発生していました。遅延チャートをクリックして、 すぐにトレースを調査できるようにしました。トレースを表示すると、その時点で何が起きているのかを確認することができます。 データを見ると、Webアプリケーションの小さなコンポーネントで800ミリ秒もの遅延が発生しているのは明らかに許容できません。アプリケーション全体から問題を引き起こしている特定のコンポーネントまで追跡することができました。遅延の問題はこのCartsコントローラーにあると思われるので、開発者に戻って、問題の報告を受けていてユーザーが問題を経験していることを説明し、何が問題だったのかを調査すべき場所を絞り込むことができました。
シナリオ2：重大なエラーの迅速な診断と対応
これが最初のシナリオ でした。アプリケーションからの明確なエラーではなく、応答が遅いというパフォーマンスの問題を調査する必要がありました。次のシナリオでは、重大なエラーが発生しています。 これは以前には発生していなかった新しい問題です。アプリケーションは順調に動作していたのですが、突然電話が鳴り始めました。こういうことは大抵午前3時くらいに起こるものですよね。 何が起きているのかを確認する際、いくつかのアプローチを取ることができます。今回は、Log Insightsを使って解決策を見つけてみようと思います。この特定の問題に対しては、それが興味深い出発点になると考えています。もちろん、時間の経過とともに追跡する必要があるパターンが見られる場合は、異常を調べることもできます。
エラーメッセージを、解決につながる可能性のある何かと関連付けたいと思います 。目標は、何が起きているかを特定するだけでなく、問題の解決方法についても提案できることです。この設定でそれができるか見てみましょう。 この場合、既に画面を表示しています。 どのアプリケーションを扱っているかわかっているので、Application Signalsを直接確認しています。おそらくアプリケーションのWatch Storeから始めましたが、もう既にそこにいます。設定したSLOを通じてシステムが警告している2つのエラーがすぐに見えます。何が起きているかを素早く特定するためにメトリクスを見ると、 Faultの増加以外には特に重要なものは見当たりません。そこで、そこに焦点を当てて調査を進めることにします。
そこをクリックすると、上部にGolden Metricsが表示されます。この場合、FaultsとErrorsのメトリクスが最も状況を把握するのに役立っています。クリックしてトレースを確認すると、すべてが関連付けられていることがわかります。 これらのシステムは相互に作用して、何が起きているかについての洞察を提供できます。そして、Checkoutサービスに問題が発生していることがわかります。そのサービスのログを調査するために、CloudWatch Log Insightsを使用することにします。
CloudWatch Log Insightsを使用すると、そのサービスのログを調査し、詳しく分析することができます。Log Insightsにアクセスすると、アプリケーション全体にわたる多くの情報を提供する一般的なクエリが表示されます。私はすでにCheckoutサービス周辺に問題があると特定しているので、その範囲に絞り込みたいと思います。Checkoutログは小売タスクの中にあることがわかっているので、クエリをその部分に限定します。そこでCartを検索すれば、必要な情報が表示されるはずです。
検索を実行すると、興味深い点が見えてきます。実際のエラーが表示され、このエラーを見つける方法は複数ありました。Application Signalsに戻れば、例外を確認することでエラーを見つけることもできました。このページでより興味深いのは、エラーが発生したタイミングが分かることです。青いバーがこのイベントの数時間前から表示され始めています。エラーの内容も正確に分かります - このイベントが発生する前には存在しなかったリストの不一致が発生しているのです。
これを特定したら、数時間前にこのサービスで何か起きていないか、また何か変更の痕跡がないかを確認したいと思います。クラスター自体とその出力に変更を加えているので、クラスターを確認してみましょう。デプロイメントページがあり、このデプロイメントページは私たちが追加した機能の1つです。これにより、このサービスで最近行われた活動を把握することができます。もしこれが新しいサービスをデプロイして完全に機能しなかった場合、ECSはヘルスチェックが失敗した時点で自動的にロールバックしていたはずです。このサービスは部分的には機能していますが、特定のAPIを呼び出したときに問題が発生するという、サービス内の特定の機能が苦戦している状況です。
ここから、今日数時間前に新しいデプロイメントが行われたことがわかります。デプロイメントが数時間前に行われ、同時期にエラーが発生し始めたことから、チームに前のバージョンへのロールバックと調査の必要性を伝えることは簡単です。新しいエラーが発生しているので、Cartサービスのリスト機能についてさらなるテストが必要です。このように、何が起きているのかを絞り込み、これらの境界を越えて、実際に修正可能な相関関係を見つけることができます。
シナリオ3：断続的な問題の追跡とトラブルシューティング
シナリオ3を見てみましょう。次のケースは、時としてより厄介になることがあります。サービスが一貫して故障する前のシナリオとは異なり、これはサービスが一貫して失敗しているわけではない状況です。アプリケーションの健全性は全体的に良好で、ヘルスチェックは常に合格しています。しかし、特定の入力で特定のパスをたどると、破綻してしまいます。これは、特に制御できない外部APIを呼び出す際によく遭遇する問題でもあります。これらのサービスでトレースすることができ、ここでの目標は検出時間を短縮し、できれば復旧時間も短縮することです。
この状況を詳しく見ていきましょう。 今回は、Watch Storeに戻ってきましたが、前回よりも少ない情報で確認していきます。これを使って状況を把握したいと思います。周りを見渡すと、 コンピュートの状態は健全で、特に気になる点はありません。多少のスパイクはありますが、極端に大きなものではありません。 コストと重要度の問題については、特にこの動画が公開された後に対処する予定です。ただし、新しい要素として、アプリケーションの一部として監視されているCanaryがあり、アラームを発生させています。このアラームは、まだ説明していない別の機能から来ています。このアプリケーションで新しい問題を追跡するために実行しているものの1つが、これらのSyntheticsです。このCanaryは単純なヘルスチェックやAPIコールだけではありません。
これは実際にシステム内のワークフローを実行するものです。このワークフローのテストには小売店のデモを使用しています。先ほどアプリケーションを最初に紹介した時に、カタログをクリックし、カートに商品を追加して、チェックアウトプロセスを開始した、あの一連の流れ全体をチェックアウトまで実行します。これは、このサービスのレコーダーをオンにして、アプリケーションをクリックしながら操作を記録し、それをCanaryに追加することで実現しています。スクリーンショットや情報も提供してくれます。
特に便利なのは、より複雑なエラーが発生した時に教えてくれることです。たくさんの赤い点が表示されていますが、直近1時間に絞って見てみると、すべてが赤い点というわけではありません。私としては、すべて赤（障害発生）かすべて青（正常動作）のどちらかが望ましいです。毎回同じ入力を使用しているにもかかわらず、時々動作して時々動作しないという結果が出る場合、それは非常に扱いにくい状況です。追跡も困難です。これらのCanaryは、問題が入力に起因するのか、それともサービス自体が時々問題を起こしているのかを理解するのに役立ちます。今回の場合、入力が一貫しているため、後者を疑う方が妥当でしょう。
明らかに問題が発生していることは分かりますが、このワークフローはアプリケーション全体で機能しています。どのコンポーネントが大きな問題を抱えているのかはまだ分かりませんが、アプリケーションのどこかで障害が発生していることは分かっています。Application Signalsに戻ってみましょう。これらの点をつなぎ合わせるのに適した方法だからです。すぐに分かるのは、このサービスにService Health Indicatorが表示されていることです。期待されるレスポンスを満たしておらず、契約に違反しています。より良いパフォーマンスを期待していたのです。これを見ると、通信している一部のサービスが一貫して問題を抱えており、どの程度の割合で問題が発生しているかも確認できます。Checkoutサービスに問題があり、Retail Store UIにも問題が表示されていますが、その割合はずっと低くなっています。おそらく、UIとの対話時に最終的にCheckoutストアと通信するためでしょう。
この時点で、Checkoutサービスが怪しいと考え、メトリクスを確認して何を示しているのか理解しようとしています。レイテンシーにはあまり問題は見られません。多少はありますが、大きな問題とは思えません。グラフには興味深いパターンが見られます。左側のグラフは上部で何かが起きていることを示しています。リトライなどが発生している可能性があります。しかし、本当に注目すべきは、他よりも多くのエラーを示しているグラフです。先ほど強調表示していたオレンジの線は、より高い障害率と問題を示しています。そして最後のグラフでは、明らかにより多くの障害が見られます。オレンジの線が他のラインから大きく上方に離れています。本来そうなるべきではなく、他のラインと同じような水準で推移するはずです。
Checkout Serviceが主な問題の原因だということがよく分かってきました。Faultsの部分を見て、それをクリックすると、何が起きているのか詳しく調べることができます。GETフローに問題があることが分かります。Checkout Service全般というわけではなく、ここを見ると、POSTやヘルスチェックのレスポンスは良好です。これらにはSLIは設定していませんが、エラーは報告されていません。エラーが出ているのはCheckout Serviceです。
そこで、Tracesを確認して何が起きているのか見てみましょう。先ほどの例では、別のセクションに移動して状況を確認しました。ここでは、Checkoutの全体的なフローを見てみます。一見問題なさそうですが、このフローには実際にエラーがあります。このエラーをクリックすると、何が起きているのか把握でき、問題の解決に役立つかもしれません。ここには様々な情報が埋め込まれています。概要情報や使用しているリソースなどがありますが、今回はExceptionsを確認して、例外が発生しているかどうかを見てみましょう。
例外は発生しているでしょうか？はい、発生しています。この例外には名前を付けました。実際の例外ではありませんが、この状況でランダムなFaultを示すものとして非常に目立っています。これを追跡して、関連するコードを確認することができます。これは私のGetCheckoutプロセスの一部で、アプリケーション内のコードの一部です。実際に投げられているエラーを確認でき、この問題を解決し、修正方法を見つけるための良いコンテキストが得られます。
これらのシナリオから理解していただきたいのは、Enhanced Container Insightsと Application Signalsの連携についてです。Container Insightsを使用すると、多くのメトリクスを深く掘り下げて理解することができ、それらをApplication Signalsと連携させることで、アプリケーション中心の視点から問題が発生しているかどうかを確認できます。また、ログに必要な情報がある場合は、さらに深く掘り下げることもできます。ここでLucyにバトンタッチしたいと思います。
ECSのコスト管理とObservabilityの次のステップ
ありがとうございます。Stevenは、これらの機能を活用して問題のトラブルシューティングや解決を行う方法について説明しました。では次に、あまり明白ではないかもしれない点について掘り下げてみましょう。それはコストです。先ほど申し上げたように、これらのコストは、アプリケーションの予算配分や、プロジェクトリーダーや管理チームなど、その情報を必要とする人々にとって重要です。また、特定のアプリケーションやワークロードで予算を超過した場合に、すぐに通知を受けられるようにアラートや通知を設定することもできます。
コストの確認方法について詳しく見ていきましょう。まずは基本的な初期設定から始めます。多くのお客様がコスト管理をどこで行えばよいのかわからないというのが現状です。Cost Preferencesまで下にスクロールすると、 ECS Split Cost Allocationというオプションがあります。この基本設定について知っておいていただきたいのですが、この機能や設定を正しく設定する必要があります。
その理由は、この設定を有効にすることでデータをエクスポートできるようになるからです。同じBilling and Cost Managementコンソールに移動し、Data Explorerを開きます。ここでSplit Data Costが有効になっているのが確認でき、その情報を取得することができます。これは、これからデモでお見せする内容の基礎となる設定です。この設定が必要な理由は、データを取得し、実際に必要な情報についてより高度なクエリを実行するために、このデータを活用できるようにするためです。ここでは、そのSplit Costデータを使用してクエリを実行しています。ここにいくつかの事前に作成されたクエリがあります。
このクエリを閉じて、新しく事前に作成したクエリを実行して、どのように表示されるか見てみましょう。これは ECSで確認したい項目に応じて高度にカスタマイズ可能です。これらは、Line ItemsやUsage Typeなどを定義した事前作成されたクエリですが、ECSで特に確認したい項目について自由にクエリを作成できます。このクエリをすぐに実行してみましょう。今、実行したクエリのプレビューを生成しています。ここでは項目の一覧が表示され、 Item IDやクエリで定義したECSクラスター内のすべての項目、Usage Type、Product IDなどが表示されます。少しスクロールしてみましょう。
この形式で生成されたすべての情報を見ていただくために、もう少しスクロールします。ただし、これはリスト表示であり、プロジェクトリーダーやマネージャーが予算について質問してきた場合、このデータの提示方法は最も効果的とは言えないかもしれません。そこで、このリスト表示のデータを、Amazon QuickSightを活用してより見やすい形で表現することができます。
ここで一旦止めましょう。先ほど実行したリスト表示から、今度はAmazon QuickSightに移ります。そのデータセットに基づいて、ECSクラスターのコストを詳しく分析するための事前作成されたダッシュボードがいくつかあります。まずはECS Usage Typeを見てみましょう。これにより、ECSクラスター全体のUsage Typeとそのコストが表示されます。この大きな青いチャートで見てわかるように、 CPU Usage Typeが使用量の大部分を占めています。次のチャートを見ると、ECSクラスターのどの要素が最もコストを占めているのかが明確に理解できます。
それでは、ECSクラスターの内訳を見ていきましょう。 これは先ほどStevenがデモで紹介したWatch Storeのコストですが、ECS上で他のアプリケーションを実行している場合もあるでしょう。これを見ると、Watch Storeの構築コストと、ECS上の他のアプリケーションの構築コストを明確に比較することができます。右側を見ると、複数のリージョンでアプリケーションを構築しているチームのリージョン別の内訳が表示されています。各リージョンがECSにどれだけのコストを費やしているか、そしてそれが期待通りかどうかを確認できます。Eastチームが最もECSクラスターにコストをかけており、次いでWestチームとなっているので、このようにリージョン別の分析も可能です。
では、Stevenが先ほどデモを行ったWatch Storeに焦点を当てて、上部を見ていきましょう。 これはこの特定のアプリケーションの2層目の分析で、Watch StoreのCPUとGBという使用タイプごとのコストを示しています。これにより、今回デモで紹介したアプリケーションについて、より詳細な情報が得られます。そして最後に、Taskごとのコストも確認できます。このWatch Storeについて、ECSの各Taskがどれだけのコストがかかっているかが分かります。これにより、特定のアプリケーションやECSクラスター全体のプロジェクトコストについて、非常に明確な定義と理解が得られます。上司からアプリケーションのコストについて質問された際には、このような分かりやすい形でワークロードやアプリケーションに関連するコストを示すことができます。
これで、コンテナを最も整理された状態に戻すことができます。まとめると、Stevenは様々な顧客シナリオに基づいて、リアルタイムの問題、断続的な問題、APIの問題など、様々な機能について説明し、私はコストの側面をカバーしました。これにより、コンテナを最も整理された状態に保つためのツールが提供されます。数日後には再び問題のある状態に戻るかもしれませんが、少なくともその時には、どこを確認し、どのように修正すれば、この理想的な状態に素早く戻れるかが分かっているはずです。最後に、このプレゼンテーションから持ち帰っていただきたいリソースと次のステップをご紹介します。
まず、すべてのお客様が無料で利用できるOne Observability Workshopから始めることをお勧めします。AWSのアカウント担当者に連絡して、Stevenと私が説明したすべての機能をテストするためのワークショップをスケジュールすることができます。
次に、アラームの設定方法、メトリクスの取得方法、ログの確認方法を学べるベストプラクティスセッションがあります。CDKとTerraformユーザーの方々には、Observabilityをより早く始められるように、事前に構築されたCDKとTerraformのテンプレートも用意しています。これにより、Observabilityの導入をスピードアップすることができます。さらに詳しく学びたい方のために、Skill BuilderプラットフォームにはObservabilityに関する多くのeラーニングリソースが用意されています。
このセッションで新しい学びがあった方は、手を挙げていただけますでしょうか。素晴らしいですね。これがみなさまのECSの旅のお役に立てることを願っています。そして、ランチ後のこの時間にお集まりいただき、本当にありがとうございます。本日は名の方にご参加いただきました。最後に、ぜひアンケートにご回答いただき、私たちのセッションについてのフィードバックをお寄せください。
※ こちらの記事は Amazon Bedrock を利用することで全て自動で作成しています。
※ 生成AI記事によるインターネット汚染の懸念を踏まえ、本記事ではセッション動画を情報量をほぼ変化させずに文字と画像に変換することで、できるだけオリジナルコンテンツそのものの価値を維持しつつ、多言語でのAccessibilityやGooglabilityを高められればと考えています。
Discussion