OSC Korea Blog

다양한 소식을 전합니다.
Blog

카프카가 왜 이렇게 주목을 받을까?

카프카가 왜 이렇게 주목을 받을까?
원문보기
apache kafka 로고

최근 아파치 카프카에 대한 이야기가 여기저기서 들리고 있다. 클라우드 좀 한다는 사람들이면 한번씩은 들어봄직한 오픈소스 솔루션이다. 소프트웨어 아키텍처와 배포 환경이 극도로 복잡해지고 실시간 처리에 대한 수요가 급증하면서 Apache Kafka가 큰 관심을 받고 있는데, 카프카가 왜 이렇게 주목을 받는지 살펴보기로 하자. 

Apache Kafka는 Linkedin에서 내부 메시지 처리용으로 개발한 분산 로그(Distributed Log) 시스템이다. 2011년 초 처음으로 공개되어 2012년 10월에는 아파치 소프트웨어 재단의 정식 프로젝트가 됐다. 여기서의 Log는 흔히 생각하는 소프트웨어의 내부 상태를 표시하는 데 사용되는 log가 아닌 Database 내부에 위치하는 자료 구조 Log를 가리킨다. 대부분의 Database는 사용자의 요청을 반영하고 데이터 무결성을 유지하기 위해 내부적으로 다양한 Log를 사용해서 record 변경 내역 등을 기록한다.

흔히 Kafka를 RabbitMQ, ActiveMQ와 같은 Messaging Queue 기술의 일종으로 생각하는 경우가 많지만, Kafka의 창시자이자 Confluent의 CEO Jay Kreps에 따르면 이러한 생각은 완전히 틀린 것이다. Kafka는 Database의 내부에 위치해서 여간해서는 외부인이 볼 일이 없는 Log 자료구조를 분산 스토리지 형태로 구현한 것이다. 메시지를 유연하게 전달하는 데 초점을 맞추는 Messaging Queue 기술과는 달리 규모 확장성 있게 쓰고, 저장하는 데 최적화되어 있다. 메시지를 빠르게 읽고 쓸 수 있기 때문에 Messaging Queue와 사용 영역이 겹치는 부분이 있을 뿐이지, 엄연히 Database에 더 가깝다.

Confluent의 전 CTO인 Neha Narkhede에 따르면, Kafka를 처음으로 구상되게 된 것은 2000년대 말 Linkedin의 내부 사정과 관련이 있다. 당시 Linkedin은 중앙 집중화된 Oracle Database에 의존하던 소프트웨어 아키텍처를 다수의 분산된 마이크로서비스의 집합으로 변경하는 작업을 수행중이었다. 이 구조는 나날이 성장하던 Linkedin 서비스의 확장성을 증대시키는 데 큰 도움이 되었지만, 데이터 통합의 측면에서는 문제가 많았다. 다수의 스토리지에 저장되어 있는 데이터를 가져다 검색 인덱스나 기계 학습 예측값을 생성할 때마다 완전히 처음부터 새로 작업을 해야 했던 것. 이 구조는 느릴 뿐만 아니라 데이터 간에 일관성/무결성을 유지하는 것도 어려웠고, 스키마가 조금이라도 변경되면 깨지기 일쑤였다. 많은 시행착오를 반복한 끝에 Linkedin의 데이터 엔지니어링 팀은 Database 안에 숨어 있는 Log를 독립된 분산 스토리지의 형태로 독립시키고, 표준화된 인터페이스를 사용해서 다수의 스토리지에 가해진 변경 내역만을 저장하는 방식으로 옮겨갔다. 이 접근 방법은 이후 데이터 통합 측면에서 뿐만 아니라 분산 마이크로서비스 애플리케이션 개발 등에도 여러 이점이 있다는 점이 밝혀졌고, 지금의 Kafka ecosystem의 토대가 되었다.

Kafka의 가장 큰 장점은 처음부터 극단적으로 빠르게 주어지는 대량의 Record를 저장할 수 있는 분산 시스템으로 설계된 만큼 규모 확장성이 매우 뛰어나다는 점이다. 각각의 저장 장치가 낼 수 있는 최대 읽기/쓰기 속도를 거의 그대로 사용할 수 있으면서도 내고장성이 우수하고 강력한 분산 처리 기능을 제공한다. 가장 큰 강점은 다른 스토리지와의 연동, 마이크로서비스 개발, 실시간 처리 등의 다양한 상황에서 사용할 수 있는 기술들의 ecosystem이 존재한다는 점이다.

OSC Korea는  다수의 마이크로서비스 아키텍쳐 기반의 프로젝트와  컨설팅을 수행하면서, 시스템안의 수많은 서비스들이 어떻게 API를 통해 커뮤니케이션을 해야 하는가에 대한 원론적이 질문을 자주 접하게 된다. 새로운 마이크로서비스 아키텍쳐를 도입하고 관리하는 시스템의 서비스 숫자가 급격하게 늘어나고, 이 각각의 서비스간의 소통 또한 매우 복잡해지고, 각 서비스간의 상호 의존도가 높아지면서 개발팀의 작업을 저하시키게 되기 때문이다.  이런 설계의 약점을 극복하기 위해 여러가지 방법을 검토하던 중, 접하게 된 것이 아파치 카프카이다. 국내에는 기업과 개발자 커뮤니티에서 의외로 오픈소스 아파치 카프카에 대한 관심이 높지만, 대규모 IT 서비스를 제공하는 사업자는 어느정도 기술인력을 갖추고 있지만 그외 엔터프라이즈 고객을 대상으로 제대로된 기술지원이 가능한 전문업체는 전무후무한 상황이었다. OSC Korea는 최근 이런 시장의 수요를 파악하고 발빠르게 아파치 카프카에 대한 투자를 시작했으며 아파치 카프카 전문가인력을 적극 영입하면서 본격적인 고객 서비스를 준비하고 있다. 

초기에는 데이터 통합을 위해 사용되는 유용한 도구에 불과했던 Kafka는 이후 실시간 이벤트 처리(Event Streaming)에 있어서 유용한 도구라는 점이 발견되고 IoT의 확산과 함께 실시간 처리에 대한 수요가 증대되면서 단순히 효율적인 자료 구조 구현체를 넘어서 범용 스트리밍 플랫폼으로 진화했다. Kafka의 최신 개발 트렌드에 대해서, 버전 1.x 대에 이루어진 업데이트의 대부분은 기본적인 성능 향상이나 기능 개선이었던 반면 2.x 를 넘어가면서는 Hybrid Cloud 환경 대응이나 Edge Computing 관련 최적화, Data Lake 관련 기능 지원 등의 비중이 늘어나고 있다.

기술 생태계의 주요 참여자들 역시 여기에 맞춰서 진화하고 있다. Uber는 초기부터 Kafka를 잘 활용해 온 것으로 유명한 회사다. 자체적인 모니터링 툴, 관리 운영 툴을 개발하여 활용하고 있을 뿐더러 이 회사가 전세계에 걸친 실시간 IoT 신호 처리 시스템을 구축하기 위해 고안한 아키텍처는 현재 Kafka 활용의 표준이 됐다. 발전 사업, 차량 생산에서부터 실시간 주행 서비스까지 제공하는 Tesla 역시 2015년 Kafka를 도입해서 활용중이다. 단순히 사용만 하는 수준을 넘어서서 자체 처리 프레임워크와 운영 툴을 개발해서 사용하고 있는 것으로 알려졌다.

Twitter의 경우 내부 메시지 교환 시스템을 구현하기 위해 Apache Bookeeper 기반으로 Apache Pulsar와 유사한 아키텍처를 가진 자체 시스템을 사용하고 있었으나, 2018년 성능과 안정성이 검증되고 강력한 기술 생태계를 보유한 Apache Kafka로 옮겨왔다. 현재 Twitter의 Kafka Infrastructure는 초당 1억 5천만 개 이상의 메시지를 처리하고 있는 것으로 알려졌다.

Hadoop이 단순한 연산 프레임워크를 넘어서 빅데이터 시대를 여는 기술 플랫폼이 되었듯이 Kafka 역시 마찬가지 경로를 타고 있는 셈이다. 말하자면, Kafka는 Event Streaming 시대의 새로운 Hadoop이라고도 할 수 있겠다.


- Kafka 소개 https://kafka.apache.org/

Apache Kafka는 실시간으로 기록 스트림을 게시, 구독, 저장 및 처리할 수 있는 분산 데이터 스트리밍 플랫폼이다. 여러 소스에서 데이터 스트림을 처리하고 여러 사용자에게 전달하도록 설계되어 있다. 간단히 말해, A지점에서 B지점까지 이동하는 것뿐만 아니라 A지점에서 Z지점을 비롯해 필요한 모든 곳에서 대규모 데이터를 동시에 이동할 수 있다. 

Apache Kafka는 전통적인 엔터프라이즈 메시징 시스템의 대안으로 하루에 1조4천억 건의 메시지를 처리하기 위해 LinkedIn이 개발한 내부 시스템으로 시작했으나, 현재 이는 다양한 기업의 요구사항을 지원하는 애플리케이션을 갖춘 오픈소스 데이터 스트리밍 솔루션으로 발전하였다. 

아파치 카프카의 상용버전은 Confluent이며, 국내에는 OSC Korea 가 컨설팅/구축 서비스 및 교육 서비스를 제공하고 있다. 

아파치 카프카/컨플루언트 소개: http://www.osckorea.com/solution/confluent

아파치 카프카 교육프로그램 소개: http://www.osckorea.com/training/apache-kafka


Latest posts

1 / 8
Next