🥇[Bro's Insights - 인기글] → 🚀 Kafka를 만든 LinkedIn 기술 넘어: Northguard & Xinfra 공개!

[cloudbro-radar]

LinkedIn이 Northguard와 Xinfra를 발표로, Kafka를 넘어서는 Log Storage와 Pub/Sub 확장 기능을 제공하고 있습니다. 자세한 정보를 확인하세요.

[원본] https://medium.com/data-engineer-things/the-company-that-created-kafka-is-replacing-it-with-a-new-solution-386cd1c2dcc8

원본을 번역해서 공유드립니다.

# 개요

LinkedIn은 2025년 기준 12억 명이 넘는 사용자를 보유하고 있다고 밝혔습니다. 이와 같은 대규모 성장으로 인해 Kafka 인프라는 큰 부담을 안게 되었습니다. 당시 Kafka 인프라는 150개의 클러스터와 1만 대의 머신으로 구성되어 있었으며, 매일 40만 개의 토픽과 17PB 규모의 데이터를 처리하고 있었습니다.

그러나 Kafka는 아키텍처적으로 강하게 결합된 구조를 가지고 있어, 트래픽이 증가하면 단순히 더 많은 머신을 추가해야만 부하를 감당할 수 있었습니다.

또한 Kafka는 데이터의 내구성을 보장하기 위해 파티션을 복제해야 합니다. 단일 리더가 쓰기 요청을 수락하면 해당 데이터를 팔로워들에게 복제합니다.

클러스터의 멤버십이 변경되면, 부하를 균형 있게 분산하기 위해 데이터가 재분배되어야 하며, 이 과정은 클러스터의 가용성에 영향을 미칩니다.

이 문제들은 LinkedIn 규모에서 Kafka를 운영할 때 더욱 심각해집니다.

LinkedIn은 더 높은 확장성을 가진 새로운 솔루션이 필요했습니다. 이 솔루션은 부하 분산 측면에서 더 효율적이어야 하고, 동시에 Kafka가 제공해왔던 높은 처리량, 낮은 지연 시간, 높은 가용성, 강력한 내구성을 잃지 않으면서 데이터와 메타데이터 모두에서 강한 일관성을 보장해야 했습니다.

이 요구를 충족하기 위해 LinkedIn은 Northguard라는 로그 스토리지 시스템을 구축했습니다. Northguard는 데이터와 메타데이터를 더 작은 청크로 분할해 노드 전체에 균등하게 분산되도록 설계되었습니다.

상위 수준에서 보면 Northguard는 Kafka와 일부 유사점을 갖고 있습니다. 마찬가지로 브로커 클러스터로 동작하지만, 데이터를 구성하고 복제하는 방식은 Kafka와 다릅니다.

# 데이터 모델

Northguard에서 **레코드(record)**는 가장 작은 데이터 단위입니다. 이는 Kafka의 메시지와 유사하며, 바이트 시퀀스로 이루어져 있습니다. 각 레코드는 키(key), 값(value), 그리고 선택적으로 사용자 정의 가능한 **헤더(headers)**를 가집니다.

레코드는 세그먼트- segment에 순차적으로 저장됩니다. Kafka와 마찬가지로, 세그먼트는 1GB 크기의 파일과 연결되어 있습니다.

활성 세그먼트- active segment는 새로운 레코드를 계속 추가할 수 있는 상태의 세그먼트를 의미합니다. 하지만 세그먼트가 최대 크기(1GB)에 도달했을 때, 1시간 이상 활성 상태가 유지되었을 때, 또는 복제에 실패했을 때, 해당 세그먼트는 봉인(sealed) 처리됩니다.

여기서 흥미로운 점은, Northguard에서는 세그먼트(segment)가 복제 단위라는 것입니다. Kafka에서는 **파티션(partition)**이 복제 단위로 사용되지만, Northguard는 이를 달리 설계했습니다. 이 부분은 뒤에서 다시 다루게 됩니다.

Kafka에서는 파티션이 논리적 로그(logical log) 역할을 합니다. 반면, LinkedIn은 Northguard에서 레인지-range라는 개념을 도입했습니다. 레인지는 Northguard의 로그 추상화-log abstraction를 의미합니다.

레인지는 연속된 키 범위 A→D, D→M, M→Q와 같은를 가지는 **세그먼트들의 체인(chain)**으로 이루어집니다. 세그먼트와 마찬가지로, 레인지도 활성-active 상태일 수 있고, 조건에 따라 봉인(sealed) 될 수 있습니다.

또한, Northguard에는 토픽-topic이라는 개념이 있습니다. 토픽은 전체 키스페이스(A→Z와 같은)를 포괄하도록 구성된 여러 레인지들의 집합-collection을 의미합니다.

Northguard는 토픽 범위를 병합하거나 분할할 수 있습니다.

• 분할을 수행하면 원본 범위가 종료되고 두 개의 새로운 범위가 생성됩니다.
• 병합을 수행하면 두 개의 원본 범위가 종료되고 새로운 범위가 생성됩니다.

토픽은 종료되거나 삭제될 수 있으며, 이 과정은 모든 토픽 범위에 걸쳐 이루어집니다. Northguard 클러스터의 관리자들은 토픽에 대한 저장 정책을 설정할 수 있습니다. 정책은 이름, 세그먼트가 삭제되는 시점을 정의하는 보존 기간, 그리고 일부 지정된 제약 조건으로 구성됩니다.

Northguard 클러스터의 각 브로커는 랙이나 데이터 센터와 같은 인코딩된 정보를 포함해 배포됩니다. 토픽에 대한 정책을 정의할 때, 사용자는 제약 조건을 표현하여 어떤 브로커가 세그먼트의 복제본(세그먼트 사본을 보관하는 브로커)으로 선택될 수 있는지를 결정하도록 할 수 있습니다.

이 접근 방식은 LinkedIn이 Northguard에서 랙 인지 기반의 replica 할당을 달성하는 데 도움이 됩니다.

# 데이터 복제

앞서 언급한 것처럼, Northguard에서 데이터 복제의 단위는 세그먼트입니다. 이는 Kafka의 파티션에 비해 더 세밀한 단위입니다.

LinkedIn은 Kafka 방식이 데이터 쏠림을 처리할 때 비효율적일 수 있다는 점을 관찰했습니다. 그 이유는 각 replica가 전체 파티션의 전체 복사본을 저장해야 하므로 다음과 같은 문제가 발생하기 때문입니다.

• Kafka에서는 클러스터에 새로운 브로커를 추가하더라도 파티션이 자동으로 새 브로커로 로드 밸런싱되지 않습니다. 새로운 브로커는 사용자가 새로운 토픽이나 파티션을 생성하거나 수동으로 재분배 작업을 수행하기 전까지는 유휴 상태로 남아 활용도가 낮습니다. 그러나 토픽이나 파티션을 새로 생성하는 작업은 자주 이루어지지 않으며, 데이터를 수동으로 이동시키는 방법도 비효율적입니다.

• 브로커는 핫 파티션(예: 대량의 데이터 수집)이 존재할 경우 과부하가 걸릴 수 있습니다. 이러한 상황에서는 데이터 재파티셔닝이 필요합니다.

Northguard는 Kafka의 로그 추상화(파티셔닝)를 사용하는 대신 세그먼트를 복제하는 방식을 선택합니다.

여기서 핵심은 세그먼트가 로그보다 더 자주 생성된다는 점입니다. 브로커가 수많은 쓰기 요청을 받고 상당한 부하 상태에 놓여 있다고 가정해봅시다.

Northguard는 새로운 브로커를 추가하여 워크로드를 분산시키는데, 흥미로운 점은 Kafka처럼 기존 브로커에서 새로운 브로커로 파티션을 이동시킬 필요가 없다는 것입니다. 시스템은 단지 새로운 활성 세그먼트를 새로운 브로커에 할당하기만 하면 됩니다. 이렇게 하면 데이터 수집 워크로드가 새로운 브로커로 전달되어 과부하에 걸린 브로커의 부담이 줄어듭니다.

또한, 세그먼트는 Kafka의 파티션보다 더 작은 단위이므로 데이터를 이동하는 과정이 Kafka에 비해 훨씬 덜 부담스럽습니다.

# 메타데이터

Northguard는 다음과 같은 메타데이터를 관리합니다.

• 토픽: 토픽이 종료되거나 삭제될 때, 그리고 해당 범위가 병합되거나 분할될 때
• 범위: 상태(active/sealed/deleting), 어떤 토픽에 속하는지, 생성 시간, 보존 기간
• 세그먼트: 세그먼트의 replica, 상태(active/sealed/reassigned), 시작 offset, 세그먼트 길이, 생성 및 종료 시간

Northguard는 메타데이터를 관리하기 위해 Raft 기반의 복제 상태 머신을 사용하며, 이는 vnodes에 분산되어 있습니다. Northguard 클러스터는 하나 이상의 vnode를 가지며(여기서 vnode는 브로커 내의 프로세스로 추정됨), 각 vnode는 토픽, 범위, 세그먼트 메타데이터의 일부를 저장합니다.

Northguard는 일관성 해싱을 사용하여 메타데이터를 vnodes에 분산시킵니다. 토픽 메타데이터는 토픽 이름을 기준으로 해싱되고, 범위와 세그먼트 메타데이터는 범위 ID를 기준으로 해싱됩니다.

메타데이터를 샤딩하고 분산된 조정을 활용함으로써, Northguard는 Kafka의 컨트롤러 병목 현상을 제거하고 강력한 일관성과 높은 가용성을 제공합니다.

# 프로토콜

예상할 수 있듯이, Northguard는 Kafka와 메타데이터 및 데이터를 조직하는 방식이 다르기 때문에 프로토콜 또한 다릅니다.

메타데이터 작업은 요청-응답 모델을 따르며, 클라이언트는 어떤 브로커로든 요청을 보낼 수 있습니다. 해당 브로커는 글로벌 상태의 로컬 복사본을 확인하여 어떤 vnode가 요청을 처리할 수 있는지 식별하고, 적절한 vnode로 요청을 라우팅합니다.

데이터와 관련된 작업(예: producer, consumer, replication)은 세션 기반 스트리밍 프로토콜을 통해 수행됩니다.

Kafka와 마찬가지로 데이터 생성 과정은 리더와의 통신을 통해 이루어집니다. 클라이언트는 활성 세그먼트 리더와 핸드셰이크를 시작하며, 브로커가 허용하는 윈도우 크기에 대한 정보를 전달받게 됩니다.

프로듀서는 레코드가 윈도우를 초과하지 않는 한, 세그먼트에 데이터를 추가하기 위한 여러 요청을 전송합니다. 브로커는 레코드가 커밋되었을 때(모든 replica에 영구 저장되었을 때)만 프로듀서에게 ACK를 반환합니다.

소비 과정은 생산 과정과 유사하지만 데이터가 반대 방향으로 흐른다는 점이 다릅니다. 클라이언트는 자신이 수용할 수 있는 데이터의 양을 결정하며, 브로커는 레코드가 사전에 정의된 양을 초과하지 않는 한 데이터를 계속 전송합니다. 이는 Kafka에서 소비자가 브로커로부터 데이터를 가져오는 방식과 대조적입니다.

세그먼트 복제 역시 데이터 생성 과정과 매우 유사하게 동작하지만, 차이점은 활성 세그먼트 리더와 세그먼트 팔로워 간의 상호작용이라는 점입니다.

# 스토리지 계층

Northguard의 스토리지는 플러그인 방식으로 구성됩니다. 기본 구현은 세그먼트별로 생성되는 Write Ahead Log(WAL)를 사용합니다. 이 구현은 Direct I/O를 활용하며, RocksDB에 희소 인덱스를 보관합니다.

쓰기 요청은 다음 조건 중 하나가 충족될 때까지 배치됩니다.

• 정의된 시간이 경과했을 때
• 배치 크기가 설정된 한도에 도달했을 때
• 쓰기 요청 수가 설정된 한도에 도달했을 때

이후 배치는 동기적으로 WAL에 기록되고, 세그먼트 파일에 추가되며, 해당 파일이 fsync 처리되고, 인덱스가 갱신됩니다.

Kafka는 zero-copy 읽기에 강점을 가지지만, 쓰기 과정에서는 여전히 애플리케이션 버퍼에서 OS 페이지 캐시로, 그리고 디스크로 데이터를 전송해야 합니다. Direct I/O는 중간 OS 페이지 캐시 복사를 제거함으로써 쓰기 경로를 최적화할 수 있습니다. 또한 Northguard는 애플리케이션 레벨 캐싱을 활용하여 소비된 데이터에 대한 정보를 캐시에 채워넣는 방식으로 성능을 향상시킵니다.

# Kafka 클라이언트의 동작 방식

Kafka와 Northguard 간의 프로토콜 차이와 LinkedIn 내에서 Kafka가 광범위하게 사용되고 있다는 점 때문에 마이그레이션은 상당히 도전적입니다.

이를 위해 LinkedIn은 Northguard와 Kafka를 모두 지원하는 가상 Pub/Sub 계층인 Xinfra를 도입했습니다. Xinfra는 물리적 클러스터를 추상화하고 Kafka와 Northguard 클라이언트 모두에게 통합된 경험을 제공합니다.

Xinfra는 사용자 토픽의 마이그레이션을 지원하기 위해 이중 쓰기 방식을 활용합니다. 이 과정에서는 프로듀서가 먼저 마이그레이션되고, 그 다음으로 컨슈머가 마이그레이션됩니다.

마이그레이션 기간 동안 프로듀서는 Kafka와 Northguard 모두에 데이터를 기록하여, 마이그레이션 실패 시 안전하게 되돌아갈 수 있도록 합니다. 프로듀서와 컨슈머는 마이그레이션 중에도 정상적으로 동작을 이어갑니다. 프로세스가 완료되면 이중 쓰기는 비활성화됩니다.