割り当てとバースト上限について
このドキュメントでは、Google Security Operations の割り当てとバースト上限について説明します。
バースト上限の定義
バースト上限は、Google SecOps のサービス上限の一種で、データの取り込みの速度制限として機能し、プラットフォームの共有インフラストラクチャをトラフィックの急激な大量の急増から保護するように設計されています。バースト上限は、5 分間のローリング ウィンドウ内で取り込み率（メガバイト/秒（MBps）またはギガバイト/秒（GBps）で測定）を制限します。
バースト上限の計算方法
Google SecOps は、Google SecOps ライセンスに基づいて、購入した年間取り込み量（購入した容量）に基づいて、Google SecOps テナントにバースト上限を割り当てます。
ログ トラフィックの予想される変動と計画外の急増に対応するため、1 日のバースト上限は特定の範囲としてプロビジョニングされます。これにより、1 日の予想平均値（購入した年間容量を 365 日で割った値）の 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 |
速度が急激に上昇する極端な取り込みトラフィックは、リージョンの安定性を保護するために、動的レート制限または一時的なスロットリングの対象となる場合があります。
この期間中、スパイクが収まるまでデータの取り込みが遅延する可能性があります。
超高スループットの要件については、超高スループットのカスタム キャパシティ プランニングをご覧ください。
プルベースのフィードに対するバースト上限の適用性
また、Google SecOps では、ログタイプごとの全体的なバースト上限の 3 分の 1（33%）にプルベースの取り込みが制限されます（すべてのフィードで）。この上限は、プルベースのデータの取り込み（通常はクラウドソースから）がテナントの全体的なバースト上限を超えて、プッシュベースの方法（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 コネクタ（プルベースの取り込み方法）を使用して Okta ユーザー コンテキスト ログを取り込んでいる場合、システムはすべての Okta フィードの取り込みレートを合計で最大 [150/3 =] 50 MBps に制限します。この追加の制限は、データ取り込みの全体的なレートが割り当てられたバースト上限内であっても適用されます。
プルベースの取り込み方法の logtype レベルの上限の例外
通常、ログタイプ レベルの上限はプルベースのフィードに適用されますが、次の例外があります。
- HTTPS ウェブフック: これは、ログタイプ レベルの制限があるプッシュベースの方法です。
- Azure Event Hub: ログタイプ レベルの制限がないプルベースのメソッドです。
バースト上限の実装方法
システムは、5 分間隔でバースト上限を適用します。たとえば、バースト上限が 50 MBps に設定されている場合、5 分ごとに最大 15 GB を取り込むことができます。最初の 2 分間で 15 GB すべてを取り込むと、そのウィンドウの残りの 3 分間は取り込みがブロックされます。この上限は、次の 5 分間隔の開始時に自動的にリセットされます。
ログタイプ レベルの上限も同様に適用されますが、個々のログタイプのレベルで適用されます。たとえば、プルベースのフィードに 5 分ごとに 5 GB が割り当てられていて、最初の 2 分間で単一のログタイプの取り込みデータ量の合計が 5 GB を超えると、そのウィンドウの残りの 3 分間は取り込みが一時停止されます。上限は、次の 5 分間隔の開始時に自動的にリセットされます。
バースト上限を超えた場合、データはどうなりますか？
バースト上限を超えると、Google SecOps は追加データの取り込みを一時停止し、データの取り込みにプルベースの方法とプッシュベースの方法のどちらを使用しているかに応じて、次のメカニズムがトリガーされます。
- プルベースのメソッドを使用する: 取り込みは自動的にバッファリングされるため、お客様による追加の構成は必要ありません。データは、上限がリセットされ、Google SecOps がデータの取り込みを再開するまで、バッファ ストレージに保存されたままになります。
- push ベースの方法を使用する: Google SecOps は、HTTP 429「Too Many Requests」エラーでデータの取り込みを一時的に拒否します。これにより、取り込みメカニズムに一時停止、バッファリング、再試行が指示され、データが失われることはありません。
プッシュベースの取り込み方法を使用する場合、バッファリングと再試行の責任はお客様にあります（データ バッファリングと再試行に関するお客様の責任をご覧ください）。
バースト上限の拒否はデータ損失ではない
バースト制限の拒否（HTTP 429）はデータ損失イベントではないことを理解しておくことが重要です。バースト上限の拒否（HTTP 429 エラー）は、データの取り込みの一時停止です。
プッシュベースのシステムに十分なディスク バッファリングと再試行ロジックを確保することで、バースト上限に達しても、セキュリティ テレメトリーが完全に失われることはなく、わずかな遅延（取り込みの遅延）が発生するだけです。
データ損失が発生するのは、送信システム（Bindplane エージェント、転送ツール、スクリプトなど）がバースト上限超過エラーを無視し、再試行のためにログエントリを保存する代わりに削除した場合のみです。
データ バッファリングと再試行に関するお客様の責任
Google SecOps は、プルベースのデータの取り込み方法を使用して取り込まれるデータのデータ バッファリングと再試行を自動的に管理しますが、プッシュベースのデータの取り込み方法（HTTPS ウェブフック、Bindplane、フォワーダー、Cribl など）を使用して取り込まれるデータのデータ バッファリングと再試行はユーザーの責任となります。
バースト上限に達したときにデータを自動的にバッファリングして再送信するようにシステムを構成し、データ オーバーフローを効率的に処理する必要があります。
次の表は、両方のタイプの取り込み方法でバースト上限に達した場合に、Google SecOps がデータの取り込みを処理する方法の主な違いを示しています。
| 機能 | pull ベースの取り込み | push ベースの取り込み |
|---|---|---|
| 仕組み | Google SecOps は、ソース API に積極的にアクセスしてデータを取得します。 | システムが接続を開始し、データを Google に送信します。 |
| データ バッファリングと再試行の責任 | Google SecOps はバッファリングを自動的に管理します。バースト上限に達すると、Google SecOps は追加データの取り込みを一時停止します。データは、上限がリセットされ、Google SecOps がフェッチを再開するまでバッファ ストレージに保存されます。 バッファ ストレージには最大 90 日間データが保存され、その後データは削除されます。 |
バッファリングはお客様が管理する必要があります。Google SecOps が HTTP 429 で応答した場合、送信システムはこのエラーをキャッチし、データをローカル キュー（ディスクまたはメモリ）に保存して、後で送信を再試行する必要があります。送信者が [drop on failure] に設定されている場合、データは失われます。 |
| データソース タイプ | サードパーティ 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 Webhook、取り込み API への直接送信。 |
| ユーザーの操作 | データの取り込み量を購入した容量に合わせる手順を行います。 | また、取り込みソースがデータ保持、バッファリング、再試行用に構成されていることを確認してください。 詳細については、プッシュベース システムのバッファリングと再試行の構成をご覧ください。 |
プルベースのフィードのバッファリングされたデータがバックフィルされるとき
プルベースの取り込み方法を使用するフィードの場合、バースト上限ウィンドウがリセットされると、Google SecOps はバッファリングされたデータをバックフィルします。このとき、バッファリングされたデータよりもライブデータが優先されます。このメカニズムにより、バッファリングされたデータのバックログが、受信するライブデータ トラフィックを妨げることがなくなります（検出遅延が複合化される可能性があります）。
割り当てられたバースト上限を表示する方法
Google SecOps テナントに割り当てられているバースト上限を確認するには、次の操作を行います。
- Google SecOps コンソールで、[ダッシュボード] > [データ取り込みと健全性] に移動します。
- [Burst Limit Graph - Quota Limit] を表示します。グラフには、実際の取り込みレートに対する割り当て上限（水平線）が表示されます。
バースト上限に近づいているか、上限を超えているかを追跡する
使用率は、組み込みのダッシュボードまたは Cloud Monitoring を使用して追跡できます。
Google SecOps ダッシュボードを使用して、バースト上限に近づいているか、上限を超えているかを確認する
[ダッシュボード] > [データの取り込みと健全性] に移動し、次の情報を確認します。
- 取り込みレートのグラフ: 現在のスループットが表示されます。
- バースト拒否グラフ: バースト上限を超えたために拒否されたログの量（HTTP 429 エラー）が表示されます。
Cloud Monitoring を使用して、バースト上限に近づいているか、バースト上限を超えているかを追跡する
Google Cloud の Metrics Explorer を使用して、カスタム アラートを作成できます。取り込まれたバイト数がバースト上限のしきい値を超えたときに通知する取り込みアラートを作成することをおすすめします。
関連する指標は次のとおりです。
- 取り込まれたボリューム:
chronicle.googleapis.com/ingestion/log/bytes_count - 拒否されたボリューム: `chronicle.googleapis.com/ingestion/log/quota_rejected_bytes_count
すぐに使えるアラート ポリシー
Google SecOps には、取り込み割り当てをモニタリングするために有効にできる Cloud Monitoring のアラート ポリシーが用意されています。
これらのポリシーを見つけて有効にする手順は次のとおりです。
- Google Cloud コンソールで、[モニタリング] > [統合] に移動します。
- 統合のリストから [Chronicle Security] を選択します。
- [アラート] タブをクリックします。
- 次のサンプル アラート ポリシーを確認して有効にします。
- 取り込み割り当て上限接近アラート ポリシー: データ取り込み量が割り当て上限に近づいているかどうかを検出します。
- 取り込み割り当て拒否アラート ポリシー: 取り込み割り当ての不足（HTTP 429 エラー）により取り込みリクエストが拒否されているかどうかを検出します。
例
以降のセクションでは、モニタリングとアラート用の 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 ベースの方法で受信データのバースト上限に達したために拒否エラー（HTTP 429）が発生した場合は、次の手順をおすすめします。
- バッファリングを確認する: 取り込み元がデータをバッファリングして再試行していることを確認します。
- 取り込みを最適化する: 取り込みスクリプトを確認し、不要なデータを送信したり、大量のバッチを一度に送信して API を storming したりしていないことを確認します。可能であれば、過去のデータ アップロードを分散させます。データ処理パイプライン機能を使用して、冗長なデータをフィルタで除外します。
- 待機: 一時的なスパイクの場合は、5 分間のウィンドウがリセットされるまで待ってから、もう一度試すだけで十分なことがよくあります。
構成例については、プッシュベースのシステムのバッファリングと再試行の構成をご覧ください。
超高スループットのカスタム キャパシティ プランニング
このドキュメントの他のセクションに記載されている内容にかかわらず、3 GBps を超えるデータの取り込みスループットは超高スループットと見なされます。大規模なデータ移行を計画している場合、超高スループットの継続的な使用を想定している場合、または大量の取り込みバーストを継続的に生成するアーキテクチャを実行している場合は、アカウント チームに連絡してカスタム容量のプロビジョニングを依頼する必要があります。
専用のリージョン容量の拡張には数週間かかることがあるため、スループット要件に対応できるように、予想される大量取り込みイベントの少なくとも 90 日前までに Google Cloud サポートに通知してください。
よくある質問
以降のセクションでは、よくある質問とその回答を紹介します。
バースト上限を引き上げることはできますか？
データ取り込み量の恒久的な増加が見込まれる場合は、Google SecOps の営業担当者に連絡して、購入した容量を増やすことができます。
プルベースのフィードの logtype レベルの上限を引き上げることはできますか？
特定のログタイプのログタイプ レベルの上限を引き上げるには、事前に Google SecOps テクニカル サポートを使用してリクエストを送信します。
1 つのログタイプのログタイプ レベルの上限を増やしても、他のログタイプに適用される上限や全体的なバースト上限は変更されません。
データ バックログを追跡することはできますか？
現在のところ、できません。
データ バックログを解消するにはどうすればよいですか？
大量のデータ バックログが蓄積され、バースト上限の割り当てを解放するためにバックログをクリアしたい場合は、次の操作を行います。
- 上限を引き上げるには、追加の容量を購入します。
- ボリュームが想定外に急増した特定のフィードを無効にします。
Google SecOps のテクニカル サポートにバックログの削除をリクエストします。
バックログを削除するには、バックフィルされたデータのすべての再試行リクエストが正常に処理されるまで、データフィードが一時的に無効になります。この期間中は、新しいデータを取り込むことはできません。
バックログがクリアされると、フィードが再度有効になり、新しいデータが流れ込むようになります。バックログのサイズによっては、数分から数時間かかることがあります。
バースト上限は、データ処理パイプラインへのデータの取り込みにも適用されますか？
Google SecOps のデータ処理パイプラインに未加工のログデータを送信するデータフィードに適用される取り込みレートの上限は、テナントのバースト上限よりも高く設定されています。
バースト上限を超えると、データ処理パイプラインは次のルールに従って追加のリクエストの受け入れを停止します。
- プルベースのメソッドを使用する: 取り込みは自動的にバッファリングされるため、追加の構成は必要ありません。
- push ベースの方法を使用する: Google SecOps は、HTTP 429「Too Many Requests」エラーでデータを一時的に拒否します。
バースト上限がトリガーされた後に変換されたデータは、上限が次の 5 分間のウィンドウでリセットされるまで、内部キューに一時的にバッファリングされます。
バースト上限が契約した値よりも低い場合はどうすればよいですか？
バースト上限が契約した値よりも低い場合は、Google サポート（Google SecOps サポートを参照）にお問い合わせください。その際、想定されるバースト上限を含めてください。
さらにサポートが必要な場合 コミュニティ メンバーや Google SecOps のプロフェッショナルから回答を得ることができます。