이 문서는 기능, 가격, 사용 사례를 검토하는 데 도움이 되므로 자체 관리형 Apache Kafka에서 Pub/Sub로의 마이그레이션을 고려하려는 경우에 유용합니다. 각 섹션에서는 일반적인 Kafka 사용 사례를 소개하고 Pub/Sub에서 동일한 기능을 구현할 수 있는 실무 가이드를 제공합니다.
Pub/Sub 개요
Pub/Sub는 비동기 메시징 서비스입니다. Pub/Sub는 이벤트를 처리하는 서비스에서 이벤트를 생성하는 서비스를 분리합니다. Pub/Sub를 메시징 기준 미들웨어 또는 스트리밍 분석 파이프라인의 이벤트 수집 및 전송용으로 사용할 수 있습니다. 두 시나리오 모두 게시자 애플리케이션이 메시지를 만들고 주제로 전송합니다. 구독자 애플리케이션은 주제에 관한 구독을 만들어 주제로부터 메시지를 수신합니다. 구독은 특정 주제에 대해 메시지 수신 의향을 나타내는 이름이 지정된 항목입니다.
Pub/Sub는 모든 Google Cloud 리전에서 실행됩니다. Pub/Sub는 리소스 위치 제한 정책에 정의된 대로 데이터 스토리지가 허용되는 가장 가까운 Google Cloud 데이터 센터로 게시자 트래픽을 전달합니다.
Pub/Sub는 Dataflow ,Cloud Storage 및Cloud Run 등 여러 Google Cloud 서비스와 통합될 수 있습니다. 이러한 서비스를 Pub/Sub에 메시지를 게시할 수 있는 데이터 소스나 Pub/Sub에서 메시지를 수신할 수 있는 데이터 싱크의 역할을 하도록 구성할 수 있습니다.
Kafka 개요
Apache Kafka는 오픈소스의 분산형 이벤트 스트리밍 플랫폼이며, 애플리케이션이 이벤트 스트림을 게시, 구독, 저장, 처리할 수 있도록 지원합니다. Kafka 서버는 클라이언트 애플리케이션이 이벤트를 읽고, 쓰고, 처리하기 위해 상호작용하는 머신 클러스터로 실행됩니다. Kafka를 사용하여 애플리케이션 분리, 메시지 전송 및 수신, 활동 추적, 로그 데이터 집계, 스트림 처리를 수행할 수 있습니다.
Kafka 클러스터 내에서 클러스터의 일부 노드는 브로커로 지정됩니다. 브로커는 제작자로부터 메시지를 수신하고 이를 디스크에 저장합니다. 저장된 메시지는 주제별로 정리되고 클러스터에서 여러 다른 브로커로 분할됩니다. 주제에 게시된 새 이벤트는 해당 주제의 파티션 중 하나의 끝에 추가됩니다. 그런 후 소비자는 디스크에서 읽혀지고 소비자로 전송되는 메시지를 브로커에서 가져올 수 있습니다.
Kafka와 Pub/Sub 사이의 차이점 이해
다음 다이어그램에서는 Kafka와 Pub/Sub의 확장 전략이 어떻게 다른지 보여줍니다.
앞의 다이어그램에서 각 M은 메시지를 나타냅니다. Kafka 브로커는 메시지의 가로 행으로 표시되는 메시지의 여러 순서가 지정된 파티션을 관리합니다. 소비자는 파티션을 호스팅하는 머신을 기준으로 일정 용량이 있는 특정 파티션에서 메시지를 읽습니다. Pub/Sub에는 파티션이 없고, 소비자는 대신 수요에 따라 자동 확장되는 주제에서 읽기를 수행합니다. 예상되는 소비자 로드를 처리하기 위해 필요한 파티션 수로 각 Kafka 주제를 구성합니다. Pub/Sub는 수요에 따라 자동으로 확장됩니다.
기능 비교
다음 표에서는 Apache Kafka 기능을 Pub/Sub 기능과 비교합니다.
| Apache Kafka | Pub/Sub | |
|---|---|---|
| 메시지 순서 | 예, 파티션 내 | 예, 주제 내 |
| 메시지 중복 삭제 | 예 | 예, Dataflow 사용 |
| 구독정보 푸시 | 아니요 | 예 |
| 데드 레터 큐 (처리할 수 없는 메시지 큐) |
버전 2.0 이상 | 예 |
| 트랜잭션 | 예 | 아니요 |
| 메시지 스토리지 | 사용 가능한 머신 스토리지만으로 제한됨 | 31일. 주제가 최대 31일 동안 확인된 메시지를 포함하여 게시된 메시지를 보존할 수 있습니다. 주제의 `message_retention_duration` 속성으로 구성할 수 있습니다. |
| 메시지 재생 | 예 | 예 |
| 지역 | MirrorMaker를 사용하여 로컬 클러스터가 복제 가능 | 구성 가능한 메시지 스토리지 위치가 있는 전 세계에 분산된 서비스 |
| 로깅 및 모니터링 | 자체 관리 | Cloud Logging 및 Cloud Monitoring을 사용한 자동화 |
| 스트림 처리 | 예, KSQL 사용 | 예, Dataflow 사용 |
Pub/Sub 메시지 스토리지 및 재생 이해
기본적으로 Pub/Sub는 미확인 메시지를 최대 7일 동안 보관하지만, 구독에서 가장 오래된 메시지(확인 또는 미확인)의 기간에 따라 최대 7일 동안 확인된 메시지를 보관하도록 Pub/Sub 구독을 구성할 수 있습니다. 확인한 메시지를 보관하면 타임스탬프를 기준으로 메시지의 일부 또는 전부를 재생할 수 있습니다. 타임스탬프를 기준으로 메시지를 재생하면 타임스탬프 이후에 수신된 모든 메시지가 미확인으로 표시됩니다. 확인하지 않은 메시지는 다시 전송됩니다.
구독을 미리 구성할 필요 없이 필요에 따라 개별 구독의 스냅샷을 만들 수 있습니다. 예를 들어 예상치 못한 확인이나 잘못된 확인으로부터 복구해야 할 수도 있으므로 새 구독자 코드를 배포할 때 스냅샷을 만들 수 있습니다.
데드 레터 주제를 포함하는 기본 제공 안전 조치
Pub/Sub는 Kafka 2.0 오류 처리는 물론 Kafka Connect가 데드 레터 주제를 처리하는 방식과 유사한 기능을 제공합니다. 메시지가 성공적으로 전송되었음을 Pub/Sub에 알리기 위해 Pub/Sub 주제 구독자가 수신하고 처리하는 메시지를 확인할 수 있습니다. 구독자가 한동안 메시지를 처리할 수 없는 경우 Pub/Sub에서 이러한 메시지를 데드 레터 주제로 자동 전달하고 나중에 액세스할 수 있도록 저장할 수 있습니다. 메시지를 데드 레터 주제로 전송하기 전에 Pub/Sub에서 메시지를 전달하는 시도 횟수를 구성할 수 있습니다.
Dataflow를 사용한 Pub/Sub의 메시지 중복 삭제
Pub/Sub는 게시된 각 메시지를 모든 구독에 최소한 한 번은 전송합니다. 일반적으로 전달을 1회 이상 수용하려면 메시지를 처리할 때 구독자에게 멱등성이 있어야 합니다. 기존 구독자가 멱등성을 갖도록 작동할 수 없는 경우 Dataflow를 사용하여 메시지 중복을 삭제할 수 있습니다. 구독자에게 전송된 메시지가 중복 비율이 높다면 구독자가 메시지를 올바르게 확인하지 못하거나 확인 기한이 너무 짧다는 의미일 수 있습니다.
Pub/Sub의 메시지 순서 지정
Kafka 구독자 애플리케이션에 메시지 순서 지정이 사용되는 경우 순서 지정 키를 사용할 때 Pub/Sub에서 이 요구사항을 지원할 수 있습니다. 현재까지 순서 지정은 지정된 리전에서 게시되는 메시지에 대해 보장됩니다. 메시지 순서 지정을 활용하기 위해서는 게시자 및 구독자가 위치별 엔드포인트를 사용하여 메시지를 올바른 리전으로 라우팅하는지 확인합니다.
자체 호스팅 서비스와 관리형 서비스의 책임 비교
다음 표에서는 Kafka를 사용해 자체 호스팅되는 기능과 Pub/Sub를 사용하여 Google에서 관리되는 기능을 비교합니다.
| Apache Kafka | Pub/Sub | |
|---|---|---|
| 가용성 | Kafka를 추가 위치에 수동으로 배포 | 고가용성과 짧은 지연 시간을 위해 모든 Google Cloud 리전에 배포 |
| 재해 복구 | 자체 백업 및 복제를 설계 및 유지보수 | Google에서 관리하는 설정 |
| 인프라 관리 | 가상 머신(VM) 또는 머신을 수동으로 배포 및 운영 (일관된 버전 관리 및 패치를 유지보수해야 합니다.) | Google에서 관리하는 설정 |
| 용량 계획 | 사전에 수동으로 스토리지 및 컴퓨팅 요구사항 계획 | Google에서 관리하는 설정 |
| 지원 | 없음 | 24시간 대기 중인 직원과 지원 서비스 |
Pub/Sub 메시지 크기 한도 및 해결 방법
Kafka 및 Pub/Sub 모두 대량의 작은 메시지를 처리할 때 성능이 우수합니다. Kafka는 메시지 크기에 엄격한 제한이 없으며 허용되는 메시지 크기를 직접 구성할 수 있습니다. 반면 Pub/Sub에서는 메시지 크기가 10MB로 제한됩니다. 다음 다이어그램과 같이 우선 Cloud Storage에 객체를 저장하면 더 큰 페이로드를 간접적으로 전송할 수 있습니다.
앞의 이미지는 게시자가 객체를 Cloud Storage에 저장할 때, 저장된 객체에 대한 URL이 포함된 메시지를 게시한다는 것을 보여줍니다. 구독자가 URL이 포함된 메시지를 수신하면 Cloud Storage에서 파일을 다운로드하고 평소와 같이 처리를 계속합니다.
Kafka 및 Pub/Sub 비용 비교
Pub/Sub에서 비용을 예측하고 관리하는 방법은 Kafka와 다릅니다. Kafka 클러스터 온프레미스 또는 클라우드의 비용에는 머신, 디스크, 네트워킹, 인바운드 및 아웃바운드 메시지 비용은 물론 이러한 시스템과 관련 인프라를 관리 및 유지보수하는 오버헤드 비용이 포함됩니다. Kafka 클러스터를 관리할 때는 머신을 수동으로 업그레이드 및 패치 적용하고, 클러스터 용량을 계획해야 할 경우가 많으며, 재해 복구를 구현하기 위해 광범위한 계획과 테스트가 필요합니다. 실제적인 총소유비용(TCO)을 확인하기 위해 이러한 모든 다양한 비용을 유추하고 집계해야 합니다.
Pub/Sub 가격 책정에는 게시자와 구독자 간 데이터 전송과 확인하지 않은 메시지를 임시로 저장하는 비용이 포함됩니다. 애플리케이션 및 예산 요구사항에 따라 용량이 자동으로 확장되어 사용한 리소스의 비용만 지불합니다.
안정성을 위한 설계
Pub/Sub는 모든 Google Cloud 리전에서 실행되는 전역 관리형 서비스입니다. Pub/Sub 주제는 전역 리소스이므로 모든 Google Cloud 위치에서 해당 주제를 보고 액세스할 수 있습니다. 그러나 특정 메시지는 리소스 위치 정책에 따라 게시자와 가장 가까운 단일 Google Cloud 리전에 저장됩니다. 따라서 하나의 주제에는 Google Cloud 전반의 여러 리전에 저장된 메시지가 있을 수 있습니다. Pub/Sub는 영역 장애에 강합니다. 리전 서비스 중단 시 서비스가 복원될 때까지 특정 리전에 저장된 메시지에 액세스하지 못할 수 있습니다. 가용성 요구사항에 따라 위치별 서비스 엔드포인트를 사용하여 리전 서비스 중단 발생 시 장애 조치 정책을 구현할 수 있습니다.
보안 및 인증
Apache Kafka는 클라이언트 인증서 기반 인증, Kerberos, LDAP, 사용자 이름과 비밀번호를 비롯한 다양한 인증 메커니즘을 지원합니다. 승인을 위해 Kafka는 액세스 제어 목록(ACL)을 사용한 특정 주제에 액세스할 수 있는 제작자 및 소비자 결정을 지원합니다.
Pub/Sub는 Google Cloud 사용자 계정 및 서비스 계정에 대한 인증을 지원합니다. Google Cloud의 Identity and Access Management(IAM)로 Pub/Sub 주제 및 구독에 대한 세밀한 액세스 제어가 관리됩니다. 사용자 계정을 사용하면 Pub/Sub 작업에 비율 제한이 적용됩니다. 대량의 트랜잭션을 수행해야 하는 경우에는 서비스 계정을 사용하여 Pub/Sub와 상호작용하면 됩니다.
Pub/Sub로의 마이그레이션 계획
Google Cloud로의 모든 마이그레이션은 워크로드 평가 및 기반 구축에서 시작합니다.
Pub/Sub Kafka 커넥터를 사용한 단계별 마이그레이션
Pub/Sub Kafka 커넥터를 사용하면 Kafka 인프라를 Pub/Sub로 단계별로 마이그레이션할 수 있습니다.
특정 주제에 대한 모든 메시지를 Kafka에서 Pub/Sub로 전달하도록 Pub/Sub 커넥터를 구성할 수 있습니다. 그런 후 Pub/Sub에서 이러한 주제에 대해 메시지를 수신하도록 개별 구독자 애플리케이션을 업데이트할 수 있으며, 게시자 애플리케이션은 Kafka로 메시지를 계속 게시할 수 있습니다. 이러한 단계별 접근 방식에 따라 오류 및 다운타임 위험을 최소화하는 대화식 방법으로 구독자 애플리케이션을 업데이트, 테스트, 모니터링할 수 있습니다.
이 섹션에는 두 가지 고유 단계로 이 프로세스를 시각화할 수 있게 해주는 2개의 다이어그램이 포함됩니다. 다음 다이어그램은 마이그레이션 단계 중의 구성을 보여줍니다.
위의 다이어그램에서 현재 구독자는 Kafka에서 메시지를 계속 수신합니다. 사용자가 Pub/Sub에서 메시지를 수신하도록 구독자를 하나씩 업데이트합니다.
특정 주제의 모든 구독자가 Pub/Sub에서 메시지를 수신하도록 업데이트된 후 Pub/Sub에 메시지를 게시하도록 해당 주제의 게시자 애플리케이션을 업데이트할 수 있습니다. 그런 다음 메시지 흐름을 엔드 투 엔드로 테스트하고 모니터링하여 설정을 확인하면 됩니다.
다음 다이어그램은 모든 구독자가 Pub/Sub에서 메시지를 수신한 후의 구성을 보여줍니다.
시간이 지나면서 모든 게시자가 Pub/Sub에 직접 게시하도록 업데이트된 후 마이그레이션이 완료됩니다. 이 접근방식을 사용하여 애플리케이션을 동시에 업데이트하는 팀들이 많습니다. 성공적인 마이그레이션에 필요한 기간만큼 Kafka와 Pub/Sub가 공존할 수 있습니다.
Pub/Sub 모니터링
Kafka에서 Pub/Sub로 마이그레이션을 수행하는 동안과 수행이 완료된 후에는 애플리케이션을 모니터링하는 것이 중요합니다. Pub/Sub는 성능, 업타임, 전반적인 애플리케이션 상태에 대한 가시성을 제공하는 데 도움이 되는 Cloud Monitoring을 사용하여 측정항목을 내보냅니다. 예를 들어 제공되지 않은 메시지 수 모니터링으로 구독자가 메시지 흐름을 따라가고 있는지 확인할 수 있습니다. 전송되지 않은 메시지를 모니터링하기 위해서는 가장 오래된 미확인 메시지의 타임스탬프가 특정 임계값을 지나서 확장될 때 알림을 만듭니다. 또한 전송 요청 수 측정항목을 모니터링하고 응답 코드를 조사하여 Pub/Sub 서비스 자체의 상태를 모니터링할 수 있습니다.
다음 단계
- Pub/Sub에서 스트림 분석
- Pub/Sub API 참조
- Pub/Sub 모니터링 문서
- 클라우드 인프라 서비스 중단의 재해 복구 설계
- Google Cloud에 대한 참조 아키텍처, 다이어그램, 권장사항 살펴보기 Cloud 아키텍처 센터 살펴보기