서비스에 적용 가능한 IPC(Inter-Process Communication) 기술은 정말 많습니다.
HTTP 기반 REST나 gRPC와 같은 요청/응답 기반의 통신 메커니즘도 있고 AMQP, STMOP와 같은 메시지 기반의 통신 메커니즘도 있습니다.
이번에는 그중에서도 비동기 메시징 시스템인 Apache Kafka에 대해서 알아보도록 하겠습니다.
Kafka ?
Kafka는 링크드인에서 시작하여 현재는 컨플루언트에서 개발 중인 발행/구독(publish/subscribe) 채널 시스템을 이용한 메시지 분산 서비스입니다.
다른 말로는 커밋 로그(distributed commit log) 또는 분산 스트리밍 플랫폼(distributed streaming)이라고도 불립니다.
카프카란 이름은 개발자인 Jay Kreps가 좋아하는 작가 Franz Kafka에서 비롯됐으며 시스템과는 아무 상관이 없습니다.
메시지 발생/구독 시스템이란 데이터(메시지)를 발행자(전송자)가 직접 구독자(수신자)에게 보내지 않고 구독자가 원하는 특정 부류의 메시지만 구독해서 소모할 수 있게 하는 시스템을 뜻합니다.
메시지 분산 서비스라는 말은 통신 복잡도를 줄이기 위해 각각의 서비스들에서 발생한 메시지를 한 곳에 모은 다음 메시지들을 분산 및 전달하는 것을 의미합니다.
말로만 들었을 때는 왜 메시지 분산 서비스가 필요한지 알 수 없으나 아래 그림처럼 서비스가 많아질수록 IPC의 복잡도는 증가하고 메시지를 추적하기 어렵기 때문입니다.
이때 메시지 분산 서비스를 쓰면 아래와 같이 깔끔하게 정리할 수 있습니다.
카프카를 선택하는 이유
선택할 수 있는 메시지 발행/구독 시스템에는 여러 가지가 있지만 아파치 카프카를 선택하면 다음 이유에서 좋습니다.
다중 프로듀서
카프카는 무리 없이 많은 프로듀서의 메시지를 처리할 수 있습니다.
여러 클라이언트가 많은 토픽을 사용하거나 같은 토픽을 같이 사용해도 처리가 가능합니다. 따라서 여러 클라이언트들의 데이터를 수집하고 일관성을 유지하는 데 이상적입니다.
다중 컨슈머
카프카는 하나의 토픽을 많은 컨슈머가 상호 간섭 없이 읽을 수 있게 지원합니다.
한 클라이언트가 특정 메시지를 소비하면 다른 클라이언트에서 그 메시지를 사용할 수 없는 큐(queue) 시스템과는 다릅니다.
디스크 기반의 보존
카프카는 지속해서 메시지를 보존할 수 있기 때문에 컨슈머가 항상 실시간으로 실행되지 않아도 됩니다. 물론 카프카 옵션(보존기간, 토픽 크기, 디스크 크기)에 따라 제한이 있습니다.
보존 옵션은 토픽 별로 지정할 수 있으며 컨슈머의 요구에 맞게 메시지 스트림마다 서로 다른 옵션을 가질 수 있습니다.
이와 같은 특성 때문에 장애 상황에서도 데이터가 유실될 위험이 적습니다. 또한 컨슈머는 소모한 지점을 기억해서 장애극복 이후 처리되지 못한 데이터부터 소모할 수 있습니다.
확장성
카프카는 확장성이 좋아서 어떤 크기의 데이터도 쉽게 처리할 수 있습니다.
데이터 증가에 따라 10개에서 심지어는 수백 개의 브로커를 갖는 대규모 클러스터로 업무용 환경을 구축하면 됩니다. 해당 작업은 시스템 전체의 사용에 영향을 주지 않고 클러스터가 온라인 상태일 때도 수행될 수 있습니다.
여러 개의 브로커로 구성된 클러스터는 개별적인 브로커의 장애를 처리할 수 있으며 동시에 여러 브로커에 장애가 생겨도 정상적으로 처리할 수 있는 기능(replication factor)을 제공합니다.
키워드로 알아보기
카프카를 이해하기 위한 키워드 들을 알아봅시다.
메시지
카프카에서는 데이터의 기본 단위를 메시지라고 합니다. 이것은 데이터베이스의 행이나 레코드에 비유될 수 있습니다.
메시지는 토픽안에 있는 파티션에 수록되는데 이때 같은 키 값을 설정하게 되면 같은 키를 갖는 메시지는 항상 같은 파티션에 수록됩니다.
토픽과 파티션
카프카의 메시지는 토픽으로 분류됩니다. 이때 하나의 토픽은 여러 개의 파티션으로 구성될 수 있습니다.
파티션은 서로 다른 서버에 분산될 수 있습니다. 즉 하나의 토픽이 여러 서버에 걸쳐 수평적으로 확장될 수 있으므로 단일 서버로 처리할 때보다 훨씬 성능이 우수합니다.
메시지는 파티션에 추가되는 형태로만 수록되며 맨 앞부터 제일 끝까지의 순서로 읽힙니다. 대게 하나의 토픽은 여러개의 파티션을 갖지만 메시지 처리 순서는 토픽이 아닌 파티션 별로 유지 관리됩니다.
메시지 처리 순서는 파티션 별로 보장되기 때문에 처리 순서가 보장되어야 하는 데이터들은 키를 사용해서 같은 파티션에 묶어야 합니다.
기본적으로 파티션은 줄일 수 없고 키값을 사용할 경우 파티션을 추가하면 키의 해시값이 변경되기 때문에 파티션 숫자를 정하는건 충분한 고민이 필요합니다.
예를 주문이란 토픽에 들어가는 메시지들이 분류에 따라 순서가 보장되어야 한다면 주문이라는 토픽에 분류를 키로 하여 메시지를 쓰게 할 수 있습니다.
그럼 같은 분류의 주문들은 항상 같은 파티션에 존재하기 때문에 같은 분류의 메시지는 처리 순서가 보장되게 할 수 있습니다.
배치
카프카는 효율성을 위해 메시지를 배치 형태로 파티션에 수록하므로 네트워크 통신에서 발생하는 비용에 대한 부담을 줄일 수 있습니다.
물론 이 경우 대기 시간과 처리량 간의 트레이드오프가 발생합니다.
스키마
카프카는 메시지의 구조를 나타내는 스키마를 사용할 수 있습니다.
많은 카프카 개발자들은 아파치 Avro를 사용해 데이터를 직렬화 하는 것을 선호합니다.
Avro를 사용할 경우 메시지와는 별도로 스키마를 유지 관리하므로 스키마가 변경되더라도 애플리케이션의 코드를 추가하거나 변경할 필요가 없어 확장에 용이합니다.
프로듀서
프로듀서는 새로운 메시지를 생성합니다. 발행/구독 시스템에서는 작성자라고 합니다.
기본적으로 프로듀서는 메시지가 어떤 파티션에 수록되는지 관여하지 않습니다. 그러나 추가 옵션을 통해 특정 파티션에 메시지가 들어가도록 할 수 있습니다.
컨슈머
컨 슈마는 메시지를 읽으며 발행/구독 시스템에서는 구독자라고 합니다.
컨슈머는 하나 이상의 토픽을 구독하여 메시지가 생성된 순서로 읽으며 메시지의 오프셋을 유지하여 소모 중인 메시지의 위치를 알 수 있습니다.
오프셋이라는 메타데이터는 지속적으로 증가하는 정숫값이며 메시지가 생성될 때 카프카가 추가해줍니다.
카프카에서는 각 파티션에서 마지막에 읽은 메시지의 오프셋을 저장하고 있으므로 컨슈머가 읽기를 중단했더라도 언제든 그다음 메시지부터 읽을 수 있습니다.
컨슈머 그룹
컨슈머를 컨슈머 그룹에 속하게 할 수 있습니다.
컨슈머 그룹은 하나 이상의 컨슈머로 구성되며 한 토픽을 소비하기 위해 같은 그룹의 여러 컨슈머가 함께 동작합니다.
같은 컨슈머 그룹끼리는 오프셋을 공유하기 때문에 다량의 메시지를 갖는 토픽을 소비하기 위해 컨슈머를 수평적으로 확장할 시켜 처리량을 증가시킬 수 있습니다.
한 토픽의 각 파티션은 하나의 컨슈머만 소비할 수 있습니다. 이때 파티션수보다 컨슈머가 더 많으면 남은 컨슈머는 아무 일도 하지 못하기 때문에 주의해야 합니다.
브로커와 클러스터
하나의 카프카 서버를 브로커라고 합니다.
브로커는 프로듀서로부터 메시지를 수신하고 오프셋을 지정한 후 해당 메시지를 디스크에 저장합니다. 그리고 컨슈머의 파티션 읽기 요청에 응답하고 디스크에 수록된 메시지를 전송합니다.
환경에 따라 다르지만 평균적으로 하나의 브로커는 초당 수천개의 토픽과 수백마내의 메시지를 처리할 수 있습니다.
브로커는 클러스터의 일부로 동작하도록 설계되었습니다. 즉 여러 개의 브로커가 하나의 클러스터에 포함될 수 있으며 그중 하나는 컨트롤러로 선정되어 브로커들이 정상적으로 동작하는지 모니터링하고 관리합니다.
그 예시로 파티션 할당이 있습니다. 토픽의 파티션들은 브로커에 할당되는데 해당 브로커에 장애가 생기면 다른 브로커가 소유권을 인계받아 그 파티션을 처리할 수 있습니다.
주키퍼
분산 코디네이션 서비스를 제공하는 오픈소스 프로젝트입니다.
카프카 브로커를 하나의 클러스터로 코디네이팅 하는 역할을 하며 클러스터에서 구성 서버들끼리 공유되는 데이터를 유지하기 위해 사용합니다.
이용사례
활동 추적
카프카를 이용해 사용자 활동 추적을 할 수 있습니다.
사용자가 웹 사이트에 접속하여 액션을 수행하면 프런트엔드에서 이것에 관한 메시지 데이터를 생성합니다.
이런 추적 데이터는 하나 이상의 토픽으로 전송되어 카프카에 저장된 후 백엔드 애플리케이션에서 소비됩니다.
메시지 전송
사용자에게 알림 메시지를 전송해야 하는 애플리케이션에도 유용합니다.
이때 각 애플리케이션에서 메시지 형식이나 전송 방법을 신경 쓰지 않게 메시지를 생성할 수 있습니다.
전송될 모든 메시지를 하나의 애플리케이션이 읽어서 다음 작업을 일관성 있게 처리할 수 있기 때문입니다.
이렇게 되면 알림 기능이 하나로 모이게 되고 응집성이 증가하게 됩니다.
메트릭과 로깅
카프카는 애플리케이션과 시스템의 메트릭과 로그 데이터를 모으는 데 이상적입니다. 여러 곳에서 같은 타입의 메시지를 생성하는 대표적인 이용 사례입니다.
각 애플리케이션들이 정기적으로 생성한 메트릭을 카프카 토픽에 저장한 후 모니터링과 보안 시스템에서 그 데이터를 사용할 수 있습니다.
데이터들은 하둡과 같은 오프라인 시스템에서 데이터 증가 예측과 같은 장기적인 분석을 위해 사용될 수도 있습니다. 또한 엘라스틱서치나 보안 분석 애플리케이션과 같은 로그 검색 전용 시스템으로 전달될 수 있습니다.
커밋 로그
카프카는 커밋 로그 개념을 기반으로 하므로 데이터베이스의 변경 사항이 카프카 메시지 스트림으로 생성될 수 있습니다.
해당 스트림은 데이터베이스의 변경 사항을 원격 시스템에 복제하는 데 사용되거나 여러 애플리케이션의 변경 데이터를 하나의 데이터베이스 뷰로 통합하는 데 사용될 수 있습니다.
또한 더 오랫동안 데이터를 보존하고자 할 때는 키 하나당 하나의 변경 데이터만 보존하는 압축 로그 토픽을 사용할 수도 있습니다.
스트림 프로세싱
카프카는 real-time processing에 적합합니다.
여러 종류의 애플리케이션에서 스트림 프로세싱(stream processing)을 지원하지만 카프카의 스트림 프로세싱은 메시지가 생성되자마자 실시간으로 데이터를 처리한다는 차이가 있습니다
Reference
