Kafka: The Definitive Guide, 2nd Edition

10장. 클러스터 간 데이터 미러링

이 작품은 AI를 사용하여 번역되었습니다. 여러분의 피드백과 의견을 환영합니다: [e-mail]

이 책의 대부분에서는 단일 Kafka 클러스터의 설정, 유지 관리 및 사용에 대해 설명합니다. 그러나 아키텍처에 두 개 이상의 클러스터가 필요할 수 있는 몇 가지 시나리오가 있습니다.

어떤 경우에는 클러스터가 완전히 분리되어 있습니다. 클러스터는 서로 다른 부서 또는 서로 다른 사용 사례에 속하며, 한 클러스터에서 다른 클러스터로 데이터를 복사할 이유가 없습니다. 때로는 서로 다른 SLA 또는 워크로드로 인해 단일 클러스터를 여러 사용 사례에 맞게 조정하기 어려운 경우도 있습니다. 다른 경우에는 보안 요구 사항이 다른 경우도 있습니다. 이러한 사용 사례는 여러 개의 별개의 클러스터를 관리하는 것이 하나의 클러스터를 여러 번 실행하는 것과 같기 때문에 매우 쉽습니다.

다른 사용 사례에서는 서로 다른 클러스터가 상호 의존적이며 관리자가 클러스터 간에 데이터를 지속적으로 복사해야 합니다. 대부분의 데이터베이스에서 데이터베이스 서버 간에 데이터를 지속적으로 복사하는 것을 복제라고 합니다. 여기서는 동일한 클러스터에 속한 Kafka 노드 간의 데이터 이동을 설명하기 위해 복제를 사용했으므로, Kafka 클러스터 간의 데이터 복사를 미러링이라고 부르겠습니다. Apache Kafka의 기본 제공 클러스터 간 복제기를 MirrorMaker라고 합니다.

이 장에서는 데이터 전체 또는 일부의 클러스터 간 미러링에 대해 설명합니다. 먼저 클러스터 간 미러링의 몇 가지 일반적인 사용 사례에 대해 설명하겠습니다. 그런 다음 이러한 사용 사례를 구현하는 데 사용되는 몇 가지 아키텍처를 보여주고 각 아키텍처 패턴의 장단점에 대해 논의합니다. 그런 다음 MirrorMaker 자체와 사용 방법에 대해 설명합니다. 배포 및 성능 튜닝을 포함한 운영 팁을 공유할 것입니다. 마지막으로 MirrorMaker를 대체할 수 있는 몇 가지 대안에 대해 논의하며 마무리하겠습니다.

클러스터 간 미러링 사용 사례

다음은 클러스터 간 미러링이 사용되는 경우의 예시 목록입니다:

지역 및 중앙 클러스터

경우에 따라 회사는 여러 지역, 도시 또는 대륙에 하나 이상의 데이터센터를 보유하고 있습니다. 각 데이터센터에는 자체 Kafka 클러스터가 있습니다. 일부 애플리케이션은 로컬 클러스터와 통신하는 것만으로도 작동할 수 있지만, 일부 애플리케이션은 여러 데이터센터의 데이터가 필요합니다(그렇지 않다면 데이터센터 간 복제 솔루션을 고려하지 않았을 것입니다). 이것이 요구되는 경우는 여러 가지가 있지만, 대표적인 예는 수요와 공급에 따라 가격을 조정하는 회사입니다. 이 회사는 진출한 각 도시에 데이터센터를 두고 현지 공급과 수요에 대한 정보를 수집하고 그에 따라 가격을 조정할 수 있습니다. 그런 다음 이 모든 정보는 중앙 클러스터로 미러링되어 비즈니스 분석가가 회사 전체에 대한 수익 보고서를 실행할 수 있습니다.

고가용성(HA) ...