割り当てとバースト上限について
このドキュメントでは、Google Security Operations の割り当てとバースト上限について説明します。
バースト上限の定義
バースト上限は、Google SecOps のサービス上限の一種で、データの取り込みの速度制限として機能します。これは、プラットフォームの共有インフラストラクチャをトラフィックの急激な大量のスパイクから保護するように設計されています。バースト上限は、5 分間のローリング ウィンドウ内の取り込み速度(メガバイト / 秒(MBps)またはギガバイト / 秒(GBps)で測定)を制限します。
バースト上限の計算方法
Google SecOps は、Google SecOps ライセンスに基づいて、購入した年間取り込み量(購入容量)に応じて、Google SecOps テナントにバースト上限を割り当てます。
ログ トラフィックの予想される変動と計画外のスパイクに対応するため、1 日のバースト上限は特定の範囲としてプロビジョニングされます。これにより、予想される 1 日の平均値(購入した年間容量を 365 日で割った値)の 1 ~ 3 倍(1 倍~ 3 倍)を取り込むことができます。この柔軟な容量割り当ては、オペレーションを中断することなく、標準的な取り込みスパイクを吸収するように設計されています。たとえば、購入した年間容量が 365 TB の場合、予想される 1 日の平均値は 1 TB です。プロビジョニングされたバースト上限は、1 日あたり 1 TB ~ 3 TB の範囲内(スループット範囲に換算すると約 12 MBps ~ 36 MBps)に厳密に収まります。データ取り込みがこのプロビジョニングされた 1 倍~ 3 倍の範囲を常に超える場合は、購入した年間容量を増やす必要があります。
バースト上限は、Google SecOps のお客様のテナントごとに適用されます。
次の表に、購入容量の量とバースト上限の対応を示します。
| 購入容量の例 | バースト上限の範囲 | 5 分間のバースト上限 | 最大バースト上限での取り込み(1 時間) | 最大バースト上限での取り込み(1 日) | 最大バースト上限での取り込み(年間) |
|---|---|---|---|---|---|
| 100 TB | 3 ~ 10 MBps | 0.9 ~ 3 GB | 約 34 GB | 約 822 GB | 300 TB |
| 500 TB | 16 ~ 48 MBps | 4.8 ~ 14.4 GB | 約 171 GB | 約 4 TB | 1.5 PB |
| 1 PB | 32 ~ 97 MBps | 9.6 ~ 29 GB | 約 343 GB | 約 8 TB | 3 PB |
| 5 PB | 158 ~ 476 MBps | 47.4 ~ 143 GB | 約 1.7 TB | 約 41 TB | 15 PB |
| 30 PB | 0.96 ~ 2.86 GBps | 288 ~ 858 GB | 約 10.3 TB | 約 247 TB | 90 PB |
極端な速度の急激なスパイクを含む取り込みトラフィックには、リージョンの安定性を保護するために、動的なレート制限または一時的なスロットリングが適用される場合があります。
この期間中、スパイクが収まるまでデータの取り込みが遅れることがあります。
超高スループットの要件については、超高スループットのカスタム キャパシティ プランニングをご覧ください。
pull ベースのフィードへのバースト上限の適用
Google SecOps では、pull ベースの取り込みも、ログタイプごとの全体的なバースト上限の 3 分の 1(33%)に制限されます(すべてのフィードで)。この制限は、pull ベースのデータ取り込み(通常はクラウドソースから)がテナントの全体的なバースト上限を使い果たし、push ベースの方法(Bindplane エージェント、フォワーダー、または Google SecOps API への直接取り込みなど)を使用したデータ取り込みが不足しないようにするために設けられています。
pull ベースの取り込み方法
pull ベースの方法には、Google SecOps がソース API に積極的にアクセスしてデータを取得する取り込み方法(Google SecOps ではソースタイプと呼ばれます)があります。 これには、Google SecOps でサポートされている次のソースタイプが含まれます。
- サードパーティ API
- Azure Event Hub
- Google Workspace からの直接取り込み Google Cloud
- Cloud Storage
- Cloud Storage フィード(イベント ドリブン)
- Amazon S3
- Amazon SQS
- Azure Blobstore
- SFTP リクエスト
- HTTP リクエスト
たとえば、テナントのバースト上限が 150 MBps に設定されていて、テナントがサードパーティ API コネクタ(pull ベースの取り込み方法)を使用して Okta ユーザー コンテキスト ログを取り込んでいる場合、システムはすべての Okta フィードの取り込み速度を合計で最大 [150/3 =] 50 MBps に制限します。この追加の上限は、全体的なデータの取り込み速度が割り当てられたバースト上限内にある場合でも適用されます。
pull ベースの取り込み方法のログタイプ レベルの上限の例外
通常、ログタイプ レベルの上限は pull ベースのフィードに適用されますが、次の例外があります。
- HTTPS ウェブフック: ログタイプ レベルの上限がある push ベースの方法です。
- Azure Event Hub: ログタイプ レベルの上限がない pull ベースの方法です。
バースト上限の実装方法
システムは 5 分間隔でバースト上限を適用します。たとえば、バースト上限が 50 MBps に設定されている場合、5 分ごとに最大 15 GB を取り込むことができます。最初の 2 分間で 15 GB をすべて取り込むと、そのウィンドウの残りの 3 分間は取り込みがブロックされます。この制限は、次の 5 分間隔の開始時に自動的にリセットされます。
ログタイプ レベルの上限は同じ方法で適用されますが、個々のログタイプ レベルで適用されます。たとえば、5 分ごとに pull ベースのフィードに 5 GB が割り当てられていて、単一のログタイプの取り込みデータ量が最初の 2 分間で 5 GB を超えた場合、そのウィンドウの残りの 3 分間は取り込みが一時停止します。制限は、次の 5 分間隔の開始時に自動的にリセットされます。
バースト上限を超えた場合のデータへの影響
バースト上限を超えると、Google SecOps は追加データの取り込みを一時停止し、データが pull ベースの方法と push ベースの方法のどちらで取り込まれているかに応じて、次のメカニズムがトリガーされます。
- pull ベースの方法を使用する場合: 取り込みは自動的にバッファリングされ、お客様による追加の設定は必要ありません。制限がリセットされ、Google SecOps がデータの取り込みを再開するまで、データはバッファ ストレージに保存されます。
- push ベースの方法を使用する場合: Google SecOps は、HTTP 429「Too Many Requests」エラーでデータの取り込みを一時的に拒否します。これにより、取り込みメカニズムが一時停止、バッファリング、再試行を行い、データが失われないようにします。
push ベースの取り込み方法を使用する場合、バッファリングと再試行の責任はお客様にあります(データのバッファリングと再試行に関するお客様の責任をご覧ください)。
バースト上限の拒否はデータ損失ではありません
バースト上限の拒否(HTTP 429)はデータ損失イベントではないことを理解することが重要です。 バースト上限の拒否(HTTP 429 エラー)は、データの取り込みの一時停止です。
push ベースのシステムに十分なディスク バッファリングと再試行ロジックがあることを確認することで、バースト上限に達しても、セキュリティ テレメトリーが完全に失われることはなく、わずかな遅延(取り込みの遅延)のみが発生します。
データ損失が発生するのは、送信システム(Bindplane エージェント、フォワーダー、スクリプトなど)がバースト上限の拒否エラーを無視し、再試行のために保存する代わりにログエントリを削除した場合のみです。
データのバッファリングと再試行に関するお客様の責任
Google SecOps は、pull ベースのデータの取り込み方法を使用して取り込まれるデータのバッファリングと再試行を自動的に管理しますが、push ベースのデータの取り込み方法(HTTPS ウェブフック、Bindplane、フォワーダー、Cribl など)を使用してデータを取り込む場合は、データのバッファリングと再試行はお客様の責任となります。
データのオーバーフローを効率的に処理するには、バースト上限に達したときにデータを自動的にバッファリングして再送信するようにシステムを構成する必要があります。
次の表に、両方の取り込み方法でバースト上限に達した場合の Google SecOps によるデータの取り込みの処理方法の主な違いを示します。
| 機能 | pull ベースの取り込み | push ベースの取り込み |
|---|---|---|
| 仕組み | Google SecOps がソース API に積極的にアクセスしてデータを取得します。 | システムが接続を開始し、データを Google に送信します。 |
| データのバッファリングと再試行の責任 | Google SecOps がバッファリングを自動的に管理します。バースト上限に達すると、Google SecOps は追加データの取り込みを一時停止します。制限がリセットされ、Google SecOps が取得を再開するまで、データはバッファ ストレージに保存されます。 バッファ ストレージには最大 90 日間データが保存され、その後データは削除されます。 |
お客様がバッファリングを管理する必要があります。Google SecOps が HTTP 429 で応答した場合、送信システムはこのエラーをキャッチし、データをローカル キュー(ディスクまたはメモリ)に保存して、後で再送信する必要があります。送信者が [失敗時に削除] に設定されている場合、データは失われます。 |
| データソース タイプ | サードパーティ API、Azure Event Hub、Google Workspace からの直接取り込み Google Cloud、Cloud Storage、Cloud Storage フィード(イベント ドリブン)、Amazon S3、Amazon SQS、Azure Blobstore、SFTP リクエスト、HTTP リクエスト。 | Google SecOps フォワーダー、Bindplane エージェント、Pub/Sub、Amazon Kinesis Firehose、HTTPS ウェブフック、取り込み API への直接取り込み。 |
| ユーザーの操作 | データの取り込み量を購入容量に合わせるための手順を行います。 | また、取り込みソースがデータの保持、バッファリング、再試行用に構成されていることを確認します。 詳細については、push ベースのシステムのバッファリングと再試行の構成をご覧ください。 |
pull ベースのフィードのバッファリングされたデータがバックフィルされるタイミング
pull ベースの取り込み方法を使用するフィードの場合、バースト上限ウィンドウがリセットされると、Google SecOps はバッファリングされたデータをバックフィルし、バッファリングされたデータよりもライブデータを優先します。このメカニズムにより、バッファリングされたデータのバックログが、受信するライブデータ トラフィックを妨げることがなくなります(検出の遅延が複合化される可能性があります)。
割り当てられたバースト上限を確認する方法
Google SecOps テナントに割り当てられたバースト上限を確認するには、次の操作を行います。
- Google SecOps コンソールで、[ダッシュボード] > [データの取り込みと健全性] に移動します。
- [バースト上限グラフ - 割り当て上限] を確認します。グラフには、割り当てられた上限(フラットライン)と実際の取り込み速度が表示されます。
バースト上限に近づいているか、超えているかを確認する
使用状況は、組み込みのダッシュボードまたは Cloud Monitoring を使用して追跡できます。
Google SecOps ダッシュボードを使用して、バースト上限に近づいているか、超えているかを確認する
[ダッシュボード] > [データの取り込みと健全性] に移動して、次の情報を確認します。
- 取り込み速度グラフ: 現在のスループットを示します。
- バースト拒否グラフ: バースト上限を超えたために拒否されたログの量(HTTP 429 エラー)を示します。
Cloud Monitoring を使用して、バースト上限に近づいているか、超えているかを追跡する
Metrics Explorer を使用して、カスタム アラートを作成できます。 Google Cloud 取り込まれたバイト数がバースト上限のしきい値を超えたときに通知する取り込みアラートを作成することをおすすめします。
関連する指標は次のとおりです。
- 取り込まれた量:
chronicle.googleapis.com/ingestion/log/bytes_count - 拒否された量:
chronicle.googleapis.com/ingestion/log/quota_rejected_bytes_count
以降のセクションでは、モニタリングとアラートの PromQL クエリの例を示します。
バースト上限の使用状況を表示する
バースト上限の使用状況を表示するには、次の PromQL クエリを使用します。
100 * sum(rate(chronicle_googleapis_com:ingestion_log_bytes_count{monitored_resource="chronicle.googleapis.com/Collector"}[10m]))/min(min_over_time(chronicle_googleapis_com:ingestion_quota_limit{monitored_resource="chronicle.googleapis.com/Collector"}[10m]))
バースト上限を超えた後に拒否されたバイト数を表示する
バースト上限を超えた後に拒否されたバイト数を表示するには、次の PromQL クエリを使用します。
topk(5, sum by ("collector_id","log_type")(rate({"__name__"="chronicle.googleapis.com/ingestion/log/quota_rejected_bytes_count","monitored_resource"="chronicle.googleapis.com/Collector","quota_type"="SHORT_TERM_DATA_RATE"}[${__interval}])))
バースト上限の 70% に達したときにアラートをトリガーする
バースト上限の 70% に達したときにアラートをトリガーするには、次の PromQL クエリを使用します。
100 * topk(5, sum by ("collector_id","log_type")(rate({"__name__"="chronicle.googleapis.com/ingestion/log/quota_rejected_bytes_count","monitored_resource"="chronicle.googleapis.com/Collector","quota_type"="SHORT_TERM_DATA_RATE"}[${__interval}]))) > 70
取り込みアラートの設定の詳細については、取り込みのインサイトに Cloud Monitoring を使用するをご覧ください。
push ベースの方法によるバースト上限の拒否を処理する
push ベースの方法を使用して受信データのバースト上限に達したために拒否エラー(HTTP 429)が発生した場合は、次の手順を行うことをおすすめします。
- バッファリングを確認する: 取り込みソースがデータをバッファリングして再試行していることを確認します。
- 取り込みを最適化する: 取り込みスクリプトを確認し、不要なデータを送信していないか、大量のバッチで API に一斉にアクセスしていないかを確認します。可能であれば、過去のデータのアップロードを分散します。データ処理パイプライン機能を使用して、冗長なデータをフィルタで除外します。
- 待機する: 一時的なスパイクの場合は、5 分間のウィンドウがリセットされるまで待ってから再試行するだけで十分なことがよくあります。
構成例については、push ベースのシステムのバッファリングと再試行の構成をご覧ください。
超高スループットのカスタム キャパシティ プランニング
このドキュメントの他のセクションに記載されている内容にかかわらず、3 GBps を超えるデータの取り込みスループットは超高スループットと見なされます。大規模なデータ移行を計画している場合、超高スループットの維持を想定している場合、または大量の取り込みバーストを常に生成するアーキテクチャを実行している場合は、カスタム キャパシティ プロビジョニングについて Google のアカウント担当者にお問い合わせください。
専用リージョンの容量拡張のデプロイには数週間かかる場合があるため、スループット要件に対応できるように、エクストリームな取り込みイベントが予想される場合は、少なくとも 90 日前までに Google Cloud サポートに通知してください。
よくある質問
以降のセクションでは、よくある質問とその回答について説明します。
バースト上限を引き上げることはできますか?
データ取り込み量が永続的に増加することが予想される場合は、Google SecOps の営業担当者にお問い合わせのうえ、購入容量を増やすことができます。
pull ベースのフィードのログタイプ レベルの上限を引き上げることはできますか?
特定のログタイプのログタイプ レベルの上限を引き上げるには、事前に Google SecOps テクニカル サポートにリクエストを送信します。
1 つのログタイプのログタイプ レベルの上限を引き上げても、他のログタイプに適用される上限や全体的なバースト上限は変更されません。
データのバックログを追跡することはできますか?
現在のところ、できません。
データのバックログをクリアするにはどうすればよいですか?
非常に大きなデータのバックログが蓄積されていて、そのバックログをクリアしてバースト上限の割り当てを解放する場合は、次の操作を行います。
- 追加の容量を購入して上限を引き上げます。
- ボリュームが予期せず急増した特定のフィードを無効にします。
Google SecOps テクニカル サポートにバックログの削除をリクエストします。
バックログを削除するには、バックフィルされたデータの再試行リクエストがすべて正常に処理されるまで、データフィードが一時的に無効になります。この間、新しいデータを取り込むことはできません。
バックログがクリアされると、フィードが再度有効になり、新しいデータが流れ込みます。バックログのサイズによっては、数分から数時間かかることがあります。
バースト上限は、データ処理パイプラインへのデータの取り込みにも適用されますか?
Google SecOps のデータ処理パイプラインに未加工のログデータを送信するデータフィードに適用される取り込み速度の上限は、テナントのバースト上限よりも高く設定されています。
バースト上限を超えると、データ処理パイプラインは次の条件に従って追加のリクエストの受け入れを停止します。
- pull ベースの方法を使用する場合: 取り込みは自動的にバッファリングされ、追加の設定は必要ありません。
- push ベースの方法を使用する場合: Google SecOps は、HTTP 429 "Too Many Requests" エラーでデータを一時的に拒否します。
バースト上限がトリガーされた後に変換されたデータは、次の 5 分間のウィンドウで上限がリセットされるまで、内部キューに一時的にバッファリングされます。
バースト上限が契約した上限よりも低い場合はどうすればよいですか?
バースト上限が契約した上限よりも低い場合は、Google サポート(Google SecOps サポートを参照)にお問い合わせください。その際、予想されるバースト上限をお知らせください。
さらにサポートが必要な場合コミュニティ メンバーや Google SecOps のプロフェッショナルから回答を得ることができます。