re:Invent 2024: AWSが解説 Amazon EKSワークロードのObservability戦略
はじめに
海外の様々な講演を日本語記事に書き起こすことで、隠れた良質な情報をもっと身近なものに。そんなコンセプトで進める本企画で今回取り上げるプレゼンテーションはこちら！
📖 AWS re:Invent 2024 - Observability strategies for Amazon EKS workloads (KUB323)
この動画では、Amazon EKSにおけるObservabilityの戦略について解説しています。Logs、Metrics、Tracesという3つの柱を基に、CloudWatch AgentやContainer Insights、Application Signalsなどの具体的なツールを活用した監視手法を紹介しています。特にCloudWatch Agentは、複数のコンポーネントを1つのSidecarで統合し、OpenTelemetryとの互換性も保ちながら、ログ、メトリクス、トレースを効率的に収集できる点が強調されています。また、実際のデモを通じて、クラスターレベルからPodレベルまでの詳細な分析方法や、メトリクス、ログ、トレース間のスムーズな連携による問題解決アプローチが示されています。
※ 動画から自動生成した記事になります。誤字脱字や誤った内容が記載される可能性がありますので、正確な情報は動画本編をご覧ください。
※ 画像をクリックすると、動画中の該当シーンに遷移します。
re:Invent 2024関連の書き起こし記事については、こちらのSpreadsheet に情報をまとめています。合わせてご確認ください！
本編
Amazon EKSにおけるObservabilityの基礎と戦略
Amazon EKSにおけるObservabilityの戦略についてお話しします。まず、Observabilityの基礎的な情報について広く説明し、その後、EKSからインサイトを得る方法や、クラスターを基本的なレベルで理解するためのアプローチに焦点を当てていきます。 まず、なぜObservabilityが必要なのかというところから始めましょう。ここでのポイントは何でしょうか？私たちは問題を検知し、調査する必要があります。クラスターやその他の問題が発生した際に、どのように修復できるかを把握する必要があります。また、クラスターについてより深いインサイトを得て、パフォーマンスをどのように改善できるか、時間とともにどのようにソリューションを改善できるか、あるいは現時点で発生している問題をどのように修正できるかを理解する必要があります。
このアプローチは3つの基本的な柱に基づいています：Logs（ログ）、Metrics（メトリクス）、そしてTraces（トレース）です。これらはそれぞれが情報を得るための基礎となる要素です。そこで問題となるのは、この情報をどのように取得し、何のために使用し、チームやシステムに関わる人々が本当に活用できる形で、どのようにアクセスするかということです。
この情報を収集し、それをどのように活用するかを考える際には、いくつかの障壁があります。まず、オンボーディングが最初の障壁となります。情報を収集する際、どのようなアプローチを取るかを決める必要があります。OpenTelemetryアプローチなのか、使用しているクラウドベンダー固有のものなのか、どのようにしてソリューションに取り込むのか。複数のアプローチがあるため、チームにとって最適なものを決める必要があります。メトリクス収集に関しては、すべてを収集することはできますが、本当にすべてが必要でしょうか？おそらくそうではありません。クラスターの用途を見て、最も価値のあるメトリクスを選択するか、業界のガイダンスに従った定評のあるアプローチを採用すべきです。
そして、その影響を分析し、意味を理解する必要があります。メトリクス、ログ、トレースが情報を提供している場合、それらをどのように関連付けるのでしょうか？そのデータをどのように価値のある情報に変換するのでしょうか？エラーが重要なのか、実際に問題を引き起こしているのかを判断する必要があります。問題が発生しても適切に回復しているのでしょうか？これらの理解が必要です。また、適切な定評のあるアプローチについても考慮する必要があります。他者の視点を採用できるのか、それとも自社独自のアプローチが必要なのか。これには通常、思考と努力が必要です。決定を下した後、時間とともに変更することはできるのでしょうか？評価と調整は可能でしょうか？多くのソリューションでは、それが可能です - 一つのソリューションから始めて、別のアプローチに移行することができます。
最後にコストの問題があります - Observabilityは素晴らしいものですが、アプリケーション自体よりもコストがかかってはいけません。インサイトを得るために支払うコストと、得られる価値のバランスを取る必要があります。 AWSでは、いくつかのオプションを提供しています。これは私たちのツールセットの概要です。3つの全体的なアプローチを指摘したいと思います。1つ目は、PrometheusやGrafanaタイプのサービスを含むマネージドオープンソースアプローチです。これらは複数の場所で活用できるオープンソースソリューションです。2つ目のオプションは、Amazon OpenSearch Serviceで、すべてのログ、メトリクス、トレースをこのサービスに送信してインサイトを得ることができます。最後のアプローチは、CloudWatchとそれに組み込まれたContainer InsightsやLogsなどのツールを中心とした、クラウドネイティブサービスです。
CloudWatch AgentとContainer Insightsによる効率的な監視
15分の講演なので、Cloud Nativeのアプローチに焦点を当てたいと思います。とはいえ、これらのアプローチやソリューションにはそれぞれ適切なユースケースがあります。より詳しい議論をご希望の方は、後ほどお声がけください。さて、最初に挙げた問題の1つ、メトリクスの収集について - OpenTelemetryを使うか、あるいは他のさまざまなアプローチを使うかという点ですが - CloudWatch Agentで大きな改善を実現しました。
CloudWatch Agentを使えば、複数の個別デプロイメントではなく、より少ないコンポーネントでデプロイできるようになりました。これを使用することで、デプロイが必要なものが少なくなります。X-Ray Daemon、Collector、あるいは何らかのトレーシングDaemon、テレメトリーCollectorを個別に用意する代わりに、CloudWatch Agentですべてを処理できます。1つのSidecarを実行するだけで、ログ、メトリクス、トレースのすべてを処理できるようになります。これは大きな進歩です。また、後方互換性があり、OpenTelemetryとも連携できるのが重要なポイントです。コードがOpenTelemetryメトリクスを出力している場合、それをCloudWatch Agentで収集できます。考えを変えてよりオープンソースな方法に切り替えたい場合でも、それは可能です。つまり、特定の方法に縛られることなく、メトリクス、トレース、そしてログを迅速に収集できる強力なツールなのです。
これらについて少し詳しく見ていきましょう。CloudWatch Logsには多くのツールがあります。異常検知や情報を取得するための様々な方法がありますが、今日はInsightsについて特に取り上げたいと思います。これは、ログを持っていて - 後ほどデモをお見せしますが - これらのログのパターンや動向を理解したい場合に最適なツールです。フィルタリングや検索ができるのか？システムで時間とともに繰り返されるパターンを深く分析して、問題の根本原因を特定できるのか？CloudWatch Insightsはまさにそのための機能を提供し、私たちのサービスと深く統合されています。私が特に強力だと感じるのは、ログだけでなく、デモでお見せするように、ログがいつ発生したかを視覚的にスパイクやディップとして確認できる点です。
次に紹介したいサービスは、Container Insightsです。ここではECSに焦点を当てていますが、EKSで長年重要な機能として提供されてきた拡張Container Insightsを、今ではECSでも提供しています。ここで皆さんに理解していただきたい興味深いポイントは、さまざまな角度から分析できることです。クラスター全体の観察から始めて、最も問題を引き起こしているサービスを特定できます。そこから、そのサービスに関連するどのPodを詳しく調査する必要があるのか、またそれに関連するアラームやメッセージがあるかどうかを確認できます。
このツールは、後ほど少しお見せしますが、異なるレベルでの問題解決に重要な役割を果たします。私はContainer Insightsが気に入っています。これはコンポーネントレベルでの把握 - 問題のあるPod、特定のNodeの問題など - を適切に行えますが、Application Signalsではまた異なる視点から見ることができます。より視点を変えて、アプリケーションのどの部分に問題があるのかを見ることができます。そして、それをPetサービスまで追跡できます。私にはPetのウェブサイトがありますが、Petサービス全体ではなく、Petサービス上のGETコール、例えばGET list petsのような特定の操作に問題があることを特定できます。これはよりアプリケーション指向のアプローチですが、それらの点を結びつけ、メトリクスに対して独自のアプローチを提供しています。
実践的なデモ：クラスター分析からApplication Signalsまで
簡単なデモをお見せしましょう。 ここに入って、ご覧ください。再生が始まるはずです。 すぐに、複数のクラスターが表示されています。このハニカムのような表示が見えますね。赤いクラスターが最も注目すべきものです。これは、アラートやアラームが発生していることを示しています。緑のクラスターは健全な状態で、マウスオーバーすると何が起きているのかがわかります。現在はアラームの表示だけをしています。薄い青のクラスターはあまり使用されていません。クラスターをクリックすると一般的な情報が表示されます。 クラスターのアラームがどこから発生しているのかを確認できます。クラスターで発生しているのか、ノードで発生しているのか、アラームの発生源を確認できます。緑のクラスターは問題なく動作していることがわかります。
濃い青のクラスターに関して、問題があるわけではありません。メモリを多く使用しているため、注意が必要だということです。メモリの割り当てが少なすぎる可能性があるためです。これは視覚的な手がかりとして便利で、注意を払う必要がある何かがあることを示しています。重点的に対処が必要になる可能性のある問題かもしれません。 メモリの状況を理解することができ、このような高レベルの情報を提供してくれます。これらは基本的に使用率の低いクラスターで、効率性とコストの観点から確認が必要かもしれません。
左上にはパフォーマンスメトリクスとクラスターのControl Planeメトリクスが表示されます。Control Planeで何が起きているのかを確認でき、概要を把握できるのが興味深いところです。下にスクロールすると、このクラスターではCPUのみですが、GPUがある場合はGPUとGPUメモリも同様に確認できます。ここでこれらの情報を収集し、どのサービスやマシンが最も多くのリソースを使用しているかを把握できます。このレベルではクラスターレベルで見ているので、コンピュータに関連する実際のマシンにより焦点が当てられています。
この高レベルの概要を把握したら、具体的な部分を掘り下げたいかもしれません。このクラスターの状況を把握したので、次のレベルに進みたい場合は、さらに詳しく調べることができます。ここでは、どれがパフォーマンスが良いのかを確認しています。下部にもう1つの概要ページがあり、これが気に入っています。個々のクラスターのスナップショットと、メモリとCPUの観点からそのプロファイルがどのようになっているかを示してくれるからです。エラーのあるものを見てみましょう。
ロードしたものについて、データが読み込まれます。クラスターレベルでこの情報を確認できます。 クラスターの一番上で、実際にトリガーされたアラームを表示し、より深い洞察を提供してくれます。アラームがあることはわかっていましたが、ここで具体的にどのアラームがトリガーされたのかを示しています。その後、 ネットワークトラフィック、異なるPodで受信されたバイト、ノードのパフォーマンスに関するより詳細なメトリクスまで、他の多くのメトリクスが表示されます。かなりの量の情報が含まれています。
現在、Clusterレベルで見ていますが、より深く掘り下げていくことで、より具体的な部分まで見ていき、確認したいComponentにまで到達することができます。Alarmをクリックすると、問題が発生している可能性のあるContainerを詳しく見ることができます。 Containerの使用状況がかなりスパイク状になっていることが分かります。これを調査して、どのような問題が発生しているのか、何が起きているのかを確認することができます。正直なところ、ほとんどは大きな問題ではなさそうです。もう少し詳しい情報を得るために、Workloadレベルで確認してみましょう。
これらの各レベルで同じような指標が得られるのが気に入っています。システム全体で一貫性のある情報が得られ、それは私たちがこのシステムで実現したことの一つです。ある程度標準化された指標を追求するという方針で進めてきました。ここではWorkloadを確認しましたが、別の視点から見る必要があるかもしれません。Application Signalsを見てみましょう。 個々のComponentを見るのではなく、アプリケーションの視点からどのように動作しているかを確認してみましょう。ここで、Vet Serviceに関して不健全な状態があることを示す新たな手がかりが見つかりました。
現在、Vet Serviceについて、画面上部に表示されているこれらの指標は、すべてGET Vetsメソッドに関連するものです。Accrual情報の取得に関して何が起きているか知りたい場合は、下の方に他のいくつかの指標があります。ここでも同じようなGolden Metricsを確認することができます。これらには、VolumeとAvailability、Latency、そしてError Rateが含まれています。これにより、各Serviceで同じような種類のデータを確認することができます。ここでAvailabilityが100%であることや、オレンジ色の線で示されているVolumeが上下していることから、Serviceの利用状況が分かります。一部でLatencyがスパイクしており、これらのデータポイントをクリックすると、そのServiceに関連する情報を確認することができます。
これらのポイントの1つをクリックすると、関連するTraceを含む追加情報を表示する新しいウィンドウが開きます。つまり、指標の高レベルな表示 と、どの特定のメソッドが呼び出されているかを確認した後、Traceを見ることができます。Traceの1つをクリックすると、Serviceの詳細が表示されます。マップには問題が発生している可能性のある場所の情報が表示され、その観点から掘り下げることができます。これらが現在発生している問題の一部である可能性があるかどうかを確認できます。下にスクロールしてみましょう。そうすると、パスとその状況を確認することができます。明らかに、 障害が発生しており、いくつかの障害が起きているので、それらを迅速に調査して問題がどこにあるのかを確認する必要があります。
その障害を追跡して、 どこで何が起きているのかを特定することができます。また、このServiceに関連するLogについても気になります。500エラーが原因である可能性が高いことが分かったので、障害についてはクリックしないでおきましょう。代わりに、Vet Serviceのログを確認して、何が起きているのか見てみましょう。
まず、Vetサービスにアクセスして、実行させる必要があります。ここでPodレベルでもう一度最後の確認をして、何が起きているのか把握しようとしています。そして、先ほど確認したPodが確実に見えていて、Podの使用率が上限に達していることがわかります。これが問題の原因かもしれません。メモリの使用量がピークに達しているのです。では、この部分についてもう少し詳しく調べるために、ログを深く見ていきましょう。
Logs Insightsで情報を絞り込んで、異なる視点で確認する方法をお見せしたいと思います。まず、該当するサービスに関連するログだけをフィルタリングしてクエリを実行します。ここで特に強調したいのは、各ログを開いて詳しく調べることもできますが、上部の視覚的なチャートが非常に役立つということです。通常はゼロに近い値が続いているのに、突然400という値が出た場合、そのログは注目に値する可能性が高いでしょう。このように、視覚的な情報からも重要な洞察が得られます。
デモの最後に強調したいポイントがこれです。メトリクス、ログ、トレースを非常にスムーズに連携させて操作できるということです。「このメトリクスを見ていたけど、今度はログを見るために別のウィンドウを開かないと」というような手間なしに、調査中に全ての情報を行き来することができます。これは自然な流れで、戦略的な洞察を得るための優れた方法だと思います。
CloudWatch Agentを使用することで、オンボーディングがずっと速くなります。システムへの導入という最初のハードルを越えやすくなるのです。これらのダッシュボードから必要となる可能性のあるメトリクスの一式と、その考え方が得られます。変更を加えたり、追加したり、修正したりして、独自のダッシュボードやアプローチを作ることもできますが、ゼロからスタートする必要はありません。多くのお客様から「これは問題解決の良い方法だ」と言っていただいている、エキスパートからの推奨アプローチが用意されているのです。
Application Signalsは、メトリクス、ログ、トレースのエンドツーエンドの統合を素晴らしく実現しています。私たちは明確な見解を持ってこれを提供しています。お客様が最初からすべてを知っている必要はありません。直接スタートしてコストを増やしていけます。コストと料金について - ここでは触れませんでしたが、Split Data Costsという機能があります。これは昨年あたりにリリースした新しい機能で、ECSからメトリクスを収集し、タスク、サービス、Pod、ノードごとにコストを確認できるようにするものです。これも非常に興味深いアプローチです。以上です。ご清聴ありがとうございました。アンケートへのご協力をお願いいたします。
※ こちらの記事は Amazon Bedrock を利用することで全て自動で作成しています。
※ 生成AI記事によるインターネット汚染の懸念を踏まえ、本記事ではセッション動画を情報量をほぼ変化させずに文字と画像に変換することで、できるだけオリジナルコンテンツそのものの価値を維持しつつ、多言語でのAccessibilityやGooglabilityを高められればと考えています。
Discussion