26A08c

Young-Kyoo Kim·2026년 4월 8일

네임스페이스마다 개별 StarRocks가 떠 있는 멀티 테넌트(Multi-tenant) 환경이라면, 범인을 찾는 과정이 조금 더 복잡해 보일 수 있지만 오히려 인프라 레벨에서 격리해서 확인하기에는 더 좋습니다.

이런 구조에서는 개별 StarRocks에 일일이 접속하기 전에, "어떤 네임스페이스의 어떤 Pod가 트래픽을 일으켰는가?"를 먼저 찾아내는 것이 순서입니다.


1. 인프라 레벨에서 '범인 네임스페이스' 찾기

가장 먼저 전체 클러스터 관점에서 50Gbps를 쓴 Pod를 식별해야 합니다.

  • Prometheus/Grafana 활용:
    만약 모니터링이 구축되어 있다면, 아래 메트릭을 NamespacePod 단위로 그룹화해서 봅니다.
    # 특정 시간대에 전송(Transmit) 트래픽이 가장 높았던 네임스페이스 찾기
    sum(irate(container_network_transmit_bytes_total[5m])) by (namespace)
  • Cilium Hubble (ClusterMesh 환경이므로 유용):
    사용 중이신 Cilium의 Hubble을 이용하면 네임스페이스 간 트래픽을 실시간/과거 기록으로 볼 수 있습니다.
    # 특정 시간대에 Storage Cluster(MinIO)로 트래픽을 많이 보낸 소스 네임스페이스 확인
    hubble observe --since 24h --dest-ip <MinIO-IP> -o wide | grep "50Gbps 수준의 트래픽 흐름"

2. 특정된 네임스페이스의 StarRocks 로그 확인

범인 네임스페이스(예: user-a-ns)를 찾았다면, 이제 그 네임스페이스 안에 있는 StarRocks FE의 Audit Log를 확인해야 합니다.

  • Kubectl로 전체 Audit Log 뒤지기:
    모든 네임스페이스의 FE 로그를 한 번에 검색하여 ScanBytes가 큰 쿼리를 찾습니다.
    # 모든 네임스페이스에서 'starrocks-fe' 라벨을 가진 파드의 로그 중 ScanBytes가 큰 것 검색
    kubectl logs -l app=starrocks-fe --all-namespaces --tail=-1 | grep "ScanBytes" | awk -F'|' '$10 > 1000000000 {print $0}' 
    (참고: $10은 log 포맷에 따라 다를 수 있으니 확인이 필요합니다. 보통 1GB 이상의 스캔을 찾도록 설정합니다.)

3. MinIO AIStor 입장에서 역추적 (Target Side)

MinIO는 모든 요청의 Source IP를 알고 있습니다.

  • MinIO Trace:
    MinIO 관리자 권한이 있다면, 특정 시간에 어떤 IP에서 GetObject가 폭주했는지 확인 가능합니다.
    mc admin trace --call get <MinIO-Alias>
    출력되는 결과에서 Client IP를 확보한 뒤, kubectl get pods -A -o wide | grep <Client-IP>를 실행하면 어떤 유저의 StarRocks BE 노드인지 즉시 나옵니다.

4. 왜 특정 유저의 Pod만 튀었을까? (시나리오 추측)

개인용 StarRocks들이라면 다음 상황일 확률이 매우 높습니다.

  1. Full Table Scan: 유저가 인덱스나 파티션 최적화 없이 수 TB급 데이터를 SELECT * 하거나 대규모 집계(Aggregation)를 수행한 경우.
  2. External Table 조회: StarRocks 내부 테이블이 아니라, MinIO에 있는 대량의 Parquet/ORC 파일을 External Catalog 기능을 통해 직접 조회할 때 캐시가 없는 상태라면 50Gbps를 쉽게 찍을 수 있습니다.
  3. 데이터 내보내기 (Export): INSERT INTO SELECT를 통해 대량의 데이터를 다른 테이블로 옮기거나 스토리지로 내보내는 작업을 했을 때입니다.

💡 추천하는 확인 순서

  1. Grafana에서 NamespaceNetwork Transmit 차트를 열어 50Gbps 피크를 친 네임스페이스를 특정한다.
  2. 해당 네임스페이스의 StarRocks FE 파드에 접속하여 fe.audit.log를 열고, 피크 시간대의 ScanBytes가 가장 큰 SQL 문장을 확보한다.
  3. 그 SQL을 실행한 유저에게 어떤 작업을 했는지 확인하거나, 쿼리 프로파일(GET TYPE_QUERY_DETAIL)을 떠서 분석한다.

현재 네임스페이스별 트래픽을 볼 수 있는 Grafana 대시보드가 있으신가요? 없다면 kubectl 명령어로 특정 시간대 로그를 추출하는 것이 가장 빠릅니다. 어떤 네임스페이스들이 있는지 리스트를 확인해 보셨나요?

0개의 댓글