[Kafka] 카프카 기본 개념: 실시간 비동기 스트리밍 솔루션

Micro Service Architecture로 아키텍처 패턴이 만들어 짐에 따라서, 각각의 서비스들이 통신하게 되는 구조가 이전보다 복잡해지게 되었습니다. 이와 같이 복잡해진 데이터 전송 구조는 베포와 장애의 어려움을 만들어내게 됩니다. 또한 데이터를 전송할 때 프로토콜의 파편화가 심각해지게 되는 문제가 발생하게 됩니다.

 

Apache Kafka는 이러한 문제를 해결하기 위해 Linked In에서 개발한 오픈소스로 Source Application과 Target Application의 커플링을 약하기 위해 개발 된 것으로 애플리케이션들의 중추 신경과 같은 역할을 하게 됩니다.

 

아래의 이미지는 카프카가 개발되기 전 링크드인의 데이터 처리 시스템을 나타낸 것입니다.

 

[출처] https://www.confluent.io/blog/event-streaming-platform-1

 

한눈에 보기에도 복장한 아키텍처 흐름도를 가지고 있습니다. 이전의 방식은 엔드투 엔드 방식. 즉 엔드포인트에서 엔드포인트로 전달하는 방식으로 중간에 어떠한 메시징 큐를 거치는 것이 아닌 다이렉트로 데이터를 전송하는 방식입니다. 이와 같은 방법의 이점으로는 빠른 전송 속도와 전송에 대한 결과를 신속하게 알 수 있다는 장점이 있습니다. 하지만 마이크로 서비스 간의 커플링이 증가하기 때문에 확장성과 장애에 내성을 갖기 힘듭니다. 예를 들어 예를 들어 위의 아키텍처 흐름도에 새로운 웹 서버 1개가 추가된다고 가정 해보겠습니다. 웹 서버가 1대 추가된다는 것은 단순히 한대가 추가되는 것이 아니라 연동해야 할 시스템이 많아지기 때문에 추가적인 작업이 매우 늘어나게 됩니다. 그리고 일대일로 통신하고 있던 A라는 서버에 문제가 생겨 응답이 지연되는 경우, 연쇄 작용으로 A서버와 연결된 다른 마이크로 서비스들에서도 지연이 발생하는 이슈가 발생할 수 있습니다.

 

이런 문제점을 해결하기 위해 링크드인에서는 마이크로 서비스들 간의 커플링을 낮추고 데이터의 중앙집중화를 위해 카프카를 개발하게 되었고, 2011년 초 오픈소스로 세상에 공개되엇습니다.

 

카프카는 기본적으로 메시징 시스템으로 동작하게 됩니다. 메시징 시스템이란 위의 엔드투엔드 방식이 아니라 메시지를 보내는 publisher(또는 producer)에서 카프카의 토픽이라 불리는 메시지 저장소에 데이터를 저장하고, subscriber(또는 consumer)라고 불리는 메시지를 가져가는 측에서 원하는 톡픽의 데이터를 가져가는 형태의 시스템을 이야기 합니다. 즉 중앙에 메시징 시스템 서버를 두고 메시지를 보내고 받는 형태의 통신으로 펍pub/섭sub 모델이라고 부릅니다.

 

 

카프카를 적용한 Linted In 아키텍처 흐름도

 

 

이와 같은 pub/sub 모델을 적용한 아키텍처 흐름도를 적용할 경우 위에서 엔드투엔드 방식과 달리 메시징 시스템을 중심으로 각각의 마이크로 서비스들이 연결되기 때문에 확장성이 용이하고, 중간에 서비스가 지연이 발생하거나 수신 불능 상태가 되더라도, 메시징 시스템만 살아 있으면 프로듀서에서 전달된 메시지는 유실되지 않기 때문에, 서비스가 다시 회복하면 언제든 메시지를 수신할 수있다는 장점이 있습니다. 하지만 모든 기술에 장점만 있을 수 없듯, 서비스간의 직접적으로 데이터를 전송하지 않기 때문에 엔드투엔드 방식에 비해 속도가 느리고, 메시지가 정확하게 전달되었는지 확인하기 위해서 코드가 좀 더 복잡해진다는 단점이 있습니다.

 

카프카는 현재 가장 관심받고 있는 기술 중 하나입니다. 아래의 stack overflow의 질문 수가 증가하는 폭을 보면 알 수 있듯이 끊임없이 상승세를 그리고 있고, Netflix, Airbnb, Microsoft, Kakao, Naver와 같은 많은 IT 기업들이 점차 카프카를 도입하고 있습니다.

 

 

 

이러한 중앙 집중형인 메시징 시스템은 분명 매력적이지만, 메시징 시스템은 카프카가 처음이 아닙니다. 그럼에도 왜 이렇게 카프카에 열광하는 것일까요?

 

카프카는 이전의 메시징 시스템과 몇가지 다른 점이 있습니다.

 

1. 고성능

기존의 메시징 시스템은 간단한 이벤트를 서버로 전송하는 데 주로 사용되었습니다. 왜냐하면 메시징 시스템의 부하와 각 컨슈머들의 큐 정합성과 전달결과를 정확하게 관리하기 위한 프로세스가 매우 다양하고 복잡해졌기 때문에 신뢰성을 중점적으로 개발되었고, 상대적으로 속도와 용량에 관해서는 크게 관심을 두지 않았습니다.

 

카프카는 이러한 메시징 시스템이 지닌 성능의 한계를 극복하기 위해 역할의 분리를 극대화 하였습니다. 즉 메시지 교환 전달의 신뢰성 관리를 각각의 프로듀서와 컨슈머로 넘기고, 부하가 많은 교환기 기능 역시 컨슈머가 만들 수 있게 함으로써 메시징 시스템 내에서는 작업량을 많이 줄였니다. 그리고 이렇게 절약한 작업량을 메시징 전달 성능에 집중시켜 고성능 메시징 시스템을 만들어냈습니다.

 

2. Disk 저장소

카프카가 기존의 메시징 시스템과 가장 다른 특징은 바로 Disk에 메시지를 저장하고 유지한다는 것입니다. 기존의 메시징 시스템에서는 컨슈머가 메시지를 읽어가면 큐에서 바로 메시지를 삭제하게 됩니다. 하지만 카프카에서는 컨슈머가 메세지를 읽어가더라도, 정해져 있는 일정 보관 주기동안 디스크에 메시지를 저장해둡니다. 따라서 트래픽이 늘어나 일시적으로 컨슈머의 처리가 늦어지거나, 장애가 생겨 서비스를 중단하게 되더라도, 카프카의 디스크에 메시지가 저장되기 때문에 컨슈머를 메시지를 손실 없이 가져올 수 있습니다.

 

3. 확장성

카프카는 확장성이 매우 용이합니다. 카프카 클러스터는 서비스의 중단 없이 온라인 상태에서 작업이 가능하고, 트래픽 및 사용량에 따라 클러스터를 확장하는 것이 매우 간답합니다.

 

 

이와같은 이유로 이전에 여러 군데 퍼져있던 파편화된 데이터를 중앙 집중화 함으로써 현재 빅데이터 분석이나 머신러닝과 같은 실시간 데이터가 중요한 영역에서 아주 중요한 요소로 자리잡게 되었습니다. 다음 포스팅에서는 카프카와 같은 분산 애플리케이션에서 사용되는 코디네이터 애플리케이션인 주키퍼에 관해서 알아보겠습니다.