마이크로 서비스 아키텍처(MSA)는 현대적인 서비스 개발을 위한 기본요소로 자리잡았습니다. MSA에서 중요한 부분 중 하나는 각 독립적인 구성 요소들 간의 데이터 파이프라인 입니다. 이때 이 데이터 파이프라인 을 위해 자주 언급되는 솔루션은 아파치 카프카(Apache Kafka)입니다. 이번 포스트에서는 카프카의 탄생 배경과 카프카가 해결하려고 한 문제에 대하여 알아보겠습니다!
모니터링이 필요한 애플리케이션이 있다고 상상해 보세요. 초기에는 각각의 서버에서 수집한 메트릭을 대시보드 앱으로 직접 보내는 것으로 충분했습니다. 이런 방식은 서버의 수가 적을 때는 잘 작동합니다.
하지만, 비즈니스가 성장함에 따라 모니터링할 서버의 수가 증가하고, 메트릭을 활용하고자 하는 서비스도 늘어나면 상황은 복잡해집니다. 이제 각 서버는 여러 대시보드와 분석 도구에 동시에 데이터를 전송해야 합니다. 아래 그림에서 볼 수 있듯, 서버와 서비스 간의 연결이 복잡하게 얽히기 시작합니다.
이러한 복잡성을 해결하기 위해, 모든 서버에서 발생하는 메트릭을 단일 지표 수신 서버로 집중시킬 수 있습니다. 그런 다음 이 서버는 수집된 데이터를 필요한 모든 대시보드와 분석 시스템에 제공합니다. 이 접근 방식으로 시스템의 복잡성을 크게 줄일 수 있으며, 아래 그림처럼 깔끔하고 관리하기 쉬운 아키텍처를 만들 수 있습니다.
이제 각 서버는 단지 메트릭을 수집하는 것에 집중할 수 있으며, 지표 수신 서버는 모든 메트릭을 적절한 대상에게 효율적으로 분배하는 역할을 합니다. 이러한 방식은 복잡한 시스템도 잘 관리될 수 있다는 것을 보여줍니다.
데이터 파이프라인의 필요성
이처럼 데이터 파이프라인은 발전하는 서비스 아키텍처에서 중요한 역할을 합니다. 데이터 파이프라인 없이는, 증가하는 데이터 볼륨과 복잡성을 관리하는 것이 점점 더 어려워집니다. LinkedIn의 경우도 마찬가지로, 수많은 시스템과 애플리케이션에서 발생하는 지표들과 사용자 활동 데이터를 효율적으로 처리하고 실시간으로 분석할 수 있는 강력한 도구가 필요했습니다.
2010년도 LinkedIn의 시스템
LinkedIn에서 카프카의 탄생은 당시 존재했던 특정 문제점들을 해결하기 위한 필요성에서 비롯되었습니다. 이를 이해하기 위해서는 2010년 당시 LinkedIn이 운영하고 있던 주요 시스템들에 대한 이해가 필요합니다. 이러한 시스템들로는 지표 수집 시스템과 사용자 활동 추적 시스템이 있었습니다.
지표 수집 시스템
지표 수집 시스템의 목적
- 전통적인 지표 수집: CPU 사용량, 애플리케이션 성능 등
- 단일 사용자 요청의 내부 애플리케이션 전파 추적
이 시스템을 통해 LinkedIn은 각 시스템 구성 요소의 상태를 모니터링하고, 사용자의 요청이 내부적으로 어떻게 처리되는지 이해할 수 있었습니다. 하지만 이 시스템은 여러 한계점을 가지고 있었습니다.
지표 수집 시스템의 한계점
- 폴링 방식을 기반으로 한 긴 주기 의 지표 수집 간격.
- 애플리케이션 소유자가 자신의 메트릭을 관리할 수 없음
- 간단한 작업에 대해서도 인간의 개입을 필요
- 동일한 측정치에 대해 일관되지 않은 지표 명명
사용자 활동 추적 시스템
사용자 활동이란?
사용자 활동은 LinkedIn 플랫폼에서 이루어지는 모든 사용자 기반의 상호작용을 의미합니다. 이에는 검색어 입력, 게시물에 대한 반응(예: 좋아요, 댓글), 다른 사용자와의 네트워킹(예: 친구 요청, 메시지 교환), 프로필 업데이트 등이 포함됩니다. 이러한 활동은 사용자의 행동 패턴과 플랫폼 내에서의 상호작용을 나타내며, 이 데이터는 사용자 경험 개선, 콘텐츠 추천, 플랫폼 최적화 등에 중요한 정보를 제공합니다.
사용자 활동 추적 시스템의 한계점
- 배치 처리 기반: 1시간 단위의 배치 처리로 실시간 반응 불가능
- 일관성 없는 데이터 스키마: XML 형식의 데이터 포맷 불일치
- 데이터(XML) 파싱 시 계산 부하가 큼
- 사용자 활동 유형 변경 시 프론트엔드와 오프라인 처리 간 상당한 조정 필요
- 스키마 변경으로 인해 시스템은 지속적으로 고장남
LinkedIn의 시스템의 한계점
모니터링과 사용자 활동 추적은 동일한 백엔드 서비스를 사용할 수 없었습니다.
- 모니터링 서비스는 너무 무겁고, 데이터 형식은 활동 추적에 적합하지 않았음
- 모니터링을 위한 폴링 모델과 추적을 위한 푸시 모델이 호환되지 않음.
- 추적 서비스는 메트릭 사용에는 너무 취약함
- 배치 지향적 처리는 실시간 모니터링 및 경고에 적합한 모델이 아님
그러나 모니터링 및 추적 데이터는 많은 특성을 공유했으며, 정보의 상관관계가 높았습니다. 가령, 특정 유형의 사용자 활동 정보와 애플리케이션 성능에는 상관관계가 존재합니다.
또한, 시스템의 한계는 비즈니스에 직접적인 영향을 주었습니다. 특정 유형의 사용자 활동 감소는 서비스하는 애플리케이션에 문제가 있음을 알려줍니다. 하지만, 활동 배치의 처리에 수시간의 지연이 발생함에 따라 이러한 유형의 문제에 대한 반응이 느렸습니다.
위의 한계점들을 극복하면, 시스템 운영의 더 나은 인사이트와 비즈니스적 이점으로 얻을 수 있습니다.
Apache Kafka의 등장
이러한 문제들을 해결하기 위해, LinkedIn은 처음에는 기존의 오픈 소스 솔루션들을 조사했습니다. 하지만, 그들은 ActiveMQ와 같은 솔루션이 규모 면에서나 사용 방식에서 LinkedIn의 필요를 충족시키지 못한다는 것을 발견했습니다. 결국, LinkedIn은 데이터 파이프라인을 위한 맞춤형 인프라 구축을 결정했고, 이로써 아파치 카프카(Apache Kafka)가 탄생하게 되었습니다.
Apache Kafka의 초기 목표
1. 데이터 생산자(Producer)와 데이터 소비자(Consumer)의 의존관계를 분리하자.
2. 여러 Consumer가 사용하게, 데이터에 대한 영속성을 제공하자.
3. 높은 데이터 처리 성능을 제공하자.
4. 데이터 처리량의 증가에 대응하기 위하여, 시스템의 수평적 확장을 허용하자.
이번 포스트에서는 LinkedIn이 직면했던 문제들과 카프카의 초기 목표에 대하여 살펴보았습니다. 다음 포스트에서는 Apache Kafka를 이해하기 위하여 필요한 용어들에 대하여 알아보겠습니다.
Reference
1. [Kafka: The Definitive Guide] : https://www.oreilly.com/library/view/kafka-the-definitive/9781491936153/
2. [Kafka: a Distributed Messaging System for Log Processing] : https://pages.cs.wisc.edu/~akella/CS744/F17/838-CloudPapers/Kafka.pdf
