VPC 흐름 로그 개요

VPC 흐름 로그는 Google Kubernetes Engine 노드로 사용되는 인스턴스를 포함하여 VM 인스턴스에서 전송되거나 수신되는 네트워크 흐름의 샘플을 기록합니다. 이러한 로그를 네트워크 모니터링, 포렌식, 실시간 보안 분석, 비용 최적화에 사용할 수 있습니다.

흐름 로그는 Cloud Logging에서 볼 수 있으며 Cloud Logging 내보내기가 지원되는 모든 대상으로 로그를 내보낼 수 있습니다.

흐름 로그는 Compute Engine VM에서 연결별로 집계된 후 실시간으로 내보내집니다. Pub/Sub를 구독하면 실시간 스트리밍 API를 사용하여 흐름 로그를 분석할 수 있습니다.

주요 속성

  • VPC 흐름 로그는 VPC 네트워크를 구동하는 소프트웨어인 Andromeda의 일부입니다. VPC 흐름 로그를 사용 설정하면 지연이나 성능 저하가 발생하지 않습니다.
  • VPC 흐름 로그는 기존 네트워크가 아닌 VPC 네트워크에서 작동합니다. 서브넷별로 VPC 흐름 로그를 사용 설정하거나 사용 중지합니다. 서브넷에 대해 사용 설정된 경우 VPC 흐름 로그는 해당 서브넷의 모든 VM 인스턴스에서 데이터를 수집합니다.
  • VPC 흐름 로그는 각 VM의 TCP 및 UDP 흐름, 인바운드 및 아웃바운드를 샘플링합니다. 이러한 흐름은 VM과 다른 VM, 온프레미스 데이터 센터의 호스트, Google 서비스, 인터넷 호스트 사이에 있을 수 있습니다. 흐름을 샘플링으로 캡처하는 경우 VPC 흐름 로그는 흐름의 로그를 생성합니다. 각 흐름 기록에는 레코드 형식 섹션에 설명된 정보가 포함됩니다.
  • VPC 흐름 로그는 다음과 같은 방식으로 방화벽 규칙과 상호 작용합니다.
    • 이그레스 패킷은 이그레스 방화벽 규칙 이전에 샘플링됩니다. 이그레스 방화벽 규칙이 아웃바운드 패킷을 거부하더라도 VPC 흐름 로그를 통해 이러한 패킷을 샘플링할 수 있습니다.
    • 인그레스 패킷은 인그레스 방화벽 규칙 이후에 샘플링됩니다. 인그레스 방화벽 규칙이 인바운드 패킷을 거부하면 해당 패킷은 VPC 흐름 로그에서 샘플링되지 않습니다.
  • VPC 흐름 로그에서 필터를 사용하여 특정 로그만 생성할 수 있습니다.
  • VPC 흐름 로그는 여러 네트워크 인터페이스가 있는 VM을 지원합니다. 각 VPC에서 네트워크 인터페이스가 포함된 각 서브넷에 VPC 흐름 로그를 사용 설정해야 합니다.
  • 동일한 Google Kubernetes Engine(GKE) 노드에서 Pod 간 흐름을 로깅하려면 클러스터에 노드 내 공개 상태를 사용 설정해야 합니다.

사용 사례

네트워크 모니터링

VPC 흐름 로그는 네트워크 처리량과 성능에 관한 실시간 시야를 제공합니다. 다음과 같은 작업을 수행할 수 있습니다.

  • VPC 네트워크 모니터링
  • 네트워크 진단 수행
  • VM 및 애플리케이션별로 흐름 로그를 필터링하여 트래픽 변화 파악
  • 용량 예측을 위한 트래픽 증가 파악

네트워크 사용량 파악 및 네트워크 트래픽 비용 최적화

VPC 흐름 로그를 사용하여 네트워크 사용량을 분석할 수 있습니다. 다음의 네트워크 흐름을 분석할 수 있습니다.

  • 리전 및 영역 간의 트래픽
  • 인터넷의 특정 국가로 가는 트래픽
  • 최상위 네트워크 소비자

분석을 기반으로 네트워크 트래픽 비용을 최적화할 수 있습니다.

네트워크 증거 수집

네트워크 포렌식용으로 VPC 흐름 로그를 활용할 수 있습니다. 예를 들어 이슈가 발생하면 다음 항목을 검사할 수 있습니다.

  • 어떤 IP로 누구와 언제 통신했는지
  • 모든 손상된 IP(들어오고 나가는 모든 네트워크 흐름 분석)

실시간 보안 분석

Pub/Sub를 통해 실시간 스트리밍 API를 활용하고 SIEM(Security Information and Event Management) 시스템과 통합할 수 있습니다. 실시간 모니터링, 이벤트, 분석, 보안 알림의 연관성을 제공할 수 있습니다.

로그 수집

흐름 로그는 각 VM 연결에서 특정 간격으로 수집됩니다. 지정된 연결에서 지정된 간격으로 수집된 모든 패킷은 일정 기간(집계 간격) 동안 단일 흐름 로그 항목에 집계됩니다. 그 다음 이 데이터가 Logging으로 전송됩니다.

로그는 기본적으로 Logging에 30일 동안 저장됩니다. 로그를 이 기간보다 오래 보관하려면 지원되는 대상으로 로그를 내보내야 합니다.

로그 샘플링 및 처리

Google Cloud는 VM을 나가고 들어오는 패킷을 샘플링하여 흐름 로그를 생성합니다. 모든 패킷이 자체 로그 레코드에 캡처되는 것은 아닙니다. 10개의 패킷마다 약 1개가 캡처되지만 이 샘플링 레이트는 VM의 부하에 따라 더 낮을 수 있습니다. 이 레이트는 조정할 수 없습니다.

흐름 로그가 생성되면 Google Cloud는 다음 절차에 따라 로그를 처리합니다.

  1. 필터링: 지정된 기준과 일치하는 로그만 생성되도록 지정할 수 있습니다. 예를 들어 특정 VM의 로그 또는 특정 메타데이터 값이 있는 로그만 생성되고 나머지는 삭제되도록 필터링할 수 있습니다.
  2. 집계: 샘플링된 패킷에 대한 정보가 구성 가능한 집계 간격을 통해 집계되어 흐름 로그 항목이 생성됩니다.
  3. 흐름 로그 샘플링: 두 번째 샘플링 프로세스입니다. 흐름 로그 항목은 구성 가능한 샘플링 레이트 매개변수에 따라 추가로 샘플링됩니다.
  4. 메타데이터: 사용 중지하면 모든 메타데이터 주석이 삭제됩니다. 메타데이터를 유지하기 위해서는 기본 필드 세트 또는 지정된 필드 세트를 보관하도록 지정하면 됩니다. 자세한 내용은 메타데이터 필드 맞춤설정을 참조하세요.
  5. 로그 작성: 최종 로그 항목은 Cloud Logging에 기록됩니다.

VPC 흐름 로그는 모든 패킷을 캡처하지 않으므로 캡처된 패킷에서 보간하여 누락된 패킷을 보완합니다. 이는 초기 샘플링 설정 및 사용자가 구성할 수 있는 샘플링 설정으로 인해 누락된 패킷에 발생합니다.

Google Cloud가 모든 패킷을 캡처하지 않을 경우에도 로그 레코드는 상당한 양이 캡처될 수 있습니다. 로그 수집의 다음 측면을 조정하여 트래픽 공개 상태와 스토리지 비용 사이에서 니즈의 균형을 유지할 수 있습니다.

  • 집계 간격: 특정 시간 간격 동안 샘플링된 패킷은 단일 로그 항목에 집계됩니다. 이 시간 간격은 5초(기본값), 30초, 1분, 5분, 10분 또는 15분입니다.
  • 샘플링 레이트: Logging에 기록되기 전에 로그 수를 샘플링하여 데이터 수를 줄일 수 있습니다. 기본적으로 로그 항목 볼륨은 0.5(50%)씩 조정됩니다. 즉, 항목의 절반 가량이 유지됩니다. 이를 1.0(100%, 모든 로그 항목 유지)에서 0.0(0%, 유지되는 로그 없음)까지 설정할 수 있습니다.
  • 메타데이터 주석: 기본적으로 흐름 로그 항목은 소스 및 대상 VM 이름이나 외부 소스 및 대상의 지리적 리전과 같은 메타데이터 정보로 주석 처리됩니다. 메타데이터 주석을 사용 중지하거나 특정 주석만 지정하여 저장공간을 절약할 수 있습니다.
  • 필터링: 기본적으로 로그는 서브넷의 모든 흐름에서 생성됩니다. 특정 기준과 일치하는 로그만 생성되도록 필터를 설정할 수 있습니다.

메타데이터 필드 맞춤설정

각 로그를 사용하여 모든 관련 메타데이터, 메타데이터 없음, 지정한 특정 메타데이터를 모두 추출할 수 있습니다. 메타데이터 필드를 전체 이름(예: src_vpc.project_id) 또는 상위 필드(예: src_vpc)로 지정할 수 있습니다. 여기에는 src_vpc.project_id , src_vpc.vpc_name, src_vpc.subnetwork_name이 포함됩니다.

메타데이터 유형의 필드만 생략할 수 있으며 기본 유형의 필드는 생략할 수 있습니다. 기본 필드는 항상 포함되며 생략할 수 없습니다. 레코드 형식 섹션에는 메타데이터와 기본 필드를 나열합니다.

새 메타데이터 주석이 VPC 흐름 로그 레코드 형식에 추가되면 '모두 포함' 구성의 필드 목록에 추가되지 않습니다. '모두 포함'에는 다음 필드만 포함됩니다.

  • src_instance
  • dest_instanc
  • src_vp
  • dest_vpc
  • src_location
  • dest_location

GKE 주석을 비롯한 새 주석은 '커스텀' 구성을 사용하여 수동으로 추가된 경우에만 로그에 표시됩니다.

메타데이터 필드 맞춤설정에 대한 안내는 서브넷을 만들 때 VPC 흐름 로깅 사용 설정을 참조하세요.

GKE 주석

GKE 클러스터의 엔드포인트가 있는 흐름은 엔드포인트의 클러스터, pod, 서비스 세부정보를 포함할 수 있는 GKE 주석으로 주석 처리할 수 있습니다. GKE 주석은 메타데이터 필드의 커스텀 구성에서만 사용할 수 있습니다.

GKE 서비스 주석

ClusterIP, NodePort 또는 LoadBalancer로 전송된 트래픽은 서비스 주석을 수신할 수 있습니다. NodePort 또는 LoadBalancer로 전송되면 흐름은 연결의 두 홉에서 서비스 주석을 수신합니다.

pod의 서비스 포트로 직접 전송된 트래픽은 대상 엔드포인트에 서비스 주석으로 주석 처리됩니다.

동일한 서비스 포트에서 pod가 2개 이상의 서비스를 백업하고 있는 pod의 서비스 포트로 전송된 트래픽은 대상 엔드포인트에 여러 서비스로 주석 처리됩니다. 서비스는 2개로 제한됩니다. 2개를 초과하면 엔드포인트는 특별한 MANY_SERVICES 마커로 주석 처리됩니다.

인터넷 트래픽의 pod 주석

pod와 인터넷 간의 트래픽은 기본적으로 pod 주석을 받지 않습니다. 인터넷으로 전송되는 패킷의 경우, 매스커레이드 에이전트는 VPC 흐름 로그가 패킷을 보기 전에 pod IP 주소를 노드 IP 주소로 변환하므로 VPC 흐름 로그는 pod에 대해 아무것도 알지 못하며 pod 주석을 추가할 수 없습니다.

매스커레이드로 인해 pod 주석은 대상이 기본 비매스커레이드 대상 또는 커스텀 nonMasqueradeCIDRs 목록에 있는 경우에만 표시됩니다. 커스텀 nonMasqueradeCIDRs 목록에 인터넷 대상을 포함하는 경우 내부 pod IP 주소가 인터넷에 전송되기 전에 변환할 방법을 제공해야 합니다. 비공개 및 비공개 클러스터 모두에 대해 Cloud NAT를 사용할 수 있습니다. 자세한 내용은 GKE 상호작용을 참조하세요.

레코드 형식

로그 레코드에는 모든 로그 레코드의 핵심 필드인 기본 필드와 추가 정보를 추가하는 메타데이터 필드가 있습니다. 메타데이터 필드를 삭제하여 저장공간을 절약할 수 있습니다.

일부 로그 필드는 한 필드에 두 가지 이상의 데이터를 포함하는 다중 필드 형식입니다. 예를 들어 connection 필드는 IpConnection 형식이며 소스 및 대상 IP 주소, 포트, 프로토콜이 단일 필드에 포함됩니다. 이러한 다중 필드 형식의 필드는 레코드 형식 표 아래에 설명되어 있습니다.

필드 필드 형식 필드 유형: 기본 또는 선택적 메타데이터
connection IpConnection
이 연결을 설명하는 5-튜플입니다.
기본
start_time string
집계된 시간 간격 동안 처음 관찰된 패킷의 타임스탬프(RFC 3339 날짜 문자열 형식)
기본
end_time string
집계된 시간 간격 동안 마지막으로 관찰된 패킷의 타임스탬프(RFC 3339 날짜 문자열 형식)
기본
bytes_sent int64
소스에서 대상으로 전송된 바이트 크기
기본
packets_sent int64
소스에서 대상으로 전송된 패킷의 수
기본
rtt_msec int64
시간 간격 동안 측정된 지연 시간(TCP 흐름에만 해당). 측정된 지연 시간은 SEQ를 보내고 상응하는 ACK를 받기까지 경과한 시간입니다. 지연 시간 결과는 네트워크 RTT와 애플리케이션에서 소비한 시간의 총합입니다.
기본
reporter string
흐름을 보고한 측. SRC 또는 DEST일 수 있습니다.
기본
src_instance InstanceDetails
연결 소스가 동일한 VPC에 위치한 VM인 경우 VM 인스턴스 세부정보가 이 필드에 입력됩니다. 공유 VPC 구성에서 project_id는 인스턴스를 소유하는 프로젝트(대개 서비스 프로젝트)에 해당합니다.
메타데이터
dest_instanc InstanceDetails
연결 대상이 동일한 VPC에 있는 VM인 경우 VM 인스턴스 세부정보가 이 필드에 입력됩니다. 공유 VPC 구성에서 project_id는 인스턴스를 소유하는 프로젝트(대개 서비스 프로젝트)에 해당합니다.
메타데이터
src_vp VpcDetails
연결 소스가 동일한 VPC에 위치한 VM인 경우 VPC 네트워크 세부정보가 이 필드에 입력됩니다. 공유 VPC 구성에서 project_id는 호스트 프로젝트의 프로젝트 ID에 해당합니다.
메타데이터
dest_vpc VpcDetails
연결 대상이 동일한 VPC에 위치한 VM인 경우 VPC 네트워크 세부정보가 이 필드에 입력됩니다. 공유 VPC 구성에서 project_id는 호스트 프로젝트의 프로젝트 ID에 해당합니다.
메타데이터
src_location GeographicDetails
연결 소스가 Google VPC 외부에 있는 경우 사용 가능한 위치 메타데이터가 이 필드에 입력됩니다.
메타데이터
dest_location GeographicDetails
연결 대상이 Google VPC 외부에 있는 경우 사용 가능한 위치 메타데이터가 이 필드에 입력됩니다.
메타데이터
src_gke_details GkeDetails
소스 엔드포인트의 GKE 메타데이터입니다. 엔드포인트가 GKE인 경우에만 사용할 수 있습니다. 메타데이터 필드의 커스텀 구성을 통해서만 사용할 수 있습니다.
메타데이터
dest_gke_details GkeDetails
대상 엔드포인트의 GKE 메타데이터입니다. 엔드포인트가 GKE인 경우에만 사용할 수 있습니다. 메타데이터 필드의 커스텀 구성을 통해서만 사용할 수 있습니다.
메타데이터

IpConnection 필드 형식

필드 유형 설명
src_ip 문자열 소스 IP 주소
src_port int32 소스 포트
dest_ip 문자열 대상 IP 주소
dest_port int32 대상 포트
protocol int32 IANA 프로토콜 번호

InstanceDetails 필드 형식

필드 유형 설명
project_id string VM이 포함된 프로젝트의 ID
vm_name string VM의 인스턴스 이름
region string VM의 리전
zone string VM의 영역

VpcDetails 필드 형식

필드 유형 설명
project_id 문자열 VPC가 포함된 프로젝트의 ID
vpc_name 문자열 VM이 작동 중인 VPC
subnetwork_name 문자열 VM이 작동 중인 서브네트워크

GeographicDetails 필드 형식

필드 유형 설명
continent string 외부 엔드포인트의 대륙
country string ISO 3166-1 Alpha-3 국가 코드로 표시되는 외부 엔드포인트의 국가입니다.
region string 외부 엔드포인트의 리전
city string 외부 엔드포인트의 도시
asn int32 이 엔드포인트가 속한 외부 네트워크의 자율 시스템 번호(ASN)

GkeDetails 필드 형식

필드 유형 설명
클러스터 ClusterDetails GKE 클러스터 메타데이터입니다.
pod PodDetails GKE pod 메타데이터로, 트래픽의 소스 또는 대상이 pod일 때 채워집니다.
서비스 ServiceDetails 서비스 엔드포인트에만 채워진 GKE 서비스 메타데이터입니다. 레코드에는 최대 2개의 서비스가 포함됩니다. 관련 서비스가 2개를 초과하면 이 필드에는 특별한 MANY_SERVICES 마커가 있는 단일 서비스가 포함됩니다.

ClusterDetails 필드 형식

필드 유형 설명
cluster_name 문자열 GKE 클러스터 이름
cluster_location 문자열 클러스터의 위치입니다. 클러스터가 영역 또는 리전인지 여부에 따라 영역 또는 리전일 수 있습니다.

PodDetails 필드 형식

필드 유형 설명
pod_name 문자열 pod의 이름입니다.
pod_namespace 문자열 pod의 네임스페이스입니다.

ServiceDetails 필드 형식

필드 유형 설명
service_name 문자열 서비스 이름입니다. 관련 서비스가 2개를 초과하면 이 필드에는 특별한 MANY_SERVICES 마커로 설정됩니다.
service_namespace 문자열 서비스의 네임스페이스입니다.

예를 들면 다음과 같습니다.

서비스가 2개 있는 경우 서비스 필드는 다음과 같습니다.

service: [
 0: {
  service_name: "my-lb-service"
  service_namespace: "default"
 }
 1: {
  service_name: "my-lb-service2"
  service_namespace: "default"
 }
]

서비스가 2개를 초과하는 경우 서비스 필드는 다음과 같습니다.

service: [
 0: {
  service_name: "MANY_SERVICES"
 }
]

로그 필터링

VPC 흐름 로그를 사용 설정하면 필터와 일치하는 로그만 보존하는 기본 필드와 메타데이터 필드를 기반으로 필터를 설정할 수 있습니다. 다른 모든 로그는 Logging에 기록되기 전에 삭제되므로 비용이 절약되고 찾고 있는 정보를 찾는 데 필요한 시간이 줄어 듭니다.

레코드 형식에서 필드의 하위 집합을 필터링할 수 있습니다.

VPC 흐름 로그 필터링은 속성 기반 논리 표현식을 위한 임베디드 표현식 언어인 CEL을 사용합니다. 자세한 내용은 지원되는 CEL 논리 연산자를 참조하세요.

CEL에 대한 자세한 내용은 CEL 소개언어 정의를 참조하세요. 생성 필터 기능은 CEL 구문의 제한된 일부 하위 집합을 지원합니다.

예시 1: 로그 수집을 my-vm이라는 특정 VM으로 제한합니다. 이 경우에는 트래픽 소스가 보고한 src_instance 필드가 my-vm이거나 트래픽 대상이 보고한 dst_instance 필드가 my-vm인 로그만 기록됩니다.

gcloud compute networks subnets update my-subnet \
--logging-filter-expr = "(src_instance.vm_name == 'my-vm' && reporter=='SRC') || (dest_instance.vm_name == 'my-vm' && reporter=='DEST')"

예시 2: 소스 IP 주소가 10.0.0.0/8 서브넷에 있는 패킷으로 로그 수집을 제한합니다.

gcloud compute networks subnets update my-subnet \
--logging-filter-expr = "inIpRange(connection.src_ip, '10.0.0.0/8')"

지원되는 CEL 논리 연산자


Expression

Supported Types

Description
true, false 부울 부울 상수
x == y x != y 부울, 정수, 문자열 비교 연산자 예시: connection.protocol == 6
x && y x || y 부울 부울 논리 연산자 예시: connection.protocol == 6 && src_instance.vm_name == "vm_1"
!x 부울 부정
1, 2.0, 0, ... 정수 상수 숫자 리터럴
x + y 문자열 문자열 연결
"foo", 'foo', ... 문자열 상수 문자열 리터럴
x.lower() 문자열 문자열의 소문자 값을 반환합니다.
x.upper() 문자열 문자열의 대문자 값을 반환합니다.
x.contains(y) 문자열 문자열에 지정된 하위 문자열이 포함된 경우 true를 반환합니다.
x.startsWith(y) 문자열 문자열이 지정된 하위 문자열로 시작하면 true를 반환합니다.
x.endsWith(y) 문자열 문자열이 지정된 하위 문자열로 끝나면 true를 반환합니다.
inIpRange(X, Y) 문자열 X가 IP이고 Y가 X를 포함하는 IP 범위인 경우 true를 반환합니다.
예시: inIpRange("1.2.3.1", "1.2.3.0/24")
x.containsFieldValue(y) x: list
y: map(string, string)
목록에 지정된 키-값 쌍과 일치하는 필드가 있는 객체가 포함된 경우 true를 반환합니다.
예시: dest_gke_details.service.containsFieldValue({'service_name': 'service1', 'service_namespace': 'namespace1'})

트래픽 패턴 예시

이 섹션에서는 다음 사용 사례에서 VPC 흐름 로그가 작동하는 방법을 설명합니다.

동일한 VPC에서 VM-VM 흐름

VPC 내의 VM 흐름(확대하려면 클릭)
VPC 내의 VM 흐름(확대하려면 클릭)

동일한 VPC의 VM-VM 흐름의 경우, 두 VM이 모두 VPC 흐름 로그가 사용 설정된 서브넷에 있으면 요청 및 응답 VM 모두에서 흐름 로그가 보고됩니다. 이 예시에서 VM 10.10.0.2는 1,224바이트의 요청을 마찬가지로 로깅이 사용 설정된 서브넷에 있는 VM 10.50.0.2로 보냅니다. 그러면 10.50.0.2는 요청에 대해 5,342바이트를 포함하는 응답을 보냅니다. 요청하는 VM과 응답하는 VM 모두에서 요청과 응답이 모두 기록됩니다.

요청하는 VM(10.10.0.2)의 보고 내용
요청/응답 connection.src_ip connection.dest_ip bytes_sent VPC 주석
요청 10.10.0.2 10.50.0.2 1224 src_instance.*
dest_instance.*
src_vpc.*
dest_vpc.*
응답 10.50.0.2 10.10.0.2 5342 src_instance.*
dest_instance.*
src_vpc.*
dest_vpc.*
응답하는 VM(10.50.0.2)의 보고 내용
요청/응답 connection.src_ip connection.dest_ip 바이트 VPC 주석
요청 10.10.0.2 10.50.0.2 1224 src_instance.*
dest_instance.*
src_vpc.*
dest_vpc.*
응답 10.50.0.2 10.10.0.2 5342 src_instance.*
dest_instance.*
src_vpc.*
dest_vpc.*

VM-외부 흐름

VM-외부 흐름(확대하려면 클릭)
VM-외부 흐름(확대하려면 클릭)

VM과 외부 항목 간 흐름의 경우 VM에서만 흐름 로그가 보고됩니다.

  • 송신 흐름의 경우 트래픽의 소스인 VM에서 로그가 보고됩니다.
  • 수신 흐름의 경우 트래픽의 대상인 VM에서 로그가 보고됩니다.

적용 대상:

  • Cloud VPN 또는 Cloud Interconnect를 통한 VPC 네트워크와 온프레미스 네트워크 간의 트래픽
  • VM과 인터넷 위치 간의 트래픽

이 예시에서 VM 10.10.0.2와 온프레미스 엔드포인트 10.30.0.2는 VPN 게이트웨이 또는 Cloud Interconnect를 통해 연결됩니다. 10.10.0.2에서 10.30.0.2로 전송된 1,224바이트의 아웃바운드 트래픽은 소스 VM 10.10.0.2에서 보고됩니다. 10.30.0.2에서 10.10.0.2로 전송된 5,342바이트의 인바운드 트래픽은 트래픽의 대상인 VM 10.10.0.2에서 보고됩니다.

요청/응답 connection.src_ip connection.dest_ip bytes_sent VPC 주석
요청 10.10.0.2 10.30.0.2 1224 src_instance.*
src_vpc.*
dest_location.*
응답 10.30.0.2 10.10.0.2 5342 dest_instance.*
dest_vpc.*
src_location.*

공유 VPC의 VM-VM 흐름

공유 VPC 흐름(확대하려면 클릭)
공유 VPC 흐름(확대하려면 클릭)

공유 VPC의 VM-VM 흐름의 경우 호스트 프로젝트에서 서브넷에 대한 VPC 흐름 로그를 사용 설정할 수 있습니다. 예를 들어 서브넷 10.10.0.0/20은 호스트 프로젝트에 정의된 공유 VPC 네트워크에 속합니다. 서비스 프로젝트에서 생성된 VM을 포함하여 이 서브넷에 속한 VM에서 흐름 로그를 볼 수 있습니다. 이 예시에서 서비스 프로젝트는 'webserver', 'recommendation', 'database'입니다.

VM-VM 흐름의 경우, 두 VM이 동일한 프로젝트 또는 동일한 호스트 프로젝트(공유 네트워크의 경우)에 있으면 연결의 다른 엔드포인트에 대한 프로젝트 ID 등의 주석이 제공됩니다. 다른 VM이 다른 프로젝트에 있으면 다른 VM의 주석이 제공되지 않습니다.

다음 표에서는 10.10.0.10 또는 10.10.0.20이 보고한 흐름을 보여줍니다.

  • VPC 서브넷은 호스트 프로젝트에 속하기 때문에 src_vpc.project_iddest_vpc.project_id는 호스트 프로젝트에 해당합니다.
  • 인스턴스는 서비스 프로젝트에 속하기 때문에 src_instance.project_iddest_instance.project_id는 서비스 프로젝트에 해당합니다.
connection
.src_ip
src_instance
.project_id
src_vpc
.project_id
connection
.dest_ip
dest_instance
.project_id
dest_vpc
.project_id
10.10.0.10 webserver host_project 10.10.0.20 recommendation host_project

서비스 프로젝트는 공유 VPC 네트워크를 소유하지 않으며 공유 VPC 네트워크의 흐름 로그에 액세스할 권한이 없습니다.

VPC 네트워크 피어링의 VM-VM 흐름

VPC 네트워크 피어링 흐름(확대하려면 클릭)
VPC 네트워크 피어링 흐름(확대하려면 클릭)

두 VM이 동일한 Google Cloud 프로젝트에 있지 않으면 피어링된 VPC의 VM-VM 흐름이 외부 엔드포인트와 동일한 방식으로 보고됩니다. 다른 VM의 프로젝트 및 기타 주석 정보는 제공되지 않습니다. 두 VM이 서로 다른 네트워크에 있더라도 동일한 프로젝트에 있기만 하면 다른 VM에 대한 프로젝트 및 기타 주석 정보도 제공됩니다.

이 예시에서는 analytics-prod 프로젝트에 있는 VM 10.10.0.2와 webserver-test 프로젝트에 있는 VM 10.50.0.2의 서브넷이 VPC 네트워크 피어링을 통해 연결됩니다. analytics-prod 프로젝트에서 VPC 흐름 로그가 사용 설정된 경우 10.10.0.2에서 10.50.0.2로 전송된 트래픽(1,224바이트)은 흐름의 소스인 VM 10.10.0.2에서 보고됩니다. 또한 10.50.0.2에서 10.10.0.2로 전송된 트래픽(5,342바이트)은 흐름의 대상인 VM 10.10.0.2에서도 보고됩니다.

이 예시에서 webserver-test 프로젝트에는 VPC 흐름 로그가 사용 설정되지 않았으므로 VM 10.50.0.2에서는 로그가 기록되지 않습니다.

reporter connection.src_ip connection.dest_ip bytes_sent VPC 주석
source 10.10.0.2 10.50.0.2 1224 src_instance.*
src_vpc.*
destination 10.50.0.2 10.10.0.2 5342 dest_instance.*
dest_vpc.*

내부 TCP/UDP 부하 분산의 VM-VM 흐름

내부 TCP/UDP 부하 분산 흐름(확대하려면 클릭)
내부 TCP/UDP 부하 분산 흐름(확대하려면 클릭)

내부 TCP/UDP 부하 분산기의 백엔드 서비스에 VM을 추가할 때 Linux 또는 Windows 게스트 환경은 VM의 로컬 라우팅 테이블에 부하 분산기의 IP 주소를 추가합니다. 그러면 VM은 대상이 부하 분산기의 IP 주소로 설정된 요청 패킷을 허용할 수 있습니다. VM은 응답 시 직접 응답을 보냅니다. 그러나 응답 패킷의 소스 IP 주소는 부하 분산이 적용되는 VM이 아니라 부하 분산기의 IP 주소로 설정됩니다.

내부 TCP/UDP 부하 분산기를 통해 전송되는 VM-VM 흐름은 소스와 대상 모두에서 보고됩니다. 다음 표에서는 예시에 나온 HTTP 요청/응답 쌍에 대해 관찰된 흐름 로그 항목의 필드를 설명합니다. 이 예에서는 네트워크 구성이 다음과 같다고 가정합니다.

  • 브라우저 인스턴스 위치 192.168.1.2
  • 내부 TCP/UDP 부하 분산기 위치 10.240.0.200
  • 웹 서버 인스턴스 위치 10.240.0.3
트래픽 방향 reporter connection.src_ip connection.dest_ip connection.src_instance connection.dest_instance
요청 SRC 192.168.1.2 10.240.0.200 브라우저 인스턴스
요청 DEST 192.168.1.2 10.240.0.200 브라우저 인스턴스 웹 서버 인스턴스
응답 SRC 10.240.0.3 192.168.1.2 웹 서버 인스턴스 브라우저 인스턴스
응답 DEST 10.240.0.200 192.168.1.2 브라우저 인스턴스

요청하는 VM은 어떤 VM이 요청에 응답할지 알지 못합니다. 또한 다른 VM은 내부 부하 분산기 IP를 소스 주소로 사용하여 응답을 보내므로 어떤 VM이 실제로 응답했는지도 알지 못합니다. 이러한 이유 때문에 요청하는 VM은 dest_instance 정보를 보고서에 추가할 수 없고 src_instance 정보만 추가할 수 있습니다. 응답하는 VM은 다른 VM의 IP 주소를 알고 있기 때문에 src_instancedest_instance 정보를 모두 제공할 수 있습니다.

pod-ClusterIP 흐름

pod-클러스터 IP 흐름(확대하려면 클릭)
pod-클러스터 IP 흐름(확대하려면 클릭)

이 예시에서는 클라이언트 pod(10.4.0.2)에서 cluster-service(10.0.32.2:80)로 트래픽이 전송됩니다. 대상은 대상 포트(8080)에서 선택한 서버 pod IP 주소(10.4.0.3)로 확인됩니다.

노드 에지에서 흐름은 변환된 IP 주소 및 포트와 함께 두 번 샘플링됩니다. 두 샘플링 시점에서 대상 pod가 포트 8080에서 서비스 cluster-service를 지원하는지 확인하고, pod 세부정보와 서비스 세부정보를 사용하여 레코드를 주석으로 처리합니다. 동일한 노드에 있는 pod로 트래픽이 라우팅되는 경우 트래픽은 노드를 벗어나지 않으며 전혀 샘플링되지 않습니다.

찾은 레코드는 다음과 같습니다. GKE 필드는 '커스텀' 메타데이터 구성에서만 사용할 수 있습니다.

reporter connection.src_ip connection.dst_ip bytes_sent VPC 주석
SRC 10.4.0.2 10.4.0.3 1224 src_instance.*
src_vpc.*
src_gke_details.cluster.*
src_gke_details.pod.*
dest_instance.*
dest_vpc.*
dest_gke_details.cluster.*
dest_gke_details.pod.*
dest_gke_details.service.*
DEST 10.4.0.2 10.4.0.3 1224 src_instance.*
src_vpc.*
src_gke_details.cluster.*
src_gke_details.pod.*
dest_instance.*
dest_vpc.*
dest_gke_details.cluster.*
dest_gke_details.pod.*
dest_gke_details.service.*

GKE 외부 부하 분산기 흐름

외부 부하 분산기 흐름(확대하려면 클릭)
외부 부하 분산기 흐름(확대하려면 클릭)

외부 IP 주소에서 GKE 서비스(35.35.35.35)로의 트래픽은 라우팅을 위해 클러스터의 노드(이 예시에서는 10.0.12.2)로 라우팅됩니다. 기본적으로 네트워크 부하 분산기는 관련 pod를 실행하지 않는 노드까지 포함해 클러스터의 모든 노드에 트래픽을 분산합니다. 트래픽에는 관련 pod로 이동하기 위한 추가 홉이 필요할 수 있습니다. 자세한 내용은 클러스터 외부 네트워킹을 참조하세요.

그러면 트래픽이 노드(10.0.12.2)에서 선택한 서버 pod(10.4.0.2)로 라우팅됩니다. 모든 노드 에지가 샘플링되므로 두 홉이 모두 로깅됩니다. 트래픽이 동일한 노드에 있는 pod로 라우팅되는 경우 이 예시에서 10.4.0.3은 두 번째 홉이 노드를 벗어나지 않으므로 로깅되지 않습니다. 두 번째 홉은 두 노드의 샘플링 시점에서 로깅합니다. 두 번째 홉은 두 노드의 샘플링 시점에서 로깅합니다. 첫 번째 홉의 경우 부하 분산기 IP 및 서비스 포트(80)를 기준으로 서비스를 식별합니다. 두 번째 홉의 경우 대상 pod가 대상 포트(8080)에서 서비스를 지원하고 있음을 식별합니다.

이 예시에서는 다음 레코드가 있습니다. GKE 필드는 '커스텀' 메타데이터 구성에서만 사용할 수 있습니다.

reporter connection.src_ip connection.dst_ip bytes_sent VPC 주석
DEST 203.0.113.1 35.35.35.35 1224 src_location.*
dest_instance.*
dest_vpc.*
dest_gke_details.cluster.*
dest_gke_details.service.*
SRC 10.0.12.2 10.4.0.2 1224 src_instance.*
src_vpc.*
src_gke_details.cluster.*
dest_instance.*
dest_vpc.*
dest_gke_details.cluster.*
dest_gke_details.pod.*
dest_gke_details.service.*
DEST 10.0.12.2 10.4.0.2 1224 src_instance.*
src_vpc.*
src_gke_details.cluster.*
dest_instance.*
dest_vpc.*
dest_gke_details.cluster.*
dest_gke_details.pod.*
dest_gke_details.service.*

GKE 인그레스 흐름

인그레스 흐름(확대하려면 클릭)
인그레스 흐름(확대하려면 클릭)

공개 IP 주소에서 인그레스 대상으로의 연결은 부하 분산기 서비스에서 종료됩니다. URL에 따라 연결이 NodePort 서비스에 매핑됩니다. 요청을 처리하기 위해 부하 분산기(130.211.0.1)는 서비스의 NodePort를 사용하여 라우팅할 클러스터 노드(10.0.12.2) 중 하나에 연결됩니다. 기본적으로 인그레스를 만들 때 GKE 인그레스 컨트롤러는 관련 pod를 실행하지 않는 노드까지 포함해 클러스터의 모든 노드에 트래픽을 분산하는 HTTP(S) 부하 분산기를 구성합니다. 트래픽에는 관련 pod로 이동하기 위한 추가 홉이 필요할 수 있습니다. 자세한 내용은 네트워크 개요를 참조하세요. 그러면 트래픽은 노드(10.0.12.2)에서 선택된 서버 pod(10.4.0.2)로 라우팅됩니다.

모든 노드 에지가 샘플링되므로 두 홉이 모두 로깅됩니다. 첫 번째 홉의 경우 서비스의 NodePort(60000)를 기준으로 서비스를 식별합니다. 두 번째 홉의 경우 대상 pod가 대상 포트(8080)에서 서비스를 지원하는지 확인합니다. 두 번째 홉은 두 노드의 샘플링 시점에서 로깅됩니다. 그러나 트래픽이 동일한 노드(10.4.0.3)의 pod로 라우팅되는 경우 트래픽이 노드를 벗어나지 않으므로 두 번째 홉이 로깅되지 않습니다.

이 예시에서는 다음 레코드가 있습니다. GKE 필드는 '커스텀' 메타데이터 구성에서만 사용할 수 있습니다.

reporter connection.src_ip connection.dst_ip bytes_sent VPC 주석
DEST 130.211.0.1 10.0.12.2 1224 dest_instance.*
dest_vpc.*
dest_gke_details.cluster.*
dest_gke_details.service.*
SRC 10.0.12.2 10.4.0.2 1224 src_instance.*
src_vpc.*
src_gke_details.cluster.*
dest_instance.*
dest_vpc.*
dest_gke_details.cluster.*
dest_gke_details.pod.*
dest_gke_details.service.*
DEST 10.0.12.2 10.4.0.2 1224 src_instance.*
src_vpc.*
src_gke_details.cluster.*
dest_instance.*
dest_vpc.*
dest_gke_details.cluster.*
dest_gke_details.pod.*
dest_gke_details.service.*

컨테이너 기반 부하 분산을 사용하는 GKE 인그레스 흐름

컨테이너 기반 부하 분산을 사용하는 인그레스 흐름(확대하려면 클릭)
컨테이너 기반 부하 분산을 사용하는 인그레스 흐름(확대하려면 클릭)

공개 IP 주소에서 컨테이너 기반 부하 분산을 사용하는 인그레스에 대한 요청은 부하 분산기에서 종료됩니다. 이 유형의 인그레스에서 Pod는 부하 분산의 핵심 객체입니다. 그런 다음 부하 분산기(130.211.0.1)에서 선택한 Pod(10.4.0.2)로 요청이 직접 전송됩니다. 대상 Pod가 대상 포트(8080)에서 서비스를 지원하는 것으로 식별됩니다.

찾은 레코드는 다음과 같습니다. GKE 필드는 '커스텀' 메타데이터 구성에서만 사용할 수 있습니다.

reporter connection.src_ip connection.dst_ip bytes_sent VPC 주석
DEST 130.211.0.1 10.4.0.2 1224 dest_instance.*
dest_vpc.*
dest_gke_details.cluster.*
dest_gke_details.pod.*
dest_gke_details.service.*

pod-외부 흐름

pod-외부 흐름(확대하려면 클릭)
pod-외부 흐름(확대하려면 클릭)

pod(10.4.0.3)에서 외부 IP(203.0.113.1) 로의 트래픽은 패킷이 pod IP 대신 노드 IP(10.0.12.2)에서 전송되도록 IP 매스커레이딩에서 수정됩니다. 기본적으로 GKE 클러스터는 트래픽을 외부 대상으로 매스커레이드하도록 구성됩니다. 자세한 내용은 IP 매스커레이드 에이전트를 참조하세요.

이 트래픽의 pod 주석을 보려면 pod IP를 매스커레이드하지 않도록 매스커레이드 에이전트를 구성하면 됩니다. 이 경우 인터넷 트래픽을 허용하려면 pod IP 주소를 처리하는 Cloud NAT를 구성하면 됩니다. GKE를 사용하는 Cloud NAT에 대한 자세한 내용은 GKE 상호작용을 참조하세요.

이 예시에는 다음 레코드가 있습니다. GKE 필드는 '커스텀' 메타데이터 구성에서만 사용할 수 있습니다.

reporter connection.src_ip connection.dst_ip bytes_sent VPC 주석
SRC 10.0.12.2 203.0.113.1 1224 src_instance.*
src_vpc.*
src_gke_details.cluster.*
dest_location.*

가격 책정

Logging, BigQuery, Pub/Sub의 표준 가격 책정이 적용됩니다. VPC 흐름 로그 가격에 관한 설명은 Network Telemetry 가격 책정에 나와 있습니다.

FAQ

  • VPC 흐름 로그에 방화벽 규칙을 기반으로 허용된 트래픽과 거부된 트래픽이 모두 포함되나요?

    • VPC 흐름 로그는 VM의 관점에서 트래픽을 포함합니다. VM의 모든 이그레스(발신) 트래픽은 이그레스 거부 방화벽 규칙에 의해 차단되는 경우에도 로깅됩니다. 인그레스(수신) 트래픽은 인그레스 허용 방화벽 규칙에 의해 허용되는 경우 로깅됩니다. 인그레스 거부 방화벽 규칙에 의해 차단된 인그레스 트래픽은 로깅되지 않습니다.
  • VPC 흐름 로그는 다중 인터페이스가 있는 VM 인스턴스에서 작동하나요?

  • VPC 흐름 로그는 이전 네트워크에서 작동하나요?

다음 단계