ゲートウェイの信頼性を維持し、データ損失を防ぐために、ゲートウェイに十分なリソースを割り当てることが重要です。ゲートウェイがダウンすると、テレメトリー データが失われる危険があり、監視および分析機能に影響を与える可能性があります。
このガイドは、環境内で Pipeline Control ゲートウェイをデプロイおよび拡張するための適切なリソースを決定するのに役立ちます。最適なパフォーマンスと効率的なデータ処理を保証するには、これらの仕様を理解することが不可欠です。
デフォルト設定
デフォルトでは、ゲートウェイは、ポッドあたり 2 GB のデフォルトのメモリ割り当てと 1 つの vCPU で構成されます。さらに、ゲートウェイ クラスターはセットアップ時に次の設定で初期構成されます (これらはゲートウェイの初期セットアップ後に変更できます)。
最小レプリカ数: 6 最大レプリカ数: 10 ターゲットCPU使用率: 60
ゲートウェイのスケーリング
Pipeline Controlゲートウェイは、受信したテレメトリー データ全体を処理するのに十分な計算能力を維持する必要があります。 さまざまなエージェントやテレメトリー ワークロードの可変サイズとスループットを考慮して、必要な容量を予測するために、段階的なアプローチでゲートウェイ クラスターをスケーリングすることをお勧めします。
- テレメトリーデータをゲートウェイに送信するように、少数の（約15～35）非本番環境のエージェントを設定します。これらのエージェントが、本番環境でゲートウェイに送信する予定のエージェントおよびテレメトリーペイロードの種類を代表するものであることを確認してください（たとえば、New Relic Infrastructure、Java APM、Fluent Bitなど）。それぞれのエージェントの数を控えておいてください。
- このテレメトリーデータをNew Relicで収集していることを確認します。
- ゲートウェイクラスタを監視して、vCPU の数と数分間の負荷にわたる平均 CPU 使用率を特定します。 これにより、このエージェント セットを実行するために必要な vCPU の数がわかります。
- 設定したエージェントの数、ピーク時の本番環境で実行すると予想されるエージェントの数、およびステップ3のCPU使用率に基づいて、線形外挿してください。たとえば、ゲートウェイ経由で25個のJava APMエージェントを実行しており、1つのvCPUのみが65％の負荷で実行されていることが確認できた場合、
<=8つのvCPUで200個のJava APMエージェントを実行できると予想されます。 - ゲートウェイにデータを送信するエージェントのセットをさらに多く構成し (たとえば、100)、手順 4 の線形外挿が依然として当てはまることを確認します。
maxReplicasが、本番環境で実行することが予想されるエージェントの数に応じて十分なポッドをスケーリングできる大きさであることを確認します。- データをゲートウェイに送信するようにすべての運用エージェントとテレメトリーデータを構成したら、ゲートウェイのクラスタの監視を続けて、それらが 100% 以上の容量で動作していないかどうかを確認します。
性能仕様
単一の CPU コアと MELT タイプごとに 100 のドロップ ルールを備えたゲートウェイは、次のボリュームのテレメトリー データを処理できます。
データ型 | 処理能力 |
|---|---|
指標 | 1秒あたり7,000データポイント |
イベント | 毎秒4,500イベント |
ログ | 2,700 ログ/秒 |
トレース | 1秒あたり3,300スパン |
エージェントの処理能力
1 つのゲートウェイ ポッドは、1 秒あたり 26 KB から 250 KB の非圧縮データのリクエスト サイズで、15 〜 35 個のエージェントを処理できます。
ヒント
これらの容量の見積もりは、既存のデプロイメントからの測定に基づいています。 実際の要件は、特定のデータ パターンと監視のニーズによって異なる場合があります。
ゲートウェイ設定の推奨事項
ゲートウェイのパフォーマンスと拡張性をさらに強化するには、お客様の考えに基づいて次の設定を検討してください。 これらの設定にアクセスするには、 New Relic Control > Gateway > Settingsに移動します。
重要
インストレーションモードの違い: 設定はフリートレベルで構成され、そのフリート内のすべてのクラスタに適用されます。フリートがFluxなしのインストレーションを使用している場合、設定ページにはスケーリングおよびバージョン設定の現在の値が読み取り専用として表示されます。ただし、2つのトラブルシューティングトグル（診断ログの収集、ゲートウェイルールのバイパス）は、どちらのモードでも引き続き編集可能です。Pipelineの設定変更（ルール、サンプリング、変換）は、両方のインストレーションモードでConfigMapを介して引き続き自動的にデプロイされます。Fluxを使用しないフリートの場合、インストレーション後のスケーリングはHorizontal Pod Autoscaler（HPA）で、バージョンはHelmアップグレードで管理します。手順については、Fluxを使用しないゲートウェイの管理を参照してください。
最小および最大のレプリカ
- 最小レプリカ:定期的なデータ ロードに対応し、冗長性と信頼性を確保するためにゲートウェイ レプリカのベースライン数を設定します。これにより、データ損失を防ぎ、ピーク時のパフォーマンスの安定性を維持できます。推奨される最小値は2で、これがデフォルト設定でもあります。
- 最大レプリカ数:ピーク使用期間を効果的に処理するために必要なレプリカの最大数を決定します。この設定により、ゲートウェイクラスタを動的に拡張でき、パフォーマンスを損なうことなく高トラフィックに十分なリソースを提供できます。 最大15 個のレプリカを設定できます。
CPU使用率閾値
- スケーリング値:ゲートウェイクラスタが自動的にスケーリングする CPU 使用率のパーセンテージを指定します。 スケーリング値を構成すると、効率的なリソース管理が保証され、過密状態が防止され、安定したデータ処理が維持されます。 デフォルト設定は60%です。
健康とパフォーマンス管理
- 診断ログを収集する:インサイトのゲートウェイ診断ログを定期的にチェックして、ゲートウェイの正常性と動作を確認します。 ログを監視することは、タイムリーなトラブルシューティングと最適なパフォーマンスの維持に不可欠です。デフォルトでは、診断ログはオフになっています。
- ゲートウェイ ルールをバイパスする:利用可能な CPU リソースが少ない場合は、複雑なゲートウェイ ルールをバイパスします。 この予防措置により、機密データが受信された場合でもNew Relicへのデータフローが継続され、リソースの節約と中断のないテレメトリ処理が可能になります。 デフォルトでは、ゲートウェイ ルールのバイパスはオフになっています。
ゲートウェイのバージョン管理
- バージョン選択: フリート内のすべてのクラスタにデプロイするゲートウェイソフトウェアのバージョン（Helmチャートのバージョン）を選択します。利用可能なバージョンはドロップダウンに表示されます。Fluxがインストールされたフリートの場合は、新しいバージョンを選択し、Save settings [設定を保存]をクリックしてデプロイメントのドラフトを作成してから、そのドラフトをデプロイしてフリート内のすべてのクラスタをアップグレードします。変更を適用するには、変更のデプロイを参照してください。Fluxなしでインストールされたフリートの場合、バージョンフィールドは読み取り専用です。Fluxを使用しないゲートウェイの管理で説明されているように、Helmコマンドを使用して手動でアップグレードする必要があります。
次のステップ
次に、エージェント設定を変更してゲートウェイ経由でデータを送信する方法を学びます。