re:Invent 2024: CloudWatchでログ分析を効率化 - コスト削減と洞察の両立
はじめに
海外の様々な講演を日本語記事に書き起こすことで、隠れた良質な情報をもっと身近なものに。そんなコンセプトで進める本企画で今回取り上げるプレゼンテーションはこちら！
📖 AWS re:Invent 2024 - Byte to insight: Maximize value from your logs with Amazon CloudWatch (COP406)
この動画では、Amazon CloudWatchを使用してログから最大限の価値を引き出す方法について解説しています。CloudWatchの進化の歴史と共に、Metric Filters、Embedded Metric Format、Contributor Insightsなどの機能を活用した効率的なログ分析手法を紹介しています。特に注目すべきは、5分ごとのクエリ実行で月額500ドルかかるダッシュボードを、メトリクスを活用することで月額2.30ドルまで削減できる具体例です。また、Enhanced log group selection、Field indexes、Pattern分析などの新機能により、複数アカウントにまたがる大規模なログ検索や異常検知が効率的に行えるようになった点も詳しく解説しています。ログからの価値の最大化という観点で、コスト削減とインサイト獲得のバランスを取る実践的なアプローチを示しています。
※ 動画から自動生成した記事になります。誤字脱字や誤った内容が記載される可能性がありますので、正確な情報は動画本編をご覧ください。
※ 画像をクリックすると、動画中の該当シーンに遷移します。
re:Invent 2024関連の書き起こし記事については、こちらのSpreadsheet に情報をまとめています。合わせてご確認ください！
本編
CloudWatchの進化：包括的なObservabilityソリューションへ
本日の朝のセッションにご参加いただき、ありがとうございます。「Byte to insight: Amazon CloudWatchを使用してログから最大限の価値を引き出す方法」というセッションを始めさせていただきます。私はAndres Silvaと申しまして、Observabilityを専門とするPrincipal Specialist Solutions Architectを務めております。Nikhil、自己紹介をお願いできますか？皆様、ご参加ありがとうございます。私はNikhil Kapoorと申しまして、Amazon CloudWatchのPrincipal Product Managerを務めております。
本日は、CloudWatchで最近リリースした新機能と、これまでご提供してきた機能についてご紹介させていただき、それらを最大限活用してログから価値を引き出す方法についてご説明いたします。その過程で、皆様の実際のワークロード、サービス、アプリケーションで応用できる具体的な手法をお伝えしたいと思います。このセッションでは「価値」という言葉を何度も耳にすることになりますが、これは私たちが特に強調したいポイントです。CloudWatchが目指しているのは、お客様がログからより良いインサイトと最大限の価値を得られるようにすることなのです。
「CloudWatchって、EC2インスタンスのメトリクスを送信するだけのものでしょう？」とよく聞かれます。今朝のDr. Wernerのキーノートをご覧になった方は、CloudWatchのスケール性や顧客の利用方法についてお聞きになったと思います。ご理解いただきたいのは、CloudWatchはこのボックスに示されているすべての機能を備えた、完全なAWSネイティブの包括的なObservabilityソリューションだということです。何かを管理したり、セットアップしたりする必要はありません。すべてのリージョンですぐに利用可能で、ログ、メトリクス、トレースといった基本的な機能から、今年リリースしたデジタルユーザーエクスペリエンスモニタリング、Application Signalsまで、すべてを網羅しています。これらの機能が組み合わさって、CloudWatchという総合的なソリューションを形成しているのです。
ログからの価値最大化：Insightの定義と重要性
では、CloudWatchがどのように進化してきたかについてお話ししましょう。CloudWatch Logsは2014年に初めて導入されました。それ以来長い時間が経ち、お客様からのご要望に耳を傾けながら、多くの機能を追加してきました。このスライドには主要なマイルストーンの一部のみを示していますが、導入以来、大きな進化を遂げてきました。
ここ2-3年を見ていただくと、CloudWatch内でのログの使用方法や価値の引き出し方に関して、非常に多くの変更と改善が加えられていることがお分かりいただけると思います。特に強調したいのは、2024年の「New」とラベル付けされている機能についてです。これは2024年に実装したすべての機能ではなく、スライドに収まる範囲でのご紹介です。また、これらの新機能は、年間を通してではなく、ここ3週間だけでリリースされたものです。本日のセッションではこれらの機能の一部をご紹介させていただきますが、すべてを網羅することはできません。また、最近発表されたAmazon Q Developerによる運用調査についてもお聞きになったかと思いますが、これもCloudWatchを基盤として動作しています。私たちはAWSのネイティブなObservabilityプラットフォームだからです。そこで、個々の機能について説明するのではなく、私たちのアプローチについてお話ししたいと思います...
Amazonが社内でどのようにログを収集し活用しているか、また何をログに記録すべきか、そしてそれらのログをどのように適切に使用するかについての考え方をご紹介します。このセッションの目的は、私たちの価値最大化に関する考え方を理解し、皆さんのサービスに活かしていただくことです。
価値とは何でしょうか？結局のところ、あらゆるテレメトリーデータやデータ全般において私たちが求めているのは、何らかのInsightです。それは、私にとって重要な質問に答えてくれるものでしょうか？その反対に、その質問に答えるためにどれだけのコストがかかるのでしょうか？これが私たちの価値の定義です。あるAnswerは非常に価値が高いためコストは二の次になりますが、一方で基本的な質問の場合は可能な限り少ないコストで対応する必要があり、そこで価値の最大化が重要になります。
Known-KnownとKnown-Unknown：ログ分析の2つのシナリオ
まず、Insightとは何かを定義しましょう。 先ほどInsightは質問に答えるものだと申し上げましたが、これこそが私たちが求めているものです。Insightの定義の一つをご紹介します：人やものについて、正確で深い直感的な理解を得る能力です。AndresとPrivateが本セッションの構成を考え、 ログに対する私たちの考え方を皆さんに伝えるにあたり、この定義を分解してみました。最初の部分、直感的な理解を得ることは、あなたが学ぼうとしていることに関するものです。 この定義の重要な部分は、学ぼうとしている文脈、つまり人やものについて学ぼうとしているということです。Observabilityの場合、特定の時点で発生したイベントや、アプリケーションのコンポーネントで起きたことについて学ぼうとしているのです。
皆さんの日常業務でよく見かけるであろう、ログやテレメトリーデータを通じて答えようとする質問をいくつか見てみましょう。 アプリケーションサーバーやWebアプリケーションなど、あらゆる種類のログで一般的に確認することの一つは、「App Aのブロックされたトランザクションの割合は？」というものです。この場合、文脈はApp Aであり、学ぼうとしているのはブロックされたトランザクションの割合です。
別の例を見てみましょう：「100ミリ秒以上かかっているトランザクションを持つTop 10のCustomerは誰か？」私たちはこのレイテンシーの増加による影響を受けている人を理解しようとしています。この場合、文脈は100ミリ秒以上のレイテンシーであり、学ぼうとしているのはその影響を受けているTop 10のCustomerが誰かということです。 これらのシナリオでは、私たちは何を学びたいのか、そしてどのような文脈で学びたいのかを、前もって知っていました。このような質問を、Known-Knownタイプのシナリオと呼びます。
反対の例を見てみましょう。 私が開発者だった頃、顧客から何かが起きたという苦情があり、ページング通知やサポートチケットを受け取ることがよくありました。その際に手元にあるのは、顧客IDやリクエストID、セッションIDと、過去24-48時間という時間枠だけでした。何を探せばいいのかわからない状況です。これは、顧客やリクエストIDというコンテキストは分かっているものの、そのリクエストIDを調べた時に何が分かるのか見当もつかないというシナリオです。
同様に、ある時点でこのLambdaに変更を加えて何かが変わった場合 - 何か違う、大きな変化があった場合 - 何かが壊れたのかどうかは分かりませんが、それが何なのかを突き止める必要があります。この場合も、最近このLambdaに変更を加えたというコンテキストは分かっていますが、何が変わったのかを調べようとしている状況です。
重要なのは、必ずしも「何が」が分からないわけではなく、時にはコンテキストが分からない場合もあるということです。例えば、チームの開発者の一人がインスタンスを終了させ、それが他の人に影響を与えたとします。この場合、インスタンス終了イベントが発生したことは分かっています - CloudWatchログでそれを確認できます。しかし、誰がいつ行ったのかを突き止めようとしているのです。つまり、インスタンス終了の呼び出しを探していることは分かっているものの、実行した人や時間というコンテキストが分からないのです。このような質問を「既知の未知」と呼びます - 求めている答えの一部（「何が」かコンテキスト）は分かっているものの、もう一方が分からない状況です。
CloudWatchの新機能：効率的なログ分析ツールの紹介
これを価値の最大化に結びつけてみましょう。 これを理解した上で、価値の部分をどう考えるべきかを説明するために、この組織構造に従っていきます。既知の既知と既知の未知を見てみましょう - この区分が重要なのは、既知の既知の場合、例えば5分間のブロックされたトランザクション数のように、すでに探しているものが分かっている場合、どんなに素晴らしいツールを使っても、どれだけお金をかけても、すでに知っていること以上のことは学べないからです。そのインターバルでブロックされたトランザクション数が分かるだけです。
この場合、私たちの目標は、そのインサイトを得るためのコストをできるだけ低く抑えることであり、それによって分母を下げることで価値を最大化することができます。逆に、既知の未知の場合は、不確実性があるため、コストを削減することよりも、より速く、より良く、より正確に、より簡単にインサイトを得ることに価値を見出すかもしれません。例えば、セッションIDを探さなければならないカスタマーサポートチケットの場合、1つのクエリで2分以内に解決できるなら、10ドル余分にかかっても喜んで支払うでしょう。これが、コスト削減を目指すべき場合と、インサイトの価値の最大化を目指すべき場合についての考え方のモデルです。
レイテンシーが100ミリ秒を超えるトップ10の顧客や、アクションブロックのあるリクエストなど、Known Knownのシナリオで回答できる質問について話しましょう。通常、このような問題に取り組む際にログがある場合、私たちは何をすぐに考えるでしょうか？それは、クエリを書いて、結果をダッシュボードに表示し、皆と共有することです。しかし、実際には、そのクエリを何百回、場合によっては何千回も実行することになってしまいます。もっと良い方法があります。
最初の質問に取り組んでみましょう。どのように対処すればよいでしょうか？ログの中でaction=blockを探し、指定した期間において5分間隔でそれが何回発生しているかを知りたいわけです。 これに対処するために、Metric Filtersを使用できます。Metric Filtersをご存知の方はどれくらいいらっしゃいますか？Metric Filtersは、すべてのデータを受け取るLog Groupがあり、そのログ内の特定の値を捕捉するフィルターを定義して、それに基づいてメトリクスを作成するものです。action=blockの問題について考えてみましょう。その条件が満たされるたびにデータポイントとメトリクス値を設定するフィルターを作成できます。これにより、その間隔を柔軟に管理でき、大量のデータを数えるクエリを実行する必要なく、環境内で常に監視することができます。
電球とドルマークに注目してください。多くのインサイトが得られ、欲しいインサイトを得るために多くの費用をかける必要がないメカニズムなのです。 Metric Filtersについて興味が湧いてきましたか？もっと効率的な方法はないでしょうか？なぜなら、今説明したことは既にお持ちのものだからです。
今説明したように、既存のLog Groupがあり、メトリクスを見つけてフィルターを定義する必要があります。ここでEmbedded Metric Formatについて話しましょう。次のスライドに進みましょう。Embedded Metric Formatとは何でしょうか？これはフィルターを次のレベルに引き上げるものです。なぜなら、 ログに値を入れるための形式で、CloudWatchが自動的にメトリクスを作成してくれるからです。フィルターを定義する必要はありません。完全にポータブルで、どのAWSアカウント、どのリージョンでも、コードは同じように動作し、望むメトリクスを生成します。Log Group上でフィルターを設定する必要は一切ありません。非常にパワフルで、コードをコントロールできる場合、これが最適な方法です。
Andresが言っていたことにもう一つ付け加えたいと思います。アプリケーションを作成したり、ログやテレメトリー全般を実装したりする際に、このプロセスの中でメトリクスを作成する設定全体を行っているわけです。そして同時に、そのメトリクスから次のレベルの分析に進む際に価値がある可能性のある追加情報を、同じログに入れているのです。これは、取り込み時に自動的にメトリクスを抽出するログメッセージです。Amazonでは、アプリケーションやサービスを実装する際、これが最優先事項です。まず、EMFでこの問題を解決できるかどうかを検討します。これが、AWSサービス全体で私たちが実装している方法です。非常に簡単になります。
次の質問である、レイテンシーが100ミリ秒を超える上位5社の顧客についてお話ししましょう。 これは少し異なる問題です。この場合に使用できるもの、そして私たちが議論すべきものは、Contributor Insightsです。Contributor Insightsをご存知の方は手を挙げてください。 Contributor Insightsでは、レイテンシーなど探したい項目を指定し、ユーザーIDやカスタマーID、アカウントIDなど、お好みの方法で顧客を参照するルールを作成できます。これにより、自動的にその情報が収集され、その値の上位が表示されます。高いレイテンシーの影響を受けている顧客は誰かといった質問に答えるために、これは非常に重要です。Contributor Insightsはこの問題に対処する優れた方法です。
これにアラームを設定できますか？もちろんできます。それがすばらしいところです。CloudWatch内で提供している他の機能をすべて活用できます。ダッシュボードに追加したり、アラームを設定したりできます。インサイトを活用できるようになり、ご覧のように電球のアイコンがそこにあります。 すべてをダッシュボードにまとめて可視化できます。大量のデータをスキャンする必要はありません。これが価値を最大限に引き出す方法です。Contributor Insightsのアラームを作成して、そのすべてを活用できます。そこにQRコードがありますので、スキャンしていただくと、自分でこれを実装する方法を示したブログをご覧いただけます。ご自身のペースで進められるように、ここではContributor Insightsを活用して価値を最大化する方法について、興味を持っていただくことを目的としています。
Zero-ETL統合とEnhanced log group selection：ログ分析の革新
ログから作成したこれらのダッシュボード、メトリクス、アラームですが、クエリを1つも書く必要がありませんでした。クエリは不要です。他のメトリクスと同じように、メトリクスを選択して、マッピングした後にダッシュボードに追加するだけです。とてもシンプルで分かりやすいですね。すぐに使える形でそれらのビューを取得できる方法はまだありますか？ 最近リリースされた新機能をご紹介できることを嬉しく思います。CloudWatch LogsとOpenSearch Service analyticsの間のZero-ETL統合です。Nikhilが言及したように、この機能を使用すると、OpenSearchの可視化を使用してキュレートされた一連のダッシュボードを利用できます。
データのETLやOpenSearchクラスターの起動など、何もする必要はありません。バックエンドですべてを処理します。さらに、この機能では、OpenSearch Piped Processing Language（PPL）とSQLという2つの追加のクエリ言語を提供しています。多くのお客様がこれに興奮しているのは、これらの言語が提供する分析機能を活用できる柔軟性が得られるからです。
良いニュースをお伝えしたいと思います。Nikhilは、ログがフィールドの追跡や分析に適した形式になっていない場合どうなるのかと気にしていました。ログ分析を強化するこの新機能を発表できることを嬉しく思います。これまでは50個だった検索可能なロググループの数が、今では10,000個まで拡大されました。この新機能では、プレフィックスを使用するか、すべてのログを横断して検索することができます。インデックスを作成することもでき、これについては後ほどNikhilが詳しく説明します。
数分後にデモをお見せしたい素晴らしい機能として、ログを変換して適切なフォーマットにし、先ほど説明したMetric Filtersやその他の機能からインサイトを抽出できるようにする方法があります。これは、他のすべての機能を活用するために利用できる変換と取り込みの機能です。 これがどのように機能するのか、もう少し詳しく説明しましょう。変換に関して、ログを取得し、JSONの場合はさらにデータを追加できます。JSONやGrok、その他いくつかのフォーマットをサポートしています。WAF、VPC、Apache、NGINXなど、変換用の事前構築されたテンプレートがあり、Grokを使用してカスタム変換も可能です。
ログの変換と様々なフォーマットからのデータ抽出に加えて、コンテキストを追加することもできます。リージョンをログのキーとして追加したり、Log Group名を追加したり、必要な情報を何でも追加できます。コードやInfrastructure as Codeで変換を作成する際に、環境やワークロード情報をパラメータ化して追加することができます。その後、後ほど説明するDiscovered FieldsやField Indexesを活用して分析を行うことができます。この情報をDashboard、アラーム、Subscription Filtersに活用できます。
先ほど説明したMetric Filter抽出やContributor Insightsなど、すべての優れた機能は、ログ内の情報が特定の方法で記録されていることを前提としています。これまでは、エージェントを更新するかクライアントサイドで変更を加える方法しかありませんでした。現在は、何も触れることなく、すべてをサービス上で実行できます。どのようなフォーマットのログでも取得して、これらのインサイトをすべて抽出できるように使用可能な形に変換できます。 デモが好きな方も多いと思うので、いくつかデモをお見せしましょう。
実践デモ：CloudWatchを使用したログ分析の効率化
まず最初にお見せしたいのは、サンプルログです。 Firefoxに戻って見てみましょう。これが私のサンプルJSONログの見た目です。これはすべてダミー情報で、実際のシステムではありません。User Statusのような興味深い情報があることがわかります。コードから生成してログに記録しているメトリクスもあります。これが簡単だからです - これを使用するか、EMFを使用することもできます。EMFの仕組みについてもすぐにお見せします。 このデータがある場合、ログに関する特定の質問に答えたいと思うことがあります。
Actionがblockに等しいリクエストの数は何件でしょうか？最初は、クエリを書こうと考えがちですが、既知のシナリオではそれが最も効率的な方法ではないことを既に説明したので、そうはしません。クエリを全く使用しないという意味ではありません - クエリは必要になります。それは、どれだけのコンテキストがあり、何を探しているかによります。しかし、Metric Filterを定義することができます。その仕組みを簡単にお見せしましょう。
Metric Filterの定義方法についてご説明します。まずLog Groupに移動し、Metric Filtersのタブを開きます。ここに私のFilterがいくつかあります - 3つありますね。1つはAction Block用、1つはLoad Time用、そしてもう1つはランダムなメトリクスを取得するものです。作成ボタンをクリックすると、このウィザードが表示されます。最初にFilter Patternを定義します。この例では、分かりやすいログがありますので、私が探したいパターン - つまり「$.action=block」を指定できます。
このパターンの良いところは、実際のログからデータを読み込んでテストできることです。Actionを探す必要がありますが、このログにはBlockが含まれていないかもしれません。今テストしても何も返ってこないと思いますが、ここで編集して、動作確認のために好きな値に変更できます。パターンをテストして満足したら、次のステップに進み、Filterに名前を付け、作成したいMetricの名前を指定します。基本的に、パターンに一致するたびにカウンターをインクリメントするように設定します。Dimensionを追加して、これで完了です。これでFilterの作成が終わりました。
より多くのデータがあるこちらの例をお見せしましょう。Filterを作成してMetricsに移動すると、Dimension Namespaceにこのディメンションが表示されます。これでMetricがマッピングされ、クエリを実行する必要はありません。何百万回もデータをスキャンする必要もありません。これをダッシュボードに移動したり、アラームを作成したりできます。このような柔軟性があり、不要なクエリを実行せずに価値を最大化できます。
次に、レイテンシーの高い上位10顧客についてお話ししましたが、Contributor Insightsについて簡単にご紹介します。Contributor Insightsの作成方法を手短にご説明しましょう。とても簡単です。基本的にルールを指定する必要があります。ウィザードを使うよりも構文を見せた方が分かりやすいですね。Load Timeを見て、キーとしてClient IPを指定します。この場合、Customer IDなどの方が理にかなっていますが、作成すると、データの収集が開始されます。ご覧のように、すでに上位10のコントリビューターのマップが表示されています。先ほど説明したように、これをダッシュボードに追加でき、運用判断やビジネス判断に役立つログデータの重要な洞察をすぐに確認できます。
では、EMFの動作について少しご紹介します。ここにPythonで書かれたLambda関数があります。とてもシンプルで、これ以上単純にはできないでしょう。基本的に、Embedded Metric Formatで指定された形式でMetricを定義しています。Namespaceなどすべての詳細を指定します。そして、私が気に入っているのがこの重要な行です - 単にStandard Outに出力するだけで、それがログに記録され、CloudWatchが残りの処理を行います。CloudWatchがそれを取得し、Metricを作成してくれます。これで完了です。
ここで、メトリクスで私が作成したものの1つをお見せできると思います。 新しい名前空間が作成されます。この場合、demo EMFと呼んでいて、これが私のメトリクスです。この特定のケースでは、 CloudTrailログに対して実行しました。CloudTrailログでは... いや、間違ったものを見ていますね。これは正しくありません。 新機能を見せましょうか。適切なセクションに移動しましょう。
カスタムLambdaメトリクス。 これは、そのLambda関数でプッシュしているEMFデータです。 次にお見せしたいのは、ブロック変換、特にログ変換についてです。 非常に似たような方法で、ロググループの変換タブに移動して、新しい変換ツールを作成します。 この変換ツールではGrokを使用しています。Grokは一般的なパーサーユーティリティです。使い方はとても簡単で、Grokを使用し、ログエントリに含まれるメッセージを入力として与えます。この場合、Apacheログ用のGrokの標準変換ツールを使用しています。Grokはすでにデータを抽出するために必要な様々なパース規則を構築しているので、その上に他のプロセッサーを追加することができます。
この場合、Copy Value変換を実行しており、リージョンをregionというフィールドに追加することでエンリッチメントを行っています。これによってログにその情報を含めることができます。 ちゃんと動作しているか確認するために、ログのサンプルをロードしてみましょう。これは基本的にロググループからログのサンプルを取得します。 変換ツールをテストすると、うまく機能していることがわかります。これが元のログの形式で、CLFフォーマット、つまり標準フォーマットです。変換後は、すべてのフィールドが定義され、整理された状態のJSONログになり、下の方には新しく追加したエンリッチメントフィールドのregionが表示されています。保存すると、すべてのデータの変換が開始され、これまで説明してきた他の機能も活用できるようになります。
最後にお見せしたいのは、Log Insightsの新機能、特にSQLに関する機能です。 ここにCloudTrailデータ用に作成したクエリがいくつかあります。 SQLの良いところは、多くのお客様が使い慣れているため非常に使いやすく、さらに活用できる強力な機能が多数あることです。これから実行するこのクエリは、CloudTrailログで呼び出されている上位のAPIを表示します。 前回実行したときは、このアカウントでサンプリングを行っていたため、X-Rayが一番上にありました。そして今回も、X-Rayがありますね。このデータを可視化し、ダッシュボードに追加して、 他にもさまざまなことができます。
最後に、OpenSearchダッシュボードの素晴らしさをお見せしましょう。 ダッシュボードを作成する際は、サポートされているログの中から必要なものを指定するだけです。CloudTrail、WAF、VPC Flow Logsをサポートしています。この例ではCloudTrailダッシュボードを使用していますが、これは事前に用意された優れたダッシュボードで、 CloudTrailログに関する重要な情報、例えばイベント数や時系列でのイベントなどを表示してくれます。 これは現在の環境で何が起きているかを検出するのに非常に強力なツールです。トラブルシューティングや運用上の問題に対処する際、このダッシュボードにアクセスして、何か変更があったか、環境に影響を与えているものがないかをすぐに確認できます。ここにはいくつかのセレクターがありますが、重要なのは、これらの機能によってクエリを増やすだけでなく、価値を最大限に引き出せるということです。
「このダッシュボードは最初からあったんですか？セットアップの必要はなかったんですか？」「はい、最初からあります。作成するだけで、事前に構築されています。何も指定する必要はありません。これはマルチアカウントのトレイルで、ご覧の通り、すべてのアカウントIDがあります - データを深く掘り下げることができます。」「完璧で、とても簡単ですね。」「その通りです。」
Known-Unknownシナリオの解決策：新機能の活用
では次に進みましょう。これまでは、先ほど説明した既知の既知の基準と、既知の既知の価値を最大化するために使用できる様々な機能についてでした。次は、既知の未知について話しましょう。既知の未知の場合、優先順位が少し異なります - より良いインサイトを得ることが重要で、コストは二次的な基準となります。
私たちが提起した2つの質問がありました：「ここで変更を加えましたが、何か新しいことが起きていますか？」そしてもう1つは、干し草の中の針のようなシナリオ：「このリクエストIDはどうなったのでしょうか？」これら2つの質問について、意味のある方法で解決する方法をご説明します。しかし、その前に、既知の未知のケースでは、これらのシナリオをより良く機能させるために事前に行えるハウスキーピングがあります。例えば、適切なロググループの命名規則と構造でログを整理できれば、検索が簡単になります。同様に、ログを整理したり計測したりする際は、可能な限り一貫性のある意味のある規則を持つようにしましょう。それができない場合は、Andreasがログ変換で示したように、それが助けになります。構造化されたログフォーマット（JSONやkey value = valueなど）の場合、他にもできることがたくさんありますが、ログに何らかの構造を持たせることが重要です。
では、ハウスキーピングの話は置いておいて、元の質問に戻りましょう。「変更を加えましたが、ログに何か新しいことがありますか？」という質問から始めました。CloudWatchには、あなたが何をしようとしているかに応じて、この質問に答えるための2つのツールがあります。Andreasのように、Lambdaで変更を加えて、その変更の結果を正確に確認したい場合 - 他の場所に行ったり行き来したりしたくない場合は、Live Tailがあります。これがLive Tailの見た目です。Live Tailは昨年発表されましたが、今年はストリーミングサポートを追加しました。つまり、コンソールにいなくても、どこにいてもLive Tailをその場所に直接ストリーミングできます。また、Lambdaのユースケースが非常に人気があり、お客様が変更を加えてログの状況を確認したいというニーズが高かったため、Lambdaコンソールにネイティブで組み込みました。
2つ目にできることは - これは変更を加えているときのリアルタイムのシナリオでしたが - Andreasがこの変更を加えて何かおかしなことが起きていて、何が起きているのかわからない場合はどうでしょうか？Andreasに変更を加えた時間を尋ねると、1時間前だと言います。何が違うのかを見つけるために様々なクエリを実行することもできますが、単純にログを見て、変更が行われる1時間前から現在までのログを表示し、何が違うのかを示してもらうこともできます。どのフィールドや何を探すべきかの入力は必要ありません。スクリーンショットを見ると、どのパターンが新しいのか、どのパターンが消えたのかを明確に示してくれています。手動でログを調べる代わりに、どこに時間を費やすべきかを絞り込むのに役立っています。
さらに一歩進んでみましょう。このパターン比較では、クエリを実行して何が起きたのかを確認する必要がありました。手動の作業が必要だったわけですが、もっと素早く答えを得られる方法はないでしょうか？これらのパターン比較を全て組み合わせたものが、Anomaly detectionとなります。重要なアプリケーションログに対してこれを適用する場合、そのLog groupやLog groupのセットに対してAnomaly detectionをオンにするだけで、先ほど見たようなパターンを自動的に監視してくれます。時間の経過とともに、何か重要な変化が起きると、異常を検出し、その異常の重大度を判定し、このパターンで何が変化したのか - そのパターンを持つログの割合が増加したのか減少したのか、あるいは今まで見たことのないパターンなのか - を説明してくれます。どこから調査を始めるべきかの道筋を示してくれるのです。さて、これで1つ目の質問は終わりです。次の質問に移りましょう。
これは私の大好きな質問です。というのも、これについては悪夢を見たことがあるからです。このRequest IDはどうなったのでしょうか？先ほど話したように、これには2つの問題があります。まず、このRequest ID以外に何を探せばいいのかわからないということ。次に、CloudWatchでクロスアカウントアクセスを使用している場合、特に数万のLog groupがある場合、数十のアカウントに100のLog groupがあるかもしれません。どこから始めればいいのでしょうか？
ここで、Andreasが言及したEnhanced log group selectionを使用したクエリが非常に強力な機能となります。今では10,000のLog groupを選択できます。しかし、大量のデータをスキャンすることになるという問題が出てきます。これを効率化してクエリ結果をより速く得る方法はないでしょうか？私が話した課題は、全てのログを検索したい（どのLog groupやアカウントかを考えたくない）けれど、同時に速い結果も欲しいということです。これらは一見、相反する要求のように見えます。全てのログを常に検索し始めると、多くのデータをスキャンすることになり、コストがかかりクエリが遅くなってしまいます。
この問題に取り組み、この機能を構築する際、私たちは一度に1つの側面だけを解決することはできないと気づきました。制限やコントロールする方法なしに、単にすべてのLog groupへのアクセスを提供するだけではダメです。同様に、制限する方法を提供しても、どのアカウントやどのようなLog groupを検索したいのかというログクエリのコンテキストで検索できなければ、意味がありません。私たちが考え出した解決策がEnhanced log group selectionで、これにより一度に10,000のLog groupを選択できます。個別に選択する必要はありません。それは現実的ではないからです。Log group名のプレフィックスで検索できますし、アカウントのLog groupが数百個か10,000未満の場合は、すべてを検索することもできます。
クエリを高速化するために、Field indexesを導入しました。Field indexesでは、Log groupごと、またはアカウントレベルで最大20個のフィールドを定義できます。Request IDのような一般的な属性は、ログが取り込まれる際に自動的にインデックス化され、取り込みから30日間インデックスが保持されます。しかし、あるLog groupや期間でRequest IDをインデックス化していなかったけれど、全てのLog groupを検索したい場合はどうでしょう？1つの問題のあるLog groupが原因で、クエリが遅くなりコストが高くなる問題に直面しませんか？そのために、filterIndexという新しいクエリコマンドを導入しました。全てのログを検索したいけれど、インデックス化されているものだけを対象にしたい場合、Request IDに対してfilterを使う代わりにfilterIndexを使用すれば、スキャンをインデックス化されたデータのみに制限できます。
簡単なデモでその仕組みをお見せしますが、ここで重要なポイントは、これらの機能がすべて組み合わさることで、問題の文脈が与えられていない状況での「干し草の中の針探し」の問題を解決できるということです。 私たちの目標は、そういった質問への回答をよりシンプルに、より速く、よりコスト効率よく行えるようにすることでした。これらの機能はすべて、Standard Log Groupsにおいて追加コストなしで利用できます。 つまり、より良いインサイトを得ながら、同時にコストを削減できるのです。これは二重の恩恵と言えます。
では、簡単なデモをお見せしましょう。これが私のデモの環境です。複数のマイクロサービスがある状況を再現しようとしました。GreenGrocerという食料品配達アプリケーションで、Checkout Service、Order Service、Payment Serviceがあります。具体的なサービスの内容は気にしないでください。強調したいのは、これが私たちの実際のアプリケーションの姿だということです。異なるサービスが複数のアカウントにまたがっていることが多く、干し草の中の針を探すときにどこから始めればいいのか分からないのです。 私の環境では、3つの異なるアカウントにまたがっています。1つは自社のウェブサイトでの食料品の直接配達用、もう1つはリセラーからの注文用、そして中央アカウントでアプリケーション全体のモニタリングを行っています。
デモに移りましょう。 クエリの説明に入る前に、もう一度強調しておきたいのは、常に何らかのナビゲーションルートから始めることが重要だということです。これらすべてをクエリできるとはいえ、私はサービスのトップレベルのダッシュボードを持っていて、そこからビジネスインサイトを得ています。Andreaが言ったように、これらはすべてクエリではありません。Metric Filters、Contributor Insightsなど、すべてを使用しています。つまり、トラブルシューティングを始める必要があるとき、平均収益やビジネスメトリクスについての出発点があり、エラーも確認できます。リセラーの支払い失敗のエラーが他より多いことが分かるので、そこから始めたいと思うかもしれません。これが問題のトラブルシューティングの出発点となります。
このクエリについては、私のログがどのようなものかイメージを持っていただくために、開始前に実行しておきました。これは各サービスで公開している単純なJSONログで、ユーザーの種類、ユーザーが誰か、エラーの内容や発生したイベントなどの最低限の情報を提供しています。これらの情報をこれからのクエリで使用していきます。ここで重要な属性がいくつかあることを皆さんに示しておきたかったのです。
さて、ここからが本題です。これがCloudWatchコンソールで、左側にたくさんの機能があります。その多くが新しいものですが、今日はすべてを紹介できません。戻られた際に、CloudWatchの新機能をぜひご確認ください。私のクエリでは、その支払い失敗を検索し、なぜエラーが多かったのかを理解したいと思います。 今日では面倒な方法で、これらのロググループをすべて選択することもできます。GreenGrocerを選択して、20個ほどのロググループを手動で選択することもできますが、私は面倒くさがり屋なので。
このprefixを使うだけで、該当する全てのロググループ（この場合は14個のロググループ）を自動的に見つけることができます。そして、特にResellerアカウントを選択することができます。先ほど申し上げたように、ResellerはDemo-3アカウントにありますので、このような一括ロググループ選択を行う場合でも、スコープを絞り込むことができます。これを12時間分実行してみましょう。 ここで起きたことについて、特に2点お話ししたいと思います。1つ目は、求めていた結果が全て得られたことです。エラーカウントを確認でき、適度な量のデータをスキャンして2.5秒で完了しました。4メガバイトをスキャンしましたが、FilterIndexを使用していたため、700メガバイトはスキップされました。FilterIndexは、この場合、インデックス付きのデータのみを検索したため、あいまいさを排除し、Eventがインデックス化されていたおかげで、全てのイベントタイプを気にする必要がなくなりました。
私たちが注目しているのは、Payment Failedイベントです。これは私のログの中では比較的まれなため、スキャンされるログも少なくなります。では、このトレンドがDirectアカウントとResellerアカウントの全てで一貫しているのか、それともResellerに特有なのかを確認してみましょう。すぐに全アカウントに切り替えて、同じクエリを実行してみます。少し多くのデータをスキャンすることになりますが、他のアカウントを検索すると、Payment Gatewayのタイムアウト数が以前よりもかなり高くなっていることがわかります。これは新しい発見ですね。
さらに一歩進めてみましょう。私はもっと怠け者なので、これまで話してきたRequest IDを使います。 私の場合、このRequest IDはSession IDに対応しています。これは全てのトランザクションをトラッキングする方法だからです。私が持っている情報はこれだけです - どこかで何らかの時点で発生したSession IDについて、顧客がCEOにエスカレーションしており、何が起きたのかを知りたがっています。正確な時間枠がわからないので、5日間分を検索してみましょう。また、どこで発生したかもわからないので、全てのロググループを選択します。
ここでコツをお見せします - FilterIndexなしでFilterを使用してこのクエリを実行すると、特に5日間分を実行しているため、より時間がかかります。 これが完了すると、クエリされるロググループが異なることに気付くでしょう。FilterとFilterIndexの違いをお見せしたいと思います。まだ実行中で、時間がかかっています。 大量のデータをスキャンしています。ここでは、私の全アカウントの全ロググループをクエリしただけです。私は数百のロググループしか持っていないので、まだ10,000以下です。 しかし、もっと多くのロググループがある場合は、別の方法が必要になるでしょう。この場合、66のロググループをスキャンしています。
スキャンされたロググループを確認できます。 31秒かかりましたが、もっと良くできると思います。14ギガバイトのデータをスキップできたので、それでもかなり効率的でした。ここで、クエリの他の部分（時間枠、スコープなど）は全て同じままで、単純にFilterIndexに変更してみましょう。66というロググループ数に注目してください。
これを実行してみると、30秒かかっていたものが4秒で完了しました。同じセッションIDが得られていますが、スキャンされたロググループは12個だけです。この比較で強調したかったのは、クエリ内でインデックスを使用する場合でも、目的に応じて利用できるツールがあるということです。filterやfilter indexをいつ使うべきか、これを知ることで、コスト全体を最小限に抑えながら、より迅速なインサイトを得ることができるようになるはずです。
まとめ：ログ分析の価値最大化と今後の展望
これは重要なポイントですね。インデックスを使用して最適化すると、スキャンするデータ量が減るからです。クエリを実行しなければならない状況はありますが、価値を最大化する方法で行いたいものです。ここで、私たちが触れた内容をまとめてみましょう。
ぜひ覚えておいていただきたいことの一つは、なぜログを取るのかを慎重に考える必要があるということです。単にデータをダンプしているだけではいけません。二つ目のポイントは、多機能ツールが単純なノミよりも非効率な場合があるということです。目的に応じて適切なツールを使用する必要があります。私たちは、Metric FiltersやEMF、そしてContributor Insightsを活用してログの使用を最適化する方法について多く話し合いました。
よく耳にする「コストをどう削減するか」という質問は、実は適切ではありません。今日、皆さんにそれを理解していただけたと思います。適切な質問は「価値をどう最大化するか」、つまり最適なコストで最大のインサイトを得るにはどうすればよいかということです。Metric Filters、Embedded Metric Format、Contributor Insightsは、まさにそのための優れたツールとなります。デモで作成したダッシュボードの一つで計算してみましたが、5分ごとにクエリを実行する1つのダッシュボードや1つのウィジェットで月額500ドルかかるところを、ダッシュボードとメトリクスのコストを合わせて月額2.30ドルで済むという違いがあります。
規模が大きくなると、この違いは非常に大きな意味を持ちます。ログ変換は、これらのツールを活用できる状態に持っていくのに役立ちます。もちろん、Logs Insightsはタイムマシンのような存在で、使用する必要はありますが、賢く慎重に使用する必要があります。私たちは皆これを愛用していますが、時として使いすぎてしまうことがあります。先ほど話した他のツール - メトリクス、Contributor Insights、EMF - これらはすべてAmazonの計測方法から生まれました。より良い方法があることに気づいたのです。EMFメトリクスは、私たちの社内サービスチームが、クエリを何度も実行したくないと考えたことから生まれました。そして、これらを皆さんと共有したいと考えたのです。
クエリを実行する際には、より使いやすく、より高速で、可能な限りコスト効率の良いものにしたいと考えています。そして最後に、問題のある領域へより素早くナビゲートできるようにしたいと考えています。そこで重要になってくるのが、Pattern分析、Compare機能、そしてAnomaly検出です。Pattern機能について、昨年これを開発した時の興味深いエピソードを一つご紹介させていただきます。私たちは通常、開発したものすべてを自社でテストします - 自社製品を自ら使用するドッグフーディングを行っています。Pattern分析を実行した際、エンジニアたちは、あるパターンを発見しました。それは誰かが入力した空白行で、そのログセットの99%を占めていたのです。
Pattern分析コマンドを実行しただけで、この問題が明らかになりました。この経験から、現在ではAWS全体で数日ごとにすべてのログに対して定期的なヘルスチェックを実施し、何か問題がある場合や、あるべきものが欠けている場合などを検出しています。このPattern機能は、このようにAWS全体で活用されていますので、皆様も是非ご自身のログ管理の改善にお役立てください。本日お話しした内容についてさらに詳しく学べるリソースをご用意しています。これらのQRコードには多くの有益な情報が含まれています。これらの機能がどのように動作し、どのように環境で活用して価値を最大化できるかについて、より深く理解していただければと思います。この後5-10分ほど質疑応答の時間を設けておりますので、ご質問のある方はお気軽にどうぞ。ご参加ありがとうございました。そして、アンケートへのご記入もお忘れなく。
※ こちらの記事は Amazon Bedrock を利用することで全て自動で作成しています。
※ 生成AI記事によるインターネット汚染の懸念を踏まえ、本記事ではセッション動画を情報量をほぼ変化させずに文字と画像に変換することで、できるだけオリジナルコンテンツそのものの価値を維持しつつ、多言語でのAccessibilityやGooglabilityを高められればと考えています。
Discussion