이 문서는 기능, 가격, 사용 사례를 검토하는 데 도움이 되므로 자체 관리형 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 사용자 계정 및 서비스 계정에 대한 인증을 지원합니다. Pub/Sub 주제 및 구독에 대한 세밀한 액세스 제어는 Google Cloud의 Identity and Access Management (IAM)에 의해 관리됩니다. 사용자 계정을 사용하면 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 아키텍처 센터를 살펴보세요.