Cloud Dataflow를 사용하여 Kafka의 외부 호스팅 메시지 처리

이 문서에서는 Dataflow 및 KafkaIO를 사용하여 메시지를 처리할 때 고려해야 하는 주요 네트워킹 관련 문제에 대해 설명합니다. 이 경우 Kafka는 Google Cloud의 외부에 있지만 Dataflow를 사용하여 Google Cloud 내부에서 메시지를 처리하려고 합니다. Kafka Apache Beam 변환이 출시됨에 따라 Apache Beam과 Dataflow를 활용하여 Kafka의 메시지를 처리할 수 있게 되었습니다. 다음 그림에서는 Dataflow를 사용하여 메시지를 처리하는 데 널리 사용되는 시나리오를 보여줍니다. 여기에서 Kafka는 온프레미스에 호스팅되거나 Amazon Web Services(AWS) 등의 다른 퍼블릭 클라우드에 호스팅됩니다.

Google Cloud 외부의 Kafka 메시지 처리

네트워크 토폴로지

Google Cloud의 리소스를 Google Cloud 외부의 리소스와 연결할 때는 다양한 연결 옵션이 가능합니다.

Google Cloud에서 예측 가능한 성능과 안정성을 위해 가장 좋은 옵션은 Dedicated Interconnect이지만, 이 옵션은 제3자가 새로운 회로를 프로비저닝해야 하므로 설정하는 데 오래 걸릴 수 있습니다. VPN 기반 토폴로지를 사용하고 있다면 처리량이 높은 VPN 설정을 고려할 수 있습니다. Dedicated Interconnect와 IPsec VPN 모두 virtual private cloud(VPC)의 RFC 1918 IP 주소에 직접 액세스하여 Kafka 구성을 단순화 할 수 있습니다. 공개 IP 기반 토폴로지에서는 네트워킹 작업이 거의 필요하지 않으므로 빠른 시작이 가능합니다.

두 가지 토폴로지 모두에서 Dataflow 인스턴스와 동일한 서브네트워크에 있는 별도의 Compute Engine 인스턴스에 있는 Kafka 클라이언트로부터 메시지 전송 및 읽기를 수행하여 연결 상태를 검증하는 것이 좋습니다.

스트림 처리 작업에서는 지연 시간도 중요하게 고려해야 합니다. Dataflow 배포에 대해 Kafka 근처에 있는 Google Cloud 리전을 선택합니다. 네트워크 성능 최적화에 대한 도움말은 Google Cloud 네트워크 성능 향상을 위한 5단계를 참조하세요.

공유 RFC 1918 주소 공간

이 섹션에서는 아래 다이어그램에 표시된 네트워크 토폴로지에 대해 설명합니다.

공유 RFC 1918 주소 공간

Dataflow 서브네트워크 지정

기본적으로 Dataflow는 기본 VPC 네트워크의 인스턴스를 실행하는데, 공개 IP 주소를 통해 외부에 호스팅된 Kafka 클러스터에 도달할 수 있다면 문제가 없습니다. Google Cloud의 서브네트워크를 해당 Kafka 클러스터에 연결하는 경로가 Cloud Router에 명시적으로 정의된 비공개 네트워크 토폴로지에서는 Dataflow 인스턴스를 어디에 둘지를 더 자세히 제어해야 합니다. 이 코드 샘플과 같이 Dataflow를 사용하여 networksubnetwork 실행 매개변수를 구성할 수 있습니다.

mvn compile exec:java \
    -Dexec.mainClass=your-pipeline-java-class \
    -Dexec.args="--project=your-gcp-project
    --network=your-dataflow-network \
    --subnetwork=your-dataflow-subnet \
    --runner=DataflowRunner"

Dataflow가 수평 확장을 시도함에 따라 인스턴스를 실행하기에 충분한 IP 주소가 해당 서브네트워크에 있는지 확인합니다. 또한 Dataflow 인스턴스를 실행하기위한 별도의 네트워크를 만들 때 프로젝트의 모든 가상 머신간에 TCP 트래픽을 사용 설정하는 방화벽 규칙이 있는지 확인합니다. 기본 네트워크에는 이 방화벽 규칙이 이미 구성되어 있습니다.

Dataflow와 Kafka 간의 통신

사설 네트워크 토폴로지에서 평소와 같이 Kafka를 구성하고 가용성, 보안, 내구성을 위한 권장사항을 따릅니다.

공개 IP 주소 공간

아래 다이어그램은 공용 인터넷을 통해 액세스할 수 있는 Kafka 브로커 3개로 구성된 클러스터를 안전하게 호스팅하는 샘플 아키텍처를 보여줍니다.

공개 IP 주소 공간

Dataflow 구성

트래픽이 공용 인터넷을 거치므로 네트워크 및 서브네트워크를 구성할 필요는 없습니다. 그러나 비공개 네트워크 토폴로지의 경우에는 Dataflow 네트워크에서 해당 Kafka 클러스터의 공개 IP 주소로 연결되는 경로가 있기만 하다면 네트워크 및 서브네트워크를 지정할 수 있습니다.

Kafka 구성

이전 다이어그램에 표시된 아키텍처에서는 Kafka 문서 및 구성에서 보안 소켓 레이어(SSL) 표준 규칙이 사용됩니다. 하지만 이 아키텍처는 실제로 전송 계층 보안(TLS)을 사용하여 외부 클라이언트와 Kafka 사이의 트래픽을 보호하고 브로커 간 통신에는 일반 텍스트를 사용합니다. Kafka 리스너가 내부 및 외부 통신에 모두 사용되는 네트워크 인터페이스에 바인딩되는 경우에는 리스너 구성이 간편합니다. 그러나 AWS 배포 등의 많은 시나리오에서는 클러스터에 속한 Kafka 브로커의 외부 공개 주소가 Kafka가 사용하는 내부 네트워크 인터페이스와 다릅니다. 이러한 경우 이 샘플 server.properties 스니펫에 나온 advertised.listeners 속성을 사용할 수 있습니다.

# Configure protocol map
listener.security.protocol.map=INTERNAL:PLAINTEXT,EXTERNAL:SSL
# Use plaintext for inter-broker communication inter.broker.listener.name=INTERNAL
# Specify that Kafka listeners should bind to all local interfaces listeners=INTERNAL://0.0.0.0:9092,EXTERNAL://0.0.0.0:9093
# Separately, specify externally visible address advertised.listeners=INTERNAL://kafkabroker-n.mydomain.com:9092,EXTERNAL://kafkabroker-n.mydomain.com:9093

이 구성에서 외부 클라이언트는 'SSL' 채널을 통해 포트 9093로 연결하고, 내부 클라이언트는 일반 텍스트 채널을 통해 포트 9092로 연결합니다. advertised.listeners에 주소를 지정할 때는 외부 및 내부 트래픽에서 동일한 인스턴스로 확인되는 DNS 이름(이 샘플에서는 kafkabroker-n.mydomain.com)을 사용합니다. 공개 IP 주소는 내부 트래픽에서 확인에 실패할 수 있으므로 사용하지 못할 가능성이 높습니다.

다음 단계