최대 한도
이 문서에서는 Google Security Operations 리소스에 적용되는 급증 한도, 특히 단일 고객이 Google SecOps에 처리할 수 있는 데이터 양을 설명합니다. 급증 한도는 모든 고객이 공유하는 사용 리소스를 제한합니다.
- 단일 고객이 사용할 수 있는 데이터 처리량의 상한선입니다. 이렇게 하면 단일 고객의 데이터가 갑자기 유입되어도 다른 고객에게 영향을 미치지 않습니다.
- 각 고객의 공유 리소스 사용을 모니터링합니다.
- 일시적 급증 한도를 자동으로 적용하는 구성을 유지합니다.
- 버스트 한도를 요청하거나 변경할 수 있는 수단을 제공합니다.
서지 보호의 경우 버스트 한도는 5분 동안 측정됩니다. 일일 처리 한도가 아닙니다.
고객당 최대 한도 증가
처리 속도를 빠르게 늘리려는 경우 데이터 처리가 안정적으로 유지되도록 사전 계획하고 이를 보장할 수 있습니다. 최대 한도 증가를 요청하려면 사전에 Google SecOps 기술 지원팀에 문의하세요.
일시적 급증 한도 개요
급증 한도는 한 고객이 Google SecOps로 전송할 수 있는 데이터 양을 제한합니다. 이렇게 하면 공정성을 보장하고 단일 고객의 처리량 급증으로 인해 다른 고객에게 미치는 영향을 방지할 수 있습니다. 급증 제한을 사용하면 고객 데이터 처리가 원활하게 이루어지며 지원 티켓을 사용하여 사전에 조정할 수 있습니다. Google SecOps에서는 처리량을 기준으로 다음과 같은 분류를 사용하여 급증 한도를 적용합니다.
| 최대 한도 | 초당 최대 버스트 한도에서 연간 등가 데이터 |
|---|---|
| 88 MBps | 2.8 PB |
| 350 MBps | 11 PB |
| 886 MBps | 28 PB |
| 2.6 GBps | 82 PB |
최대 한도에는 다음 가이드라인이 적용됩니다.
- 최대 처리량 한도는 현재 처리 한도의 2~7배입니다.
- 급증 한도에 도달하면 올바르게 구성된 처리 소스가 추가 데이터를 버퍼링하도록 설정해야 합니다. 데이터를 삭제하도록 구성해서는 안 됩니다.
- Google Cloud 및 API 피드와 같은 가져오기 기반 처리의 경우 처리가 자동으로 버퍼링되며 추가 구성이 필요하지 않습니다.
- 전달자, 워크플로, API 처리와 같은 푸시 기반 처리의 경우 급증 한도에 도달하면 데이터를 다시 전송하도록 시스템을 구성합니다. BindPlane 및 Crible의 경우 버퍼링을 구성합니다.
- 버스트 한도에 도달하기 전에 한도를 늘릴 수 있습니다.
- 최대 한도에 근접했는지 확인하려면 최대 한도 사용량 보기를 참고하세요.
최대 한도 사용량 보기
Google SecOps 또는 Cloud Monitoring을 사용하여 최대 한도 초과 사용량을 확인할 수 있습니다.
Google SecOps 대시보드를 사용하여 최대 한도 확인하기
한도 사용량을 보려면 Google SecOps 데이터 수집 및 상태 대시보드에서 다음 시각화를 사용하세요.
- 수집 한도 그래프: 수집 속도와 초당 한도를 보여줍니다.
- 버스트 거부 그래프: 버스트 한도를 초과하여 거부된 로그의 양을 표시합니다.
버스트 한도 그래프 및 버스트 거부 그래프 시각화를 보려면 다음 단계를 따르세요.
- Google SecOps 메뉴에서 대시보드를 선택합니다.
기본 대시보드 섹션에서 데이터 처리 및 상태를 선택합니다.
표시되는 데이터 수집 및 상태 대시보드에서 급증 한도 그래프 및 급증 거부 그래프 시각화를 볼 수 있습니다.
Cloud Monitoring을 사용하여 최대 한도 보기
Google Cloud 콘솔에서 Google SecOps 급증 한도를 보려면 Google Cloud 한도와 동일한 권한이 필요합니다. 자세한 내용은 Cloud Monitoring에 액세스 권한 부여를 참고하세요.
차트를 사용하여 측정항목을 확인하는 방법에 대한 자세한 내용은 측정항목 탐색기로 차트 만들기를 참고하세요.
최대 한도 사용량을 보려면 다음 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 쿼리를 사용하세요.
sum(rate(chronicle_googleapis_com:ingestion_log_quota_rejected_bytes_count{monitored_resource="chronicle.googleapis.com/Collector"}[15m]))
처리된 바이트가 최대 처리량 한도의 70% 를 초과할 때 알림을 만들려면 다음 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])) > 70
수집 소스에서 데이터 버퍼링
다음 표에서는 처리 소스에 따라 엔터프라이즈의 데이터를 삭제하지 않고 버퍼링하는 데 필요한 구성을 설명합니다.
| 수집 소스 | 버퍼링 구성 |
|---|---|
| Google Cloud 및 Chronicle API 피드 | 자동으로 버퍼링 제공 |
| 전달자, 웹훅, API 처리 | 재시도 구성 |
| BindPlane, Cribl, 전달자 | 영구 큐 구성 |
문제 해결
다음 가이드라인을 따르면 최대 전송량 한도를 초과하지 않을 수 있습니다.
- 처리된 바이트 양이 급증 한도 기준을 초과하면 알림을 보내는 처리 알림을 만듭니다. 처리 알림 설정에 관한 자세한 내용은 처리 알림에 Cloud Monitoring 사용을 참고하세요.
처리 소스와 양을 식별하려면 측정항목
chronicle.googleapis.com/ingestion/log/bytes_count와 함께collector_id,log_type를 사용하여 모니터링 알림을 만듭니다. 처리 소스 및 양을 식별하려면 다음 PromQL 쿼리를 사용하세요.sum by (collector_id,log_type)(rate(chronicle_googleapis_com:ingestion_log_bytes_count{monitored_resource="chronicle.googleapis.com/Collector"}[5m]))처리량이 평소 처리량의 4배 이상 증가할 것으로 예상되면 Google SecOps 기술 지원팀에 미리 문의하여 급증 한도를 늘리세요.
Google SecOps 전달기를 사용하여 데이터를 수집하는 경우 버스트 한도를 초과할 때 디스크 버퍼를 사용하여 데이터를 버퍼링할 수 있습니다. 자세한 내용은 전달자에 디스크 버퍼 사용을 참고하세요.
다음 표에는 처리 방법과 급증 한도에 도달할 때 취해야 하는 해당 작업이 나와 있습니다.
| 처리 모드 | 제안된 작업 |
|---|---|
| Ingestion API | 일시적 한도 미만으로 돌아올 때까지 기다립니다. 처리를 더 빨리 재개하려면 Google SecOps 기술 지원팀에 문의하세요. |
| 피드 관리 | 일시적 한도 미만으로 돌아올 때까지 기다립니다. 처리를 더 빨리 재개하려면 Google SecOps 기술 지원팀에 문의하세요. |
| 전달자 | 버스트 한도를 초과할 때 디스크 버퍼를 사용하여 데이터를 버퍼링합니다. |
| Amazon Data Kinesis, Pub/Sub 또는 웹훅을 사용하는 HTTPS 푸시 처리 | 보관 기간이 최대한 긴 값으로 설정되어 있는지 확인합니다. 예를 들어 Pub/Sub의 보관 기간을 설정하려면 구독 메시지 보관 구성을 참고하세요. |
전달자에 디스크 버퍼 사용
Google SecOps SIEM 전달기를 사용하는 경우 버스트 한도가 초과될 때 디스크 버퍼를 사용하여 데이터를 버퍼링하는 것이 좋습니다. 수집기에서 사용하는 최대 RAM 크기는 4GB입니다. 수집기 구성에서 max_file_buffer_bytes 설정을 사용하여 이 한도를 설정할 수 있습니다. 4GB가 넘는 데이터를 버퍼링하려면 디스크 버퍼를 사용하세요. 디스크 버퍼 크기를 결정하려면 다음 MQL 쿼리를 사용하여 전달자가 처리하는 속도를 확인합니다.
sum(rate(chronicle_googleapis_com:ingestion_log_bytes_count
{monitored_resource="chronicle.googleapis.com/Collector", collector_id!~ "
(aaaaaaaa-aaaa-aaaa-aaaa-aaaaaaaaaaaa
|bbbbbbbb-bbbb-bbbb-bbbb-bbbbbbbbbbbb
|cccccccc-cccc-cccc-cccc-cccccccccccc
|dddddddd-dddd-dddd-dddd-dddddddddddd
|aaaa2222-aaaa-2222-aaaa-2222aaaa2222)"}[5m]))
예를 들어 전달자의 처리 속도가 415Kbps이고 버퍼 압축 효율이 70%인 경우 버퍼 채우기 속도는 415Kbps x (100% - 70%) = 124.5Kbps로 계산됩니다. 이 속도로는 기본 메모리 내 버퍼 값인 1GB 버퍼 크기가 2시간 20분 만에 채워집니다. 계산은 1024 x 1024 / 124.5 = 8422.297초 = 2시간 20분입니다. 최대 한도를 초과한 경우 하루 동안 데이터를 버퍼링하려면 100GB 디스크가 필요합니다.
자주 묻는 질문(FAQ)
버스트 한도를 초과하면 어떤 오류가 발생하나요?
최대 한도를 초과하면 HTTP 429 오류가 발생합니다.
HTTP 429 오류를 해결하려면 어떻게 해야 하나요?
5분 후에 다시 요청하세요.
버스트 한도는 얼마나 자주 새로고침되나요?
최대 한도는 5분마다 새로고침됩니다.