re:Invent 2025: Warner Bros Discoveryのオープンソースオブザーバビリティスタック大規模運用事例
はじめに
海外の様々な講演を日本語記事に書き起こすことで、隠れた良質な情報をもっと身近なものに。そんなコンセプトで進める本企画で今回取り上げるプレゼンテーションはこちら！
re:Invent 2025 の書き起こし記事については、こちらの Spreadsheet に情報をまとめています。合わせてご確認ください
📖 re:Invent 2025: AWS re:Invent 2025 - Scaling open source observability stack feat. Warner Bros Discovery (COP333)
この動画では、Warner Bros DiscoveryのオブザーバビリティジャーニーとAWSのマネージドオープンソースサービスを活用した大規模運用のベストプラクティスが紹介されています。1億2,800万人以上の加入者を支える同社は、operational metadataによるデータ整理、統一されたログスキーマ(OWL)の導入、geo-shardingと論理的パーティショニングによるスケーリング戦略を実装しました。ProxyやOpenSearchのクロスクラスタサーチによる抽象化レイヤーにより、バックエンドの複雑性を隠蔽し、カスタムコストメータリングフレームワークで財務的な透明性を確保しています。Amazon Managed Service for PrometheusとAmazon OpenSearch Serviceを活用し、サンプリング、バッチ処理、recording rulesなどの最適化手法により、MTTRの削減と運用効率の向上を実現した事例が詳しく解説されています。
※ こちらは既存の講演の内容を最大限維持しつつ自動生成した記事になります。誤字脱字や誤った内容が記載される可能性がありますのでご留意下さい。
本編
COP333セッション開始：大規模システムにおけるオブザーバビリティの重要性
おはようございます。皆さんにお願いがあります。ヘッドセットを装着していただいて、親指を立てていただけますか？そうしたら準備完了です。ありがとうございます。COP333へようこそ。「Scaling Open Source Observability Stack featuring Warner Bros Discovery」というセッションです。私の名前は Vikram Venkataraman で、AWS のプリンシパルソリューションズアーキテクトです。大規模に AWS を運用している戦略的なお客様とお仕事をしています。本日は、AWS のプリンシパルプロダクトマネージャーの Abhi Khanna と、Warner Bros Discovery のディレクターの Hans Robert と一緒にお話しします。
シーンを設定してみましょう。皆さんが大好きな OTT ショーのシーズンフィナーレの夜だと想像してください。皆さんと何百万人ものユーザーがこのショーを見るのを待っています。再生ボタンを同時に押すと、あの厄介な回転する円が出てきて、ずっと回り続けるだけです。一方、プロバイダーは考えています。自分たちのプラットフォームに何か問題があるのか？認証システムなのか？決済システムなのか？それとも両方なのか？残念ながら、それが大規模なシステムを運用する現状です。何十万ものマイクロサービスが様々なコンピュートプラットフォーム上で実行されている場合、課題はメトリクス、ログ、トレースを収集することではありません。これらのメトリクス、ログ、トレースの上に洞察を得ることが全てです。それが正に最新のオブザーバビリティが私たちを助けることができる場所です。単なる監視ツールではなく、問題がどこにあるのか、根本原因は何だったのか、そしてどのように修正できるのかを特定するのに役立ちます。それが本日のセッションの焦点になります。
数分後に、Hans がステージに上がってきます。彼は、Warner Bros Discovery がこれらのメトリクス、ログ、トレースから大規模に洞察を得て、運用上の問題を特定し、改善するまでの平均時間を短縮することができた方法についてお話しします。アジェンダについてですが、まずオブザーバビリティの進化からスタートします。ここではメトリクス、ログ、トレースというオブザーバビリティの基本要素を理解しようとします。その後、これらのシグナルを信頼性が高く耐久性のある方法で保存するのに役立つ、マネージドなオープンソースサービスについて深掘りします。その後、Hans に Hans Robert にバトンを渡して、Warner Bros Discovery の AWS へのオブザーバビリティジャーニーについてお話しいただきます。そして、これらのオブザーバビリティツールを大規模に運用するためのベストプラクティスでセッションを締めくくります。
手を挙げてもらえますか。皆さんの環境で 50 個以上の監視ダッシュボードを運用している人はどのくらいいますか？100 個以上のダッシュボードがある場合は、手を挙げたままにしてください。500 個？1,000 個？わあ、ダッシュボードが多すぎるとそれが課題になります。これらのダッシュボードから洞察を相関させるのは、そう簡単ではありません。このセッションから何か学べることがあれば、皆さんの環境でこれらのベストプラクティスの一部を適用できるといいですね。
堅牢なオブザーバビリティスタックを持つことの重要性を本当に強調したいです。これらの例を見てください。e コマースプラットフォーム、ヘルスケアプロバイダー、商業銀行。彼らは皆、良いオブザーバビリティスタックを持っていなかったため、目隠しをされた状態で飛んでいて、問題がどこにあるのかを特定して問題を修正するのに何時間もかかったため、莫大な経済的損失を被りました。私たちの CTO が言うように、すべてのものは常に失敗しますが、もし皆さんがこれらの失敗に対してアプリケーションをエンジニアリングするなら、つまり適切な KPI を導入して、これらのテレメトリシグナルを相関させる能力を持つなら、それが皆さんを平穏な状態に置くことになります。
オブザーバビリティの3つの基本要素とレイヤー化されたアプローチ
observability の基本的なブロックについて理解しましょう。metrics、logs、traces です。 Logs というのは、簡単に言うと、人間が日記に日々のことを記録するのと同じようなものです。タイムスタンプと、イベントの詳細な説明が含まれています。基本的にはそれだけです。一方、metrics は、アプリケーションの脈動を見る能力を与えてくれます。私のアプリケーションは速く動いているのか、それとも遅いのか。4XX エラーはいくつあるのか、5XX エラーはいくつあるのか。これによって、アプリケーション内の特定のコンポーネントを深く掘り下げるのに役立ちます。Traces は、複雑なマイクロサービスアーキテクチャを通じて、エンドユーザーのリクエストがどのように流れるかをキャプチャする能力を与えてくれます。例えば、e-commerce ウェブサイトで何かを注文してから、その商品が配送されるまでの全てをキャプチャします。全てを捉えるわけです。
しかし、このトークは metrics、logs、traces を収集することについてではありません。 これは、運用上の問題を特定して解決するまでの平均時間をどのように短縮できるかについてです。私たちはこれをオンコール エンジニアの視点から考えました。 オンコール エンジニアや SRE の方はいますか。はい、ありがとうございます。皆さんの視点からすると、ある朝早く目が覚めたら、対応を待っているアラートが何千個もあることに気づきます。問題の根本原因にたどり着くために、50,000 個の時系列 metrics と 2 petabytes のログを調べなければならないかもしれません。そして、既に時間との競争をしていることを忘れないでください。5 分で済む修正に 5 時間もトラブルシューティングに費やすことになると、
これはモニタリングの危機やモニタリングの課題ではありません。課題は、これら全てのテレメトリ信号を相関させることです。私たちはこれについて考えて、レイヤー化されたアプローチを考え出しました。最初のレイヤーは、何かから始めることについてです。すぐに使える monitoring を使用してください。ページ アラート、ダウン アラート、100% CPU 使用率アラートが出ます。これがスタート地点になります。特定のアプリケーションが影響を受けていることを教えてくれます。そして、2 番目のレイヤーに深く掘り下げます。
その特定のアプリケーションのログを取得して、何が起きているのかを見てください。もしかしたら、たくさんの 5XX エラーが出ているかもしれません。ログを深く掘り下げて、5XX エラーの根本原因が何であるかを理解しましょう。その後、3 番目のレイヤーが来ます。ここで、trace 情報でこの情報を強化します。 多くの場合、その特定のアプリケーションが根本原因ではありません。例えば、ダウン アラートが出たとします。それはそのアプリケーションに関連していないかもしれませんが、依存するサービスに関連しているかもしれません。これはまさに trace が役に立つ場面です。私が話している 5XX エラーは、バックエンド データベースの障害の結果かもしれません。trace はその情報を特定するのに役立ちます。なぜなら、複雑なマイクロサービスアーキテクチャを構成する各マイクロサービスで、各リクエストが費やした時間を教えてくれるからです。
最後に、重要な部分である相関させる部分が来ます。 これはまさに、何らかのメタデータを注入する必要がある場所です。そうすることで、問題をトラブルシューティングするときに、metrics、logs、traces から全ての情報を相関させることができ、直面している可能性のある根本原因を特定することができます。これは AI を使用できる領域でもあります。AI は、すぐに使える状態で、テレメトリ信号から全ての情報を引き出し、直面しているかもしれない根本原因へと導くことができます。では、ここで Abhi Khanna にバトンを渡して、これらの信号を確実に保存するのに役立つ、私たちのマネージド オープンソース サービスについて話してもらいます。
AWSのマネージドオープンソースサービス：Prometheus、Grafana、OpenSearch
本当にありがとうございます、Vikram。AWS では、様々な異なるオープンソースの可観測性ツールを一緒に構築してきました。収集の観点からは、OpenTelemetry と Prometheus メトリクス用のマネージドコレクターをサポートしています。取り込み、ストレージ、分析の観点からは、Prometheus メトリクス用の Amazon Managed Service for Prometheus と、ログとトレース用の Amazon OpenSearch Service を備えており、Amazon Managed Grafana と OpenSearch Dashboards にまたがる様々な可視化機能を備えて、すべてを統合しています。
多くのお客様が、オープンソースを好むとおっしゃっています。ですから、私たちはよくその理由を尋ねるのですが、共感を呼ぶのは、オープンスタンダードのサポート、ベンダーロックインのない戦略を持つことができること、コミュニティが提供する最高のものを手に入れることができること、実行しているものについて透明性と制御を得ることができること、そしてもちろん、必要に応じて調整して、可観測性プラットフォームのコスト効率を得ることができることです。
しかし残念ながら、単に Helm install を実行して、本番環境スタックに導入して、すぐに使用開始できるほど簡単ではありません。スケーリングしません。信頼性がありません。複数のチームが同時に使用する場合、オーバーロードされる傾向があります。これらすべてが摩擦を生み出します。リソース管理とキャパシティプランニングの問題に対処する必要があり、高可用性の問題、テナンシー制御と分離、管理、パッチ適用、アップグレードする必要があるサーバーの膨大な数に対処する必要があります。
そしてもちろん、これらのシステムをすべて監視して、チームが実際のアプリケーションを監視するために使用できるように、稼働し続けていることを確認する必要があります。これらすべてが運用上のオーバーヘッドを追加し、これらのオープンソーステクノロジーを活用してこれらの問題を解決するのに支障をきたします。
AWS では、マネージドオープンソースソリューションをどのように提供するかを検討してきました。まず、すべてのピースを一緒に組み立てる必要がないように、エンドツーエンドでどのように提供するかを検討しています。メトリクス、ログ、トレース全体で相関を直接製品体験を通じて相関させることができるように、相関を組み込む方法。コスト要素への可視性があり、コスト効率を調整するために使用できるコスト制御があることを確認する方法。そして、AWS が必要とするエンタープライズワークロードをシームレスにサポートするスケールで、IAM、CloudFormation、CloudTrail などの他のすべての AWS テクノロジーと統合された AWS の保証でセキュリティを提供する方法。そしてもちろん、私たちが行うすべての改善について、コミュニティに還元していることを確認し、それらのコミュニティが繁栄し、スケーリングと可用性に関して同じメリットを得られるようにしています。
マネージドサービスの詳細とデプロイメント戦略
念のため、Amazon Managed Service for Prometheus についてざっと説明しておきますね。これは高可用性でセキュアなマネージド型のメトリクスサービスです。サーバーレスで、Prometheus と完全互換性があり、オープンソースの Prometheus データモデルとクエリ言語に対応しています。すべて従量課金制で、もちろんあらゆる環境、あらゆるスケールに対応しています。昨年、ワークスペースあたり 10 億個のアクティブな時系列データへの対応をリリースしました。ワークスペースはいくつでも作成できるので、1 つのシステムで数十億のメトリクスを保存・分析することができます。
もちろん Amazon Managed Grafana もあります。これはオープンソースの Grafana プロジェクト向けのマネージド型サービスで、さまざまなデータソースから データを取得して、美しいダッシュボードを構築できます。いわゆる単一の管理画面という感じですね。
そして最後に OpenSearch Service があります。これはログとトレースデータ全体にわたってリアルタイムの検索と分析機能を提供します。完全にマネージドされており、AWS 標準のセキュリティに対応し、ログ分析と可観測性のユースケースに組み込まれた機能で対応し、AWS エコシステムと深く統合されています。
これらをすべて組み合わせると、OpenTelemetry を使ってログ、メトリクス、トレースを収集し、メトリクスを Amazon Managed Service for Prometheus に保存し、ログとトレースを OpenSearch に保存して、Grafana と OpenSearch のダッシュボード全体で可視化できるようになります。AWS エコシステムのどこからこのデータを収集しているかに関わらず、データを取得し、収集し、精製し、適切に取り込み、これらのシステムで分析し、選択した可視化レイヤーですべてをまとめることができるようになります。これにより、単一の管理画面ビューを作成できるわけです。
お客様はこれを 2 つの異なるモードでデプロイしています。1 つは集約型モードで、すべてのリージョンとアカウント全体から、すべてのデータを 1 つの中央の場所にある中央オープンソース可観測性スタックに集約します。これにより、AWS フットプリント全体でアプリケーションを実行しているすべての異なる場所の統合ビューを 1 つの場所で得ることができます。別のお客様は、より地理的にローカルな戦略を採用しており、リージョンごとに 1 つのスタックを持ち、そのリージョン内のすべてのアカウント全体で集約し、その後、共通の可視化レイヤーを使用してすべてを最後に結び付けています。
では、Warner Bros. Discovery のストーリーについて話すために Hans にバトンタッチします。AWS が私たちに提供してくれた素晴らしいツールと製品について聞きました。これらのツールはかつてないほど強力になっていますが、それでもツールにはスケーリングの観点での限界があります。エンタープライズレベルで本当に成功するには、スケーリング戦略が必要です。それが今日お話ししたいことです。
Warner Bros. Discoveryのオブザーバビリティジャーニー：課題とオープンソース採用の理由
皆さん、おはようございます。私は Warner Bros. Discovery の Director of Observability の Hans Robert です。 Warner Bros. Discovery は、本質的にはストーリーテラーの企業です。私たちは視聴者を強力なストーリーとナラティブに結びつけ、CNN、Food Network、HBO、TNT などの象徴的なブランドの本拠地です。 私たちは非常に複雑なエコシステムを運営しており、それはストリーミングの世界、つまり HBO Max と Discovery Plus で結晶化しています。100 以上の市場で 1 億 2,800 万人以上の加入者をサポートしており、すべて 1 つのマルチテナントプラットフォーム上で運営しています。毎日収集するログ、メトリクス、トレースの量は非常に膨大です。
私たちにとって、これらのログ、メトリクス、トレースを収集することは、単に私たちがやらなければならないことではなく、本当に運用上の必須事項であり、保持の必須要件です。今日は、Abby が話していた observability プラットフォームをスケーリングするために私たちが使用した学習と戦略の一部を共有し、実際にそのエンタープライズの課題に対応し、これらの数字にスケーリングする方法についてお話しします。
数年前、Discovery と Warner Brothers の合併直後に始めたとき、複数の異なる observability ソリューションを持つという古典的なテクノロジー合併の課題に直面していました。 異なるチームが異なるツールを使用し、異なるデータを見ていたため、トラブルシューティングと問題の特定が非常に遅くなっていました。 また、データの標準化の欠如に悩まされていました。一貫性のないデータ形式とタクソノミーにより、チーム全体で洞察を相関させることが複雑な問題になっていました。そして最後に、今日お話しすることにとって最も重要なことですが、これはスケーリングの課題に悪影響を与え、あらゆるイベント、トラフィックスパイク、または加入者の成長に対応することが、解決する必要がある頭痛の種になっていました。
このレガシー状態は非効率で持続不可能でした。MTTI を削減し、インシデントをできるだけ早く解決したいという私たちの希望とは相性が悪かったのです。そこで、Abby が話していたオープンソーステクノロジーに基づいた、まったく新しいプラットフォームを構築しました。 戦略について話す前に、オープンソースについて、そしてなぜオープンソースなのかについて少し話したいと思います。
Abby がいくつかの理由を挙げてくれましたが、私はそのいくつかについてさらに掘り下げたいと思います。まず第一に、私たちが「一方通行のドア」と呼ぶものを避けたかったのです。つまり、時間が経って新しいニーズが生じた時に、非常に難しい決定や選択肢、あるいは特定のプロプライエタリなベンダー技術やストラテジーにロックインされることを避けたかったのです。第二に、私たちは意見を持ったプラットフォームを構築したかったのです。つまり、プラットフォーム内に多くのガードレールとゴールデンパスウェイを直接構築するということです。ガードレールはユーザーのミスやエラー、そしてプラットフォームに問題を引き起こすようなデータスパイクを防ぐためにあります。ゴールデンパスウェイは、チームとエンジニアがプラットフォームにオンボードし、observability プラットフォームを最大限に活用するのを支援するためにあります。
そして最後に、コストの観点からおそらく最も重要なのは、私たちのデータとパイプラインに対する完全なコントロールを持ちたかったということです。データパイプラインとデータ保持、ストレージの観点から、私たちはデータをいつ、どのように収集し、どこに保存するのかを正確に把握したかったのです。では、今日私たちが持っているプラットフォームにスケールさせることができた戦略についていくつか話しましょう。 私たちにとって非常に重要な三つの異なることについて話します。データの整理、共有を通じたシステムの適用と最適化、そして最後にコスト監視と私たちがコストをどのように管理しているかです。今日の私の目標は、どの業界にいるかに関わらず、あなたの業界に適用できる戦略をいくつか提供することです。これはビデオストリーミングに特有のものではなく、私たちがスケールアップするのに成功したのと全く同じ方法で、あなたも適用して活用できるはずです。
データ整理戦略：Operational MetadataとOWLスキーマの導入
では、データの整理と、情報の混沌とした量をどのように整理することで制御してきたかについて始めましょう。いくつかのことに触れますが、 まず最初に、業界の決まり文句は「データは新しい石油だ」ということですが、率直に言って、私の慎重な見方では、大規模なデータは整理されていない限り、本質的に混沌としています。今日、私たちはデータをどのように整理するかについて、二つの柱に焦点を当てています。まず第一に、operational metadata、略して OMD を確立して、私たちのデータフローをタグ付けして追跡することです。そして第二に、ログとトレースの両方にわたって統一されたイベントスキーマを実装することです。
Operational metadata は observability に特有の戦略ではありませんが、後で見るように、私たちがシャードしてスケールするために行ってきた多くのことの基礎となっています。 あなたがそれをしっかり理解できるようにしたいと思います。私たちは、私たちが持っているすべてのアプリケーションとインフラストラクチャのために、ストリーミングエコシステムの機能的階層を確立したかったのです。画面に表示されているのは、ビジネスサービスが最上位にある、システムの単純な三層階層です。この場合、ビデオ再生のようなビジネスサービスは、高レベルのビジネス機能を表しています。その下に、私たちは OMD サービス、例えば markers のような、その機能内の論理的な機能を持っています。そして最後のもの、OMD コンポーネントは、その機能内の特定の機能を実装する最終的なマイクロサービスです。ちなみに、markers は、あなたがストリーミングの選択肢をどのように視聴してきたかを追跡する方法です。つまり、一時停止して後で再開したい場合、私たちはあなたがどこにいたかを知っています。
この階層を確立するために、私たちは本当にそのデータの作成と収集を分散させる必要がありました。私たちはそれを、エンジニアが標準ファイル形式でそのすべての情報を GitHub に彼らのコードと一緒に入れることで解決しました。 私たちはデータ品質を強制するための自動チェックを実装しました。その上に、私たちは本質的にすべてのデータをスクレイピングして、 それを収集して Amazon Aurora に保存しています。その上に、私たちはグラフとダッシュボードを構築しました。それは Service Catalog と呼ばれ、私たちのシステム全体のトポロジーを提供します。これはすべて、単一の情報源を提供しています。つまり、私たちのプラットフォーム全体の運用的および機能的なマップです。つまり、アプリケーションプラットフォームとストリーミングプラットフォームです。しかし、後で見るように、これは observability にとって大きな関連性があります。
では、operational metadata が確立されたので、 2 番目の重要な目標は、本当に observability データをすべてマップすることでした。
ログであれ、traces であれ、metrics であれ、それらをすべてこの functional hierarchy にマップする必要がありました。ここに、business service、service、component タグを適用したログの例があります。video playback、markers、collectors ですね。そのデータは今、タグ付けされて整理されています。
このタグ付けをスケールさせるには、automation が不可欠でした。私たちは collector レベルで standardization を強制するソリューションを設計しました。Communities cluster では、 ログを収集するために Fluent D を実行しています。Fluent D と一緒に、add-in があって、Fluent D からの incoming data に自動的にタグを付けます。 node レベルで収集された情報を使ってタグ付けするのですが、それには business service、service、components が含まれています。このタグ付けされたすべての情報を observability account に送信するメッセージに直接付けることで、データがどこから来ているのか、どこに属しているのか、何に関連しているのかを正確に知ることができます。
metrics と traces についても非常に似たようなことをしているので、すべての metrics には operational metadata の business service、service、component が付いていますし、同様に traces にも同じものが付いています。この automation により、volume がどうであれ、observability account に向かうすべてのデータが正しくタグ付けされることが保証されます。これはスケーリングにとって重要であり、すぐに説明する sharding strategy と cost metering strategies の基本となっています。
その前に、 データを整理するための他の側面、特に logs や traces のようなイベントデータについて話したいと思います。強い event schema や standard を確立しなければ、すべての service と component、つまり会社内のすべてのチームまたは developer が独立して動作します。これは通常、schema drift につながります。client identifier のような単純なエンティティでさえ、複数の異なる方法で表現されることがあります。client underscore ID、client dash ID、CL ID など。これは単なる semantic な問題ではなく、operational blocker なのです。
異なるidentifierを持つデータを簡単かつ効率的に結合することができません。さらに、それはindexingとcross-service correlationに大きな影響を与え、そのデータを保存するコストと query complexityを大幅に増加させます。schema proliferationを解決することは、observability platformのスケーリングを実現するために重要でした。私たちはorganization-wide logging schemaを導入しました。これを短縮してOWLと呼んでいます。 OWLはmandatory core log schemaの上に構築されているため、すべてのログは、どのような場合でも、timestampやseverityのような交渉の余地のないフィールドを持っています。 そして、先ほど述べたmessageやoperational metadataフィールドのようなその他のものもあります。
その上に、business service aligned schemasを持つことができます。 これは各business serviceに関連するより詳細なものを定義します。payment log schemaの場合、payment method typeやpayment referencesを追加したいかもしれません。video playbackの場合、video IDやstream IDを追加するかもしれません。core log schemasとbusiness schemasはその後、マージされ、 OpenSearch indexに注入される特定のbusiness-oriented schemaになります。今、私たちは 非常に専用のschemaを持っていますが、core schemaから発生する共通フィールドを備えています。
このenforced mappingにより、schemaの一部として定義されていないものをingestしようとするイベントがある場合、そのフィールドを拒否することができます。メッセージを拒否することも、関連性のないフィールドだけを拒否することも、またはそれをS3に保存してさらにレビューすることもできます。その後、ログの作成者に通知を送信して、それを修正して再度試すよう指示することができます。変わったことの1つは、文化と会話の一部です。ログがschemaの境界外に出た場合、いくつかのイベントが拒否される可能性があることを知ることで、人々は何をいつログするかについてより慎重に考えるようになり、潜在的には、単にdata swampに物を詰め込むのではなく、observability platformに情報を送信するより意図的な方法を持つようになりました。
operational metadataと私たちのschemaを組み合わせることで、 私たちはいくつかの重要な成果を達成しました。reduced MTTRは本当にdata qualityから来ていますが、またdata standardizationと異なるservicesとmicroservicesを一緒に接続する能力からも来ています。Intentional consumptionは、人々が今、observability telemetryの数を無限に増やすのではなく、何をログするか、どのmetricsをログするかについて二度考えるようになったことを意味します。最後に、それはscaleのための強固な基盤であり、shardingを構築するためにoperational metadata自体をどのように使用するか、また cost meteringについても見ることになります。
シャーディング戦略：ジオロケーションと論理パーティショニングによるスケーリング
これがshardingに至ります。 私たちはgeolocation approachを採用しました。これについては後ほど説明しますが、また、何も非常に大規模にならないという点に到達するために必要だったlogical partitioningについても説明します。また、shardsが引き起こす問題のため、shardsを抽象化する必要があります。100以上のmarketsを9つのregionsでグローバルに提供するために、私たちのbusiness applicationsはそれらの9つのregions全体に分散しており、ほとんどのcomponentsとcomputersはEKSで実行されており、CloudWatchによって監視されているdatabaseやstorageのようなservicesのサポートキャストがあります。
まずログを見てみると、 Fluent D が EKS のポッドから直接ログを収集して、そのデータを、データが発生したのと同じリージョンにある regional OpenSearch に転送しています。これを世界中のすべてのリージョンで複製しています。 メトリクスも非常に似たようなパスをたどっています。Grafana Agent を使用して各ポッドから EKS メトリクスを直接スクレイプして、その後、同じリージョンに存在する Amazon Managed Service for Prometheus ワークスペースに送信しています。最後に、Amazon CloudWatch とのギャップを埋めるために、 YACE、Yet Another CloudWatch Exporter を活用して、CloudWatch からデータを抽出し、同じリージョンの同じ Amazon Managed Service for Prometheus に転送しているので、インフラストラクチャとアプリケーション間の相関関係を追加することができ、これにより単一のペイン・オブ・グラスに向けて一歩前進することができます。
Geo-sharding は物理的な場所を処理し、既にある程度のシャーディングを提供していますが、そのリージョン内で何も大きくなりすぎないように論理的に整理する戦略も必要です。 例えば、Prometheus で 11 億のメトリクスが必要で、それが 10 億になった場合、1 つ以上が必要になります。メトリクスの場合、 Grafana Agent は OMD ラベルを読み込んで、それを使用して決定を下します。すべてを同じ巨大なバックエンドに送信するのではなく、 ビジネスサービス、サービス、またはコンポーネントを活用してシャーディングを行い、最適な分散を実現しています。その後、ログとトレースに対しても全く同じロジックを適用します。この場合、Fluent D を活用して Firehose に転送し、最終的に OpenSearch の関連インデックスまたはインスタンスに転送され、本質的にはそのビジネスサービス、サービス、またはコンポーネントの関連する論理インデックス内に自動的にインデックスされます。
この戦略により、物事が大きくなりすぎるのを防ぐだけでなく、1 つのサービスまたは 1 つのコンポーネント、または 1 つのビジネスサービスが、同じエコシステム内に存在する別のサービスの隣人にノイズを与えたり、別のサービスの取り込みパフォーマンスに影響を与えるようなトラフィックスパイクを作成するのを防ぐことができます。リスクのあるコンポーネントまたは非常にスパイク性の高い性質のものについては、それら自身にのみ影響を与えることができるように、専用のシャードに分離する傾向があります。
シャードの制限について少し話しましたが、 シャードと私たちが探索したパーティショニングの主な問題は、Grafana が単に 1 つのクエリを実行することができなくなるということです。本当にバックエンドのシステムのトポロジーを深く理解して、データが属する場所からデータをクエリする必要があります。どのワークスペースが実際にデータを含んでいるのか、US East、Europe、またはビデオサービス用のものなのかを知ることは、管理するのが非常に複雑で難しいものにつながる可能性があります。
ログとトレースでも同じような摩擦があり、OpenSearch Dashboard も、その特定のメッセージをキャプチャし、そのメッセージを含む正確な OpenSearch クラスタに対応するために、そのトランザクションまたはログが どこから取り込まれたのかを知る必要があります。想像できるように、これは本当に実装するための実用的な方法ではありません。かなり急速に退屈になり、Vikram が話していた私たちが本当に目指している MTTR を遅くしてしまいます。
では、このケースでいくつかの抽象化を導入しました。メトリクスの最上部から始めると、Proxy という、データの前に位置するオープンソースの集約プロキシを導入しました。これは Grafana の観点からは Prometheus インスタンスとまったく同じに見えます。Proxy は 1 つの巨大なメトリクスワークスペースとして機能し、その内部では、シャードと同じように、クエリを自分が認識しているすべての異なるワークスペースに分散させます。すべてのデータシリーズを取得し、それらを再度まとめて、Grafana に返します。
Proxy を使用することで、Grafana は背後にいくつのワークスペースがあるのか、1 つなのか 70 個なのかを知る必要がない完全な抽象化を効果的に実現しました。ログとトレースについては、OpenSearch のネイティブなクロスクラスタサーチ機能を活用しました。これは Proxy が行っていることとほぼ同じことを行います。リクエストを背後にある異なる OpenSearch ワークスペースまたはクラスタに分散させ、それらを再度集約してから OpenSearch Dashboard に返します。
人々がクエリを書いたり、ダッシュボードを作成したり、アラートを構築したり、データの上に何らかの可視化を行ったりするのを簡単かつ効率的にしただけでなく、重要なことに、バックエンドのライフサイクル、つまりシャードの数とそれらがどこに存在するかについて再構築し、再設計する必要性を完全に切り離しました。フロントエンドの消費に影響を与えることなく、すべてを変更することができます。このアーキテクチャで 3 つのワークスペースで書かれたダッシュボードは、明日 2 つのワークスペースで、または 3 つ、5 つのワークスペースでスケールするときに機能します。なぜなら、それは依然として同じ Proxy インスタンスと通信しているからです。同じことが OpenSearch Dashboard にも当てはまります。これは、フェデレーションを行う 1 つのクロスクラスタサーチインスタンスのみを認識しています。
まとめると、ジオシャーディング、論理的パーティショニング、そして私たちが構築した抽象化のこの組み合わせにより、非常に柔軟でスケーラブルなアーキテクチャが実現しました。事実上、プラットフォームを将来に対応させることができました。ビジネスが明日新しいリージョンでの展開を決定した場合、または特定のサービスがトラフィックの 10 倍の増加を予想している場合、または大量のログとメトリクスを生成する新しい機能がある場合、新しいシャードを追加するか、新しいクラスタを起動するだけで、かなり簡単にそれを行うことができます。Grafana と OpenSearch Dashboard を活用してそのデータを作成している SRE やエンジニアに何の支障も与えることなく。
コストメータリングフレームワークと大規模運用のベストプラクティス
次に、今回の最終的な戦略に移ります。コストメータリングです。画面のこの人物を認識していれば、このセクションが何についてのものかわかります。もし認識していなければ、彼は Succession の Roy Logan で、HBO で見ることを強くお勧めする番組です。でも、それでもその人が誰かわからなければ、あなたの会社の CFO または CEO だと考えることができます。そういった人たちは高カーディナリティやインデックスの断片化については気にしません。彼らが気にするのは収支です。スケールで生き残るためには、何らかの財務的なショーバックまたはチャージバックを実装する必要がありました。
このアプローチにより、コストがどこから発生しているのかを理解でき、observability が AWS の請求書の中で最も高額な項目にならないようにすることができます。 AWS 内では、共有環境でのコスト配分に特有の課題があります。payment と video playback という 2 つのサービスがあると想像してください。どちらも logs と traces を 1 つの OpenSearch サービスバックエンドに送信しています。同様に、彼らはメトリクスを生成していますが、おそらくまったく異なるカーディナリティで、完全に異なる時系列の数を持っており、それらはすべて同じ AMP ワークスペースまたは AMP インスタンスに集約されます。
現在、AWS 内での標準的な戦略はインスタンスにタグを付けることです。 つまり、Cost Explorer に移動すれば、OpenSearch または Prometheus に費やした合計金額がわかりますが、実際にそのコストを生成しているのが誰なのかという詳細はわかりません。payment ですか？video playback ですか？どうやってそれを整理するのでしょうか？ このコスト配分のギャップを埋めるために、私たちはカスタムコストメータリングフレームワークを開発しました。
このフレームワークは本質的に 3 つの異なるタイプのデータを三角測量します。まず、コストです。これなしには生きていけません。AWS から抽出して analytics プラットフォームに保存します。 次に、OpenSearch サービスと AMP の使用状況を取得します。これは log gigabytes、traces の数、AMP の時系列の数といった特定のボリュームメトリクスを収集することで行います。その後、新しい時系列を生成して Prometheus に保存します。 3 番目に、チームが allocation rules を入力できるようにしており、ルールとそこにあるコストに基づいて、その金額をどのように分割し、数学的に分割するかを定義します。
reconciliation の魔法は、ここの Lambda の中で起こります。 これはトリガーで実行され、本質的にこれらすべてをマージして、両方のインスタンスについて収集したコストを数学的に分割し、「あなたはより多く使用しました、あなたはより多く支払います」というようなことを言います。その後、別の時系列を作成して Amazon Timestream に保存します。最後に、Grafana でダッシュボードを構築しました。各ビジネスサービス専用のダッシュボードがあり、observability プラットフォームに関連する特定のコストを非常によく把握しています。
この透明性と可視化に加えて、私たちは accountability フレームワークも構築しました。それが利用可能であるだけでは十分ではありません。その背後にも accountability が必要です。これは文化をかなり変えました。AWS の請求書がなぜこんなに高いのかという会話から、「私のチームがどのようにコストを効率的かつ適切に管理するのに貢献できるか」というより建設的な議論へと移行しました。
それでは、3つの戦略を実装したことで、ストリーミングの未来のためのプラットフォームを構築することに成功しました。 本日共有した戦略を実装することで、3つの強力な柱を確立しました。まず1つ目は、Amazon Managed Service for Prometheus や Amazon OpenSearch Service のようなマネージドサービスを活用した、スケーラブルなグローバル observability ソリューションです。 2つ目は、運用メタデータとスキーマを標準化することで、データを戦略的資産に変えました。 すべてのメトリクス、ログ、トレースが即座に価値があり、検索可能で、それらに依存するエンジニアから信頼されるものになっています。 3つ目は、インテリジェントな共有とコスト計測フレームワークを通じてスケーラビリティを実現し、サブスクライバーの成長に合わせてスケールし、新しいリージョンに拡張したり、トラフィックスパイクに対応できるインフラストラクチャを手に入れました。
もし皆さんの組織が同様の成長課題や問題に直面しているのであれば、これらの戦略を検討することを強くお勧めします。
セッションを終える前に、スケーラブルな observability プラットフォームの運用方法についてもう少し詳しくお話しいただく Vikram にバトンを渡したいと思います。ありがとうございました。では、スケール時の observability ツール運用のベストプラクティスを共有して締めくくりたいと思います。 これを2つのセクションに分けました。まず1つ目は、メトリクス、ログ、トレースといったテレメトリシグナルを収集するベストプラクティスについてお話しします。選択したコレクターを使用します。メトリクスとトレースには OpenTelemetry を、ログには Fluent Bit を使用します。また OpenSearch ingestion pipelines もありますので、これが最初のレッスン、つまり最初のベストプラクティスになります。そして2つ目は、これらのテレメトリシグナルを Amazon managed open source services に信頼性と耐久性を持って取り込む方法についてです。
サンプリングとバッチ処理から始めるのは当然のことです。多くの皆さんはすでにこれを実施しているかもしれません。サンプリングというのは、私たちが気にするデータの一定の割合だけを保持することで、これは膨大な量のトレースを扱う場合に非常に効果的です。バッチ処理では、バックエンドに取り込む前にシグナルをグループ化します。サンプリングとバッチ処理の両方に従うことで、バックエンドに過負荷をかけないようにするとともに、これらのテレメトリシグナルを取り込むことによるネットワークオーバーヘッド全体を削減することができます。
メトリクスに関しては、これらは高カーディナリティ情報です。ですから、どのラベルが皆さんにとって大きな価値を追加しないかもしれないと思ったら、不要なラベルをドロップすることをお勧めします。特に OpenTelemetry コレクターや Prometheus コレクター内にこの action config があります。非常にシンプルです。ラベルを指定して、単にそれをドロップするだけです。これにより、時系列メトリクスデータベースをより小さく保つことができ、また、コレクターからバックエンドのマネージドサービスへのネットワークトラフィックも改善されます。
私たちのコレクターの多くは、こうしたベストプラクティスを最初から備えています。例えば、圧縮はその一つです。OpenTelemetry は GZIP 圧縮をそのままサポートしているので、これを使ってテレメトリシグナルを送信前に圧縮することができます。また、テレメトリデータに必要なメタデータを追加することで、テレメトリデータを強化することもできます。例えば、デプロイメント設定、ポッド名、またはネームスペース名を追加することができます。これによってあなたが収集しているテレメトリシグナルがさらに充実します。
ログに関しては、バッファ使用量を監視して最適化する必要があります。デッドレターキューを設定する必要があります。そうすることで、リクエストの一部が失敗した場合、それらをドロップするのではなく、デッドレターキューに移動させて、後で再度確認したり、何が起きたのかをトラブルシューティングしたりできます。最後に、最も重要なのは、あなたの監視ツール自体を監視する必要があるということです。何らかのオートスケーリング戦略を設定する必要があります。OpenTelemetry はそのままで、監視する必要がある多くのメトリクスを提供してくれます。また、コレクターに十分なリソースが設定されていることを確認し、何らかのオートスケーリング戦略を用意していることを確認してください。
レッスン2は、これらのテレメトリシグナルを Amazon Managed Service for Prometheus と Amazon OpenSearch Service にどのようにしてより良く取り込むかについてです。繰り返しになりますが、これらはそのままで利用可能な機能です。複雑なクエリに関しては、recording rules を使用することを強くお勧めします。そうすることで、複雑なクエリを実行したり、Prometheus データベースに負荷をかけたりする必要がなくなります。代わりに、これらの recording rules はすべて定期的に計算され、別の時系列として変換されます。
Amazon Managed Service for Prometheus は、マルチテナント環境でのラベルベースのアクティブ時系列を発表しました。ミッションクリティカルでないアプリケーションとミッションクリティカルなアプリケーションが同じクラスター上で実行されている場合、特定のアプリケーションに対して使用したいアクティブ時系列の上限を指定することができます。ラベルでスコープを絞ることができるのです。ミッションクリティカルでない時系列については、20,000 時系列あれば十分です。ミッションクリティカルなものについては、1 百万時系列必要かもしれません。このようにラベルに基づいてスコープを絞ることができます。
クエリコントロールとクエリログを実装することは確実にできます。これにより、このクエリを実行するために何個のサンプルをトラバースすべきかを指定する能力が得られます。膨大な数のサンプルに対してクエリを実行したくはありませんが、使用できるサンプル数を指定することができます。
Amazon OpenSearch Service に関しては、まず最初にやらなければならないことはストレージ要件を計算することです。インデックスのオーバーヘッド、レプリカ、データフロー を考慮に入れて、適切なインスタンスタイプとストレージ要件を選択する必要があります。シャーディング戦略は絶対に必要です。一般的な経験則として、ヒープスペースの 1 ギガバイトあたり 25 個未満のシャードを持つことをお勧めします。インジェストフローとバッファリングを制御する必要があり、OpenSearch Ingestion パイプラインがそれを処理できます。
Amazon OpenSearch Service と一緒に OpenSearch Ingestion パイプラインを使用することをお勧めします。そうすることでログフローを制御できます。最後に、バルクリクエストと圧縮を最適化する必要があります。バルクリクエスト API を使用してログフローをバッチ処理し、バックエンド（Amazon OpenSearch Service）に送信する前に圧縮してください。
また、今年 AWS マネージドオープンソースサービスについて発表した最近のアナウンスメントをいくつかハイライトしたいと思います。これらの機能についてご質問がある場合は、廊下でお答えするのが大好きです。ベストプラクティスの議論の一部として、これらの重要なアナウンスメントのいくつかをカバーしました。本セッションにお立ち寄りいただき、ご参加いただきありがとうございました。
※ こちらの記事は Amazon Bedrock を利用し、元動画の情報をできる限り維持しつつ自動で作成しています。
Discussion