Apache Kafka 계층형 스토리지로 가는 단계

데이터를 클라우드의 객체 스토리지로 오프로드할 수 있는 Apache Kafka 3.6의 기능인 계층형 스토리지는 오픈 소스의 힘을 보여주는 대표적인 예입니다.

2022년 데이터를 클라우드의 객체 스토리지로 오프로딩할 수 있는 Apache Kafka®의 기능인 Tiered Storage에 대한 기술적 개요를 설명하면서 시작되었습니다. Tiered Storage가 이루고자 하는 바에 대한 기술적 개요를 제공하는 훌륭한 프레젠테이션이었고, 강연이 끝날 때쯤 노트북을 사용하고 S3 프로토타입 플러그인을 구현하기 시작할 정도로 많은 영감을 받았습니다.

 

 

Apache Kafka 계층형 스토리지로 가는 단계

 

 

계층형 스토리지 관심을 가져야 하는 이유

Tiered Storage는 Kafka 3.6의 가장 수요가 많은 기능 중 하나로, Kafka의 생산자나 소비자를 변경하지 않고도 객체 스토리지 외에 객체 스토리지와 같은 다른 위치에 Kafka의 핵심 데이터를 투명한 방식으로 저장할 수 있습니다. Kafka 브로커는 데이터가 빠르고 비용이 많이 들고 제한적인 로컬 디스크에 저장되는지 아니면 Amazon S3와 같은 대체 스토리지 장소에 저장되는지 여부를 제어합니다. Tiered Storage가 적절하게 구성되면 최근 데이터는 로컬 패스트 디스크에 저장되고, 오래되고 액세스 빈도가 낮은 데이터는 더 저렴하고 공간 요구 사항이 덜 우려되는 다른 곳에 저장할 수 있습니다.

Tiered Storage에 대한 가능성을 보여주었고, 커뮤니티의 업스트림 진행이 진행되는 동안 프로세스를 시작하고 싶었습니다. 결국 Kafka 커뮤니티 모두가 Tiered Storage를 시도할 수 있도록 Tiered Storage를 공개적으로 시작하는 사전 결정을 내렸습니다.

 

 

계층형 스토리지를 Apache Kafka 3.3으로 포팅

Apache Kafka의 Tiered Storage의 기존 상태를 조사했을 때, 2022 직후, 두 가지의 거의 완벽한 Tiered Storage 구현이 있다는 것을 알게 되었습니다. 하나는 Uber for Kafka 2.8, 다른 하나는 LinkedIn의 Kafka 3.0의 구현이었습니다. LinkedIn의 초기 포인터를 사용하여, Kafka 3.3으로 포워딩을 시작했습니다.

이는 Kafka의 핵심 데이터 구조인 LogSegment 서브시스템이 크게 변경되어 디스크에 Kafka 로그 데이터가 저장되는 방식을 정의했기 때문에 쉬운 작업이 아니었습니다. 따라서 서브시스템은 Tiered Storage에 매우 중요했습니다. 특히 Kafka 3.0의 경우 단일 Log만 있었던 반면, Kafka 3.3의 경우에는 Local Log와 Unified Log로 분할되어 Tiered Storage를 준비했습니다.

링크드인의 3.0 카프카 포크의 각 커밋에는 아파치 카프카 3.3에 해당하는 체리픽 커밋이 있으므로 포워딩할 때는 세심한 주의가 필요했습니다. 더 자세히 설명하면 이렇게 큰 변경 사항을 포워딩할 수 있는 두 가지 다른 방법이 있습니다. 한 가지 방법은 체리픽 수정 사항(즉, 새로운 분기인 카프카 3.3에 복사하여 적용)을 선택하고 문제가 있는 경우 이를 수정하기 위한 추가 커밋을 수행하는 것입니다. 이는 간단하지만 외부 관찰자가 추가 노이즈로 인해 무슨 일이 일어나고 있는지 추적하는 것을 어렵게 합니다. 대신 링크드인의 카프카 3.0 포크에서 원래 커밋 하나와 일치하는 체리픽 커밋을 엄격하게 선택했습니다. 선택한 커밋에 호환성이나 버그 수정을 위해 추가 변경이 필요하더라도 일치 커밋을 사용하면 버그/문제를 더 쉽게 추적할 수 있습니다.

Apache Kafka 3.6에서 계층형 스토리지 테스트

포워드 포팅은 최신 버전의 Kafka에서 Tiered Storage를 실행하기 위한 명백한 첫 단계였지만, 그것은 단지 일부에 불과했습니다. Tiered Storage는 Kafka의 핵심과 맞닿아 있기 때문에 광범위한 테스트가 필요하며, 데이터를 저장하는 방식과 데이터를 저장할 위치 및 읽기 방법에 대한 계산을 변경합니다. 상황을 더 어렵게 만들기 위해 Tiered Storage는 많은 움직이는 부분을 포함합니다. Tiered Storage의 순수한 Kafka 측면은 외부 스토리지 시스템에 대한 인터페이스일 뿐이며, 원격 스토리지에서 데이터를 저장/읽기하는 방법을 정의하는 플러그인이라는 구현을 작성하는 것은 다른 사람들의 몫입니다.

또한 기능을 제대로 테스트하기 위해서는 계층화 스토리지가 어떻게 수행되고 있는지 이해하는 데 중요한 메트릭을 쉽게 노출할 수 있어야 했습니다. 이러한 작업의 예로는 도커 이미지가 있으며, 필요한 메트릭을 이미 사전 구성한 계층화 스토리지 Amazon S3 플러그인과 함께 전체 Kafka 클러스터를 쉽게 생성할 수 있습니다. 도커 이미지는 테스트 및 검증할 수 있는 공통 환경을 제공하기 때문에 특히 커뮤니티의 다른 팀과 협업할 때 필요했습니다. 또한 오픈 작업의 이점은 관심 있는 기여자(Apple, Datadog, Slack과 같은 회사)가 프로젝트를 찾았고 핵심 계층화 스토리지 기능뿐만 아니라 당시 Amazon S3 객체 스토리지용으로 개발 중이던 오픈 소스 플러그인을 돕고 테스트하는 데 열심이었다는 것을 의미합니다.

모든 기여자들은 아마존 S3 플러그인 구현을 위한 성능 제안뿐만 아니라 다양한 버그를 발견하고 검증하는 데 도움이 되는 정확한 피드백을 테스트하고 제공하는 데 핵심적이었습니다. 오픈 소스의 정신으로 이러한 문제를 수집하고 보고했으며 필요에 따라 업스트림 카프카를 참조했습니다.

프로세스에서 발견된 버그 및 수정 사항

예상했던 대로, 커뮤니티는 테스트 시에만 발생하는 흥미로운 경주 조건에서 여러 KIP의 변경 및 업데이트에 이르기까지 많은 문제를 극복할 수 있었습니다.

이러한 변경의 예는 향후 Azure 객체 스토리지 구현에 필요한 RemoteLog Segment에 사용자 지정 메타데이터를 추가한 Ivan Yurcheno가 만든 KIP-917에서 볼 수 있습니다. KAFKA-15131, KAFKA-15135 및 KAFKA-15181과 같은 풀 요청의 코드 품질 및 문서화에 대한 호르헤 에스테반 퀼케이트 오토야의 많은 개선은 말할 것도 없습니다.

그 과정에서 다양한 업스트림 풀 요청이 주목을 받기 시작했고 카프카에 상륙하기 시작했습니다. 주목할 것은 풀 요청으로 카프카 3.0에서 현재 카프카 3.6에서 사용 가능한 것으로 모든 변경 사항을 전달했습니다. Tiered Storage의 첫 번째 프리뷰가 카프카 3.6에 상륙했기 때문에 Tiered Storage를 카프카로 포팅하는 작업이 실패한 것처럼 보일 수 있지만, 주목해야 할 중요한 것은 Aiven의 내부 팀이 Amazon S3 및 GCS 플러그인 및 관련 기능을 작업하기 위해 차단을 해제한 작업뿐만 아니라 다른 회사 및 기여자들도 기능 개발에 협력할 수 있다는 것입니다.

 

오픈에서 새로운 기능을 함께 구축

궁극적으로, 이것은 오픈 소스의 힘을 보여줍니다. 커뮤니티의 작업을 사용하여 기술을 향상시키고, 새로운 기능을 도입하며, 아파치 카프카와 함께 데이터 스트리밍의 다음 단계를 위한 발판을 마련하는 협업 접근 방식으로 카프카를 발전시킬 수 있는 커뮤니티 기반 소프트웨어 개발 접근 방식입니다. 만약 우버의 계층화된 스토리지 구현이 오픈되어 있지 않았다면, 링크드인은 이를 사용하고 혜택을 받을 수 없었을 것이고, 그 결과 다른 회사들도 시작하지 않았을 것입니다.

대체로 업계의 다른 기업들은 오픈 소스에서 멀어지고 있지만, 이러한 여정은 기업과 사용자 간의 협업을 촉진하는 데 있어 오픈 소스가 얼마나 강력한지를 보여주기 때문에 위안을 삼아야 합니다.