카프카에서 계층 저장소(Tiered storage)가 필요한 이유

2020년 11월 Cofluent Platform 6.0이 릴리즈되면서 카프카의 계층 저장소가 처음으로 대중에게 소개되었습니다. 이전까지 카프카 오픈소스 진영에서 많이 논의 되었지만 실제로 개발자가 사용 가능한 형태로 나온 것은 이때가 처음입니다. 컨플루언트를 사용하는 많은 개발자와 회사에서는 카프카의 계층 저장소를 사용해왔습니다. 이후 2023년 10월, 오픈소스 카프카 3.6.0이 릴리즈 되면서 계층 저장소 얼리 엑세스 모드를 사용할 수 있게 되었습니다. 

 

카프카에서 계층 저장소는 현재의 브로커 구조에서 아주 중요한 역할을 수행하게 될 것입니다. 계층 저장소는 많은 장점이 있겠으나 그 중 핵심은 비용 절감이라고 생각합니다. 비용 절감에는 크게 두가지가 있는데 컴퓨팅 리소스 비용과 휴먼 리소스 비용입니다. 이 2가지 측면에서 카프카의 계층 저장소가 어떤 역할을 하는지 알아보겠습니다.

 

1) 컴퓨팅 리소스 감소

현재의 카프카는 여러대의 브로커(서버)에 로컬의 파일시스템에 레코드를 세그먼트 단위로 저장하고 있습니다. 프로듀서가 토픽에 데이터를 전달할 때 마다 세그먼트에 레코드를 추가, 저장함으로써 파일시스템의 크기가 계속해서 늘어나는 구조를 가지고 있죠.

 

문제는 이 데이터의 양이 많아지고 리텐션(Retention)기간을 길게 가져가야할 때 입니다. 파일시스템이 저장되는 공간인 로컬 디스크가 아무리 램에 비해 저렴하다고 하더라도 100TB, 1000TB 혹은 그 이상으로 구성하기는 매우 어렵고 비용이 많이 발생합니다. 카프카의 분산 이벤트 스트리밍 플랫폼 특성상 모든 토픽의 리텐션을 3일, 3시간 이내로 가져가는 것은 카프카의 특징을 오히려 상쇄 시키는 역효과로 가져옵니다. 그렇기 때문에 더 긴 리텐션을 만족시키기 위해서는 로컬 저장소 저장 방식이 아니라 리모트 저장소가 필요합니다.

 

카프카에서 제공하는 계층 저장소는 S3, HDFS, Azure storage 등 우리에게 익숙한 저장소를 지원합니다. 리모트 저장소 사용 여부 설정은 토픽 단위로 지정 가능합니다. 그렇기 때문에 리텐션 기간이 짧고 자주 접근이 필요한 데이터가 들어 있다면 로컬 저장소로 선택하면 됩니다. 반대로 자주 접근하지 않는 데이터를 오랜기간 저장해야 한다면 리모트 저장소로 설정하면 됩니다. 이 설정을 활용하여 로컬 저장소의 저장 용량은 줄이되, 자주 접근하지 않는 데이터는 로컬 저장소보다 더 저렴한 리모트 저장소에 저장함으로서 비용적인 측면에서 더 효율적이라고 볼 수 있습니다.

 

리모트 저장소와 로컬 저장소로 설정한 토픽 둘 다 최근 데이터 읽기/쓰기는 거의 비슷합니다. 다만, 리모트 저장소에 저장된 토픽의 레코드 중 브로커의 페이지 캐시에 존재하지 않는 데이터를 읽을 때(컨슈머)는 약간의 지연이 발생할 수 있습니다. 일반적으로 우리가 스트림 데이터를 다룰 때 가장 최신의 데이터를 자주 접근하고 오래된 데이터를 다시 가져오는 리플레이 상황은 빈번히 일어나지 않기 때문에 리모트 저장소로 설정된 토픽의 지연은 일반적인 상황에서 크게 문제되지 않는다고 볼 수 있습니다. 

 

2) 휴먼 리소스 감소

오랜기간 동안 카프카를 운영하면서 많은 카프카 운영자들은 브로커를 운영하기 위해 많은 피땀을 흘려왔습니다. 운영을 지속함에 따라 토픽의 개수가 계속해서 늘어나고 토픽의 파티션 개수는 각양 각색이며, 토픽별 데이터양도 모두 다르기 때문입니다. 그렇기 때문에 브로커의 디스크 용량 불균등 현상으로 인해 특정 토픽의 파티션 개수를 배수로 늘리거나 파티션 재설정(partition reassign)을 수행해야만 했습니다. 카프카 클러스터의 로컬 디스크 모니터링/운영은 컴퓨터가 자동으로 하거나 일반적인 자동화 툴로는 하기 어려운 일이며 카프카 클러스터 운영자가 수동으로 해야 합니다.

 

리모트 저장소는 카프카 클러스터 운영자가 들이는 수고를 한층 줄여줄 수 있습니다. 리모트 저장소로 설정된 토픽은 로컬 디스크에 저장되는 것이 아니라 외부 저장소에 저장되기 때문에 각 브로커별 로컬 디스크의 데이터양을 이전만큼 민감하게 모니터링할 필요가 없습니다. 또한 브로커 업그레이드와 같은 롤링 리스타트 상황에서도 각 브로커의 영향도가 한층 적어진다는 장점이 있습니다. 이전 만큼 대규모로 비싼 비용의 브로커를 운영할 필요가 없어집니다.

 

물론, 리모트 저장소를 사용한다고 모든게 해결되는 것은 아닙니다. 리모트 저장소와 연결된 토픽을 따로 관리해야할 것입니다. 예를 들어 카프카와 리모트 저장소의 연결 상태, 데이터 크기, 네트워크 속도 등 다양한 부분을 인프라 관점에서 고민이 필요합니다. 

 

정리

카프카가 제공하는 계층 저장소는 아직 얼리 엑세스 모드로서 많은 기능들이 제한적으로 제공됩니다. 한번 리모트 저장소로 저장한 토픽은 다시 로컬 저장소로 변경이 불가능, 카프카 클라이언트와 호환성 부족 등이 대표적이며 이외에도 안정성 측면에서 프로덕션 레벨에서 사용하기에는 아직 부적합 합니다.

 

그럼에도 불구하고 카프카의 계층 저장소는 상당히 가치있기 때문에 빠르게 프로뎍션 레벨로 제공될 것이라 생각됩니다.

 

참고문서

- https://cwiki.apache.org/confluence/display/KAFKA/Kafka+Tiered+Storage+Early+Access+Release+Notes

Kafka Tiered Storage Early Access Release Notes - Apache Kafka - Apache Software Foundation

- https://cwiki.apache.org/confluence/display/KAFKA/KIP-950%3A++Tiered+Storage+Disablement

KIP-950: Tiered Storage Disablement - Apache Kafka - Apache Software Foundation

- https://dzone.com/articles/the-stairway-to-apache-kafka-tiered-storage

The Stairway to Apache Kafka® Tiered Storage - DZone

- https://joshua-robinson.medium.com/simplify-kafka-at-scale-with-confluent-tiered-storage-ae8c1a2c9c80

Simplify Kafka at Scale with Confluent Tiered Storage

- https://www.confluent.io/blog/confluent-platform-6-0-delivers-the-most-powerful-event-streaming-platform-to-date/

Confluent 6.0 Delivers the Most Powerful Event Streaming Platform to Date

- https://cwiki.apache.org/confluence/display/KAFKA/KIP-405%3A+Kafka+Tiered+Storage

KIP-405: Kafka Tiered Storage - Apache Kafka - Apache Software Foundation

- https://www.confluent.io/blog/introducing-apache-kafka-3-6/

Introducing Apache Kafka 3.6