[카프카 핵심 가이드] 데이터 파이프라인 구축하기, 클러스터간 데이터 미러링하기

데이터 파이프라인에 있어서 카프카가 갖는 주요한 역할은 데이터 파이프라인의 다양한 단계 사이사이에 있어 매우 크고 안정적인 버퍼 역할을 해 줄 수 있다는 점이다. 이는 데이터파이프라인의 데이터 쓰는 쪽과 읽는 쪽을 분리하여 하나의 원본에서 가져온 동일 데이터를 상이한 요구 조건을 가진 여러 애플리케이션으로 보낼 수 있게 한다.

데이터 파이프라인 구축 시 고려사항

적시성(timeliness)

어떤 시스템은 하루에 한 번 대량의 데이터를 필요로 할 수도 있고, 어떤 시스템은 데이터가 생성된 뒤 몇 밀리초 내로 받아야 할 수도 있다. 좋은 데이터 통합 시스템은 서로 다른 적시성 요구 조건을 지원하여 요구 사항이 변경되었을 때 이전하기 쉬워야 한다.

이러한 맥락에서 카프카는 읽는 쪽과 쓰는 쪽 사이의 시간적 민감도에 대한 요구 조건을 분리시키는 거대한 버퍼로 볼 수 있으며, 데이터 소비 속도가 온전히 읽는 쪽에 의해 결정된다.

신뢰성

대부분의 경우 최소 한 번 보장을 요구하는게 보통이다. 카프카는 기본적으로 최소 한 번 전송을 보장하며, 필요 시 설정을 통해 정확히 한 번 전달을 할 수 있도록 지정이 가능하다.

처리율

데이터 파이프라인은 매우 높은 처리율을 가질 수 있도록 확장이 가능해야 한다. 특히 처리율을 높여야 할 때 대응이 가능해야 한다. 

데이터 형식

데이터 파이프라인에서 중요한 고려점 중 하나는 서로 다른 데이터 형식과 자료형을 적절히 사용하는 것이다. 각 시스템과 데이터베이스는 지원되는 자료형이 서로 다르다. 카프카는 프로듀서와 컨슈머는 필요한 데이터 형식을 지원할 수만 있다면 어떤 시리얼라이저도 쓸 수 있기 때문에 데이터 형식이 무엇이든 간에 사용할 수 있는 커넥터는 영향을 받지 않는다.

변환

데이터 파이프라인을 구축하는 방식에는 크게 ETL과 ELT 방식이 있다. 

• ETL(추출 - 변환 - 적재, Extract - Transform - Load): 데이터 파이프라인이 통과하는 데이터에 변경을 가하는 작업까지도 담당하며, 데이터 수정한 뒤 다시 저장할 필요가 없어서 시간과 공간을 절약한다. 다만, 파이프라인에서 데이터 변환이 일어나기 때문에 파이프라인 하단에서 데이터를 처리하고자 할 때 가공하기 어렵다.
• ELT(추출 - 적재 - 변환, Extract - Load - Transform): 데이터 파이프라인은 대상 시스템에 전달되는 데이터가 원본 데이터와 최대한 비슷하도록 최소한의 변환만 수행한다. 이러한 시스템에서는 대상 시스템이 가공되지 않은 raw data를 받아서 필요한 처리를 하기 때문에 유연성을 제공하지만, 변환 작업이 각 대상 시스템의 CPU와 자원을 잡아먹는다는 점이 단점이다.

카프카 커넥트는 원본 시스템의 데이터를 카프카로 옮기거나, 카프카의 데이터를 대상 시스템으로 옮길 때 단일 레코드를 변환할 수 있게 해주는 Single Message Transformation 기능을 탑재하고 있다. 

카프카를 이용한 ETL 구축은 보통 다수의 애플리케이션에서 데이터를 읽게 하는 일대다 파이프라인을 구축할 수 있다. 데이터를 수집하는 과정에서 너무 많은 정제가 일어나면, 대상 시스템에서 원하는 데이터가 없을 수도 있으므로 성급하게 데이터를 정제하면 안된다.

보안

데이터 파이프라인에서도 보안은 신경써야 하는 문제로, 아래와 같은 지점들을 고민해야한다.

• 누가 데이터로 접근이 가능한가?
• 파이프라인을 통과한 데이터는 암호화된 것으로 확신할 수 있는가?
• 누가 파이프라인을 변경할 수 있는가?
• 파이프라인이 접근이 제한된 곳의 데이터를 읽거나 쓸 때, 인증을 통과할 수 있는가?

결합(Coupling)과 민첩성(Agility)

데이터 파이프라인을 구현할 때 중요한 것 중 하나는 데이터 원본과 대상을 분리할 수 있어야 한다.의도치 않게 결합이 되면 아래와 같은 문제가 생길 수 있다.

• Ad-hoc 파이프라인
  • 애플리케이션을 연결할 때 커스텀 파이프라인을 구축(예: Logstash를 사용해 로그를 ES에 밀어넣거나, Flume을 사용해 로그를 HDFS에 밀어넣는 등)할 경우, 데이터 파이프라인이 특정 엔드포인트에 강하게 결합된다. 이 경우, 새로운 시스템을 도입할 때마다 추가적인 데이터 파이프라인 구축을 해야 할 수 있어서 신규 기술 도입에 비용이 늘어날 수 있다.
• 메타데이터 유실
  • 데이터 파이프라인이 스키마 메타데이터를 보존하지 않고 스키마 진화 역시 지원하지 않는다면 소스 쪽 데이터 생성하는 소프트웨어와 싱크 쪽에서 데이터를 사용하는 소프트웨어를 강하게 결합시키게 된다.
• 과도한 처리
  • 파이프라인에서 데이터를 너무 많이 정제하면 데이터 활용처에서 선택지가 많이 남지 않게 된다. 데이터를 처리하고 집적하는 방법은 애플리케이션이 알아서 하도록 하는 것이 좀 더 유연한 방법이다.

카프카 커넥트 VS 프로듀서/컨슈머

카프카 클라이언트(프로듀서/컨슈머)는 애플리케이션의 코드를 변경할 수 있으면서 카프카에 데이터를 쓰거나 읽고싶을 때 사용한다. 반면에 카프카 커넥트는 직접 코드나 API를 작성하지 않고, 변경도 할 수 없는 데이터 저장소에 연결해야 할 때 사용한다.

카프카 커넥트

카프카 커넥트는 아파치 카프카의 일부로 카프카와 다른 데이터 저장소 사이 확장성과 신뢰성을 가지면서 데이터를 주고받을 수 있는 수단을 제공한다.커넥트는 커넥터 플러그인을 개발하고 실행하기 위한 API와 런타임을 제공하며, 커넥터 플러그인은 카프카 커넥트가 실행시키는 라이브러리로 데이터를 이동시키는 것을 담당한다.카프카 커넥트는 여러 워커 프로세스들의 클러스터 형태로 실행된다.

커넥터(connector)와 태스크(task)

커넥터 플러그인은 커넥터 API를 구현한다. 이는 커넥터와 태스크 두 부분을 모두 포함한다.

• 커넥터
  • 커넥터에서 몇 개의 태스크가 실행되어야 하는지 결정한다.
  • 데이터 복사 작업을 각 태스크에 어떻게 분할할 지 결정한다.
  • 워커로부터 태스크 설정을 얻어와 태스크에 전달한다.
• 태스크
  • 데이터를 실제로 카프카에 넣거나 가져오는 작업을 담당한다.
  • 모든 태스크는 워커로부터 컨텍스트를 받아 초기화된다.

워커

카프카 커넥트의 워커 프로세스는 커넥터와 태스크를 실행시키는 역할을 맡는 컨테이너 프로세스라고 할 수 있다. 워커 프로세스는 커넥터와 그 설정을 정의하는 HTTP 요청을 처리할 뿐 아니라 커넥트 설정을 내부 카프카 토픽에 저장하고, 커넥터와 태스크 실행, 적절한 설정값 전달하는 역할을 한다.

 

만약 워커 프로세스가 정지하거나 크래시 나면, 커넥터 클러스터 내 다른 워커들이 이를 감지(컨슈머 프로토콜의 하트비트 사용)해서 해당 워커에서 실행중인 커넥터와 태스크를 다른 워커로 재할당한다. 새 워커가 커넥트 클러스터에 추가되면 다른 워커들은 이를 감지해서 모든 워커 간 부하가 균형이 잡히도록 커넥터와 태스크를 할당해준다.워커는 소스와 싱크 커넥터의 오프셋을 내부 카프카 토픽에 자동으로 커밋하는 작업과 태스크에서 에러가 발생할 때 재시도하는 작업 역시 담당한다.

 

워커는 커넥터, 태스크와는 서로 다른 책임을 맡는다. 커넥터와 태스크는 데이터 통합에서 데이터 이동 단계를 맡는 반면, 워커는 REST API, 설정 관리, 신뢰성, 고가용성, 규모 확장성 그리고 부하 분산을 담당한다.

컨버터 및 커넥트 데이터 모델

카프카 커넥터 API에는 데이터 API가 포함되어 있으며, 이 API는 데이터 객체와 이 객체의 구조를 나타내는 스키마 모두를 다룬다.

• 예) JDBC 소스 커넥터는 DB의 열을 읽어온 뒤 DB에서 리턴된 열의 데이터 타입에 따라 ConnectSchema 객체를 생성한다. 그리고, 해당 스키마를 사용해 DB 레코드의 모든 필드를 포함하는 Struct 객체를 생성하고, 각 열에 대해 열의 이름과 저장된 값을 함께 저장한다.

컨버터를 사용함으로써 커넥트 API는 커넥터 구현과 무관하게, 카프카에 서로 다른 형식의 데이터를 저장할 수 있도록 해준다. 사용 가능한 컨버터만 있다면, 어떤 커넥터도 레코드 형식 무관하게 사용할 수 있다.

오프셋 관리

오프셋 관리는 워커 프로세스가 커넥터에 제공하는 편리한 기능 중 하나다. 커넥터는 어떤 데이터를 이미 처리했는지 알아야 하기 때문에, 카프카가 제공하는 API를 사용해 어느 이벤트가 이미 처리되었는지에 대한 정보를 유지 관리한다.

카프카 커넥트의 대안

• 다른 데이터 저장소를 위한 수집 프레임워크
  • 하둡이나 엘라스틱서치와 같은 시스템을 중심으로 데이터 아키텍처가 구축되어 있다면, 자체적인 데이터 수집 툴을 활용할 수 있다(하둡의 경우 flume, 엘라스틱서치의 경우 logstash, fluentd).
• GUI 기반 ETL 툴
  • Talend, Pentaho, NiFi, StreamSets은 GUI 기반 ETL 파이프라인을 개발할 때 합리적인 선택이다.
  • 다만, 단순히 카프카와 데이터 교환이 목적일 경우에는 사용하기에 다소 무겁고 복잡하므로 필요한 내용에 맞게 선택하는게 좋다.

다중 클러스터 아키텍처

운영자가 상호 의존하는 클러스터 사이에 데이터를 지속적으로 복사해줘야 하는 경우가 있다. 카프카에서는 같은 클러스터에 속한 카프카 노드 간 데이터의 교환을 복제(replication)이라고 부르고 있어서 서로 다른 카프카 클러스터 간의 데이터 복제는 미러링(mirroring)이라고 부른다. 아파치 카프카에는 클러스터간 데이터 복제를 위해 미러메이커(MirrorMaker) 툴을 포함하고 있다.

데이터센터간 통신의 현실적 문제들

• 높은 지연(high latency): 두 카프카 클러스터 간 거리나 네트워크 홉(hop) 개수가 증가하므로 통신 지연 역시 증가한다.
• 제한된 대역폭(limited bandwidth): 광역 통신망(WAN)은 일반적으로 단일 데이터센터 내부보다 훨씬 낮은 대역폭을 가지며 사용 가능한 대역폭 역시 시시각각 변하는 특성이 있다.
• 더 높은 비용(higher cost): 클러스터 간 통신에는 더 많은 비용이 든다.

아파치 카프카는 브로커와 클라이언트는 하나의 데이터센터 안에서 실행되도록 설계, 개발, 테스트, 조정되었다. 개발자들은 브로커와 클라이언트 사이 낮은 지연, 높은 대역폭을 가진 상황을 상정하였기 때문에 카프카 브로커를 서로 다른 데이터 센터에 나눠서 설치하는 것은 권장되지 않는다. 

또한, 원격 데이터센터에 데이터를 쓰는 것은 피하는 것이 좋기 떄문에, 원격 클러스터 간 복제가 필요할 경우, 원격 브로커-컨슈머 통신을 하는 것이 안전한 형식의 클러스터간 통신이다.

허브-앤-스포크 아키텍처(hub-and-spokes architecture)

허브-앤-스포크 아키택처

허브-앤-스포크 아키텍처는 여러 개의 로컬 카프카 클러스터와 한 개의 중앙 카프카 클러스터가 있는 상황을 상정한 것이다. 이 아키텍처는 데이터가 여러 개의 데이터센터에 나누어 생성되지만, 일부 컨슈머는 전체 데이터를 사용해야 할 경우 사용된다.

 

이 아키텍처의 주된 장점은 로컬 데이터센터에서 데이터가 생성되고, 로컬 데이터센터에 저장된 이벤트들이 중앙 데이터센터로 한 번만 미러링된다는 점이다. 미러링은 한 방향으로만 진행되고, 각각의 컨슈머는 언제나 같은 클러스터에서 데이터를 읽게 되므로 이 아키텍처는 배포, 설정, 모니터링이 간편하다.

 

다만, 이 아키텍처를 사용하면 지역 데이터센터에 있는 애플리케이션은 다른 데이터센터의 데이터를 사용할 수 없다.

액티브-액티브 아키텍처(active-active architecture)

액티브-액티브 아키텍처

액티브-액티브 아키텍처는 2개 이상의 데이터센터가 전체 데이터의 일부 혹은 전체를 공유하면서, 각 데이터센터가 모두 읽기와 쓰기를 수행할 수 있어야 할 경우 사용된다.

 

이 아키텍처의 주된 장점은 인근 데이터센터에서 사용자들의 요청을 처리할 수 있다는 점이고, 데이터 중복과 회복 탄력성이 았다는 것이 장점이다. 모든 데이터센터가 동일한 기능을 가지기 때문에 한 데이터센터가 장애가 발생해도 사용자 요청을 다른 데이터센터가 처리할 수 있다.

 

다만, 데이터를 여러 위치에 비동기적으로 읽거나 변경할 경우 발생하는 동시성 이슈를 피하는 것이 어렵다(데이터센터 간 데이터 일관성 유지하는 것이 어려움). 따라서, 동일한 데이터세트를 여러 위치에서 비동기적으로 읽고 쓰는 문제를 해결할 방안이 있다면, 이 아키텍처는 사용할 만한 방안이다. 

액티브-스탠바이 아키텍처(active-standby architecture)

액티브-스탠바이 아키텍처

다중 클러스터가 필요한 이유가 재해 대비뿐이라면, 액티브-스탠바이 모델을 활용할 수 있다. 이 모델을 사용하면, 양쪽 데이터센터에 동일한 데이터를 가지고 있되, 한쪽 클러스터만 읽기/쓰기에 이용한다. 그러다가 문제가 생겼을 때 놀고 있던 데이터센터를 이용해 데이터를 제공하게 된다.

 

이 방식의 장점은 액티브 클러스터의 모든 이벤트를 미러링하는 프로세스만 설치하면 되기 때문에 간단히 설치가 가능하다는 점이다.

 

다만, 사용되지 않는 클러스터가 생기기 것이라 자원이 낭비되기도 하고 카프카 클러스터 간 장애 복구가 생각보다 훨씬 어렵다는 것이 문제다. 기본적으로 카프카 미러링 솔루션들은 비동기적으로 작동하기 때문에, 스탠바이 클러스터(DR 클러스터)가 액티브 클러스터의 가장 최신 메시지를 가지고 있지 못할 확률이 높다. 따라서, 현재로써는 일체의 데이터 유실이나 중복 없이 카프카 클러스터를 복구하는 것은 불가능하다. 따라서 최대한 데이터가 얼마나 뒤쳐져있는지 모니터링하고 너무 뒤쳐지지 않도록 신경써야 한다.

 

카프카 0.10.0 버전부터 메시지는 카프카로 전송된 시각을 가리키는 타임스탬프 값을 갖는다. 그리고 0.10.1.0 버전 부터는 브로커는 타임스탬프를 기준으로 오프셋을 검색할 수 있는 API를 제공한다. 이 API를 통해 DR 클러스터로 장애 복구할 때 장애가 발생한 타임스탬프보다 조금 더 이전 시간으로 오프셋을 당겨서 컨슈머가 다시 데이터를 처리할 수 있도록 할 수 있다.

스트레치 클러스터(stretch cluster) - 단일 클러스터

액티브-스탠바이 아키텍처는 카프카 클러스터에 장애가 발생했을 때 애플리케이션이 다른 클러스터와 통신하도록 함으로써 장애 복구를 진행한다. 스트레치 클러스터는 데이터센터 전체에 문제가 발생했을 때 카프카 클러스터에 장애가 발생하는 것을 방지하기 위해 사용하는 것이다. 이는 하나의 카프카 클러스터를 여러 개의 데이터센터에 걸쳐 설치한다.

 

스트레치 클러스터는 다중 클러스터가 아닌, 단지 하나의 클러스터일 뿐이다. 따라서, 클러스터간 데이터 동기화를 위한 미러링 프로세스가필요하지 않다. 기존에 알고 있던 카프카 복제 메커니즘에 따라 클러스터 내 브로커들을 동기적으로 복제가 일어난다고 보면 된다. 스트레치 클러스터는 메시지가 두 데이터센터에 위치한 카프카 브로커 각각에 성공적으로 쓰여진 뒤에야 프로듀서에 응답가도록 할 수도 있고, 컨슈머는 정의된 랙(가용영역) 기준으로 가장 가까운 레플리카에서 읽어오도록 브로커를 설정할 수도 있다.

 

이 아키텍처는 대응할 수 있는 장애의 종류가 한정되어 있지만, 액티브-스탠바이에서 살펴봤던 유형의 자원 낭비는 없다.

아파치 카프카의 미러메이커

미러메이커는 아파치 카프카에서 두 데이터센터 간 데이터 미러링을 위해 사용되는 툴이다. 미러메이커는 데이터베이스가 아닌 다른 카프카 클러스터로부터 데이터를 읽어오기 위해 소스 커넥터를 사용한다. 

카프카의 미러메이커 프로세스

미러메이커는 카프카의 컨슈머 그룹 관리 프로토콜을 사용하지 않고 태스크에 파티션을 균등하게 배분하여 새로운 토픽이나 파티션 추가시 발생하는 리밸런스로 인해 지연이 튀는 상황을 방지한다. 미러메이커는 원본 클러스터의 각 파티션에 저장된 이벤트를 대상 클러스터의 동일한 파티션으로 미러링하여 파티션의 의미 구조나 각 파티션 내 이벤트 순서를 그대로 유지한다.

미러메이커는 데이터 복제 뿐 아니라 컨슈머 오프셋, 토픽 설정, 토픽 ACL 마이그레이션까지 지원하는 자동 클러스터 배치에 필요한 완전한 기능을 갖춘 미러링 솔루션이다.

기타 클러스터간 미러링 솔루션

• 우버  uReplicator

uReplicator: Uber Engineering’s Robust Kafka Replicator

• 링크드인 Brooklin

Load-balanced Brooklin Mirror Maker: Replicating large-scale Kafka clusters at LinkedIn

• 컨플루언트 replicator