試算の単位

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

単位サイズ観測可能性パイプラインワーカースループット*
非構造化ログイベント~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、ネットワークロードバランサー、観測可能性パイプラインワーカーアグリゲーターに分解し、Agent からのデータをロードバランサー、観測可能性パイプラインワーカー、そして他の宛先に送る様子を示した図

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

クラウドリージョンを Agent、ブローカー、観測可能性パイプラインアグリゲーターに分解して示した図。Agent からのデータはブローカーに送られ、ブローカーと観測可能性パイプラインワーカーとの間で送受信され、ワーカーから他の宛先に送信される

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

ロードバランシング

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

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

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

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

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

クラウドプロバイダー推奨事項
AWSAWS ネットワークロードバランサー (NLB)
Azure内部 Azure ロードバランサー
Google Cloud内部 TCP/UDP ネットワークロードバランサー
プライベートHAProxy、Nginx、またはレイヤー 4 をサポートするその他のロードバランサー
ロードバランサーの構成

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

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

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

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

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

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

垂直スケーリング

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

オートスケーリング

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

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