- 重要な情報
- はじめに
- 用語集
- エージェント
- インテグレーション
- OpenTelemetry
- 開発者
- API
- CoScreen
- アプリ内
- インフラストラクチャー
- アプリケーションパフォーマンス
- 継続的インテグレーション
- ログ管理
- セキュリティ
- UX モニタリング
- 管理
観測可能性パイプラインワーカー (OPW) のアグリゲーターアーキテクチャは、データの集中処理とルーティングのためのスタンドアローンサービスとして観測可能性パイプラインワーカーをデプロイします。
観測可能性パイプラインワーカーを他のサービスのようにインフラストラクチャーにデプロイし、データをインターセプトして操作し、宛先に転送することができます。観測可能性パイプラインワーカーインスタンスはそれぞれ独立して動作するため、シンプルなロードバランサーでアーキテクチャを拡張することができます。
このガイドでは、新規の観測可能性パイプラインワーカーユーザーのために、推奨されるアグリゲーターアーキテクチャを説明します。具体的には、以下のトピックです。
タイプ | 最小値 |
---|---|
CPU コア | 2 vCPU 以上 (CPU サイジングを参照) |
CPU アーキテクチャ | X86_64、AMD64、ARM64、ARMHF、ARMv7 |
メモリ | vCPU あたり 2 GiB 以上 (メモリサイジングを参照) |
ディスク | 1 Gib 以上、ディスクバッファの場合はそれ以上 (ディスクサイジングを参照) |
インストールのドキュメントをご覧ください。
観測可能性パイプラインワーカー (OPW) を構成する場合、Datadog は以下の一般的なフローに従うことを推奨しています。
構成は様々ですが、以下の主要な目標に従うべきです。
できるだけ多くのソースをインテグレーションして、観測可能性パイプラインワーカーアグリゲーターにデータを簡単に送信できるようにします。観測可能性パイプラインワーカーアグリゲーターには、数十のソースがあることも珍しくありません。セキュリティと耐久性の要件をサポートする限り、ソースコンポーネントを構成します。これにより、社内のユーザーがレガシーサービスを使用している場合でも、観測可能性パイプラインワーカーアグリゲーターを採用することができます。
観測可能性パイプラインワーカーアグリゲーターを使用してデータの大部分を処理することで、Agent から責任を引き離すことができます。これにより、Agent への依存度が下がり、後々 Agent を変更することが容易になります。データ処理の詳細については、データを活用するを参照してください。
分析システム (例えば Datadog) と記録システム (例えば AWS S3) を分離します。これにより、それぞれの目標に向かって独立して最適化することができます。
少なくとも 8 つの vCPU と 16 GiB のメモリを持つ最適化されたインスタンスを計算します。これらは、観測可能性パイプラインワーカーアグリゲーターを水平方向に拡張するための理想的なユニットです。観測可能性パイプラインワーカーは、より大きなインスタンスを選択すると、垂直方向にスケールし、自動的に追加リソースを利用することができます。可用性を高めるために、データボリュームに対して少なくとも 2 つの観測可能性パイプラインワーカーインスタンスを使用できるサイズを選択します。
クラウドプロバイダー | 推奨事項 |
---|---|
AWS | c6i.2xlarge (推奨) または c6g.2xlarge |
Azure | f8 |
Google Cloud | c2 (8 vCPU、16 GiB メモリ) |
プライベート | 8 vCPU、16 GiB メモリ、ローカルディスクは必要ありません |
観測可能性パイプラインワーカーワークロードの多くは、CPU に制約があり、最新の CPU の恩恵を受けることができます。
クラウドプロバイダー | 推奨事項 |
---|---|
AWS | 最新世代の Intel Xeon、8 vCPU (推奨)、最低 4 vCPU |
Azure | 最新世代の Intel Xeon、8 vCPU (推奨)、最低 4 vCPU |
Google Cloud | 最新世代の Intel Xeon、8 vCPU (推奨)、最低 4 vCPU |
プライベート | 最新世代の Intel Xeon、8 vCPU (推奨)、最低 4 vCPU |
観測可能性パイプラインワーカーは、最新の CPU アーキテクチャで動作します。X86_64 アーキテクチャは、観測可能性パイプラインワーカーに最も適したパフォーマンスを提供します。
観測可能性パイプラインワーカーのアフィン型システムにより、観測可能性パイプラインワーカーのワークロードでは、メモリが制約されることはほとんどありません。そのため、Datadog は最小で vCPU あたり 2 GiB 以上のメモリを推奨しています。メモリ内バッファリングとバッチ処理により、シンクの数に応じてメモリ使用量が増加します。シンクの数が多い場合は、メモリの増設やディスクバッファへの切り替えを検討してください。
観測可能性パイプラインワーカーのディスクバッファを使用して高耐久性を実現する場合 (推奨)、vCPU あたり少なくとも 36 GiB のディスクスペースをプロビジョニングします。8 vCPU の推奨に従い、288 GiB のディスク領域をプロビジョニングします (10 MiB * 60 秒 * 60 分 * 8 vCPU)。
クラウドプロバイダー | 推奨* |
---|---|
AWS | EBS gp3、vCPU あたり 36 GiB、IOPS およびスループットの追加なし |
Azure | Ultra-disk または標準的な SSD、vCPU あたり 36 GiB |
Google Cloud | バランス型または SSD の永続ディスク、vCPU あたり 36 GiB |
プライベート | ネットワークベースのブロックストレージ相当、vCPU あたり 36 GiB |
*推奨サイズは、観測可能性パイプラインワーカーの 10MiB/s/vCPU のスループットで 1 時間計算したものです。例えば、8 vCPU のマシンの場合、288 GiB のディスクスペースが必要です (10 MiB * 60 秒 * 60 分 * 8 vCPU)。
耐久性と回復のために最適化されたディスクタイプを選択します。例えば、標準的なブロックストレージは、インスタンスから切り離され、複数のディスクにデータをレプリケートして高い耐久性を実現するため、理想的なストレージです。高性能なローカルドライブは、スループットが観測可能性パイプラインワーカーのニーズを上回り、耐久性がブロックストレージに比べて低下するため、推奨されません。
このアーキテクチャでディスクが使用される理由については、高耐久性を参照してください。
可能であれば、glibc (GNU) ≧ 2.14 (2011 年リリース) の Linux ベースの OS を選択してください。観測可能性パイプラインワーカーは他のプラットフォームでも動作しますが、この組み合わせが Datadog のベンチマークで最高のパフォーマンスを発揮します。
以下の単位は、リソースの容量を見積もるための出発点ですが、ワークロードによって異なる場合があります。
単位 | サイズ | 観測可能性パイプラインワーカースループット* |
---|---|---|
非構造化ログイベント | ~512 バイト | ~10 MiB/s/vCPU |
構造化ログイベント | ~1.5 KB | ~25 MiB/s/vCPU |
メトリクスイベント | ~256 バイト | ~25 MiB/s/vCPU |
トレーススパンイベント | ~1.5 KB | ~25 MiB/s/vCPU |
*この数値は試算のための保守的なものです。1 vCPU = ARM 物理 CPU × 1、Intel 物理 CPU × 0.5。
水平スケーリングとは、複数の観測可能性パイプラインワーカーインスタンスにトラフィックを分散させることです。観測可能性パイプラインワーカーはシェアードナッシングのアーキテクチャを採用しており、リーダーノードやスケーリングを複雑にするような調整を必要としません。
プッシュベースのソースの場合、観測可能性パイプラインワーカーインスタンスをネットワークロードバランサーで前面化し、必要に応じてスケールアップ/ダウンしてください。
プルベースのソースの場合、ロードバランサーは必要ありません。観測可能性パイプラインワーカーをデプロイし、必要に応じてスケールアップ/ダウンしてください。観測可能性パイプラインワーカーがデータの読み取りを要求したときに、パブリッシュサブスクリプションシステムがデータへの排他的なアクセスを調整します。
混合ワークロード (プッシュベースとプルベースのソース) の詳細については、高度な構成を参照してください。
ロードバランサーは、Agent のようなプッシュベースのソースにのみ必要です。Kafka のようなプルベースのソースのみを使用する場合は、ロードバランサーは必要ありません。
クライアント側のロードバランシングは推奨されません。クライアント側のロードバランシングとは、複数の観測可能性パイプラインワーカーインスタンスにまたがるトラフィックのロードバランシングをクライアントが行うことを指します。このアプローチはよりシンプルに聞こえますが、以下のため信頼性が低く、より複雑になる可能性があります。
Datadog では、レイヤー 4 (L4) ロードバランサー (ネットワークロードバランサー) を推奨しています。これは、観測可能性パイプラインワーカーのプロトコル (TCP、UDP、HTTP) をサポートしているためです。HTTP トラフィック (レイヤー7) のみを送信している場合でも、Datadog はそのパフォーマンスとシンプルさのために L4 ロードバランサーを推奨しています。
クラウドプロバイダー | 推奨事項 |
---|---|
AWS | AWS ネットワークロードバランサー (NLB) |
Azure | 内部 Azure ロードバランサー |
Google Cloud | 内部 TCP/UDP ネットワークロードバランサー |
プライベート | HAProxy、Nginx、またはレイヤー 4 をサポートするその他のロードバランサー |
クライアントとロードバランサーを構成する場合、Datadog は以下の一般的な設定を推奨しています。
ロードバランシングホットスポットは、1 つまたは複数の観測可能性パイプラインワーカーインスタンスが不均衡なトラフィックを受け取る場合に発生します。ホットスポットは通常、2 つの理由のうちの 1 つによって発生します。
このような場合、以下のようなそれぞれの緩和策をとることをお勧めします。
観測可能性パイプライン ワーカーの同時実行モデルは、すべての vCPU を活用するために自動的にスケーリングされます。同時実行の設定や構成の変更は必要ありません。Datadog では、垂直スケーリングを行う場合、インスタンスのサイズを総ボリュームの 50% 以下に抑え、高可用性のために最低 2 つの観測可能性パイプラインワーカーインスタンスをデプロイすることを推奨しています。
オートスケーリングは、平均的な CPU 使用率に基づいて行う必要があります。大半のワークロードでは、観測可能性パイプラインワーカーは CPU の制約を受けています。CPU 使用率は、誤検出が発生しないため、オートスケーリングの最も強力なシグナルとなります。Datadog は、以下の設定を使用し、必要に応じて調整することを推奨します。
多くのユーザーは、複数のクラウド、リージョン、VPC、クラスターなど、多くのネットワーク境界を持つ複雑な本番環境を持っています。これらの境界の中で、観測可能性パイプラインワーカーをどこに位置づけるかを決めると、複雑になることがあります。そのため、Datadogで は、複数のアカウント、VPC、クラスターがある場合でも、リージョンごとに 1 つの観測可能性パイプラインワーカーアグリゲーターで始めることを推奨しています。この境界は、公衆インターネット上でのデータ送信を回避する最も広いネットワーク粒度です。複数のクラスターがある場合は、ユーティリティやツールクラスターに観測可能性パイプラインワーカーをデプロイするか、共有サービスに最も適したクラスタを選びましょう。
観測可能性パイプラインワーカーの利用が増えれば、複数の観測可能性パイプラインワーカーのデプロイがどのような位置づけになるかが明らかになります。
複数デプロイの詳細については、高度な構成を参照してください。
組織は、基本的な DNS を通じて促進されているとしても、何らかの形のサービスディスカバリーを採用しているかもしれません。観測可能性パイプラインワーカーアグリゲーターとサービスの発見は、サービスディスカバリーメカニズムによって解決される必要があります。
サービスディスカバリーを使用すると、名前付きホスト名 (固定 IP アドレスではない) で Agent を構成し、トラフィックのルーティングとロードバランシングを促進することができます。これは、Agent がロードバランサーを発見し、ロードバランサーが観測可能性パイプラインワーカーアグリゲーターを発見する方法です。
観測可能性パイプラインワーカー自身は DNS クエリの解決を行わず、システムレベルのリゾルバ (例えば Linux 解決など) に委ねます。
観測可能性パイプラインワーカーには、すべての送信 HTTP トラフィックをプロキシ経由でルーティングするグローバルプロキシオプションがあります。プロキシを使用するかどうかは、組織のセキュリティとネットワークの設定に依存します。
観測可能性パイプラインワーカーは、ネットワーク管理者が簡単に発見できるように、すべてのポートを明示的に構成する必要があります。したがって、観測可能性パイプラインワーカーのコンフィギュレーションファイルを見ることで、公開されているすべてのポートの完全なインベントリを得ることができます。観測可能性パイプラインワーカーアグリゲーターは、以下のポートを公開するデフォルト構成で出荷されています。
ポート | ソース | プロトコル | 方向 | 説明 |
---|---|---|---|---|
8282 | Datadog Agent | HTTP | 着信 | フルエントソースからデータを受け取ります。 |
123 | ファイル | Syslog | 着信 | Syslog ソースからデータを受け取ります。 |
管理者が公開ポートを変更している可能性がありますので、観測可能性パイプラインワーカーの構成を見直してください。
観測可能性パイプラインワーカーは、様々なプロトコルでデータを受信・送信できるように設計されています。Datadog では、インテグレーションで最もサポートされているプロトコルを使用することを推奨しています。可能であれば、アプリケーションレベルの配信確認とプラットフォーム間でのユビキタスなサポートのために、HTTP ベースのプロトコルを選択します。それ以外の場合は、TCP ベースのプロトコルを選択します。UDP は、データを失うリスクがあるため、推奨されません。
観測可能性パイプラインワーカーのソースとシンクを使用して、観測可能性パイプラインワーカーインスタンス間でデータを送信します (例えば、統一アーキテクチャを使用した場合など)。これらのソースは、効率的なロスレス通信のために GRPC プロトコルを使用します。
観測可能性パイプラインワーカーは、多くの Agent のために特定のソースを提供します。例えば、datadog_agent ソースは Datadog Agent から全てのデータタイプをロスレス構造化フォーマットで受信する処理を行います。
Datadog のベンチマークによると、圧縮を行うとスループットが 50% 低下する可能性があります。圧縮は慎重に使用し、有効にした後はパフォーマンスを監視してください。
ネットワークトラフィックの圧縮は、パフォーマンスに影響を与えるため、コスト重視のイグレスシナリオにのみ使用する必要があります (例えば、公衆インターネット上でのデータ送信など)。したがって、内部ネットワークトラフィックの圧縮は推奨されません。
高耐久性とは、システム障害が発生したときにデータを保持できることです。アグリゲーターアーキテクチャは、高耐久性の責任を負うように設計されています。このため、Agent からアグリゲーターに負担を移し、ローカライズすることで、耐久性戦略を簡素化することができます。さらに、この集中的なアプローチにより、すべての Agent ノードに渡って実装することが困難な耐久性戦略が可能になります。
高耐久性を実現するために
Agent をシンプルなデータフォワーダーとして構成し、観測可能性パイプラインワーカーアグリゲーターに直接データをストリーミングします。これにより、データはまだ冗長化されていないため、エッジで損失にさらされる時間を減らすことができます。
記録システムとして機能する耐久性の高い宛先を選択します (例えば、AWS S3)。このシステムは、静止しているデータの耐久性に責任があり、一般的にアーカイブやデータレイクと呼ばれます。
最後に、記録システムに書き込む観測可能性パイプラインワーカーのシンクを構成し、エンドツーエンド確認応答とディスクバッファを有効にしてください。例:
sinks:
aws_s3:
acknowledgments: true
buffer:
type: "disk"
観測可能性パイプラインワーカーのオペレーティングシステムプロセスの問題により、問題の発生時にメモリに保持されているデータが失われる危険性があります。観測可能性パイプラインワーカーのエンドツーエンド確認応答機能を有効にして、データ消失のリスクを軽減してください。
sinks:
aws_s3:
acknowledgments: true
この機能を有効にすると、観測可能性パイプラインワーカーは、データが永続的に保持されるまで Agent に応答しません。これにより、Agent が早期にデータを解放し、確認応答を受信していない場合に再度送信することを防ぐことができます。
ノード障害は、個々のノードの完全な障害に対処します。これらはエンドツーエンドの確認応答を使って対処することもできます。詳しくはエンドツーエンド確認応答の使用を参照してください。
ディスク障害は、個々のディスクの障害に対処します。ディスク障害によるデータ損失は、ブロックストレージ (例えば AWS EBS) のような複数のディスクにデータを複製する高耐久性のファイルシステムを使用することで軽減できます。
観測可能性パイプラインワーカーは、不正なデータを処理しようとすると、ログのパースに失敗するなどの問題が発生することがあります。この問題を軽減する方法は 2 つあります。
ダイレクトアーカイブ: ソースからアーカイブに直接データをルーティングします。これにより、データが落とされるリスクなしにアーカイブに到達することを保証します。また、このデータは、処理エラーを修正した後に再生することができます。
イベントルーティングの失敗: 観測可能性パイプラインワーカーは、構造化データやリッチ化データなど、処理したデータをアーカイブしたいユーザー向けに、失敗したイベントのルーティングを提供します。観測可能性パイプラインワーカーの変換には、耐久性と再生のためにシンクに接続することができるドロップ出力が付属しているものがあります。
耐久性が最も重要な基準である場合は、データ損失のシナリオに対応するため、ダイレクトアーカイブ方式を使用します。アーカイブ内のデータを分析したい場合は、一般にデータレイクと呼ばれる障害イベントルーティング方式を使用します。アーカイブ/データレイクを長期的な分析に使用できる利点があります。Datadog Log Archives や AWS Athena は、アーカイブストレージソリューションの一例です。
宛先の障害とは、ダウンストリームの宛先 (例えば Elasticsearch) の全障害を指します。ダウンストリームの宛先の問題は、停止時間を維持するのに十分な大きさのディスクバッファを使用することで、データ損失を軽減することができます。これにより、サービスが停止している間、データを持続的にバッファリングし、サービスが回復したときにデータを排出することができます。このため、少なくとも 1 時間分のデータを保持するのに十分な大きさのディスクバッファを使用することをお勧めします。詳しくは、ディスクサイジングを参照してください。
高可用性とは、観測可能性パイプラインワーカーにシステムトラブルが発生しても、常に利用可能であることを指します。
高耐久性を実現するために
システムプロセスの問題を軽減するには、観測可能性パイプラインワーカーを複数のノードに分散し、必要に応じて別の観測可能性パイプラインワーカーインスタンスにトラフィックをリダイレクトできるネットワークロードバランサーで前面化します。さらに、プラットフォームレベルの自動自己修復機能により、最終的にはプロセスを再起動するか、ノードを交換する必要があります。
ノードの問題を軽減するには、観測可能性パイプラインワーカーを複数のノードに分散し、別の観測可能性パイプラインワーカーノードにトラフィックをリダイレクトできるネットワークロードバランサーで前面化します。さらに、プラットフォームレベルの自動自己修復機能により、最終的にはノードを交換する必要があります。
アベイラビリティゾーンの問題を軽減するために、複数のアベイラビリティゾーンに観測可能性パイプラインワーカーをデプロイします。
観測可能性パイプラインワーカーは、内部の観測可能性データをルーティングするために設計されており、他のリージョンにフェイルオーバーするべきではありません。その代わりに、観測可能性パイプラインワーカーは、ネットワーク境界セクションで推奨されているように、全てのリージョンにデプロイされるべきです。そのため、ネットワーク全体やリージョンに障害が発生した場合、観測可能性パイプラインワーカーも一緒に障害になります。
観測可能性パイプラインワーカーは、内部の観測可能性データをルーティングするために設計されたインフラストラクチャーレベルのツールです。シェアードナッシングアーキテクチャを実装しており、災害復旧 (DR) サイトに複製または転送されるべき状態を管理しません。そのため、リージョン全体が障害になった場合、観測可能性パイプラインワーカーも一緒に障害になります。したがって、より広範な DR 計画の一環として、DR サイトに観測可能性パイプラインワーカーをインストールする必要があります。
Datadog のようなマネージドデスティネーションを使用している場合、観測可能性パイプラインワーカーのサーキットブレーカー機能を使用して、Datadog DR サイトへのデータの自動ルーティングを容易にすることができます。
ネットワーク境界で説明したように、Datadog では、1 つのリージョンにつき 1 つの観測可能性パイプラインワーカーアグリゲーターで始めることを推奨しています。これは、観測可能性パイプラインワーカーの最初のデプロイを複雑にしすぎないためですが、複数のデプロイで開始することが理想的な状況もあります。
**公衆インターネット上でのデータ送信を防止する。**複数のクラウドやリージョンがある場合、インターネット上に大量のデータを送信しないように、それぞれのクラウドやリージョンに観測可能性パイプラインワーカーアグリゲーターをデプロイしてください。観測可能性パイプラインワーカーアグリゲーターは、内部データを受け取り、ネットワークの単一のイグレスとして機能する必要があります。
**独立した管理。**ユースケースに応じて、観測可能性パイプラインワーカーアグリゲーターを独立して運用・管理できるチームがある場合です。例えば、データサイエンスチームは、独自のインフラストラクチャーを運用する責任があり、独自の観測可能性パイプラインワーカーアグリゲーターを独立して運用する手段を持っている場合があります。
多くのユーザーは、VPC とクラスターを内部に持つ複数のクラウドアカウントを持っています。Datadog はこのような場合でも、1 つのリージョンに 1 つの観測可能性パイプラインワーカーアグリゲーターを導入することを推奨しています。観測可能性パイプラインワーカーをユーティリティやツールのクラスターにデプロイし、すべてのクラウドアカウントがこのクラスターにデータを送信するように構成します。詳細については、ネットワーク境界を参照してください。
Kafka のような Pub-Sub システムを使用することは、アーキテクチャを高可用性または高耐久性にするために必須ではありませんが (高耐久性および高可用性のセクションを参照)、次のような利点があります。
**信頼性の向上。**Pub-Sub システムは、高い信頼性と耐久性を持ち、頻繁に変更されることのないシステムとして設計されています。マネージドオプションを使用している場合は特に信頼性が高くなります。観測可能性パイプラインワーカーは、その目的から頻繁に変更される可能性があります。観測可能性パイプラインワーカーのダウンタイムを Pub-Sub システムの背後に分離することで、クライアントの認識から可用性を高め、復旧をよりシンプルにすることができます。
**ロードバランサーが不要。**Pub-Sub システムは、ロードバランサーを必要としません。Pub-Sub システムがコンシューマーの調整を行うため、観測可能性パイプラインワーカーを簡単に水平にスケールすることができます。
パーティショニング (Kafka 用語では「トピック」) とは、Pub-Sub システム内のデータを分離することを指します。データを生成したサービスやホストなど、データの起点に沿ったパーティショニングを行う必要があります。
Pub-Sub システムを使用する場合、Datadog は、観測可能性パイプラインワーカーの以下の構成変更を推奨しています。
このセクションでは、レガシーの宛先に対してグローバル計算を実行するための推奨事項を説明します。最新の宛先は、すでにグローバル計算をサポートしています。例えば、Datadog は、メトリクスデータのグローバルな観測を解決するディストリビューション (DDSketch など) をサポートしています。
グローバル集計とは、リージョン全体のデータを集計する機能です。例えば、CPU 負荷平均のグローバル分位を計算することができます。これを実現するには、1 つの観測可能性パイプラインワーカーインスタンスが、すべてのノードの CPU 負荷平均統計にアクセスできる必要があります。これは水平スケーリングでは不可能です。個々の観測可能性パイプラインワーカーインスタンスは、全体のデータのスライスにしかアクセスすることができません。したがって、集計は階層化する必要があります。
上の図では、第 2 層のアグリゲーターは、第 1 層のアグリゲーターから全体データの集計されたサブストリームを受け取っています。これにより、単一のインスタンスが、ストリーム全体を処理し、単一障害点を導入することなく、グローバルビューを取得することができます。