アグリゲーターアーキテクチャ

概要

観測可能性パイプラインワーカー (OPW) のアグリゲーターアーキテクチャは、データの集中処理とルーティングのためのスタンドアローンサービスとして観測可能性パイプラインワーカーをデプロイします。

観測可能性パイプラインワーカーを他のサービスのようにインフラストラクチャーにデプロイし、データをインターセプトして操作し、宛先に転送することができます。観測可能性パイプラインワーカーインスタンスはそれぞれ独立して動作するため、シンプルなロードバランサーでアーキテクチャを拡張することができます。

このガイドでは、新規の観測可能性パイプラインワーカーユーザーのために、推奨されるアグリゲーターアーキテクチャを説明します。具体的には、以下のトピックです。

• データの収集、処理、ルーティングを行うための観測可能性パイプラインワーカーの構成。
• インスタンスの最適化により、観測可能性パイプラインワーカーのアグリゲーターを水平方向にスケールさせることができるようになります。
• キャパシティプランニングのためのリソース容量を見積もるための出発点。
• 観測可能性パイプラインワーカーのスケーリング。
• 観測可能性パイプラインワーカー用のネットワークトポロジと構成の決定。
• 高耐久性と高可用性の実現。
• 観測可能性パイプラインワーカーを災害復旧の一環として活用する。
• 複数のアグリゲーター、パブリッシュサブスクライブシステム、およびグローバル集計をデプロイするための、その他の高度な構成。

要件

観測可能性パイプラインワーカーのインストール

インストールのドキュメントをご覧ください。

観測可能性パイプラインワーカーの構成

観測可能性パイプラインワーカー (OPW) を構成する場合、Datadog は以下の一般的なフローに従うことを推奨しています。

構成は様々ですが、以下の主要な目標に従うべきです。

データの収集

できるだけ多くのソースをインテグレーションして、観測可能性パイプラインワーカーアグリゲーターにデータを簡単に送信できるようにします。観測可能性パイプラインワーカーアグリゲーターには、数十のソースがあることも珍しくありません。セキュリティと耐久性の要件をサポートする限り、ソースコンポーネントを構成します。これにより、社内のユーザーがレガシーサービスを使用している場合でも、観測可能性パイプラインワーカーアグリゲーターを採用することができます。

データの処理

観測可能性パイプラインワーカーアグリゲーターを使用してデータの大部分を処理することで、Agent から責任を引き離すことができます。これにより、Agent への依存度が下がり、後々 Agent を変更することが容易になります。データ処理の詳細については、データを活用するを参照してください。

データのルーティング

記録システムの選択

分析システム (例えば Datadog) と記録システム (例えば AWS S3) を分離します。これにより、それぞれの目標に向かって独立して最適化することができます。

インスタンスの最適化

インスタンスサイジング

少なくとも 8 つの vCPU と 16 GiB のメモリを持つ最適化されたインスタンスを計算します。これらは、観測可能性パイプラインワーカーアグリゲーターを水平方向に拡張するための理想的なユニットです。観測可能性パイプラインワーカーは、より大きなインスタンスを選択すると、垂直方向にスケールし、自動的に追加リソースを利用することができます。可用性を高めるために、データボリュームに対して少なくとも 2 つの観測可能性パイプラインワーカーインスタンスを使用できるサイズを選択します。

CPU サイジング

観測可能性パイプラインワーカーワークロードの多くは、CPU に制約があり、最新の CPU の恩恵を受けることができます。

CPU アーキテクチャ

観測可能性パイプラインワーカーは、最新の CPU アーキテクチャで動作します。X86_64 アーキテクチャは、観測可能性パイプラインワーカーに最も適したパフォーマンスを提供します。

メモリサイジング

観測可能性パイプラインワーカーのアフィン型システムにより、観測可能性パイプラインワーカーのワークロードでは、メモリが制約されることはほとんどありません。そのため、Datadog は最小で vCPU あたり 2 GiB 以上のメモリを推奨しています。メモリ内バッファリングとバッチ処理により、シンクの数に応じてメモリ使用量が増加します。シンクの数が多い場合は、メモリの増設やディスクバッファへの切り替えを検討してください。

ディスクサイジング

観測可能性パイプラインワーカーのディスクバッファを使用して高耐久性を実現する場合 (推奨)、vCPU あたり少なくとも 36 GiB のディスクスペースをプロビジョニングします。8 vCPU の推奨に従い、288 GiB のディスク領域をプロビジョニングします (10 MiB * 60 秒 * 60 分 * 8 vCPU)。

*推奨サイズは、観測可能性パイプラインワーカーの 10MiB/s/vCPU のスループットで 1 時間計算したものです。例えば、8 vCPU のマシンの場合、288 GiB のディスクスペースが必要です (10 MiB * 60 秒 * 60 分 * 8 vCPU)。

ディスクタイプ

耐久性と回復のために最適化されたディスクタイプを選択します。例えば、標準的なブロックストレージは、インスタンスから切り離され、複数のディスクにデータをレプリケートして高い耐久性を実現するため、理想的なストレージです。高性能なローカルドライブは、スループットが観測可能性パイプラインワーカーのニーズを上回り、耐久性がブロックストレージに比べて低下するため、推奨されません。

このアーキテクチャでディスクが使用される理由については、高耐久性を参照してください。

オペレーティングシステムと GCC

可能であれば、glibc (GNU) ≧ 2.14 (2011 年リリース) の Linux ベースの OS を選択してください。観測可能性パイプラインワーカーは他のプラットフォームでも動作しますが、この組み合わせが Datadog のベンチマークで最高のパフォーマンスを発揮します。

キャパシティプランニング

試算の単位

以下の単位は、リソースの容量を見積もるための出発点ですが、ワークロードによって異なる場合があります。

*この数値は試算のための保守的なものです。1 vCPU = ARM 物理 CPU × 1、Intel 物理 CPU × 0.5。

スケーリング

水平スケーリング

水平スケーリングとは、複数の観測可能性パイプラインワーカーインスタンスにトラフィックを分散させることです。観測可能性パイプラインワーカーはシェアードナッシングのアーキテクチャを採用しており、リーダーノードやスケーリングを複雑にするような調整を必要としません。

プッシュベースのソースの場合、観測可能性パイプラインワーカーインスタンスをネットワークロードバランサーで前面化し、必要に応じてスケールアップ/ダウンしてください。

プルベースのソースの場合、ロードバランサーは必要ありません。観測可能性パイプラインワーカーをデプロイし、必要に応じてスケールアップ/ダウンしてください。観測可能性パイプラインワーカーがデータの読み取りを要求したときに、パブリッシュサブスクリプションシステムがデータへの排他的なアクセスを調整します。

混合ワークロード (プッシュベースとプルベースのソース) の詳細については、高度な構成を参照してください。

ロードバランシング

ロードバランサーは、Agent のようなプッシュベースのソースにのみ必要です。Kafka のようなプルベースのソースのみを使用する場合は、ロードバランサーは必要ありません。

クライアント側のロードバランシング

クライアント側のロードバランシングは推奨されません。クライアント側のロードバランシングとは、複数の観測可能性パイプラインワーカーインスタンスにまたがるトラフィックのロードバランシングをクライアントが行うことを指します。このアプローチはよりシンプルに聞こえますが、以下のため信頼性が低く、より複雑になる可能性があります。

• 適切なフェイルオーバーを伴うロードバランシングは複雑です。この分野の問題は、データの損失やサービスを停止させるインシデントにつながる可能性があるため、デリケートな問題です。複数のタイプのクライアントを取り扱っている場合は、さらに悪化します。
• 観測可能性パイプラインワーカーアグリゲーターのポイントは、Agent から責任を取り除くことであり、ロードバランシングを担うことはその一助となります。

ロードバランサーの種類

Datadog では、レイヤー 4 (L4) ロードバランサー (ネットワークロードバランサー) を推奨しています。これは、観測可能性パイプラインワーカーのプロトコル (TCP、UDP、HTTP) をサポートしているためです。HTTP トラフィック (レイヤー7) のみを送信している場合でも、Datadog はそのパフォーマンスとシンプルさのために L4 ロードバランサーを推奨しています。

ロードバランサーの構成

クライアントとロードバランサーを構成する場合、Datadog は以下の一般的な設定を推奨しています。

• シンプルなラウンドロビンのロードバランシング戦略を使用します。
• ゾーン間のトラフィックが非常に不均衡である場合を除き、クロスゾーンのロードバランシングを有効にしません。
• 観測可能性パイプラインワーカーのヘルス API エンドポイントを使用して、ターゲットのヘルスを確認するようにロードバランサーを構成します。
• 観測可能性パイプラインワーカーインスタンスがスケールする際に、自動的に登録または登録解除されるようにします。詳細は、サービスディスカバリーを参照してください。
• クライアントとロードバランサーの両方で、1 分以内のアイドルタイムアウトでキープアライブを有効にします。
• サポートされている場合は、Agent で接続の同時実行とプーリングを有効にします。サポートされていない場合は、エッジに観測可能性パイプラインワーカーをデプロイする統合アーキテクチャを検討してください。接続プーリングは、大量のデータを複数の接続に分散させ、トラフィックのバランスを取ることを可能にします。

ロードバランサーのホットスポット

ロードバランシングホットスポットは、1 つまたは複数の観測可能性パイプラインワーカーインスタンスが不均衡なトラフィックを受け取る場合に発生します。ホットスポットは通常、2 つの理由のうちの 1 つによって発生します。

1. 1 つの接続でかなりの量のトラフィックが送信されている。
2. あるアベイラビリティゾーンのトラフィックが、他のゾーンよりはるかに多い。

このような場合、以下のようなそれぞれの緩和策をとることをお勧めします。

1. 大きな接続を複数の接続に分割します。ほとんどのクライアントでは、複数の接続にデータを分散させる接続の同時実行とプーリングが可能です。この戦術により、ロードバランサーは複数の観測可能性パイプラインワーカーインスタンスに接続を分散させることができます。クライアントがこれをサポートしていない場合は、観測可能性パイプラインワーカーをエッジに追加でデプロイできる統一アーキテクチャを検討してください。
2. ロードバランサーでクロスゾーンのロードバランシングを有効にします。クロスゾーンバランシングは、すべての観測可能性パイプラインワーカーインスタンスですべてのアベイラビリティゾーンのトラフィックをバランスさせます。

垂直スケーリング

観測可能性パイプライン ワーカーの同時実行モデルは、すべての vCPU を活用するために自動的にスケーリングされます。同時実行の設定や構成の変更は必要ありません。Datadog では、垂直スケーリングを行う場合、インスタンスのサイズを総ボリュームの 50% 以下に抑え、高可用性のために最低 2 つの観測可能性パイプラインワーカーインスタンスをデプロイすることを推奨しています。

オートスケーリング

オートスケーリングは、平均的な CPU 使用率に基づいて行う必要があります。大半のワークロードでは、観測可能性パイプラインワーカーは CPU の制約を受けています。CPU 使用率は、誤検出が発生しないため、オートスケーリングの最も強力なシグナルとなります。Datadog は、以下の設定を使用し、必要に応じて調整することを推奨します。

• 使用率 85% を目標とした平均的な CPU。
• スケールアップとスケールダウンのための 5 分間の安定時間。

ネットワーキング

ネットワークトポロジー

ネットワーク境界

多くのユーザーは、複数のクラウド、リージョン、VPC、クラスターなど、多くのネットワーク境界を持つ複雑な本番環境を持っています。これらの境界の中で、観測可能性パイプラインワーカーをどこに位置づけるかを決めると、複雑になることがあります。そのため、Datadogで は、複数のアカウント、VPC、クラスターがある場合でも、リージョンごとに 1 つの観測可能性パイプラインワーカーアグリゲーターで始めることを推奨しています。この境界は、公衆インターネット上でのデータ送信を回避する最も広いネットワーク粒度です。複数のクラスターがある場合は、ユーティリティやツールクラスターに観測可能性パイプラインワーカーをデプロイするか、共有サービスに最も適したクラスタを選びましょう。

観測可能性パイプラインワーカーの利用が増えれば、複数の観測可能性パイプラインワーカーのデプロイがどのような位置づけになるかが明らかになります。

複数デプロイの詳細については、高度な構成を参照してください。

DNS とサービスディスカバリー

組織は、基本的な DNS を通じて促進されているとしても、何らかの形のサービスディスカバリーを採用しているかもしれません。観測可能性パイプラインワーカーアグリゲーターとサービスの発見は、サービスディスカバリーメカニズムによって解決される必要があります。

サービスディスカバリーを使用すると、名前付きホスト名 (固定 IP アドレスではない) で Agent を構成し、トラフィックのルーティングとロードバランシングを促進することができます。これは、Agent がロードバランサーを発見し、ロードバランサーが観測可能性パイプラインワーカーアグリゲーターを発見する方法です。

観測可能性パイプラインワーカー自身は DNS クエリの解決を行わず、システムレベルのリゾルバ (例えば Linux 解決など) に委ねます。

ネットワークトラフィック

プロキシ

観測可能性パイプラインワーカーには、すべての送信 HTTP トラフィックをプロキシ経由でルーティングするグローバルプロキシオプションがあります。プロキシを使用するかどうかは、組織のセキュリティとネットワークの設定に依存します。

ポート

観測可能性パイプラインワーカーは、ネットワーク管理者が簡単に発見できるように、すべてのポートを明示的に構成する必要があります。したがって、観測可能性パイプラインワーカーのコンフィギュレーションファイルを見ることで、公開されているすべてのポートの完全なインベントリを得ることができます。観測可能性パイプラインワーカーアグリゲーターは、以下のポートを公開するデフォルト構成で出荷されています。

管理者が公開ポートを変更している可能性がありますので、観測可能性パイプラインワーカーの構成を見直してください。

プロトコル

観測可能性パイプラインワーカーは、様々なプロトコルでデータを受信・送信できるように設計されています。Datadog では、インテグレーションで最もサポートされているプロトコルを使用することを推奨しています。可能であれば、アプリケーションレベルの配信確認とプラットフォーム間でのユビキタスなサポートのために、HTTP ベースのプロトコルを選択します。それ以外の場合は、TCP ベースのプロトコルを選択します。UDP は、データを失うリスクがあるため、推奨されません。

ワーカー間の通信

観測可能性パイプラインワーカーのソースとシンクを使用して、観測可能性パイプラインワーカーインスタンス間でデータを送信します (例えば、統一アーキテクチャを使用した場合など)。これらのソースは、効率的なロスレス通信のために GRPC プロトコルを使用します。

Agent 通信

観測可能性パイプラインワーカーは、多くの Agent のために特定のソースを提供します。例えば、datadog_agent ソースは Datadog Agent から全てのデータタイプをロスレス構造化フォーマットで受信する処理を行います。

圧縮

Datadog のベンチマークによると、圧縮を行うとスループットが 50% 低下する可能性があります。圧縮は慎重に使用し、有効にした後はパフォーマンスを監視してください。

ネットワークトラフィックの圧縮は、パフォーマンスに影響を与えるため、コスト重視のイグレスシナリオにのみ使用する必要があります (例えば、公衆インターネット上でのデータ送信など)。したがって、内部ネットワークトラフィックの圧縮は推奨されません。

高耐久性

高耐久性とは、システム障害が発生したときにデータを保持できることです。アグリゲーターアーキテクチャは、高耐久性の責任を負うように設計されています。このため、Agent からアグリゲーターに負担を移し、ローカライズすることで、耐久性戦略を簡素化することができます。さらに、この集中的なアプローチにより、すべての Agent ノードに渡って実装することが困難な耐久性戦略が可能になります。

高耐久性を実現するために

1. Agent をシンプルなデータフォワーダーとして構成し、観測可能性パイプラインワーカーアグリゲーターに直接データをストリーミングします。これにより、データはまだ冗長化されていないため、エッジで損失にさらされる時間を減らすことができます。

2. 記録システムとして機能する耐久性の高い宛先を選択します (例えば、AWS S3)。このシステムは、静止しているデータの耐久性に責任があり、一般的にアーカイブやデータレイクと呼ばれます。

最後に、記録システムに書き込む観測可能性パイプラインワーカーのシンクを構成し、エンドツーエンド確認応答とディスクバッファを有効にしてください。例:

sinks:
    aws_s3:
        acknowledgments: true
        buffer:
            type: "disk"

データ損失の防止

エンドツーエンド確認応答の使用

観測可能性パイプラインワーカーのオペレーティングシステムプロセスの問題により、問題の発生時にメモリに保持されているデータが失われる危険性があります。観測可能性パイプラインワーカーのエンドツーエンド確認応答機能を有効にして、データ消失のリスクを軽減してください。

sinks:
    aws_s3:
        acknowledgments: true

この機能を有効にすると、観測可能性パイプラインワーカーは、データが永続的に保持されるまで Agent に応答しません。これにより、Agent が早期にデータを解放し、確認応答を受信していない場合に再度送信することを防ぐことができます。

ノード障害への対応

ノード障害は、個々のノードの完全な障害に対処します。これらはエンドツーエンドの確認応答を使って対処することもできます。詳しくはエンドツーエンド確認応答の使用を参照してください。

ディスク障害への対応

ディスク障害は、個々のディスクの障害に対処します。ディスク障害によるデータ損失は、ブロックストレージ (例えば AWS EBS) のような複数のディスクにデータを複製する高耐久性のファイルシステムを使用することで軽減できます。

データ処理障害への対応

観測可能性パイプラインワーカーは、不正なデータを処理しようとすると、ログのパースに失敗するなどの問題が発生することがあります。この問題を軽減する方法は 2 つあります。

1. ダイレクトアーカイブ: ソースからアーカイブに直接データをルーティングします。これにより、データが落とされるリスクなしにアーカイブに到達することを保証します。また、このデータは、処理エラーを修正した後に再生することができます。

2. イベントルーティングの失敗: 観測可能性パイプラインワーカーは、構造化データやリッチ化データなど、処理したデータをアーカイブしたいユーザー向けに、失敗したイベントのルーティングを提供します。観測可能性パイプラインワーカーの変換には、耐久性と再生のためにシンクに接続することができるドロップ出力が付属しているものがあります。

どの戦略がベストなのか？

耐久性が最も重要な基準である場合は、データ損失のシナリオに対応するため、ダイレクトアーカイブ方式を使用します。アーカイブ内のデータを分析したい場合は、一般にデータレイクと呼ばれる障害イベントルーティング方式を使用します。アーカイブ/データレイクを長期的な分析に使用できる利点があります。Datadog Log Archives や AWS Athena は、アーカイブストレージソリューションの一例です。

宛先障害への対応

宛先の障害とは、ダウンストリームの宛先 (例えば Elasticsearch) の全障害を指します。ダウンストリームの宛先の問題は、停止時間を維持するのに十分な大きさのディスクバッファを使用することで、データ損失を軽減することができます。これにより、サービスが停止している間、データを持続的にバッファリングし、サービスが回復したときにデータを排出することができます。このため、少なくとも 1 時間分のデータを保持するのに十分な大きさのディスクバッファを使用することをお勧めします。詳しくは、ディスクサイジングを参照してください。

高可用性

高可用性とは、観測可能性パイプラインワーカーにシステムトラブルが発生しても、常に利用可能であることを指します。

高耐久性を実現するために

1. 各アベイラビリティゾーンに少なくとも 2 つの観測可能性パイプラインワーカーインスタンスをデプロイします。
2. 観測可能性パイプラインワーカーを少なくとも 2 つのアベイラビリティゾーンにデプロイします。
3. 観測可能性パイプラインワーカーインスタンス間のトラフィックをバランスさせるロードバランサーで観測可能性パイプラインワーカーインスタンスを前面化します。詳細については、水平スケーリングのセクションを参照してください。

障害シナリオの軽減

観測可能性パイプラインワーカープロセスの問題への対応

システムプロセスの問題を軽減するには、観測可能性パイプラインワーカーを複数のノードに分散し、必要に応じて別の観測可能性パイプラインワーカーインスタンスにトラフィックをリダイレクトできるネットワークロードバランサーで前面化します。さらに、プラットフォームレベルの自動自己修復機能により、最終的にはプロセスを再起動するか、ノードを交換する必要があります。

ノード障害の軽減

ノードの問題を軽減するには、観測可能性パイプラインワーカーを複数のノードに分散し、別の観測可能性パイプラインワーカーノードにトラフィックをリダイレクトできるネットワークロードバランサーで前面化します。さらに、プラットフォームレベルの自動自己修復機能により、最終的にはノードを交換する必要があります。

アベイラビリティゾーン障害への対応

アベイラビリティゾーンの問題を軽減するために、複数のアベイラビリティゾーンに観測可能性パイプラインワーカーをデプロイします。

リージョン障害の軽減

観測可能性パイプラインワーカーは、内部の観測可能性データをルーティングするために設計されており、他のリージョンにフェイルオーバーするべきではありません。その代わりに、観測可能性パイプラインワーカーは、ネットワーク境界セクションで推奨されているように、全てのリージョンにデプロイされるべきです。そのため、ネットワーク全体やリージョンに障害が発生した場合、観測可能性パイプラインワーカーも一緒に障害になります。

災害復旧

内部災害復旧

観測可能性パイプラインワーカーは、内部の観測可能性データをルーティングするために設計されたインフラストラクチャーレベルのツールです。シェアードナッシングアーキテクチャを実装しており、災害復旧 (DR) サイトに複製または転送されるべき状態を管理しません。そのため、リージョン全体が障害になった場合、観測可能性パイプラインワーカーも一緒に障害になります。したがって、より広範な DR 計画の一環として、DR サイトに観測可能性パイプラインワーカーをインストールする必要があります。

外部災害復旧

Datadog のようなマネージドデスティネーションを使用している場合、観測可能性パイプラインワーカーのサーキットブレーカー機能を使用して、Datadog DR サイトへのデータの自動ルーティングを容易にすることができます。

高度な構成

複数のアグリゲーターデプロイ

ネットワーク境界で説明したように、Datadog では、1 つのリージョンにつき 1 つの観測可能性パイプラインワーカーアグリゲーターで始めることを推奨しています。これは、観測可能性パイプラインワーカーの最初のデプロイを複雑にしすぎないためですが、複数のデプロイで開始することが理想的な状況もあります。

1. **公衆インターネット上でのデータ送信を防止する。**複数のクラウドやリージョンがある場合、インターネット上に大量のデータを送信しないように、それぞれのクラウドやリージョンに観測可能性パイプラインワーカーアグリゲーターをデプロイしてください。観測可能性パイプラインワーカーアグリゲーターは、内部データを受け取り、ネットワークの単一のイグレスとして機能する必要があります。

2. **独立した管理。**ユースケースに応じて、観測可能性パイプラインワーカーアグリゲーターを独立して運用・管理できるチームがある場合です。例えば、データサイエンスチームは、独自のインフラストラクチャーを運用する責任があり、独自の観測可能性パイプラインワーカーアグリゲーターを独立して運用する手段を持っている場合があります。

複数のクラウドアカウント

多くのユーザーは、VPC とクラスターを内部に持つ複数のクラウドアカウントを持っています。Datadog はこのような場合でも、1 つのリージョンに 1 つの観測可能性パイプラインワーカーアグリゲーターを導入することを推奨しています。観測可能性パイプラインワーカーをユーティリティやツールのクラスターにデプロイし、すべてのクラウドアカウントがこのクラスターにデータを送信するように構成します。詳細については、ネットワーク境界を参照してください。

パブリッシュ・サブスクライブ (Pub-Sub) システム

Kafka のような Pub-Sub システムを使用することは、アーキテクチャを高可用性または高耐久性にするために必須ではありませんが (高耐久性および高可用性のセクションを参照)、次のような利点があります。

1. **信頼性の向上。**Pub-Sub システムは、高い信頼性と耐久性を持ち、頻繁に変更されることのないシステムとして設計されています。マネージドオプションを使用している場合は特に信頼性が高くなります。観測可能性パイプラインワーカーは、その目的から頻繁に変更される可能性があります。観測可能性パイプラインワーカーのダウンタイムを Pub-Sub システムの背後に分離することで、クライアントの認識から可用性を高め、復旧をよりシンプルにすることができます。

2. **ロードバランサーが不要。**Pub-Sub システムは、ロードバランサーを必要としません。Pub-Sub システムがコンシューマーの調整を行うため、観測可能性パイプラインワーカーを簡単に水平にスケールすることができます。

Pub-Sub パーティショニング

パーティショニング (Kafka 用語では「トピック」) とは、Pub-Sub システム内のデータを分離することを指します。データを生成したサービスやホストなど、データの起点に沿ったパーティショニングを行う必要があります。

Pub-Sub 構成

Pub-Sub システムを使用する場合、Datadog は、観測可能性パイプラインワーカーの以下の構成変更を推奨しています。

• **すべてのシンクでエンドツーエンドの確認応答を有効にする。**この設定により、データの書き込みが成功するまで Pub-Sub チェックポイントを進めないようにします。
• **メモリバッファを使用する。**観測可能性パイプラインワーカーが Pub-Sub システムの背後にある場合、観測可能性パイプラインワーカーのディスクバッファを使用する必要はありません。Pub-Sub システムは、高い耐久性を持つ長期的なバッファリングのために設計されています。観測可能性パイプラインワーカーは、データの読み取り、処理、ルーティングのみを担当する必要があります (耐久性ではありません)。

グローバル集計

このセクションでは、レガシーの宛先に対してグローバル計算を実行するための推奨事項を説明します。最新の宛先は、すでにグローバル計算をサポートしています。例えば、Datadog は、メトリクスデータのグローバルな観測を解決するディストリビューション (DDSketch など) をサポートしています。

グローバル集計とは、リージョン全体のデータを集計する機能です。例えば、CPU 負荷平均のグローバル分位を計算することができます。これを実現するには、1 つの観測可能性パイプラインワーカーインスタンスが、すべてのノードの CPU 負荷平均統計にアクセスできる必要があります。これは水平スケーリングでは不可能です。個々の観測可能性パイプラインワーカーインスタンスは、全体のデータのスライスにしかアクセスすることができません。したがって、集計は階層化する必要があります。

上の図では、第 2 層のアグリゲーターは、第 1 層のアグリゲーターから全体データの集計されたサブストリームを受け取っています。これにより、単一のインスタンスが、ストリーム全体を処理し、単一障害点を導入することなく、グローバルビューを取得することができます。

推奨事項

• グローバル集計は、グローバルヒストグラムの計算など、データを減らすことができるタスクに限定します。すべてのデータをグローバルアグリゲーターに送りません。
• 単一障害点を発生させないために、ほとんどのデータの処理と配信には、引き続きローカルアグリゲーターを使用してください。