카프카 핵심 가이드 - 01 카프카 시작하기

발행/구독 메시지 전달

카프카에 대해 알아보기 이전에, 발행/구독 메시지 전달의 개념과 데이터 주도 애플리케이션에서의 중요성을 이해해야한다. 간단하게 특징을 설명하자면,

전송자

발행하는 쪽, 데이터를 보낼 때 직접 수신자로 보내지 않는다. 대신 어떤 형태로든 데이터를 분류해 보낸다.

수신자

읽는 쪽, 이렇게 분류된 메시지를 구독한다.

중계자

메시지를 전달받고, 중계해주는 중간 지점 역할을 한다.

초기의 발행/구독 시스템

데이터를 전달하는 애플리케이션과 받는 애플리케이션이 있다고 할 때, 전송자와 수신자가 직접 연결되는 형식으로 해결했다. 이렇게 해결했을때 전송자와 수신자의 수가 적다면 괜찮지만, 이 수가 늘어난다면? 직접 연결되는 선이 너무 많아져 연결을 추적하는 것이 힘들어진다. 이럴 때, 모든 애플리케이션에서 데이터를 받는 하나의 애플리케이션을 만들고, 어느 시스템이든 이 데이터를 조회할 수 있도록 하는 서버를 제공하면 된다. 이것이 메시지 발행/구독 시스템이다.

개별 메시지 큐 시스템

이렇게 만들어진 메시지 발행/구독 시스템을 사용중인 데이터의 종류가 다양하다면, 메시지 발행/구독 시스템은 각 데이터 종류별로 존재하게 될텐데, 시스템 자체는 중복이 된다. 시스템이 중복되면, 버그도 한계도 제각각인 시스템을 유지 관리해야해서 비즈니스가 확장됨에 따라 함께 확장되는, 일반화된 유형의 데이터를 발행하고 구독할 수 있는 중앙 집중화된 시스템이 필요하다.

카프카 입문

아파치 카프카는 위에서 말한 문제를 해결하기 위한 메시지 발행/구독 시스템이다. 분산 커밋 로그, 분산 스트리밍 플랫폼 이라고 불리기도 한다.

카프카의 특징으로는

카프카에 저장된 데이터는 순서를 유지한채로 지속성 있게 보관되며 결정적(deterministic)으로 읽을 수 있다.

확장시 성능을 향상시키고 실패가 발생하더라도, 데이터 사용에는 문제가 없도록 시스템 안에서 데이터를 분산시켜 저장할 수 있다.

결정적(deterministic)으로 읽을 수 있다?

항상 동일한 순서로 메시지를 받을 수 있다는 의미

이제 카프카의 기본 용어와 개념에 대해 알아보자.

메시지와 배치

메시지(Message)

데이터의 기본 단위, 단순한 바이트의 배열로 여기에 포함된 데이터에는 특정한 형식이나 의미가 없다.

데이터베이스의 로우(row)나 레코드(record)와 비슷해 보일 수 있다.

키(Key)라는 메타데이터를 포함할 수 도 있다.

키(Key)

메시지와 같이 의미 없는 바이트의 배열

메시지를 저장할 파티션을 결정하기 위해 사용된다.

키(Key)를 사용해 파티션을 결정하는 방법

1. 키(Key)값에서 일정한 해시값을 생성
2. 생성된 해시값을 토픽이나 파티션의 수로 나눈 나머지 값에 해당하는 파티션에 메시지를 저장

배치(Bacth)

효율성을 위해 메시지를 저장할 때 배치 단위로 저장함

같은 토픽의 파티션에 쓰여지는 메세지들의 집합

배치(Batch)를 사용해 메세지를 저장하면 효율적인 이유

메세지를 쓸 때 마다 네트워크 오버헤드를 발생시키는데, 배치 단위로 모아서 쓰면 줄일 수 있다. 단, 이것은 지연과 처리량 사이에 트레이드오프를 발생(=네트워크 오버헤드는 줄어들지만, 메세지가 전달되는 시간은 증가)시킨다. 더 효율적으로 전송과 저장을 위해 약간의 압축 처리를 하는 경우가 많은데, 이건 이후에 살펴보자.

스키마

카프카 입장에서는 메세지가 단순한 바이트 배열일 뿐이지만, 내용을 이해하기 쉽도록 일정한 구조를 부여하는 것이 권장된다.

사용할 수 있는 스키마로는

• json
• xml
• 에이브로(Avro)

에이브로를 가장 선호하는데, 그 이유는 1. 조밀한 직렬화 형식을 제공하고, 2. 메시지 본체와 스키마를 분리하기 때문에 스키마가 변경되더라도 코드를 생성할 필요가 없다. 또, 3. 강력한 데이터 타이핑과 스키마 변경에 따른 상위, 하위 호환성을 지원한다. 카프카에서는 메시지 쓰기와 읽기 작업을 분리할 수 있도록 하기위해 일관적인 데이터 형식이 중요하다.

토픽과 파티션

토픽(Topic)

메세지를 분류하는 단위

데이터베이스의 테이블(table)이나 파일시스템의 폴더(folder)와 비슷해 보일 수 있다.

토픽에 여러 개의 파티션이 존재할 수 있다.

파티션(Partition)

토픽을 나누는 단위

커밋 로그의 관점으로 돌아가자면, 파티션은 하나의 로그에 해당한다.

파티션이 서로 다른 서버에 저장될 수 있기 때문에, 하나의 토픽이 여러 개의 서버로 확장되어 하나의 서버 용량을 넘어가는 성능을 보여줄 수 있다.

파티션은 복제될 수 있기 때문에, 서로 다른 서버들이 동일한 파티션의 복제본을 저장해 장애를 대응할 수 있다.

스트림(Stream)

하나의 토픽에 저장된 데이터로 간주되며, 프로듀서로부터 컨슈머로 하나의 데이터 흐름을 나타낸다.

프로듀서와 컨슈머

카프카 클라이언트(=이 시스템의 사용자)는 기본적으로 프로듀서와 컨슈머가 있고, 고급 클라이언트 API로는 카프카 커넥트API와 카프카 스트림즈가 있다.

고급 클라이언트들은 프로듀서와 컨슈머를 기본적인 요소로 사용하며, 좀 더 고차원적인 기능을 제공한다.

프로듀서(Producer)

새로운 메시지를 생성, 발행자(Publisher)나 작성자(Writer)라고 불리기도 한다.

메시지를 작성할 때, 파티션 사이에 고르게 나눠서 쓴다.

특정 상황에는 파티셔너(Partitioner)를 이용해, 특정한 파티션을 지정해 메시지를 작성하기도 한다.

컨슈머(Consumer)

메세지를 읽음, 구독자(Subscriber)나 독자(Reader)라고 불리기도 한다.

1개 이상의 토픽을 구독해, 메시지들을 파티션에 쓰여진 순서대로 읽어온다.

컨슈머는 컨슈머 그룹의 일원으로서 작동한다.

오프셋(Offset)

컨슈머는 메시지의 오프셋(offset)을 기록해, 읽은 메시지의 위치를 저장한다.

카프카가 메시지를 저장할 때 메시지에 부여해주는 메타데이터로, 지속적으로 증가하는 정수값으로 모두 고유한 오프값을 가지며 뒤의 메세지가 앞의 메세지보다 더 큰 값을 가진다.

파티션별로 오프셋 값을 저장한다.

컨슈머 그룹(Consumer Group)

하나 이상의 컨슈머로 구성, 토픽에 저장된 데이터를 읽어오기 위해 협업하는 그룹

각 파티션이 하나의 컨슈머에 의해서만 읽히도록 한다.

컨슈머의 파티션 소유권(Ownership)?

컨슈머에서 파티션의로의 대응 관계를 의미

이 방법을 사용해, 토픽을 읽기 위한 컨슈머들을 수평 확장할 수 있고, 그룹 안에 다른 컨슈머들이 장애가 발생한 컨슈머가 읽고 있던 파티션을 재할당 받아 데이터를 읽을 수 있다.

브로커와 클러스터

브로커(Broker)

카프카 서버를 의미한다.

프로듀서로부터 메시지를 전달받아 오프셋을 할당한 뒤 디스크 저장소에 쓴다.

컨슈머의 파티션 읽기 요청은 처리하고 메시지를 보내준다.

하나의 브로커는 초당 수천 개의 파티션과 수백만 개의 메세지를 쉽게 처리할 수 있다.(하드웨어 성능에 차이는 있다.)

브로커에는 토픽에 대해 기본적인 보존 설정이 되어있고, 보존 기능은 기준이 지나면 삭제된다.

클러스터(Cluster)

하나의 클러스터 안에 여러 개의 브로커가 포함될 수 있다.

클러스터 내의 파티션 복제

파티션 리더

클러스터 안의 브로터 중 하나가 담당

파티션의 팔로워

복제된 파티션이 여러 브로커에게 할당될 때, 이 복제 파티션의 브로커

복제 기능

장애 발생시 팔로워 중 하나가 리더 역할을 이어받을 수 있도록 한다.

프로듀서는 리더 브로커에게 메시지를 발행해야 하지만, 컨슈머는 리더와 팔로워 중 하나로부터 데이터를 읽어 올 수 있다.

다중 클러스터

다중 클러스터에 대한 부분은 완벽하게 이해하지 못함, 이후 내용 학습 후 다시 복습하려고 함

설치된 카프카가 확장되어감에 따라 다수의 클러스터를 운용하는 것이 더 나은 경우가 있는데, 아래와 같은 장점이 있다.

• 데이터 유형별 분리
• 보한 요구사항을 충족시키기 위한 격리
• 재해 복구를 대비한 다중 데이터센터

미러메이커(Mirror Maker)

: 데이터를 다른 클러스터로 복제하는데 사용되는 도구

미러메이커를 이용해 두 개의 로컬 클러스터의 메세지를 하나의 집적 클러스터로 모은 뒤 다른 데이터센터로 복사하는 예제

왜 카프카인가?

여러 발행/구독 메시지 전달 시스템에는 여러 가지가 있는데, 카프카의 좋은 이유는 뭐가 있을까?

다중 프로듀서

카프카는 여러 프로듀서를 처리할 수 있다. 다수의 마이크로서비스에서 데이터를 전송해야하는 상황이 있다면, 사용될 수 있다.

다중 컨슈머

또, 카프카는 다중 컨슈머가 어떤 메시지 스트림도 읽을 수 있도록 설계되었다.

타 발행/구독 메시지 전달 시스템은 1개의 메시지를 1개의 클라이언트만 소비할 수 있도록 설계된 것과 비교하면 결정적인 차이점이다.

다수의 카프카 컨슈머는 컨슈머 그룹의 일원으로 작동함으로써 하나의 스트림을 여럿이나 나눠서 읽을 수 있다.

디스크 기반 보존

카프카는 메시지를 지속성있게 저장한다. 그렇기에 컨슈머를 정지하더라도 메시지는 카프카 안에 남아있고, 컨슈머가 다시 시작하면 멈췄던 지점부터 유실 없이 데이터를 처리할 수 있다.

확장성

카프카는 어떠한 크기의 데이터도 쉽게 처리할 수 있다.

카프카 클러스터는 작동 중에도 시스템 전체의 가용성에 영향을 주지 않으면서 확장이 가능하다.

고성능

지금까지 말한 특징들로 인해 고부하 아래에서도 높은 성능을 보여준다.

발행된 메시지가 컨슈머에게 전달될 때까지 1초도 안걸리면서, 모두가 매우 큰 메시지 스트림을 다룰 수 있도록 수평적으로 확장 될 수 있는 것이다.

플랫폼 기능

개발자들이 자주 하는 작업을 쉽게 수행할 수 있도록 해주는 API와 라이브러리가 존재한다.

카프카 커넥트는 소스 데이터 시스템으로부터 카프카로 데이터를 가져오거나 카프카의 데이터를 싱크 시스템으로 보내는 작업을 도와준다.

카프카 스트림즈는 규모 가변성과 내고장성을 갖춘 스트림 처리 애플리케이션을 쉽게 개발할 수 있도록 해준다.

데이터 생태계

아파치 카프카는 데이터 생태계에 있어서 순환 시스템을 제공한다. 모든 클라이언트에 대해 일관된 인터페이스를 제공하면서 다양한 인프라스트럭처 요소들 사이에 메시지를 전달하는 것이다.

이용사례

활동 추적

링크드인에서 처음 의도헀던 카프카의 원래 용도는 사용자 활동 추적으로, 사용자가 활동을 할 때 마다 프론트엔드에서 메시지를 하나 이상의 토픽으로 발행 되도록 하는 것이였다. 이를 통해 풍부한 사용자 경험을 제공하기 위해 다른 작업을 수행할 수 있다.

메시지 교환

메시지 교환하는 데도 사용될 수 있어서 이메일과 같이 사용자에게 알림을 보내야하는 애플리케이션에서 활용할 수 있다.

지표 및 로그 수집

로그 메시지도 같은 방식으로 발행될 수 있으며, elasticsearch와 같은 로그 검색 전용 시스템이나 보안 분석 애플리케이션으로 보내질 수 있다.

커밋 로그

데이터베이스에 가해진 변경점들이 카프카로 발행될 수 있으며, 애플리케이션은 이 스트림을 지켜봄으로써 쉽게 실시간 업데이트를 받아볼 수 있다.

스트림 처리

카프카를 사용하는 모든 경우가 스트림 처리라고 생각될 수 있는데, 이 부분은 이후에 다룬다.

카프카의 기원

링크드인이 직면한 문제

링크드인은 커스텀 수집기와 애플리케이션 지표를 수집하는 시스템, 사용자 활동 정보를 추적하기 위한 시스템이 있었는데, 이 시스템은 간단한 작업조차 사람이 작업하는 등의 자원이 많이 사용되었다. 그래서 이것을 개선하기 위해 ActiveMQ를 사용해 개발했지만, 확장성이 떨어지거나 안정성이 부족한 등의 문제가 있었다.

카프카의 탄생

이후 문제점을 개발하기 위한 메시지 교환 시스템을 개발하기 시작했고, 성공했다. 이것이 카프카였다.

오픈소스

카프카는 2010년말 깃허브에 오픈소스로 공개되었고, 이후 아파치 소프트웨어 재단의 인큐베이터 프로젝트를 거쳐 정식 프로젝트가 되었다. 그리고는 많은 곳에서 사용되고 있다.

상업적 제품

카프카의 초기 개발자는 컨플루언트를 창업했고, 현재는 카프카의 매니지드 서비스를 제공한다.

이름

카프카의 이름은 개발자가 대학생 때 좋아하던 작가의 이름에서 유래되었다.