Kafka로 멀티 클러스터 배포 및 복제 마스터하기

Apache Kafka 및 일반 사용 사례, 다중 클러스터 배포를 확장하는 현재 도구, 다중 클러스터 배포를 단순화하는 연결 솔루션에 대한 간략한 개요입니다.

목차

• 카프카란 무엇인가?

• 카프카와 쿠버네티스

• 다중 클러스터 Kafka 사례

• 멀티 클러스터 Kafka

  • 확장된 클러스터 - 동기식 복제
  • 연결된 클러스터 - 비동기 복제

• 결론

  
  

카프카란 무엇인가?

일반적으로 Kafka 라고 알려진 Apache Kafka는 Apache Software Foundation에서 관리하는 오픈 소스 이벤트 스트리밍 플랫폼입니다. 처음 LinkedIn 에서 구상된 Apache Kafka는 Jay Kreps , Neha Narkhede 및 Jun Rao 가 공동으로 제작했으며 이후 2011년에 오픈 소스 프로젝트로 출시되었습니다. Wiki 페이지

오늘날 Kafka는 실시간 데이터 피드를 처리하도록 설계된 가장 인기 있는 이벤트 스트리밍 플랫폼 중 하나입니다. 확장 가능하고 내결함성이 있는 고성능 스트리밍 데이터 파이프라인을 구축하는 데 널리 사용됩니다.

Kafka의 용도는 지속적으로 확장되고 있으며, Brij Pandey 가 첨부된 이미지에서 상위 5개 사례를 잘 보여줍니다.

간략한 입문서로서 Kafka 플랫폼의 구성 요소와 작동 방식을 이해하는 것이 중요합니다.

Kafka는 실시간 데이터 피드를 효율적으로 처리하도록 설계된 분산 이벤트 스트리밍 플랫폼으로 작동합니다. 게시-구독 메시징 모델을 기반으로 작동하며 분산 및 내결함성 아키텍처를 따릅니다. 이는 "주제"라고 불리는 지속적이고 질서 있고 분할된 일련의 기록을 유지합니다. 생산자는 이러한 주제에 데이터를 쓰고 소비자는 이를 읽습니다. 이를 통해 데이터 생산자와 소비자 간의 분리가 가능하고 여러 애플리케이션이 동일한 데이터 스트림을 독립적으로 사용할 수 있습니다.

Kafka의 주요 구성 요소는 다음과 같습니다.

1. 주제 및 파티션: Kafka는 데이터를 주제로 구성합니다. 각 주제는 레코드 스트림이며 주제 내의 데이터는 여러 파티션으로 분할됩니다. 각 파티션은 순서가 있고 변경할 수 없는 레코드 시퀀스입니다. 파티션을 사용하면 데이터를 여러 Kafka 브로커에 분산시킬 수 있어 수평 확장성과 병렬성이 가능해집니다.

   
   

2. 생산자 : 생산자는 Kafka 주제에 데이터를 쓰는 애플리케이션입니다. 특정 주제에 레코드를 게시한 다음 해당 주제의 파티션에 저장합니다. 생산자는 명시적으로 특정 파티션에 레코드를 보내거나 Kafka가 파티셔닝 전략을 사용하여 파티션을 결정하도록 허용할 수 있습니다.

   
   

3. 소비자 : 소비자는 Kafka 주제에서 데이터를 읽는 애플리케이션입니다. 하나 이상의 주제를 구독하고 할당된 파티션의 레코드를 소비합니다. 소비자 그룹은 소비 규모를 조정하는 데 사용되며, 주제 내의 각 파티션은 그룹 내 한 명의 소비자만 사용할 수 있습니다. 이를 통해 여러 소비자가 병렬로 작업하여 동일한 주제의 서로 다른 파티션의 데이터를 처리할 수 있습니다.

   
   

4. 브로커 : Kafka는 서버 클러스터로 실행되며 각 서버를 브로커라고 합니다. 브로커는 생산자와 소비자의 읽기 및 쓰기 요청을 처리하고 주제 파티션을 관리하는 일을 담당합니다. Kafka 클러스터에는 로드를 분산하고 내결함성을 보장하기 위해 여러 브로커가 있을 수 있습니다.

   
   

5. 파티션/복제 : 내결함성과 데이터 내구성을 달성하기 위해 Kafka는 주제 파티션에 대한 복제 구성을 허용합니다. 각 파티션에는 여러 개의 복제본이 있을 수 있으며, 하나의 복제본은 리더로 지정되고 다른 복제본은 팔로워로 지정됩니다. 리더 복제본은 해당 파티션에 대한 모든 읽기 및 쓰기 요청을 처리하는 반면, 팔로워는 동기화 상태를 유지하기 위해 리더의 데이터를 복제합니다. 리더 복제본이 있는 브로커에 장애가 발생하면 팔로어 중 하나가 자동으로 새 리더가 되어 지속적인 운영을 보장합니다.

   
   

6. 오프셋 관리 : Kafka는 각 파티션에 대한 오프셋 개념을 유지합니다. 오프셋은 파티션 내 레코드의 고유 식별자를 나타냅니다. 소비자는 현재 오프셋을 추적하여 실패 또는 재처리 시 중단한 부분부터 소비를 재개할 수 있습니다.

   
   

7. ZooKeeper : Kafka 자체의 일부는 아니지만 ZooKeeper는 메타데이터를 관리하고 Kafka 클러스터의 브로커를 조정하는 데 자주 사용됩니다. 리더 선택, 주제 및 파티션 정보, 소비자 그룹 조정 관리에 도움이 됩니다. [참고: Zookeeper 메타데이터 관리 도구는 내부적으로 관리되는 메타데이터용 프로토콜인 Kafka Raft 또는 KRaft를 위해 곧 단계적으로 폐지될 예정입니다. ]

   
   

전반적으로 Kafka의 디자인과 아키텍처는 대량의 실시간 데이터 스트림을 처리하기 위한 확장성이 뛰어나고 내결함성이 뛰어나며 효율적인 플랫폼을 제공합니다. 이는 많은 데이터 기반 애플리케이션 및 데이터 인프라의 핵심 구성 요소가 되어 데이터 통합, 이벤트 처리 및 스트림 분석을 촉진합니다.

일반적인 Kafka 아키텍처는 다음과 같습니다.

Kafka 클러스터링은 여러 Kafka 브로커를 하나의 그룹으로 함께 실행하여 Kafka 클러스터를 형성하는 방식을 의미합니다. 클러스터링은 Kafka 아키텍처의 기본 측면으로, 확장성, 내결함성, 고가용성을 비롯한 여러 이점을 제공합니다. Kafka 클러스터는 대규모 데이터 스트림을 처리하고 장애가 발생하더라도 시스템이 계속 작동하도록 보장하는 데 사용됩니다.

클러스터에서 Kafka 토픽은 확장성과 병렬성을 달성하기 위해 여러 파티션으로 나뉩니다. 각 파티션은 선형적으로 정렬된 불변의 레코드 시퀀스입니다. 따라서 파티션을 사용하면 클러스터의 여러 브로커에 데이터를 분산시킬 수 있습니다.

최소 Kafka 클러스터는 3개의 Kafka 브로커로 구성되며 각 브로커는 별도의 서버(가상 또는 물리적)에서 실행될 수 있습니다. 3노드 지침은 브로커 오류가 발생할 경우 분할 브레인 시나리오를 방지하는 데 도움이 됩니다.

카프카와 쿠버네티스

Kafka를 채택하는 기업이 늘어나면서 Kubernetes에 Kafka를 배포하는 데 대한 관심도 높아지고 있습니다.

실제로 Dynatrace의 최신 Kubernetes in the Wild 보고서 2023에 따르면 대규모 조직의 40% 이상이 Kubernetes 내에서 오픈 소스 메시징 플랫폼을 실행하고 있으며, 이 중 대부분이 Kafka입니다.

소스 .

같은 보고서는 "쿠버네티스가 클라우드의 '운영체제'로 떠오르고 있다"는 대담한 주장도 내놨다.

따라서 Kafka 관리자는 Kafka와 Kubernetes 간의 상호 작용과 이를 규모에 맞게 적절하게 구현하는 방법을 이해하는 것이 중요합니다.

다중 클러스터 Kafka 사례

단일 Kubernetes 클러스터 설정에서 Kafka 클러스터를 실행하는 것은 매우 간단하며 이론상 필요에 따라 확장성을 가능하게 합니다. 그러나 제작 과정에서는 그림이 약간 흐려질 수 있습니다.

Kafka와 Kubernetes 간에 클러스터 라는 용어의 사용을 구별해야 합니다. Kubernetes 배포에서는 클러스터라는 용어를 사용하여 Kubernetes 클러스터라고 하는 연결된 노드 그룹을 지정합니다. Kafka 워크로드가 Kubernetes에 배포되면 Kubernetes 클러스터 내에서 실행되는 Kafka 클러스터로 끝나게 되지만, 논의와 더 관련이 있는 것은 탄력성, 성능, 데이터 주권을 위해 여러 Kubernetes 클러스터에 걸쳐 있는 Kafka 클러스터를 가질 수도 있습니다. 등.

우선 Kafka는 다중 테넌트 설정용으로 설계되지 않았습니다. 기술적인 측면에서 Kafka는 Kubernetes 네임스페이스 또는 리소스 격리와 같은 개념을 이해하지 못합니다. 특정 주제 내에서 여러 사용자 그룹 간에 보안 액세스 제한을 적용하는 쉬운 메커니즘은 없습니다.

또한 워크로드마다 업데이트 빈도와 규모 요구 사항이 다를 수 있습니다(예: 배치 애플리케이션과 실시간 애플리케이션). 두 워크로드를 단일 클러스터로 결합하면 부정적인 영향을 미치거나 필요한 것보다 훨씬 더 많은 리소스를 소비할 수 있습니다.

데이터 주권 및 규정 준수로 인해 특정 지역이나 애플리케이션에 데이터와 주제를 함께 배치하는 데 제한이 적용될 수도 있습니다.

물론 탄력성은 여러 Kafka 클러스터가 필요한 또 다른 강력한 원동력입니다. Kafka 클러스터는 주제의 내결함성을 위해 설계되었지만 여전히 전체 클러스터의 치명적인 오류에 대비해야 합니다. 이러한 경우 완전히 복제된 클러스터가 필요하므로 적절한 비즈니스 연속성 계획이 가능합니다.

워크로드를 클라우드로 마이그레이션하거나 하이브리드 클라우드 전략을 갖고 있는 기업의 경우 위험한 전체 규모의 Kafka 마이그레이션보다는 시간이 지남에 따라 여러 Kafka 클러스터를 설정하고 계획된 워크로드 마이그레이션을 수행하는 것이 좋습니다.

이는 실제로 기업이 서로 상호 작용해야 하는 여러 Kafka 클러스터를 생성해야 하는 이유 중 일부에 불과합니다.

멀티 클러스터 Kafka

서로 연결된 여러 Kafka 클러스터를 가지려면 한 클러스터의 주요 항목을 다른 클러스터에 복제해야 합니다. 여기에는 주제, 오프셋 및 메타데이터가 포함됩니다. Kafka 용어에서는 이러한 복제를 미러링으로 간주합니다. 다중 클러스터 설정에는 두 가지 접근 방식이 가능합니다. 확장된 클러스터 또는 연결된 클러스터.

확장된 클러스터 - 동기식 복제

확장된 클러스터는 여러 물리적 클러스터에 걸쳐 '확장'된 논리적 클러스터입니다. 주제와 복제본은 물리적 클러스터에 분산되어 있지만 논리적 클러스터로 표시되므로 애플리케이션 자체는 이러한 다중성을 인식하지 못합니다.

확장된 클러스터는 강력한 일관성을 가지며 관리가 더 쉽습니다. 애플리케이션은 여러 클러스터의 존재를 인식하지 못하기 때문에 연결된 클러스터에 비해 확장된 클러스터에 배포하기가 더 쉽습니다.

확장된 클러스터의 단점은 클러스터 간에 동기 연결이 필요하다는 것입니다. 이는 하이브리드 클라우드 배포에 적합하지 않으며 '분할 브레인' 시나리오를 방지하려면 최소 3개 클러스터의 쿼럼이 필요합니다.

연결된 클러스터 - 비동기 복제

반면에 연결된 클러스터는 여러 개의 독립 클러스터를 연결하여 배포됩니다. 이러한 독립적인 클러스터는 다양한 지역이나 클라우드 플랫폼에서 실행될 수 있으며 개별적으로 관리됩니다.

연결된 클러스터 모델의 주요 이점은 다른 클러스터가 독립적으로 실행되므로 클러스터 오류가 발생하더라도 가동 중지 시간이 없다는 것입니다. 각 클러스터는 특정 리소스에 맞게 최적화될 수도 있습니다.

연결된 클러스터의 주요 단점은 클러스터 간의 비동기 연결에 의존한다는 것입니다. 클러스터 간에 복제되는 토픽은 '쓰기 시 복사'가 아니라 최종 일관성에 따라 달라집니다. 이로 인해 비동기 미러링 프로세스 중에 데이터 손실이 발생할 수 있습니다.

또한 연결된 클러스터에서 작동하는 애플리케이션은 여러 클러스터를 인식하도록 수정되어야 합니다.

이 난제에 대한 솔루션을 다루기 전에 Kafka 클러스터 연결을 활성화하기 위해 시중에서 판매되는 일반적인 도구에 대해 간략하게 설명하겠습니다.

오픈 소스 Kafka 자체에는 Mirror Maker라는 미러링 도구가 함께 제공됩니다.

Mirror Maker는 내장된 생산자를 통해 서로 다른 클러스터 간에 주제를 복제합니다. 이러한 방식으로 데이터는 개별 프로세스를 중단하지 않고 최종 일관성을 유지하면서 클러스터 간에 교차 복제됩니다.

Mirror Maker는 개념적으로는 단순하지만 Mirror Maker를 대규모로 설정하는 것은 IT 조직에 상당히 어려울 수 있다는 점에 유의하는 것이 중요합니다. IP 주소, 명명 규칙, 복제본 수 등을 올바르게 관리해야 합니다. 그렇지 않으면 주제가 무한히 복제되어 결국 충돌이 발생하는 '무한 복제'로 이어질 수 있습니다.

Mirror Maker의 다른 단점은 업데이트 허용/불허 목록의 동적 구성이 부족하다는 것입니다. 또한 Mirror Maker는 주제 속성을 적절하게 동기화하지 않으므로 복제할 주제를 추가하거나 제거할 때 규모에 따라 운영상 골치 아픈 일이 됩니다. Mirror Maker 2는 이러한 문제 중 일부를 해결하려고 시도하지만 많은 IT 상점에서는 여전히 Mirror Maker를 올바르게 설정하는 데 어려움을 겪고 있습니다.

Kafka 복제를 위한 다른 오픈 소스 도구로는 Salesforce의 Mirus, Uber의 uReplicator, Netflix 의 맞춤형 Flink가 있습니다.

상업용 라이센스 옵션의 경우 Confluent는 Confluent Replicator와 Cluster Linking의 두 가지 옵션을 제공합니다. Confluent Replicator는 기본적으로 클러스터 간에 주제 데이터를 복사하는 고성능 및 탄력적 방법을 제공하는 Kafka Connect 커넥터입니다. 클러스터 연결은 내부적으로 개발된 또 다른 제품으로, 주제 오프셋을 유지하면서 다중 지역 복제를 목표로 합니다.

그럼에도 불구하고 클러스터 연결은 데이터가 네트워크 경계를 넘어 공용 트래픽 경로를 통과해야 하는 비동기식 복제 도구입니다. 지금까지 명확하게 알 수 있듯이 Kafka 복제는 대규모 프로덕션 애플리케이션에 중요한 전략이므로 어떤 옵션을 선택해야 하는지가 문제입니다.

상상력이 풍부한 Kafka 관리자는 애플리케이션 성능 및 복원력 요구 사항에 따라 연결된 클러스터와 확장된 클러스터 또는 이러한 배포의 조합이 필요할 수 있다는 것을 빨리 깨닫게 될 것입니다.

그러나 어려운 점은 클러스터 구성을 설정하고 이를 여러 클러스터에 걸쳐 대규모로 관리하는 기하급수적인 과제입니다. 이 악몽을 해결하는 더 우아한 방법은 무엇입니까?

Avesha의 KubeSlice는 두 세계의 장점을 최대한 활용할 수 있는 간단한 방법입니다. KubeSlice는 클러스터 또는 네임스페이스 간에 직접적인 서비스 연결을 생성함으로써 Kafka 클러스터 간의 개별 연결을 수동으로 구성할 필요가 없습니다.

KubeSlice는 핵심적으로 클러스터 간에 안전한 동기식 레이어 3 네트워크 게이트웨이를 생성합니다. 애플리케이션 또는 네임스페이스 수준에서 격리됩니다. 이것이 설정되면 Kafka 관리자는 모든 클러스터에 Kafka 브로커를 자유롭게 배포할 수 있습니다.

각 브로커는 브로커 자체가 별도의 클러스터에 있더라도 슬라이스를 통해 조인된 다른 모든 브로커에 대해 동기식 연결을 갖습니다. 이는 브로커 간에 확장된 클러스터를 효과적으로 생성하고 강력한 일관성과 낮은 관리 오버헤드라는 이점을 제공합니다.

케이크도 드세요!

Mirror Maker를 클러스터에 배포하려는 경우 클러스터 간의 연결이 KubeSlice에 위임되므로 최소한의 노력으로 이를 수행할 수 있습니다. 따라서 Kafka 애플리케이션은 필요에 따라 기능을 혼합하고 일치시킬 수 있는 기능을 통해 동일한 배포에서 동기(속도, 탄력성) 및 비동기(독립성, 규모) 복제의 이점을 누릴 수 있습니다. 이는 온프레미스 데이터 센터, 퍼블릭 클라우드 또는 하이브리드 설정의 모든 조합에 해당됩니다.

가장 좋은 점은 KubeSlice가 중단 없이 배포된다는 점입니다. 즉, 이미 배포된 도구를 제거할 필요가 없습니다. 단순히 슬라이스를 설정하고 해당 슬라이스 에 Kafka 배포를 추가하기만 하면 됩니다.

결론

이 블로그에서는 Apache Kafka에 대한 간략한 개요를 제공하고 몇 가지 일반적인 사용 사례를 다루었습니다. 여러 클러스터에 걸쳐 Kafka 배포를 확장하는 데 사용할 수 있는 현재 도구를 다루고 각각의 장점/단점을 논의했습니다. 마지막으로 이 기사에서는 Kafka 다중 클러스터 배포를 단순화하고 대규모로 여러 클러스터에 걸쳐 Kafka 복제를 구성하는 것과 관련된 문제를 제거하는 새로운 서비스 연결 솔루션인 Kubeslice도 소개했습니다.

독자들이 유용하다고 생각할 수 있는 몇 가지 링크:

AWS에서 Kafka를 실행하는 모범 사례에 대한 이전 블로그 (KubeSlice가 도입되기 전)

KubeSlice 설정 안내

GKE에 Kafka 배포