Apache kafka 개요

본 문서는 "실전 아파치 카프카", "카프카 데이터 플랫폼의 최강자" 책과 위키백과 등을 기반으로 작성되었음을 알려드립니다.

아파치 카프카 탄생 배경

아파치 카프카는 2011년 미국 링크드인에서 개발되어 최종적으로 오픈소스화 되었고, 현재는 카프카에 집중하기 위해서 Confluent 회사를 창립했다. 링크드인은 2002년 12월에 설립되어 2003년 5월에 운영을 시작한 미국의 비즈니스 중심의 소셜 네트워크 서비스이며, 당시 링크드인은 두가지 이슈가 존재했다.

1. 데이터 중앙소가 무엇인가?

   • 카프카가 탄생하기 이전 하둡과 빠르게 대응할 수 있는 SQL 데이터베이스가 존재하지 않았다.
   • 모든 데이터를 빠르게 접근하기 위한 방법이 필요했다.

2. 다양한 데이터 소스가 존재한다.

   • 사용할 데이터와 애플리케이션, 이벤트, 네트워크 핑 정보를 수집했으나 이러한 데이터를 통합할 방법이 필요했다.
   • 애플리케이션과 데이터를 바라보는 시각차를 고민하여 애플리케이션은 데이터베이스나 큐를 사용하고 데이터는 ETL이나 분석도구를 사용했다. 이를 통해 애플리케이션과 데이터간의 시각차가 존재함을 알게 되었다.

이러한 이슈를 해결하기 위해서 새롭게 무엇을 만드는 것 이외에 RabbitMQ. Retrofit, ETL을 조합해서 사용하였으나, 본질적인 두 이슈를 해결하지 못한다고 판단하여 새롭게 카프카를 만들게 되었다.

ETL Tool

​ Extract, transform, load의 약자로 타 기종의 데이터 소스로 부터 데이터를 추출하여 조회 또는 분석을 목적으로 하는 포맷이나 구조로 데이터를 변환하는 역할을 한다.

RabbitMQ

오픈소스 메시지 브로커 소프트웨어로서, 메시지를 생산하는 생산자(Producer)가 메시지를 큐에 저장해 두면, 메시지를 수신하는 소비자(Consumer)가 메시지를 가져와 처리하는 Publish/Subscribe 방식의 메시지 전달 브로커이다.

Retrofit

Square에서 제작하여 안드로이드 애플리케이션에서 통신 기능을 위해 제작한 라이브러리로서 REST 기반으로 JSON 구조를 사용한다.

아파피 카프카 목표

1. 높은 처리량을 실시간으로 처리해야 한다.
   • 사용자의 활동에 대해서 신속하게 파악하고 피드백하기 위해서는 활동 단위로 실시간 처리가 가능해야 한다. 이는 데이터 수집부터 처리까지 사람이 느끼지 못할 정도로 빠르게 동작해야 함을 의미한다.
2. 임의의 타이밍에서 데이터를 읽어야 한다.
   • 처리되어야 하는 데이터는 실시간으로 처리되어야 하는 부분도 있으나, 이용 목적에 따라 다르게 사용될 가능성이 있기 때문에 데이터를 저장하는 버퍼의 역할을 수행한다.
3. 다양한 제품과 시스템을 쉽게 연동한다.
   • 현존하는 대부분의 시스템은 단일 시스템과 단일 응용프로그램으로 운영하지 않는다. 분산처리 및 확장 가능성 또한 시스템과 시스템끼리 연결에 있어 표준적이고 제약이 없어야 한다.
4. 메시지를 잃지 않는다.
   • 전달하고자 하는 메시가 일부 중복이 발생하더라도 절대 메시지 손실이 발생하면 안된다. 하지만 엄격한 메시지 관리를 할 경우 높은 처리량으로 인해 발생하는 오버헤드로 실시간 처리가 힘들어 질 수 있기 때문에 둘 사이의 균형이 반드시 필요하다.

Kafka vs RabbitMQ

RabbitMQ와 Kafka는 기본적으로 message queue를 사용한다는 공통점을 가지고 있다. 자세히 들어가자면 RabbitMQ는 push모델이고, Kafka는 pull 모델이라고 정의하며 이부분에 대한 자세한 설명은 다음에 진행하도록 하겠다.

message queue는 한 건의 레코드 단위로 실시간 처리를 할 때 사용한다. 그림을 통해 쉽게 설명하자면 생산자는 메시지를 Queue에 넣어두면 소비자가 이를 가져와 처리한다라고 생각하면 된다. 여기서 Queue에서 소비자가 메시지를 직접 가져가는지 아니면 Queue에서 메시지는 전달해주는지에 대한 방식에 따라 차이가 발생한다.

다르게 생각하면 메시지를 전달하는 과정에 Queue 과정이 더해지면서 시스템 성능이 하락되지 않겠다는 생각이 들 수도 있지만 서버와 클라이언트 통신과정에서 동기식으로 많은 데이터를 전송하게 되면 병목현상으로 인해 서버 성능이 하락될 수 있기 때문에 이런 현상을 막기 위해서 Queue라는 미들웨어를 추가하고 메시지를 위임함으로 순차적으로 처리할 수 있음을 보장하는데 있다. 다음을 통해 message queue의 장점을 살펴보도록 한다.

---

• 비동기(Asynchronous): Queue에 넣기 때문에 나중에 처리할 수 있다.
• 비동조(Decoupling): 애플리케이션과 분리할 수 있다.
• 탄력성(Resilience): 일부가 실패 시 전체에 영향을 받지 않는다.
• 과잉(Redundancy): 실패할 경우 재실행 가능하다.
• 보증(Guarantees): 작업이 처리된걸 확인할 수 있다.
• 확장성(Scalable): 다수의 프로세스들이 큐에 메시지를 보낼 수 있다.

---

위의 장점으로 보았을 때, message queue는 반드시 사용해야 할 것으로 보인다. 하지만 여기서 주의해야 할 점은 우리가 사용하는 모든 서비스에 message queue가 적합하지 않을 수 있다는 것이다. 다시 말해서 message queue를 사용하면서 즉각적인 처리성능을 원한다면 커스터마이징이나 물리적 성능을 올려야 할 수 있고, 어느 한쪽에 부하가 발생할 경우 병목현상이 생길 수 있다. 따라서 우리는 용도에 맞는 message queue를 사용해야 하며, 이를 위한 다양한 서비스를 선택해야 한다.

그렇다면 가장 많이 사용하는 RabbitMQ와 Kafka의 차이를 알아보도록 하자.

RabbitMQ

• 구성이 간단하다.

• 유연한 라우팅이 가능하고 UI가 편리하다.

• 오픈소스이지만 성숙도(품질)이 뛰어나다.

• 개방형 프로토콜인 AMQP를 구현하기 위해 개발되었다.

  • AMQP(Advanced Message Queuing Protocol)는 메시지 지향 미들웨어를 위한 개방형 표준 응용 계층 프로토콜이다. AMQP의 정의 기능들은 메시지 지향, 큐잉, 라우팅(P2P 및 발행-구독), 신뢰성, 보안이다.

    

• 필요에 따라서 동기/비동기 구현이 가능하다.

• 소비자 중심의 설계

• 20k/sec 처리를 보장한다.

Kafka

• 구독방식과 비동기식 구성
• 고성능 고가용성
• 분산처리에 특화되어 설계
• 생산자 중심의 설계
• 범용 메시지 시스템에서 제공되는 다양한 기능은 제공되지 않음
• 100k/sec 처리 보장

Kafka vs RabbitMQ 처리 속도

Kafka와 RabbitMQ는 좋은 솔루션이다. 다만 RabbitMQ의 경우 메시지를 복잡한 방법으로 컨슈머(소비자)에게 라우트하거나, 메시지당 전달보장을 필요하지 않을 때, 클러스터별 HA가 필요하지 않는 경우에 사용하는데 적합하다. 이에 반해 Kafka의 경우 초당 100k 이상의 메시지를 전달하는 대규모 서비스와 메시지를 다시 읽거나 HA 구성이 필요한 대규모 서비스에서 적합하다고 할 수 있다.