re:Invent 2024: AWSとStripeが語るオープンソースObservabilityの実践
はじめに
海外の様々な講演を日本語記事に書き起こすことで、隠れた良質な情報をもっと身近なものに。そんなコンセプトで進める本企画で今回取り上げるプレゼンテーションはこちら！
📖 AWS re:Invent 2024 - Observability the open source way (COP324)
この動画では、AWSにおけるオープンソースObservabilityについて、AWS Specialist Solutions ArchitectのRodrigue Koffi氏とAWSのMarc Chéné氏、StripeのCody Rioux氏が解説します。Amazon Managed Service for PrometheusやAmazon Managed Grafana、Amazon OpenSearch Serviceなどのマネージドサービスの特徴と、それらを活用した監視の実践方法が紹介されます。特にStripeでの事例では、ベンダーソリューションからAmazon Managed Service for Prometheusへの移行により80%のコスト削減を実現した具体的な経緯が語られます。また、新機能としてワークスペースあたり10億のアクティブな時系列と10万のルールをサポートする大規模なスケーリング、30以上のプリビルトソリューションを備えたObservable Solutions Catalogの提供開始などが発表されています。
※ 動画から自動生成した記事になります。誤字脱字や誤った内容が記載される可能性がありますので、正確な情報は動画本編をご覧ください。
※ 画像をクリックすると、動画中の該当シーンに遷移します。
re:Invent 2024関連の書き起こし記事については、こちらのSpreadsheet に情報をまとめています。合わせてご確認ください！
本編
AWSにおけるオープンソースObservabilityセッションの概要
皆さん、こんにちは。re:Inventへようこそ。本日は、AWSにおけるオープンソースObservabilityについてお話しできることを大変嬉しく思います。私はSpecialist Solutions Architectのrodrigue Koffiです。Observabilityを専門としています。本日は、AWSのプロダクトおよびエンジニアリングチームを率いるMarc Chénéと、StripeのObservabilityテックリードであるCody Riouxをお迎えしています。
本セッションでは、まずオープンソースObservabilityの課題についてお話しし、その後デモをご覧いただきます。続いてCodyがStripeでの経験についてお話しし、最後にMarcがAWSのマネージドオープンソースの新機能についてご紹介します。
Example Corpのインシデント対応事例
このセッションの導入として、ある事例をご紹介したいと思います。 JessicaというSREについてお話しします。JessicaはExample Corpで働いています。金曜日のオンコール当番で、そろそろ帰宅したい時間帯です。 夜11時、Jessicaにアラートが入ります。フロントエンドアプリケーションを常時テストしているCanaryテストから、あちこちでレスポンスが遅くなっているという警告が届いたのです。
Jessicaは「完璧なダッシュボードがあるから、すぐに問題を見つけて金曜の夜を取り戻せるはず」と考えます。 Example CorpのEKS上で管理しているGrafanaにログインしようとしますが、アクセスできません。Prometheusにもアクセスできません。セルフマネージドのPrometheusを使ってダッシュボードにアクセスしようとしますが、これも利用できない状態です。 Prometheusのブラウザ式を使おうとしても、それも読み込めません。 アラートは次第にエスカレーションし、バックアップのオンコールエンジニアであるBobにも通知が行きます。
Bobは通話に参加し、「Jessica、Prometheusのトラブルシューティングを続けて。私はアプリケーションログを確認してみるよ」と言います。しかし、これは多数のサービスを含む大規模なマイクロサービスアプリケーションです。どこから手をつければいいのでしょう？どのアプリケーションログを確認すべきか、手がかりがありません。BobはJessicaがPrometheusの問題を調査している間、ログの確認を始めることにしました。
数分後、CTOのSarahが電話会議に参加します。顧客が苛立ちを見せ始め、 サポートには多くの問い合わせが殺到していたためです。Sarahは状況を確認し、より迅速な問題解決に協力するために参加しました。 Jessicaが戻ってきて回答し、「Prometheusがメモリ不足になったと思います。ログにkillの記録がたくさんあり、おそらくディスク容量も不足していたようです」と報告しました。
その数分後、Bobもログから新たな発見を報告しました。Cart Serviceがデータベースへの接続に問題を抱えているとのことでした。Cart Serviceで接続プールのエラーが発生しており、おそらく他のサービスでも同様の問題が起きているとのことでした。彼らは手がかりを見つけ、サービスの再起動など、状況を回復させるために必要な対策を講じることにしました。
Example Corpで起きた出来事を振り返ってみましょう。午後11時にインシデントが発生し、午後11時5分から11時50分まで、 完全に手探り状態でログを確認し、根本原因を特定できない状況が続きました。彼らは長年の経験に基づく観察力を頼りに、サービスについての知識と、どこを確認すべきかの勘を頼りに対応していました。 その後、インシデントは解決し、すべてが復旧しました。
オープンソースObservabilityの課題とマネージドサービスの利点
「オープンソースが無料なのは、あなたの時間に価値がない場合だけだ」という有名な言葉があります。自分でオープンソースを運用する際にはいくつかの課題があります。この例で言えば、Prometheusが適切にスケールし、すべてのメトリクスをホストしてクエリするのに十分なスペースを確保する必要があるという追加の負担が生じます。
オープンソースコミュニティでは、すべてが頻繁に変更される急速なリリースサイクルがあります。今日構築したWebアプリケーションを6ヶ月後に開いてコンパイルしようとしても、何も動作せず、すべての依存関係が壊れているということがあります。このような状況に直面した時、問題解決のために相談できる人や得られるサポートは限られています。さらに、コンプライアンスやセキュリティプログラムを経験された方ならご存知かと思いますが、コンプライアンスレベルを維持するには多大な努力が必要で、自分の意思とは関係なく常に変化するものを扱うことで、その維持がより困難になる可能性があります。
Managed Observabilityで何ができるか見ていきましょう。 この複雑さを取り除くと、このようになります。例えば、午後11時にインシデントが発生したとします。 そして、アプリケーションに焦点を当てて根本原因の特定に時間をかけます。私たちは、 調査すべきシグナルを指摘します。その後、インシデントをクローズします。これにより、アプリケーションの構築に必要な部分に集中することで、平均復旧時間を短縮できます。
AWSのマネージド型オープンソースObservabilityソリューション
AWSのマネージド型オープンソースObservabilityでは、Amazon Managed Service for Prometheusを提供しています。これは、サーバーレスでPrometheus互換の完全マネージド型サービスで、あらゆる環境を大規模に監視できます。私たちがお客様に代わってスケーリングを行い、ニーズに対応します。また、ログとトレースのホスティングにはOpenSearchを使用します。 メトリクスのホスティングも可能ですが、その用途にはPrometheusの方が適しています。OpenTelemetryを使用すれば、データを収集して両方の場所に送信できます。 可視化については、選択肢があります。Amazon Managed Grafanaを使用してメトリクスとOpenSearchをクエリするか、OpenSearch Dashboardsを使用してデータソースをクエリすることができます。
一般的に見られるリファレンスアーキテクチャでは、 AWS LambdaやAmazon ECSなど、多くのソースからデータが収集されます。アプリケーションがホストされている場所からデータを収集でき、多くのAWSサービスと統合されています。例えば、Amazon EBSは最近、EBSボリュームメトリクスをAmazon Managed Service for Prometheusに取り込むサポートをリリースしました。 通常、OpenTelemetryやPrometheusのコレクターを使用してデータを送信します。昨年、マネージドコレクターをリリースしたので、Amazon EKSでは何も管理することなく、メトリクスを収集できます。送信先としてPrometheusまたはOpenSearchがあり、すべてを可視化するために、Grafana とOpenSearch Dashboardsを使用できます。
メトリクス収集の仕組みを詳しく見ていきましょう。 通常、Prometheus側にはOpenTelemetryエージェントがあります。 Prometheusのremote writeプロトコルでデータを送信することを想定しています。Amazon Managed Service for Prometheusの内部では、Cortexアーキテクチャをベースにしており、インジェスターモジュールがあります。このモジュールは、すべてのデータをS3に送信します。これは完全に私たちが管理し、スケーリング、パッチ適用、運用のすべてを処理します。 お客様の手を煩わせることなく、安心して夜も眠れるようにします。Amazon EKSを使用する場合、 すべてのデータ収集を抽象化できます。データのクエリには、 GrafanaやHTTP APIとして使用できるクエリAPIがあります。Prometheus APIをサポートしているので、APIを直接使用するか、S3を活用するクエリモジュールを通じてGrafanaを使用できます。アラートについては、ルーラーモジュールとアラート マネージャーモジュールがあり、ルールとアラートを処理します。すべてがサービス内で管理され、Amazon SNSを通じて接続され、VPCエンドポイントでセキュリティとスケーラビリティの両方を提供します。
ログの取り込みについては、Amazon EKSやアプリケーションを実行している場所で、Fluentbitエージェントを接続できます。 また、OpenTelemetryフォーマットのデータも扱えます。アプリケーションでOTLP SDKsを使用している場合は、ログを処理してAmazon S3を使用できます。S3にログがある場合、すべてをOpenSearch取り込みパイプラインに接続できます。 これは完全マネージド型のDataPrepperサービスで、アプリケーションソースからデータを収集するために実行できます。内部には、バッファーと複数のプロセッサーがあり、データを操作してOpenSearchドメインまたはOpenSearchコレクションに送信できます。 これが完全マネージド型のサーバーレスOpenSearchで、可視化にはGrafanaとOpenSearch Dashboardsを使用します。
通常、お客様にはアプリケーションを複数のアカウントにまたがって実行することをお勧めしています。 時には複数のリージョンにまたがって実行する必要がある場合や、自社のデータセンターや異なるクラウドプロバイダーで実行する必要がある場合もあります。これらのシナリオはすべて対応可能です。この包括的なアーキテクチャ全体を実行し、AWSで監視を一元化することができます。
ここで、これまでお話ししたことすべてを結びつけるデモを簡単にご紹介したいと思います。 OpenTelemetryをご存知の方のために説明しますと、これは負荷生成ツールを備えたマイクロサービス群で、フロントエンドからのトラフィックを複数のサービスに分散させます。 これは私のアカウントにデプロイされており、先ほどお見せしたリファレンスアーキテクチャを使用してOpenTelemetryですべてのデータを収集しています。こちらが最初のダッシュボードです。 すべてのサービスに対するリクエストが表示されています。サービスごとのトレンド、リクエスト数、エラー数などが確認でき、これらはすべてAmazon Managed Service for Prometheusから取得しています。クエリの内容をお見せしますと、これはPrometheusのデータソースで、これらのクエリはすべてPrometheusを通じて実行しています。
サービスの動作についてより詳しく知りたい場合は、ここをクリックします。 Amazon Managed Grafanaを使用して可視化しています。ログの量を示すダッシュボードがあり、 アプリケーションのトラフィックパターンを把握することができます。ダッシュボードではPrometheusと共にOpenSearchをデータソースとしてログのクエリを実行しています。メモリ、CPU、その他の一般的なメトリクスに加えて、トレーススパンに関する情報も確認できます。
遅いリクエストの例を見てみましょう。 レイテンシーでフィルタリングして、このトレースを選択します。何が起きているかを示すサービスマップが表示されます。トラフィックは負荷生成ツールから始まり、フロントエンドプロキシを経由して広告サービスに到達します。 また、その特定のトレースに関連するログも確認できます。ログはOpenSearchに、メトリクスはPrometheusに保存されています。
このダッシュボードについて興味深い点を手短にご紹介します。Prometheusで検出したサービスにはサービスを示すラベルが付いており、このサービス名を使ってOpenSearchですべてのトレースを見つけることができます。これにより、異なる場所に存在するメトリクスとトレースを関連付けることができます。 さらに詳しく、ログとトレース用に特別に作られたダッシュボードを見ることもできます。例えば、 Namespace別のログを確認できます。これはKubernetesクラスターでホストされています。コンテナごとのエラーもすべて確認できます。先ほど申し上げたように、完璧なダッシュボードを提供していますが、違いは私たちがそれを管理するということです。もちろん、これは私のデモなので、うまく動作しています。
StripeのCody RiouxによるAmazon Managed Service for Prometheusへの移行事例
それでは、Codyを壇上にお招きして、Stripeで直面した課題についてお話しいただきたいと思います。
Rodrigueが紹介してくれた通り、私はCodyと申しまして、Stripeのオブザーバビリティ部門のTech Leadを務めています。具体的には、ログ、メトリクス、トレース、プロファイリングデータを扱うテクノロジーとチームを統括しています。本日は特にメトリクスの事例に焦点を当てたいと思います。というのも、昨年、私たちはAmazon Managed Service for Prometheusへの大規模な移行を行ったからです。
Stripeと聞くと、決済会社というイメージをお持ちかもしれません。確かにその通りなのですが、私たちはより広く、インターネットのGDPを向上させることを目標とした、グローバルな決済・財務ネットワークとして自身を位置づけています。これまでの実績を見ても、その成果は着実に表れています。昨年は1兆ドルの取引を処理し、1日あたり5億件のAPIリクエストを処理しました。そして、これらを99.999%という高い信頼性で実現しています。もちろん、この信頼性を支える上で、オブザーバビリティとメトリクスは重要な役割を果たしています。
私は2022年10月にStripeに入社したのですが、着任時に目の当たりにした状況は、皆さんにも馴染みがあるかもしれません。オブザーバビリティのコストが予算を大幅に超過しており、これを削減する必要に迫られていたのです。 そこで経営陣は、ベンダーベースのメトリクスソリューションをオープンソースソリューションに移行し、単価を下げることを決定しました。 そして、オブザーバビリティのコストを適切な水準に抑えることを目指しました。2022年10月、私たちが選んだオープンソースソリューションが、Amazon Managed Service for Prometheusでした。
実は同じ月に、私は引退した家具職人の元を訪ねて、この木材を購入しました。念のため申し上げておきますが、これは私生活での話で、Stripeが費用を出したわけではありません。この木材は長さ7フィート、幅3フィート、厚さ3インチあります。パートナーとカスタムダイニングテーブルを作る話をしていたので、これを自分で作ってみようと思ったんです。1〜2ヶ月もあれば完成するだろうと考え、既存のダイニングテーブルを売って、スペースを空けました。ところが2年経った今でも、この木材は私の工房の床に置きっぱなしです。 ダイニングルームは今も空っぽのままで、パートナーにはよくからかわれる種になっています。
私はここで何をしてしまったのでしょうか？最終製品が見えていたため、それを思い描くことはできたのですが、そこに至るまでの全てのステップと時間を想像することができませんでした。それが実際よりもずっと簡単だと考えてしまう、この間違いを犯してしまったのです。私のような木工初心者にとって、これは非常によくある落とし穴です。しかし、オープンソースのソフトウェアの世界では、ベテランであってもこの落とし穴に陥りやすいものです。私たちはソフトウェアの専門家なのだから、これらのツールを運用するのはそれほど難しくないはずだと考えてしまいます。しかし実際のところ、ベンダーは私たちが支払うお金の見返りとして、多くのことを行ってくれているのです。私たちはこの利点を維持したかったので、このターンキーの特性を保ちながら、オープンソースのダイナミクスを得るために、Amazon Managed Service for Prometheusへの移行を決定しました。
Amazon Managed Service for Prometheusへの移行は、ベンダーとの新しい契約を締結する必要があったため、1年以内に完了しなければなりませんでした。最初に私たちが行ったのは、どの自尊心のあるコンピュータサイエンティストもそうするように、コンパイラを使うべきか、それともAIを構築して移行すべきかについて大議論を交わすことでした。移行とは具体的に何を意味するのでしょうか？私たちには40,000個のアラート、150,000個のダッシュボードクエリ、そして2億7000万のメトリクスを含む無数のコンポーネントがありました。手作業での移行は現実的ではなかったため、何らかの自動化を実行する必要がありました。皆さんの職場でも多くの移行プロジェクトを経験されていると思います - 古いシステムを稼働させながら、新しいシステムを立ち上げ、古いシステムは非推奨になるので移行してくださいと伝えます。そして何年も経っても、完全な移行は実現していない、というような状況です。
私たちにはそのような選択肢はありませんでした。なぜなら、多額の資金が関係していたからです。そこで私たちは腰を据えて、それらのアラートとダッシュボードのパーサーの開発に取り掛かりました。入力空間は非常に大きかったものの、ユーザーが実際に使用していたクエリ言語の機能は、ごく一部に限られていることが分かりました。そのため、すぐにパースができるようになり、便利な中間表現を得ることができました。パーサーを作ったことがある人なら分かると思いますが、Abstract Syntax Treeを取得して、それを何かにコンパイルする必要があります。そこで私たちはコンパイラの構築を始めました。
この時点で、私は自分の能力を超えていることに気づきました。幸いなことに、上司のScottはコンパイラの専門家を手配してくれました。多くのStripeの社員がこの専門家に感謝しています。というのも、誰かが私に何かを作れるかと尋ねてきたとき、私が「それは不可能です」と言うと、この専門家が「3時間で作れます」と言って、本当に作ってしまうからです。Stripeは彼のおかげでずっと良くなっています。
私たちは全てのアセットを効果的に移行することができました。しかし問題は、何か間違いを見つけた時に、人々はただそれを編集して修正し、先に進んでしまうことでした。しかし先ほど述べたように、私たちの入力空間は実際にはそれほど大きくありませんでした。最終的に、私たちの一人が中間表現（Abstract Syntax Tree）を使って実験を行い、セマンティクスを変更しないノードを全て削除すると、実際には同じものであるアラートやダッシュボードクエリのグループを見つけることができることに気づきました。さらに良いことに、一つの問題を見つけて修正した場合、その修正が必要な他の全てのケースを自動的に見つけて適用できることが分かりました。逆に、あるアラートについての情報がある場合、一つが正しく動作していることが分かれば、最近発火していない、あるいは発火していないかもしれない他の全てのアラートを見つけ出し、このアラートは正しく変換されていることが分かっているので動作するはずだと、オーナーに伝えることができました。
これにより、最終的な受け入れを得るための大きな一歩となりました。もし何らかのタイムラインに沿って移行を行う必要がある場合、私のアドバイスは、できるだけ早い段階で、理想的にはお客様との関わりを持つ前に、そのフィードバックループを自動化された形で閉じることです。私たちはそのルートを取らなかったため、苦労することになりました。
2番目の課題として「Alert Management Experience」と書きましたが、実際には「User Experience」とすべきだったかもしれません。これらのオープンソースソリューションにおけるユーザー体験は、しばしば隠れたスケーリングの制限となります。良い例として、オープンソースのGrafanaは、Prometheusから全てのアラートセットをダウンロードし、クライアントサイドでフィルタリングを行います。これは1,000件、あるいは2,000件、場合によっては10,000件のアラートであれば問題なく動作します。私たちは40,000件からスタートし、現在では100,000件を超えています。ほとんどの場合、ユーザーには単にこのスピニングアイコンが表示されるだけで、それ以外は何も表示されません。そして、もし十分に待てば、このエラーメッセージが表示されるかもしれませんが、もう私たちにとってはお馴染みになってしまいました。
これらのユーザー体験の問題に対処するため、私たちは段階的なアプローチを取ることにしました。最初の移行段階では、ユーザーが古いシステムから新しいシステムに移行する際のアラートとダッシュボードの管理を支援する、移行に特化したUIを構築しました。しかし、移行が完了すると、そのUIは不要になりました。そこで中期的な対応として、Stripeの一般的なコントロールパネルに独自のアラート管理ツールを組み込みました。途中で気づいたことの一つは、Markにしつこく言い続けると、魔法のように物事が解決されるということでした。
良い例として、ある日ログインしてみると、アラートと同様にオートコンプリートの動作に問題が発生していました。クエリの編集時に全てのメトリクスを取得しようとするのですが、2億7,000万個ものメトリクスがあると、ブラウザはそれを本当に嫌がります。ある日、クエリの編集を始めようとログインすると、少し異なるオートコンプリートのインターフェースが表示され、異なるフィルターを使用していることを示していました。そして、それは本当に高速でした。申し訳ありませんMark、でも私はもう少しナグり続けると思います。結局のところ、オープンソースではそのままで完璧なものは提供されないので、ユーザー体験のギャップを埋める準備をしておく必要があります。一般的に、これらのツールは大規模な環境で書かれているわけではありません。
私たちが直面した3番目の課題はカーディナリティでした。これは私たちにとって本当に興味深い問題でした。古いソリューションでは2億7,000万個のメトリクスがありました。これらをAmazon Managed Service for Prometheusに送信し始めると、古いソリューションでは増加していないのに、数が増え続けていました。何が起きているのか分からなかったので、Markに助けを求めました。彼のチームは2日後に私たちとミーティングを設定し、とても奇妙な現象を見ていると言いました。ミーティングで彼らは、「error」というラベルを持つメトリクスを示してくれました。そこでは最も一般的な値がfalse、2番目に多い値がtrue、そしてその後に何百万もの一意のスタックトレースが続いていました。それを見た瞬間、私たちはRubyを使用している会社なので、おそらくブーリアン変数に何らかの時点でスタックトレースが追加されたのだろうと気づきました。調査を進めると、タイムスタンプ、IPアドレス、URL、データベースのプライマリーキー、メモリアドレスなど、時系列データベースでよく見られるような興味深い事例が次々と見つかりました。結局のところ、私たちのベンダーソリューションは単にインジェスト時に自身を保護していただけでした。しかし、オープンソースのTSDBであるPrometheusは、私たちが何を保存したいのかについて仮定を設けません。APIコールで何かを保存しようとする場合、それはそのデータを保存したいという意図があるからです。
スタックトレースが長すぎる場合、それは破棄されていました。おそらくIPアドレスや類似データのパターンマッチングが行われていたため、私たちが報告していた問題のあるデータはベンダーソリューションに到達することはありませんでした。
この問題を解決するために、コレクションと保存層の間にStream Processorを配置しました。私たちは、Netflixで開発されたオープンソースプロジェクトのMantisを使用しています。これは、現時点では価値があるものの、全てを保存する必要のない大量のデータを扱う、高カーディナリティまたは高頻度のシナリオに対応するために特別に作られたものです。このStream Processor上で、保存前にカーディナリティとデータを削減したり、特定の値をフィルタリングしたりするジョブを実行します。ユーザーがデータベースのプライマリーキーやIPアドレスでアラートを設定したい場合（これは実際に有効なユースケースです）、保存層に到達させることなく、Stream Processor上で直接実行できるようにしています。これが、私たちの分散型ストレージと可観測性に対するアプローチです。
ここでの重要なポイントは、予期せぬ事態に備えることです。これは単に奇妙なことが起きた時に受け入れるということだけでなく、予期せぬ状況に対処するためのツールを構築することを意味します。私が考えるに、Amazonがストレージ層とユーザーインターフェース層を運用することが差別化されていない重労働だとすれば、これこそが私たちのチームがStripeで成し遂げようとしていることにおいて違いを生み出せる興味深い部分なのです。
これは私たちにとってどのような成果をもたらしたのでしょうか？コストを約80%削減することができました。アクティブなTime Seriesの数は2倍になりましたが、これはただのランダムなデータの増加ではなく、単純にフットプリントが大きくなり、より多くのメトリクスを使用するようになったためです。実行しているアラートルールの数は3倍になり、これは素晴らしい成果です。そしてまだ十分な余裕があります。先ほど話したように、このマイグレーションの契機はコストでしたので、この大幅な削減は重要な成果といえます。
Codyさん、ありがとうございました。特に、私たちのマネージドサービスを採用する際の課題、解決策、得られた教訓について、可観測性への取り組みを共有していただき、ありがとうございます。本日発表する新機能の一部が、あなたの時間を解放し、最も重要なことに集中できるようになることを願っています。おそらく、次のプロジェクトがあなたとご家族のための犬小屋作りにならないように、テーブルを完成させることかもしれませんね。
AWSのMark Sannyによる新機能と改善点の紹介
私の名前は Mark Sanny です。AWS のシニアマネージャーとして、本日は Prometheus、Grafana、そして OpenSearch の新機能についてお話しさせていただきます。 過去5年間の数多くのお客様とのコミュニケーションを通じて、これら5つのテーマが常に浮かび上がってきました。私たちはお客様のニーズに応えるための取り組みを進めてきました。まず、スケーラビリティについてですが、これはお客様の最も高い要求に応えるためのスケーリングに関する煩雑な作業を担いながら、高可用性と信頼性の高いサービスを提供することを意味します。
AWS での仕事を始めた当初から、最も印象的だったのは、私たちの顧客への徹底的なこだわりと、私たちが運営している規模の大きさです。AWS でのスケーリングは継続的な取り組みですが、一部のオープンソースプロジェクトでは、私たちだけでは対応できないことがあります。必要なスケールを実現するには、オープンソースコミュニティとの協力が不可欠です。 昨年、ワークスペースあたり5億のアクティブな時系列メトリクスと3万のルールをサポートすることを発表しました。ワークスペースは、メトリクスの取り込み、クエリ、保存のための分離とセキュリティを提供します。
本日、ワークスペースあたり10億のアクティブな時系列と10万のルールをサポートすることを発表できることを嬉しく思います。これにより、EKS クラスター、EC2 環境、アカウント、ハイブリッド環境、マルチクラウド環境など、すべてのメトリクスを統合することが可能になります。Grafana では、これまで500の同時ユーザーをサポートしていましたが、現在は1,000の同時ユーザーをサポートしており、大規模なチームに必要なすべての可観測性データを統合することができます。
次はコスト効率性についてです。 コストの削減や監視を求められていない方はいらっしゃいますか？コスト効率性は、サービス所有者である私たちにも影響を与えます。私自身、自分のサービスのコスト管理に責任を持っており、これは重要な考慮事項です。
これに対処するため、可観測性データからより多くの価値を引き出しながら、同時にコストを削減する方法として、データを統合する方法についてお話ししたいと思います。 ここでは、VPC Flow logs、CloudTrail events、AWS Web Application Firewall logs という3つの異なるログソースについてお話しします。しかし、その前に、コスト効率の良い方法の1つとして、Vended logs についてお話ししましょう。AWS Vended logs は、AWS サービスから CloudWatch、Kinesis Data Firehose、S3 などの異なる配信先に出力されるログです。これらのログを分析する際、集中管理することで階層型料金体系を活用でき、より高い階層に達すると、コストが1GBあたり50セントから5セントに下がる、つまり10分の1になります。
VPC Flow logsは、VPCネットワーク内のAWSリソースとワークロードがどのように相互作用しているかを理解するための貴重な情報源です。トップトーカーの特定、ネットワークレイテンシーの把握、VPC内の帯域幅使用状況のモニタリングに優れた機会を提供し、ネットワークのトラブルシューティング、セキュリティ監視、キャパシティプランニングに役立ちます。GrafanaとVPC Flow logsを使用して、お客様の環境でこれらを実装する方法について詳しく学ぶことができます。
CloudTrailイベントは、コンプライアンスと監査のニーズを満たしながら、環境の変更を理解するためのもう一つの重要な情報源です。誰が何をどこでなぜ変更したのかを追跡し、最終的にパフォーマンスに影響を与える変更を理解するのに役立ちます。コンプライアンスは非常に重要です - SOCコンプライアンス、HIPAAコンプライアンス、FedRAMPコンプライアンスを満たしているかを理解する必要があります。CloudTrailイベントはこれらの貴重な情報をすべて提供します。イベントの種類、スキーマ、環境でこれらのイベントを作成する方法について詳しく学べるリンクを共有しています。
3番目に紹介したいのは、Web Application Firewall（WAF）ログです。WAFログは、ネットワークに入ってくるトラフィックを理解し、トランザクション処理のためのインフラをより多く使用してコストを増加させるボットトラフィックなどの不要なトラフィックをブロックするために不可欠です。接続IPやユーザーエージェントに関する情報を含む、セキュリティイベントや潜在的な脅威をより良く理解するのに役立ちます。実装に関する2つのリンクを共有しています。その中には、Random Cut Forestを使用した異常検知で季節データとWebアプリケーションのパターンを理解し、トラフィックを削減してリソースを節約するための効果的なルールを確立するのに役立つOpenSearchブログも含まれています。
手を挙げていただきたいのですが、セキュリティまたは可観測性データにOpenSearchを使用している方はどのくらいいらっしゃいますか？何人かいらっしゃいますね、素晴らしいです。OpenSearchは、可観測性とセキュリティの両方のデータを分析するための強力な分析エンジンです。Piped Processing Language（PPL）というクエリ言語を使用し、コマンドを順次実行してデータから情報を抽出するための強力な検索機能を提供します。 しかし、これらすべてのデータを統合することは課題となります。複雑なパイプラインを管理し、データを統合する必要があり、これによりコストが増加します。エンジニアは、CloudTrail用のSQL、CloudWatch logs用のCloudWatch Logs Insightsクエリ言語、OpenSearch用のSQLまたはPPLなど、異なる言語を学ぶ必要があります。エンジニアが複数のクエリ言語を学ぶのは困難で、AWSコンソール、Grafana、OpenSearchダッシュボードなど異なる可視化ツールを使用することになり、情報の相関関係を見出すのが難しい回転椅子アプローチが生まれてしまいます。
分析機能を統合し、多様なデータソースのクエリを簡素化することで、ログをOpenSearchに抽出・変換する必要性をなくし、データの重複を避けることでコストを効果的に削減できるようになったことを発表できることを嬉しく思います。 このソリューションは、異なる方法や異なるクエリ言語でデータを使用したいチームを支援しながら、すべてを1つの領域に統合するのに役立ちます。 Amazon OpenSearch Serviceから直接、左側のメニューをクリックしてCloudWatchを含む新しいデータソースを追加することができます。
このデータソースのセクションでは、CloudWatchを選択することができます。すべてのVendedログをCloudWatchに集約したい場合や、すでにCloudWatchにログがある場合、それらを移動することなくすべてのログを確認できます。権限設定のための手順を完了し、完了をクリックすれば、OpenSearchで直接クエリを実行できるようになります。
さらに、VPC Flow Logs、CloudTrailイベント、WAFログなど、上記で言及したログの一部については、すぐに使えるダッシュボードを提供しています。これにより、環境内のボトルネックや問題の原因を理解する上で、即座に価値を得ることができます。次はポータビリティについてです。
最近の顧客との会話で、あるエンジニアが私にこう言いました。「オープンソースは大好きですが、オープンソースのObservabilityツールは積み木のようなもので、必要な価値を得るために多くの手作業が必要です。」Codyが、これらのオープンソースツールで起きていることについて、いくつか例を共有してくれたと思います。これは事実かもしれません。何を収集する必要があるのか、どのように収集するのか、何をモニタリングする必要があるのか、どのようなアラームを設定すべきか、さまざまなコンピュート環境で常に変化するワークロードを監視するための適切なシグナルは何か、といったことすべてが関係してきます。さらに、CI/CDパイプラインを使用して統合しながらこれをどのようにデプロイするのか、そして最終的に、これをすべてのAWSアカウントと異なるコンピュート環境で一貫させる方法という課題もあります。
私たちは、30以上のプリビルトソリューションを備えたObservable Solutions Catalogのサポートを開始したことを発表できることを嬉しく思います。これらのソリューションは、データ収集のための明確なテレメトリシグナルを提供し、サードパーティソリューションやAWSサービス向けのデフォルトのダッシュボードとアラームを提供します。これは、簡単に始められるObservableソリューションの基盤セットです。私たちがこれらのアプリケーションをどのようにモニタリングしているかを学び、EKSとEC2の両方で必要に応じてカスタマイズすることができます。これらのソリューションはInfrastructure as Codeとして提供され、CI/CDプロセスの一部として簡単に統合できます。現在、これを実現するためにCDKまたはTerraformを使用しており、コンソール内から直接開始できます。
CloudWatchコンソールの左側に、テレメトリ設定があります。そこから、Observable Solutionsの探索をクリックすると、コンソール内で直接デプロイできる30以上の異なるObservableソリューションのリストが表示されます。Amazon Elastic Kubernetes Service（EKS）から始めましょう。EKSでは、マネージドオープンソースサービスであるPrometheusとGrafanaにデプロイしたいと思います。これをクリックすると、CDKまたはTerraformを使用して既存のEKSクラスターにアプリケーションをデプロイし、既存のPrometheusワークスペースとGrafanaワークスペースを活用して、自動的に収集された情報を可視化する方法についての段階的な手順が表示されます。
これにより、Rodrigueが説明していたAMP Collectorもデプロイされます。これは、メトリクスを収集するために必要なCollectorの数を自動的に発見してスケールする収集機能です。EKSクラスター内のパフォーマンスや健全性、ログを監視するための11個ほどの異なるDashboardが表示されることになります。Dashboardをクリックすると、パフォーマンス、CPU、メモリ、そしてインフラストラクチャクラスターのパフォーマンスすべてを自動的に可視化できます。オープンソースから学んだり、自分で理解したりする必要はありません。私たちが可視性と、意見が込められたObservabilityソリューションを提供します。
AIの機能について触れないセッションは完璧とは言えません。先ほど異常検知について説明し、OpenSearchでサポートされている機能である異常検知の詳細を学べるブログをご紹介しました。また、OpenSearchへのAIアシスタンスとAIを活用したNatural Language Queryのサポートも発表しました。OpenSearchでAI搭載の検索アプリケーションをデプロイすると、必要なセットアップとモデルを自動化するための事前定義されたテンプレートが提供され、Amazon BedrockやOpenAIなどのAPIとのConnectorが統合されており、Semantic Searchなどの独自のアプリケーションを構築できます。OpenSearchアシスタントは、分析しているデータの種類に基づいて適切な可視化を推奨することができます。Natural Language Queryは、SQLやPPLの専門家ではないエンジニアが、より早く始められるようにも役立ちます。単に「最も多く発生しているエラーは何ですか？」と普通の英語で尋ねるだけで、PPLを生成し、クエリを実行して、探している結果を表示してくれます。OpenSearchで利用可能なAI機能をすぐに活用でき、今週さらに多くの発表が予定されています。
AWSのオープンソースへの貢献とマネージドサービスの総括
5年前、私がこの旅を始めたとき、オープンソースコミュニティから学び、コラボレーションを通じて還元したいと考えてこれらのオープンソースプロジェクトに取り組みました。2021年、AWSとオープンソースコミュニティはOpenSearchを作り出しました。このプロジェクトは7億回以上のダウンロード数を記録し、活気あるコミュニティであることを示しています。私たちは23以上のリリースに貢献し、9月にはAWSがOpenSearchをオープンソースプロジェクトの信頼できる拠点である非営利組織のLinux Foundationに移管しました。OpenSearch Foundationは、AWS、SAP、Uber、Atlassianなど、多くの企業とパートナーシップを結んでいます。
オープンソースへの同様のコミットメントは、私のチームが大きく貢献している他のプロジェクト、具体的にはCortex、Prometheus、Thanos、OpenTelemetryなどのPrometheus関連プロジェクトにも及んでいます。オープンソースコミュニティへの貢献に興味がある方や、これらのツールの使い方を学びたい方は、このセッション後に声をかけてください。まとめると、私たちは3つのマネージドサービスについて説明しました：高カーディナリティメトリクス向けのAmazon Managed Service for Prometheus、豊富なデータ可視化のためのAmazon Managed Grafana、そしてログとトレースにわたる強力な分析のためのAmazon OpenSearch Serviceです。
私たちは、SOCコンプライアンス、FedRAMPコンプライアンス、その他のコンプライアンス要件に関してアプリケーションが準拠していることを確保し、Identity Access Managementとの統合を通じてセキュリティを提供し、エンジニアの適切な認証と認可を確保します。運用オーバーヘッドについては、アクティブなタイムシリーズメトリクスの数やデータ取り込み量に関わらず、需要に応じたスケーリングという差別化されていない重労働を私たちが担当します。CloudFormation CDKを使用してこれらのリソースを直接プロビジョニングすることをより簡単にし、Observable SolutionsやZero ETLなどの機能により、データを移動する必要がなくなり、これらのソリューションからより早く価値を得られるようにし続けます。
最も重要なのは、24時間365日のサポートを提供していることです。そのため、これらのソリューションをサポートするためにPagerを持ち歩く必要はもうありません。何か問題が発生した場合、Personal Health DashboardsやService Health Dashboardsを通じて、サービスの劣化を事前に通知し、サービスで何が起きているのかを理解できるようにします。その結果、テーブルの組み立てを終わらせるなど、個人的な作業により多くの時間を使えるようになります。 オープンソースサービスを始めたばかりの方は、Workshopやドキュメント、Labs、Skill Buildersをご確認ください。始めるための有益な情報が豊富に用意されています。CloudOpsブースにお立ち寄りいただければ、専門家が皆様のご質問にお答えします。また、スワッグもお忘れなく。モバイルアンケートにもぜひご回答ください。質問も大歓迎です。私たちは会場フロアにおりますので、ぜひお越しください。ご参加ありがとうございました。
※ こちらの記事は Amazon Bedrock を利用することで全て自動で作成しています。
※ 生成AI記事によるインターネット汚染の懸念を踏まえ、本記事ではセッション動画を情報量をほぼ変化させずに文字と画像に変換することで、できるだけオリジナルコンテンツそのものの価値を維持しつつ、多言語でのAccessibilityやGooglabilityを高められればと考えています。
Discussion