Apache Kafka 클러스터 유형에 대한 배포 전략

기관들은 첫 번째 사용 사례를 배포하기 위해 단일 Apache Kafka 클러스터로 데이터 스트리밍 채택을 시작합니다. 그룹 전체 데이터 거버넌스 및 보안 요구 사항이 있지만 SLA, 지연 시간 및 인프라 요구 사항이 다르기 때문에 새로운 Kafka 클러스터가 도입됩니다. 여러 Kafka 클러스터가 규칙이며, 예외가 아닙니다. 사용 사례에는 하이브리드 통합, 집계, 마이그레이션 및 재해 복구가 포함됩니다. 이 블로그 게시물에서는 산업별로 다른 Kafka 배포를 위한 실제 성공 사례 및 클러스터 전략을 탐구합니다.

Apache Kafka: 이벤트 기반 아키텍처 및 데이터 스트리밍의 사실상 표준

Apache Kafka는 대량 처리, 낮은 지연 시간 데이터 처리를 위한 오픈 소스 분산 이벤트 스트리밍 플랫폼으로 설계되었습니다. 실시간으로 레코드 스트림을 발행, 구독, 저장 및 처리할 수 있습니다.

카프카는 실시간 데이터 파이프라인과 스트리밍 애플리케이션을 구축하기 위한 인기 있는 선택입니다. 카프카 프로토콜은 다양한 프레임워크, 솔루션 및 클라우드 서비스에서 이벤트 스트리밍의 사실상 표준이 되었습니다. 이는 지속적인 저장소, 확장성 및 결함 허용과 같은 기능으로 운영 및 분석 작업을 지원합니다. 카프카는 통합을 위한 카프카 커넥트와 스트림 처리를 위한 카프카 스트림과 같은 구성 요소를 포함하여 다양한 데이터 기반 사용 사례에 적합한 다용도 도구입니다.

카프카는 실시간 사용 사례로 유명하지만 많은 프로젝트가 데이터 일관성을 위해 데이터 스트리밍 플랫폼을 활용하여 데이터베이스, 데이터 레이크, 레거시 시스템, 오픈 API 및 클라우드 네이티브 애플리케이션을 포함한 전체 기업 아키텍처에서 사용되고 있습니다.

다양한 아파치 카프카 클러스터 유형

카프카는 분산 시스템입니다. 프로덕션 설정은 일반적으로 최소 네 개의 브로커가 필요합니다. 따라서 대부분의 사람들은 처리량과 사용 사례를 추가할 때 자동으로 스케일업할 수 있는 단일 분산 클러스터만 필요하다고 가정합니다. 이는 처음에는 틀리지 않습니다. 하지만…

하나의 카프카 클러스터가 모든 사용 사례에 대한 정답이 아닙니다. 다양한 특성이 카프카 클러스터의 아키텍처에 영향을 미칩니다:

• 가용성: 제로 다운타임? 99.99% 가동 시간 SLA? 비핵심 분석?
• 지연 시간: 종단 간 처리 시간 <100ms(처리 포함)? 10분 종단 간 데이터 웨어하우스 파이프라인? 역사적 이벤트 재처리를 위한 시간 여행?
• 비용: 가치 대비 비용? 총 소유 비용(TCO)이 중요합니다. 예를 들어, 공용 클라우드에서 네트워킹은 전체 카프카 비용의 최대 80%를 차지할 수 있습니다!
• 보안 및 데이터 개인정보: 데이터 개인정보(PCI 데이터, GDPR 등)? 데이터 거버넌스 및 규정 준수? 속성 수준의 종단 간 암호화? 자체 키 지원? 공개 액세스 및 데이터 공유? 공기 갭트 엣지 환경?
• 처리량 및 데이터 크기: 중요한 트랜잭션(일반적으로 소량)? 빅데이터 피드(클릭스트림, IoT 센서, 보안 로그 등)?

온프레미스 대 공용 클라우드, 지역 대 글로벌 등 관련 주제는 카프카 아키텍처에도 영향을 미칩니다.

아파치 카프카 클러스터 전략 및 아키텍처

단일 카프카 클러스터는 종종 데이터 스트리밍 여정을 시작하는 올바른 출발점입니다. 올바르게 운영 및 확장된 경우 다른 비즈니스 도메인에서 여러 사용 사례를 수용하고 초당 기가바이트 단위로 처리할 수 있습니다.

그러나 프로젝트 요구 사항에 따라 여러 카프카 클러스터가 있는 엔터프라이즈 아키텍처가 필요합니다. 여기에는 몇 가지 일반적인 예가 있습니다:

• 하이브리드 아키텍처: 여러 데이터 센터 간의 데이터 통합 및 단방향 또는 양방향 데이터 동기화. 종종 온프레미스 데이터 센터와 퍼블릭 클라우드 서비스 제공업체 간의 연결. 레거시에서 클라우드 분석으로의 이동은 가장 일반적인 시나리오 중 하나이다. 그러나 명령 및 제어 통신도 가능하며, 예를 들어 결정/권고/거래를 지역 환경(예: 모바일 앱에서 메인프레임에 지불 또는 주문 저장)으로 전송할 수 있다.
• 다중 지역/다중 클라우드: 규정 준수, 비용 또는 데이터 개인 정보 보호 이유로 데이터 복제. 데이터 공유는 일반적으로 모든 Kafka 주제가 아닌 일부 이벤트만 포함된다. 의료는 이러한 방향으로 나아가는 많은 산업 중 하나이다.
• 재해 복구: 서로 다른 데이터 센터 또는 클라우드 지역 간의 중요 데이터를 활성-활성 또는 활성-수동 모드로 복제. 재해 발생 시 업무 연속성과 규정 준수를 보장하기 위한 장애 조치 및 롤백 메커니즘의 전략 및 도구.
• 집계: 로컬 처리(예: 사전 처리, 스트리밍 ETL, 스트림 처리 비즈니스 응용 프로그램)를 위한 지역 클러스터 및 정제된 데이터를 대규모 데이터 센터 또는 클라우드로 복제. 소매점이 우수한 예시이다.
• 이전: 온프레미스에서 클라우드로 또는 자체 관리 오픈 소스에서 완전히 관리되는 SaaS로의 이전을 통한 IT 현대화. 업무가 계속되는 동안 제로 다운타임이나 데이터 손실 없이 마이그레이션을 수행할 수 있다.
• 에지 (연결 끊김/공기 갭): 보안, 비용 또는 지연이 공장이나 소매점과 같은 곳에 에지 배치를 요구한다. 어떤 산업 분야는 단방향 하드웨어 게이트웨이와 데이터 다이오드를 사용하여 안전 중요 환경에 배치한다.
• 단일 브로커: 복구력이 없지만 기계나 산업용 PC(IPC)에 Kafka 브로커를 포함하거나 집계된 데이터를 대규모 클라우드 분석 Kafka 클러스터로 복제하는 등의 시나리오에 충분하다. 한 가지 좋은 예는 전장의 군인의 컴퓨터에 데이터 스트리밍(통합 및 처리 포함)을 설치하는 것이다.

혼합 Kafka 클러스터 연결

이러한 옵션은 결합될 수 있다. 예를 들어, 에지에 단일 브로커를 배치하면 일반적으로 어떤 정제된 데이터를 원격 데이터 센터로 복제한다. 하이브리드 클러스터는 어떻게 연결되는지에 따라 다양한 아키텍처를 갖는다: 공용 인터넷을 통한 연결, 사설 링크, VPC 피어링, 트랜짓 게이트웨이 등.

Confluent Cloud의 발전을 몇 년간 지켜왔지만, 보안과 연결성에 소요되는 엔지니어링 시간을 과소평가했다. 그러나 보안 브릿지의 부재는 Kafka 클라우드 서비스의 채택을 막는 주요 요인이다. 따라서, 공용 인터넷 이상의 Kafka 클러스터 간 다양한 보안 브릿지를 제공할 방법이 없다.

조직이 데이터 센터에서 클라우드로 데이터를 복제해야 하는 사용 사례도 있습니다. 그러나 클라우드 서비스는 연결을 시작할 수 없습니다. Confluent는 “소스 기반 링크”라는 특정 기능을 구축하여 소스(즉, 온프레미스 카프카 클러스터)가 항상 연결을 시작하도록 하는 보안 요구 사항에 대응합니다. 심지어 클라우드 카프카 클러스터가 데이터를 소비하더라도:

출처: Confluent

보시다시피, 상황이 빠르게 복잡해지고 있습니다. 처음부터 도움을 받을 수 있는 적합한 전문가를 찾으세요,첫 번째 클러스터와 애플리케이션을 이미 배포한 후가 아니라면요.

오랜 시간 전에 이미 분산, 하이브리드, 엣지, 그리고 글로벌 아파치 카프카 배포에 대한 아키텍처 패턴을 자세히 설명한 프레젠테이션을 했습니다. 해당 슬라이드 덱과 비디오 녹화를 참조하여 배포 옵션과 트레이드오프에 대해 더 많은 내용을 확인하세요.

RPO vs. RTO = 데이터 손실 vs. 다운타임

RPO와 RTO는 카프카 클러스터 전략을 결정하기 전에 논의해야 하는 두 가지 중요한 KPI입니다:

• RPO(복구 지점 목표)는 최대 허용 데이터 손실량을 시간으로 측정한 것으로, 데이터 손실을 최소화하기 위해 백업이 얼마나 자주 발생해야 하는지를 나타냅니다.
• RTO (복구 시간 목표)은 중단 이후 비즈니스 운영을 복구하는 데 걸리는 최대 허용 기간입니다. 이들은 조직이 비용과 운영 영향을 균형있게 고려하여 데이터 백업 및 재해 복구 전략을 계획하도록 돕습니다.

사람들은 종종 RPO = 0 및 RTO = 0의 목표로 시작하지만, 이것을 실현하기가 얼마나 어렵고(하지만 불가능하지는 않다는 것을) 빨리 깨닫게 됩니다. 재해 시 얼마나 많은 데이터를 잃을 수 있는지 결정해야 합니다. 재해가 발생한 경우 재해 복구 계획이 필요합니다. 법률 및 준수 팀은 재해 시 몇 개의 데이터 세트를 잃어도 상관없는지 여부를 알려주어야 합니다. 이러한 등의 많은 도전 과제들은 카프카 클러스터 전략을 평가할 때 논의되어야 합니다.

MIrrorMaker 또는 Cluster Linking과 같은 도구를 사용하여 카프카 클러스터 간 복제는 비동기적이며 RPO > 0입니다. RPO = 0을 제공하는 것은 늘어난 카프카 클러스터뿐입니다.

늘어난 카프카 클러스터: 데이터 센터 간 동기 복제로 제로 데이터 손실

여러 카프카 클러스터를 사용하는 대부분의 배포는 MirrorMaker 또는 Confluent Cluster Linking과 같은 도구를 통해 데이터 센터나 클라우드 간 비동기 복제를 사용합니다. 대부분의 사용 사례에는 충분하지만 재해 시 일부 메시지를 잃게 됩니다. RPO는 0보다 큽니다.

늘어난 카프카 클러스터는 하나의 클러스터 내에서 데이터를 복제하는 방식과 동일한 방식으로 세 개의 데이터 센터에 카프카 브로커를 배치합니다. 이러한 복제는 동기적이며(카프카가 하나의 클러스터 내에서 데이터를 복제하는 방식이기 때문) 재해 시에도 데이터 손실이 없도록 보장합니다(RPO = 0)!

늘어난 클러스터를 항상 왜 사용해서는 안 될까요?

• 데이터 센터 간에 낮은 지연 시간 (<~50ms)과 안정된 연결이 필요합니다.
• 세 개의 (!) 데이터 센터가 필요합니다; 과반수가 쓰기와 읽기를 인정해야만 시스템의 신뢰성을 보장하기 때문에 두 개는 충분하지 않습니다.
• 이들은 설정, 운영 및 모니터링이 어렵습니다 그리고 한 데이터 센터에서 운영되는 클러스터보다 훨씬 어렵습니다.
• 비용 대 가치는 많은 사용 사례에서 그렇지 않습니다; 실제 재해 시, 대부분의 조직 및 사용 사례는 몇 가지 메시지를 잃는 것보다 더 큰 문제를 안고 있습니다(비록 결제 또는 주문과 같은 중요한 데이터라도).

명확히 하자면, 공용 클라우드에서 한 지역은 일반적으로 세 개의 데이터 센터(가용 영역)를 갖습니다. 따라서 클라우드에서는 한 클라우스터가 스트레치된 클러스터로 간주되는지 여부는 SLA에 따라 달라집니다. 대부분의 SaaS Kafka 제공 업체는 여기에서 스트레치된 클러스터에 배포합니다.

그러나, 많은 규정 시나리오에서는 단일 클라우드 지역의 Kafka 클러스터를 SLA를 보장하고 재해 시 업무 연속성을 보장하기에 충분하지 않다고 보지 않습니다.

Confluent는 이러한 일부 문제를 해결하기 위해 전용 제품을 개발했습니다: Multi-Region Clusters (MRC). 이 제품은 스트레치된 Kafka 클러스터 내에서 동기 및 비동기 복제를 수행할 수 있는 기능을 제공합니다.

예를 들어, 금융 서비스 시나리오에서 MRC는 저량의 중요 거래를 동기적으로 복제하지만 고량의 로그는 비동기적으로 복제합니다:

• 미국 동부 및 서부에서 ‘지불’ 거래를 처리하고 완전히 동기화된 복제를 사용
• 동일한 클러스터의 ‘로그’ 및 ‘위치’ 정보는 비동기식으로 처리되며 지연 시간이 최적화됨
• 자동화된 재해 복구(제로 다운타임, 제로 데이터 손실)

저의 글로벌 카프카 프레젠테이션에서 스트레칭된 카프카 클러스터 대 상호 활성/비활성 복제에 대한 자세한 내용을 확인하실 수 있습니다.

카프카 클라우드 제품의 가격 설정(자체 관리 대비)

위의 섹션들은 프로젝트 요구 사항에 따라 다른 카프카 아키텍처를 고려해야 하는 이유에 대해 설명합니다. 자체 관리형 카프카 클러스터는 필요한 대로 구성할 수 있습니다. 공용 클라우드에서 완전 관리형 제품은 다르게 보입니다(다른 완전 관리형 SaaS와 마찬가지로). 가격은 합리적인 제한을 구성해야 하는 SaaS 공급업체들의 필요로 인해 다릅니다. 공급업체는 특정 SLA를 제공해야 합니다.

데이터 스트리밍 환경에는 다양한 카프카 클라우드 제품이 포함되어 있습니다. Confluent의 현재 클라우드 제품의 예시를 살펴보면, 다양한 SLA, 보안 기능 및 비용 모델을 갖춘 멀티 테넌트 및 전용 환경이 포함되어 있습니다.

소스: Confluent

다양한 퍼블릭 클라우드에서 제공되는 다른 업체의 클러스터 유형을 평가하고 이해해야 합니다. 총 소유 비용(TCO), 제공된 가동 시간 SLA, 지역 또는 클라우드 제공업체 간 복제 비용 등을 고려해야 합니다. 간격과 제한 사항은 종종 세부 사항에 의도적으로 숨겨져 있습니다.

예를 들어, Amazon Managed Streaming for Apache Kafka (MSK)를 사용하는 경우, “서비스 의무가 해당되지 않으며, 요청 실패로 이어지는 아파치 카프카 또는 아파치 주키퍼 엔진 소프트웨어에 의한 가용성 부재, 중단 또는 종료”로 인한 것임을 알아야 합니다.

그러나 가격 및 지원 SLA는 단순히 비교의 중요한 부분 중 하나뿐입니다. 데이터 스트리밍 플랫폼을 평가하는 일환으로 해야할 “구매 vs. 구매” 결정이 많습니다.

Kafka 저장소: 계층화된 저장소 및 데이터를 한 번만 저장하는 Iceberg 테이블 형식

아파치 카프카는 계산과 저장을 분리하는 티어드 스토리지를 추가했습니다. 이 기능은 더 많은 확장 가능성, 신뢰성 및 비용 효율적인 기업 아키텍처를 가능하게 합니다. 카프카를 위한 티어드 스토리지는 새로운 카프카 클러스터 유형을 가능하게 합니다: 데이터 레이크와 같이 비용 효율적인 방식으로 카프카 커밋 로그에 페타바이트의 데이터를 저장하고, 타임스탬프와 보장된 순서를 통해 과거 데이터를 다시 처리하기 위해 시간을 되감을 수 있습니다. KOR Financial은 Apache Kafka를 장기 보관용 데이터베이스로 사용하는 좋은 예입니다.

카프카는 작업 및 분석 데이터 세트를 위해 데이터를 한 번만 저장하는 Shift Left Architecture를 가능하게 합니다:

이를 염두에 두고, 여러 카프카 클러스터에 대해 위에서 설명한 사용 사례를 다시 생각해보세요. 데이터를 여전히 데이터베이스, 데이터 레이크 또는 레이크하우스로 배치 복제해야 할까요? 한 데이터 센터 또는 클라우드 지역에서 다른 지역으로 아니요. 실시간으로 데이터를 동기화하고, 데이터를 한 번 저장한 다음 (일반적으로 Amazon S3와 같은 객체 저장소에) 모든 분석 엔진을 이 표준 테이블 형식에 연결해야 합니다.

다중 카프카 클러스터에 대한 실제 성공 사례

대부분의 기관은 여러 카프카 클러스터를 보유하고 있습니다. 이 섹션에서는 서로 다른 산업군을 대상으로 네 가지 성공 사례를 탐색합니다:

• 페이팔 (금융 서비스) – 미국: 즉시 지급, 사기 방지.
• JioCinema (통신사/미디어) – APAC: 데이터 통합, 클릭스트림 분석, 광고, 맞춤화.
• Audi (자동차/제조업) – EMEA: 연결된 차량과 중요한 분석 요구 사항.
• New Relic (소프트웨어/클라우드) – US: 전 세계적으로 관측 가능성 및 응용 프로그램 성능 관리 (APM).

Paypal: 보안 존에 의한 분리

PayPal은 사용자가 안전하고 편리하게 전 세계적으로 실시간으로 온라인으로 돈을 보내고 받을 수 있는 디지털 결제 플랫폼입니다. 이를 위해 확장 가능하고 안전하며 규정 준수를 요구하는 Kafka 인프라가 필요합니다.

2022년 블랙 프라이데이 기간에 Kafka 트래픽 양은 하루에 약 1.3조 개의 메시지로 최고치를 기록했습니다. 현재 PayPal은 85개 이상의 Kafka 클러스터를 보유하고 있으며 매 연휴 시즌마다 트래픽 급증을 처리하기 위해 Kafka 인프라를 확장합니다. Kafka 플랫폼은 비즈니스에 영향을 미치지 않으면서 이 트래픽 성장을 지원하기 위해 원활하게 확장됩니다.

지금은 PayPal의 Kafka 플리트는 1,500개 이상의 브로커로 구성되어 있으며 20,000개 이상의 토픽을 호스팅합니다. 클러스터 간에 이벤트가 복제되어 99.99%의 가용성을 제공합니다.

Kafka 클러스터 배포는 데이터 센터 내에서 다른 보안 영역으로 분리됩니다:

출처: Paypal

Kafka 클러스터는 데이터 분류 및 비즈니스 요구 사항에 따라 보안 존에 배포됩니다. MirrorMaker(이 예에서는 Kafka Connect 인프라에서 실행되는)나 Confluent Cluster Linking(복제를 위해 Kafka 프로토콜을 직접 사용하는 더 간단하고 오류 가능성이 적은 방법)과 같은 도구를 사용하여 데이터 센터 간에 데이터를 미러링하고 재해 복구 및 보안 존 간 통신을 달성하는 데 도움이 됩니다.

JioCinema: 사용 사례 및 SLA별 분리

JioCinema는 인도에서 급속하게 성장하는 비디오 스트리밍 플랫폼입니다. 이 텔코 OTT 서비스는 인도 프리미어 리그(IPL)와 같은 실시간 스포츠, 새롭게 출시된 Anime Hub, 파리 2024 올림픽과 같은 주요 이벤트를 커버하기 위한 포괄적인 계획으로 유명합니다.

데이터 아키텍처는 데이터 처리를 위해 Apache Kafka, Flink 및 Spark를 활용하며, 이는 2024년 카프카 서밋 인도에서 발표되었습니다(방갈로르):

출처: JioCinema

데이터 스트리밍은 사용자 경험과 콘텐츠 전송을 변형하는 다양한 사용 사례에서 중요한 역할을 합니다. 초당 1천만 개 이상의 메시지는 분석, 사용자 통찰력 및 콘텐츠 전송 메커니즘을 향상시킵니다.

JioCinema의 사용 사례에는:

• 서비스 간 통신
• 클릭스트림/분석
• 광고 추적기
• 머신 러닝 및 개인화

JioCinema의 데이터 플랫폼, 분석 및 소비 책임자인 쿠샬 칸델왈은 모든 데이터가 같지 않으며 사용 사례에 따라 우선 순위와 SLA가 다르다고 설명했습니다:

출처: JioCinema

데이터 스트리밍은 여정입니다. 전 세계의 많은 조직과 마찬가지로 JioCinema는 1000개 이상의 Kafka 주제와 100,000개 이상의 Kafka 파티션을 사용하는 하나의 대규모 Kafka 클러스터로 시작했습니다. 시간이 지나면서 사용 사례와 SLA에 대한 관심의 분리가 여러 Kafka 클러스터로 발전했습니다:

출처: JioCinema

JioCinema의 성공 스토리는 데이터 스트리밍 조직의 일반적인 진화를 보여줍니다. 이제 하나의 사용 사례를 위해 처음부터 매우 다른 두 개의 Kafka 클러스터가 배포된 또 다른 사례를 살펴보겠습니다.

아우디: 연결된 차량을 위한 운영 vs. 분석

자동차 제조업체 아우디는 인터넷 연결성과 지능형 시스템을 통합한 첨단 기술을 갖춘 연결된 차량을 제공합니다. 아우디의 차량은 실시간 내비게이션, 원격 진단 및 향상된 차량 내 엔터테인먼트를 가능하게 합니다. 이 차량들은 아우디 커넥트 서비스를 갖추고 있습니다. 기능에는 긴급 통화, 온라인 교통 정보 및 스마트 홈 기기와의 통합이 포함되어 있어 운전자의 편의성과 안전성을 높입니다.

출처: 아우디

아우디는 2018년 카프카 서밋의 기조연설에서 연결된 차량 아키텍처를 발표했습니다. 아우디의 기업 아키텍처는 매우 다른 SLA와 사용 사례를 가진 두 개의 Kafka 클러스터에 의존합니다.

출처: 아우디

데이터 수집 Kafka 클러스터는 매우 중요합니다.규모에 상관없이 24시간 7일 가동되어야 합니다. 수백만 대의 차량에 마지막 연결성을 제공합니다. Kafka 및 MQTT를 사용하여 IT 측에서 차량으로의 역방향 통신이 서비스 통신 및 OTA(Over-The-Air) 업데이트에 도움이 됩니다.

ACDC Cloud는 Audi의 연결된 자동차 아키텍처의 분석 Kafka 클러스터입니다. 이 클러스터는 Apache Spark와 같은 배치 처리 프레임워크를 사용하여 광범위한 양의 IoT 및 로그 데이터를 처리하는 많은 분석 워크로드의 기초입니다.

이 아키텍처는 이미 2018년에 소개되었습니다. Audi의 슬로건 “기술을 통한 진전”은 회사가 대부분의 자동차 제조업체가 비슷한 시나리오를 배포하기 훨씬 이전에 혁신을 위해 새로운 기술을 적용했다는 것을 보여줍니다. 연결된 차량의 모든 센서 데이터가 실시간으로 처리되어 기록 및 보고를 위해 저장됩니다.

New Relic: 전 세계적인 멀티 클라우드 관찰

New Relic는 전 세계의 고객을 대상으로 애플리케이션 및 인프라에 대한 실시간 성능 모니터링 및 분석을 제공하는 클라우드 기반의 관찰 플랫폼입니다.

뉴 렐릭의 소프트웨어 엔지니어링 부사장인 Andrew Hartnett는 데이터 스트리밍이 뉴 렐릭의 전체 비즈니스 모델에 중요하다고 설명했습니다.

“Kafka는 우리의 중추 신경계입니다. 우리가 하는 모든 일의 일부입니다. 수백 개의 서비스가 110개의 다른 엔지니어링 팀 전체에 걸쳐 Kafka에 어떤 방식으로든 접근하므로, 이는 정말 중요한 미션입니다. 우리가 찾고 있던 것은 성장할 수 있는 능력이었고, Confluent Cloud가 그것을 제공했습니다.”

New Relic는 분당 최대 70억 개의 데이터 포인트를 처리하며, 2023년에는 2.5 엑사바이트의 데이터를 처리할 예정입니다. New Relic이 멀티 클라우드 전략을 확장함에 따라, 팀은 모든 환경에서의 통합된 화면을 위해 Confluent Cloud를 사용할 것입니다.

“New Relic은 멀티 클라우드입니다. 우리는 고객이 있는 곳에 있고 싶습니다. 우리는 동일한 환경, 동일한 지역에 있고 싶으며, Kafka를 함께 사용하고 싶었습니다.”라고 Artnett는 Confluent 사례 연구에서 말했습니다.

여러 Kafka 클러스터는 예외가 아니라 일반적입니다

이벤트 주도 아키텍처와 스트림 처리는 수십 년 동안 존재해 왔습니다. Apache Kafka와 Flink와 같은 오픈 소스 프레임워크와 완전히 관리되는 클라우드 서비스를 결합하여 채택이 증가하고 있습니다. 점점 더 많은 조직이 Kafka 규모에 어려움을 겪고 있습니다. 기업 전체적인 데이터 거버넌스, 우수한 운영 및 배포 자동화, 기업 아키텍처 모범 사례는 독립적 또는 협력하는 비즈니스 도메인을 위한 여러 Kafka 클러스터로 데이터 스트리밍을 성공적으로 제공하는 데 도움이 됩니다.

다중 Kafka 클러스터는 예외가 아닌 표준입니다. 하이브리드 통합, 재해 복구, 마이그레이션 또는 집계와 같은 사용 사례는 필요한 SLA로 어디서든 실시간 데이터 스트리밍을 가능하게 합니다.