링크드인이 카프카를 직접 개발한 이유

아파치소프트웨어재단이 2011년 오픈소스로 공개한 카프카(Kafka). 카프카는 비즈니스와 구인·구직 기반의 소셜 네트워크 서비스인 링크드인(LinkedIn)의 수석 엔지니어 제이 크렙스Jay Kreps가 고안했다. 

크렙스는 카프카(메시징 시스템) 외에도 볼드모트Voldemort, 분산 키-값 저장소, 삼자Samza, 스트림 처리 시스템 등의 오픈소스 프로젝트를 이끈 인물로, 링크드인에서 개발한 비동기 메시징 시스템에 평소 존경했던 대문호 프란츠 카프카의 이름을 따서 ‘카프카’라 명명했다.

카프카는 글로벌 IT 기업의 상당수가 채택한 분산 스트리밍 플랫폼이다. 링크드인은 여러 대안을 두고 왜 카프카를 독자 개발했는지, 당시 링크드인이 처한 문제는 무엇이고 요구사항은 무엇이었을까? - 편집자 주

링크드인의 고민과 카프카의 탄생

카프카는 2011년 미국 링크드인에서 출발했다. 카프카는 링크드인 웹사이트에서 생성되는 로그를 처리하여 웹사이트 활동을 추적하는 것을 목적으로 개발되었다. 웹사이트에서의 활동은 사용자가 페이지 뷰와 검색 시 키워드 광고의 이용 상황도 포함된다. 웹에서 생성되는 대량의 로그를 분석하여 사용자가 웹에서 하는 활동을 모니터링하고 서비스 개선에 활용하는 것이다. 

빅데이터를 어떻게 활용할 것인지가 큰 화제였던 당시 많은 웹 기업에서는 웹사이트에서 생성되는 로그를 활용하기 시작했다. 이러한 상황을 감안하여 지금부터 카프카가 탄생한 배경을 살펴보자. 링크드인이 실현하려는 목표는 다음과 같다.

  • ➊ 높은 처리량으로 실시간 처리한다.
  • ➋ 임의의 타이밍에서 데이터를 읽는다.
  • ➌ 다양한 제품과 시스템에 쉽게 연동한다.
  • ➍ 메시지를 잃지 않는다.순서대로 살펴보자.

높은 처리량으로 실시간 처리한다: 앞서 언급한 바와 같이 링크드인은 전 세계 사용자의 방대한 액세스 데이터를 처리해야 하기에 처리량이 우수해야 한다. 또한 사용자의 활동을 신속하게 파악하거나 사용자의 활동에 따라 즉각 피드백하기 위해서는 사용자의 활동 단위로 실시간 처리가 가능해야 한다. 

여기서 말하는 실시간 처리는 수집부터 시작해 수백 밀리초에서 수 초 안에 데이터가 처리되는 처리 방식을 가정하고 있다.

임의의 타이밍에 데이터를 읽는다: 실시간 처리에 대한 요구가 있는 반면, 링크드인은 기존 시스템에서 수집한 액세스 로그를 일정 시간마다 배치 처리로 취급하고 싶었다. 데이터를 사용하는 타이밍이 반드시 실시간이 아니라 이용 목적에 따라 다를 수 있기 때문에 방대한 데이터를 전달할 때 버퍼 역할도 하기를 원했다.

다양한 제품과 시스템에 쉽게 연동한다.: 링크드인에서는 데이터의 발생원인 데이터 소스와 관련된 시스템이 하나가 아니어서 여러 시스템을 통해 데이터를 받아들여야 했다. 또한 이용 목적에 따라 데이터베이스, 데이터 웨어하우스, 아파치 하둡 등 여러 기반이 존재하고 있었다.

당시 대량의 데이터를 처리할 수 있는 기반으로 하둡의 유용성이 인지되어 링크드인도 사용하고 있었는데, 다른 데이터베이스와 데이터 웨어하우스에서 실시하고 있는 처리를 모두 하둡에 이식하는 것은 현실적인 방법이 아니었다. 기존 자산을 활용하기 위해 하둡하고만 연결할 수 있으면 좋다는 것이 아니라, 데이터베이스나 데이터 웨어하우스 등 다른 제품과의 연결을 쉽게 하고 싶다는 요구가 있었다.

메시지를 잃지 않는다.: 취급하는 메시지가 방대하더라도 메시지를 잃어서는 안 됐다. 다만, 링크드인은 당초 이용 목적이 웹에서 사용자 활동을 추적하는 것이었기 때문에 한 건 한 건의 활동을 엄격하게 관리하기보다는 약간의 중복이 있더라도 메시지를 잃지 않는 것이 중요했다. 

건마다 엄격하게 관리해 처리 오버헤드processing overhead가 커지는 것은 이미 인식하고 있었으므로, ‘높은 처리량으로 실시간 처리’라는 요건과의 균형을 가미하여 현실적으로 제거해도 좋은 것을 찾아야 했다.

링크드인이 검토한 제품들

링크드인은 이러한 요구를 충족하는 여러 제품을 검토했다. 요구를 부분적으로 충족하는 제품이 있었을지도 모르지만, 포괄적으로 해결할 수 있는 제품은 없었다. 데이터를 전달하거나 데이터를 로드할 때 필요한 제품에는 크게 메시지 큐, 로그 수집, ETL 도구가 있다. 

메시지 큐: 레코드 단위로 실시간 처리를 할 때 가장 먼저 떠오르는 것이 메시지 큐다. 메시지 큐 제품으로는 IBM의 WebSphere MQ5와 JMSJava Messaging system사양을 따르는 아파치 ActiveMQ, 그 외 RabbitMQ가 있다. 기존 메시지 큐의 예메시지 큐에서 제공하는 기능은 제품마다 차이는 있지만 대략 다음과 같이 정리할 수 있다. 모두 링크드인에서 요구하는 사항과 일치하지 않았다. 

강력한 전달 보증이 오버 스펙이었다.

IBM WebSphere MQ는 메시지 단위로 트랜잭션을 지원하는 기능이 있다. 하나의 메시지가 정확히 한 번만 전송되는 것을 보증할 수 있다. JMS에도 사양으로 규정되어 있으며, 애플리케이션에서 commit ( )이나 rollback ( )이라고 기술하면 각 커밋/롤백을 할 수 있다. 

그러나 링크드인에서 다루는 로그의 성질을 고려하면 엄격한 트랜잭션 관리는 다소 오버 스펙이며, 그보다 ‘높은 처리량’이 우선순위가 더 높은 상황이었다. 메시지는 분실하지 않은 채 송수신 보증을 너무 중시한 나머지 처리량이 나오지 않는 것은 바람직하지 않다는 게 당시의 상황이었다.스케일 아웃이 용이한 제품이 아니었다.

대량의 메시지를 처리하는 데 1대의 서버로만 대응하는 것은 한계가 있다. 그러므로 처음부터 여러 대의 서버를 사용할 것을 전제할 필요가 있었다. 물론 메시지 큐의 제품에도 클러스터 구성을 취하는 것이 있었지만 실제로는 가용성을 위한 중복 구성에 주안점을 두고 있었다. 

처리 성능을 높이는 목적으로 필요 시 노드를 추가할 수 있는 스케일 아웃 기능을 전제로 한 제품이 당시에는 없었다.

메시지가 대량으로 쌓이는 것을 예상하지 않았다.

카프카 등장 이전의 메시지 큐에서는 메시지를 쌓아둘 수 있었는데, 큐에 쌓인 메시지는 즉시 이용되는 것으로 전재했지, 장시간에 걸쳐 대량으로 축적하는 것은 고려하지 않았다. 

링크드인은 실시간 처리뿐만 아니라 메시지를 배치 처리하는 것도 가정했다. 일정량의 데이터를 일정 기간마다 묶음으로 받아 데이터 웨어하우스에서 처리하기 위해서는 데이터의 축적 시간이 훨씬 길어야 했지만 기존 메시지 큐로는 감당할 수 없었다.

로그 수집 시스템

실시간으로 데이터를 수집한다는 관점에서 생각할 수 있는 것은 로그 수집을 위한 미들웨어다. 

주로 웹 서버 등의 프론트엔드 서버의 로그를 수집하기 위한 것이다. 당시 이 카테고리의 제품으로는 페이스북이 개발한 Scribe와 미국 클라우데라가 개발한 Flume이 있었다.

기존 로그 수집 기반의 제품은 각 프론트엔드 서버가 로그를 중계용 서버에 전송하고, 거기서 로그를 수집하여 데이터베이스와 분산 파일시스템 HDFSHadoop Distributed File system에 축적한다. 원래 대량의 로그를 처리하는 것을 가정하고 있었기 때문에 분산 환경의 다중 서버 구성으로 이루어져 있다. 그러나 이들 제품을 링크드인에서 사용하기에는 다음과 같은 문제가 있었다.

HDFS로 데이터 축적과 배치 처리만 고려했다.

이들 제품은 대량의 로그를 HDFS에 축적하고 하둡 맵리듀스에서 일괄 처리하는 것이 주목적이다. 링크드인에서도 하둡을 사용하고 있었지만, 동시에 데이터 웨어하우스를 이용한 데이터 분석도 실시하고 있어 모두 하둡에서 동작하도록 애플리케이션을 다시 작성하는 것은 현실적이지 않다.

또한 데이터는 배치 처리로 이용할 뿐만 아니라 실시간으로도 처리하고자 하는 요구가 있었다. 따라서 HDFS를 전제로 하는 로그 집약의 구조로는 불충분하고 동일한 로그 데이터를 다목적으로 활용할 수 있어야 했다.

알기 쉬운 API가 없다.

카프카 이전의 제품은 미들웨어의 구현 사양을 모르면 사용하기 힘들었다. 데이터 송신 쪽과 데이터 수신 쪽에서 사용되는 다양한 제품을 연계하기 위해서는 이용하기 쉬운 송수신 API가 필요했다.

수신하는 쪽이 임의로 메시지를 수신하기 어렵다.

로그 수집 기반 서버에서 그다음 수신 시스템으로 메시지 전달에서, 기존 제품은 로그 수집 기반 서버에서의 ‘push’에 의해 수신자에게 메시지를 전달했다. 그러나 링크드인은 메시지의 다양한 활용이 필요했기 때문에 각 수신자가 자신의 속도나 처리의 빈도에 따라 수신할 수 있어야 했다.

따라서 로그 수집 기반 서버가 그 뒤에 있는 수신 시스템의 수신 여부를 일일이 모니터링하면서 ‘push’하는 것보다는 수신 시스템이 메시지를 갖고 가는 ‘pull’ 방식이 오히려 사용하기 쉽다고 생각했다.

ETL 도구

또 하나의 제품은 데이터 발생원에서 데이터를 추출하고 필요에 따라 변환해 데이터베이스와 데이터 웨어하우스에 로드하는 기능을 갖추고 있는 ETL 도구다.여기서 ETL 도구로는 DataStage, Interstage, Cosminexus, Informatica PowerCenter, Talend 같은 제품이 있다. ETL 도구에서는 다음과 같은 부분이 요구 사항을 충족하지 못했다고 한다.

데이터를 파일 단위로 다룬다.

카프카 등장 이전에 대량의 데이터를 높은 처리량으로 전달하려면 데이터를 파일 단위 등으로 뭉쳐서 배치 처리로 전송하는 것이 일반적이었다. 이를 실현하기 위해 ETL 도구를 사용했다. 이들 도구는 ‘한 건의 레코드 단위’로 ‘실시간 처리’를 하고 싶다는 링크드인의 요구 사항을 충족하지 않았다.

수신하는 쪽이 임의로 메시지를 수신하기 어렵다.로그 수집과 동일한 논의가 ETL 도구에서도 성립한다. ETL 도구는 데이터를 추출, 변환하여 다른 데이터 저장소에 전달하는 것을 주축으로 하고 있지, 임의의 타이밍에 데이터를 읽을 수 있는 중계 역할까지 하지는 않았다.

앞서 설명한 것처럼 2009년 당시의 제품들은 링크드인의 요구 사항을 충족시키지 못했기에 카프카 개발을 시작했다. 

카프카가 링크드인 요구 사항을 어떤 수단으로 실현했는지 살펴보자.

요구 사항

  • ➊ 높은 처리량으로 실시간 처리한다.
  • ➋ 임의의 타이밍에 데이터를 읽는다.
  • ➌ 다양한 제품과 시스템에 쉽게 연동한다.
  • ➍ 메시지를 잃지 않는다.

실현 수단

  • ➊ 메시징 모델과 스케일 아웃형 아키텍처
  • ➋ 디스크로의 데이터 영속화
  • ➌ 이해하기 쉬운 API 제공
  • ➍ 전달 보증

이 글은 IT전문 출판사 한빛미디어 웹사이트에 실린 것으로 회사 측의 허락을 얻어 테크잇에서 퍼블리싱하는 것입니다. 뒷부분의 다소 기술적인 내용들을 생략했고, 링크드인이 카프카를 개발한 배경과 카프카를 개발하면서 초점을 맞춘 부분들 위주로 정리했습니다.제목은 일부 수정했습니다.

테크잇 뉴스레터를 전해드립니다!

오피니언 기반 테크 블로그 'TechIt'
테크 비즈니스를 보는 다양한 통찰들을 이메일로 간편하게 받아 볼 수 있습니다.

About the author

한빛미디어
한빛미디어

한빛미디어 / 더 나은 세상을 위한아시아 출판 네트워크

No more pages to load


TechIT

테크 비즈니스를 보는 다양한 통찰 '테크잇'

독자 여러분들께서 좋은 의견이나 문의 사항이 있으시면 아래 양식에 따라 문의 주시기 바랍니다.

Contact