CHAPTER1. 훑어보기

추천사

<aside> 💡 카프카는 지속적인 데이터의 흐름을 처리하는데 도움을 주기 위해 만들어진 streaming platform 입니다. 데이터 스트림을 쓰고 읽고 저장하고 처리하는 그런 시스템이죠. 카프카는 메시지 스트림을 쓰고 읽게 해주는 메시징 시스템과 같지만 여러 가지 핵심적인 차이가 있습니다. 첫째로 클러스터에서 실행되기 때문에 카프카는 회사의 모든 데이터 스트림 처리를 위해 탄력적으로 확장할 수 있는 중심 플랫폼의 역할을 합니다. 둘째, 카프카는 우리가 원하는 충분한 기간 동안 데이터를 저장하기 위해 만들어진 진정한 스토리지 시스템 입니다. 또한 신뢰성 있는 데이터 전달을 확실히 보장하므로, 카프카를 서로 다른 시스템의 연결 계층으로 사용할 수 있다는 큰 장점을 갖습니다. 끝으로 대부분의 메시징 시스템은 단순히 메시지 전달에만 초점을 두지만 카프카는 훨씬 더 적은 코드를 사용해서 우리 스트림으로부터 파생된 다른 스트림과 데이터세트를 산출할 수 있는 프로세싱 능력이 있습니다.

</aside>

카프카는 실시간 이벤트 스트림 처리를 지향하는 플랫폼의 역할을 합니다.

CHAPTER1. 훑어보기

---

1.1 발행/구독 메시지 전달

발행/구독 메시지 전달 패턴의 특징은 전송자가 데이터를 보낼 때 수신자로 보내지 않는다는 것이다. 대신 전송자는 어떤 형태로든 메시지를 분류해서 보내고 수신자는 이렇게 분류된 메시지를 구독한다. 발행/구독 시스템에는 대개 발행된 메시지를 전달받고 중계해주는 중간 지점 역할을 하는 브로커가 있다.

1.1.1 초기의 발행 구독 시스템

발행자과 구독자가 직접 연결된 아키텍쳐는 연결 추적 및 운영이 어렵다

1.1.2 개별 메시지 큐 시스템

중복 및 버그

1.2 카프카 입문

아파치 카프카는 발행/구독 시스템으로서 ‘분산 커밋 로그’ 혹은 ‘분산 스트리밍 플랫폼’이라고 불리기도 한다.

durable, consistency, deterministic

1.2.1 메시지와 배치

카프카에서 데이터의 기본 단위는 메시지다. (중략) 메시지는 키라 불리는 메타데이터를 포함할 수도 있다. 키를 해시값으로 생성하여 토픽의 파티션 수로 나눴을 때 나오는 나머지 값에 해당하는 파티션에 메시지를 저장하면 같은 키 값을 가진 메시지는 항상 같은 파티션에 저장할 수 있다.

카프카는 효율성을 위해 메시지를 배치 단위로 저장한다. 배치는 그저 같은 토픽의 파티션에 쓰여지는 메시지들의 집합일 뿐이다. 네트워크 비용을 줄일 수 있으나 latency 과 throughput 사이에 트레이드오프를 발생시킨다.

1.2.2 스키마

카프카 입장에서 메시지는 단순한 바이트 배열일 뿐이지만, 내용을 이해하기 쉽도록 일정한 구조를 부여하는 것이 권장된다. 각 애플리케이션의 필요에 따라 사용 가능한 메시지 스키마에는 여러 가지가 있는데 JSON, XML이 있다. 그러나 아파치 Avro를 사용하여 조밀한 직렬화 형식을 제공하는 데다 메시지 본체와 스키마를 분리하기 때문에 스키마가 변경되더라도 코드를 생성할 필요가 없다. 강력한 데이터 타이핑과 스키마 변경에 따른 상위 호환성, 하위 호환성 역시 지원한다.

카프카에서는 일관적인 데이터 형식이 중요하다. 메시지 쓰기와 읽기 작업을 분리할 수 있도록 해주기 때문이다. (중략) 잘 정의된 스키마를 공유저장소에 저장함으로써 카프카는 두 버전 형식을 동시에 지원하도록 하는 작업 없이도 메시지를 처리할 수 있다.

1.2.3 토픽과 파티션

카프카에 저장된느 메시지는 토픽단위로 분류된다. 토픽과 가장 비슷한 개념으로는 데이터베이스의 테이블이나 파일시스템의 폴더가 있을 것이다. 토픽은 다시 여러 개의 파티션으로 나뉘어진다. (중략) 파티션은 카프카가 데이터 중복과 확장성을 제공하는 방법이기도 하다.

카프카와 같은 시스템을 이야기할 때면 ‘스트림’이라는 용어가 자주 사용된다. 대부분의 경우 스트림은 하나의 토픽에 저장된 데이터로 간주되며, producer로부터 consumer로의 하나의 데이터 흐름을 나타낸다.

1.2.4 프로듀서와 컨슈머

카프카 클라이언트는 이 시스템의 사용자이며, 기본적으로 프로듀서와 컨슈머의 두 종류가 있다. 좀 더 고급 클라이언트 API도 있는데, 데이터 통합에 사용되는 카프카 커넥트 API와 스트림 처리에 사용되는 카프카 스트림즈가 그것이다. 이 고급 클라이언트들은 프로듀서와 컨슈머를 기본적인 요소로서 사용하며, 좀 . 더고차원적인 기능을 제공한다.

프로듀서는 새로운 메시지를 발행하며 메시지는 특정한 토픽에 쓰여지고 토픽의 파티션들에 고르게 나눠서 쓰도록 되어 있지만 파티셔너를 사용해서 일부에만 저장하기도 한다.

컨슈머는 메시지를 읽는다. 1개 이상의 토픽을 구독해서 여기에 저장된 메시지들을 각 파티션에 쓰여진 순서대로 읽어 온다. 컨슈머는 offset을 통해 어느 메시지까지 읽었는지를 유지한다.

컨슈머는 컨슈머그룹의 일원으로 작동한다. 컨슈머 그룹은 토픽에 저장된 데이터를 읽어오기 위해 협업하는 하나 이상의 컨슈머로 이루어진다. 컨슈머 그룹은 각 파티션이 하나의 컨슈머에 의해서만 읽히도록 한다. 컨슈머 중 둘은 각각 하나의 파티션만 읽어서 처리하는 반면, 마지막 하나는 두 개의 파티션을 읽어온다. 컨슈머에서 파티션으로 대응 관계는 컨슈머의 파티션 소유권이라고 부른다.

1.2.5 브로커와 클러스터

하나의 카프카 서버를 브로커라고 부른다. 브로커는 프로듀서로부터 메시지를 전달받아 오프셋을 할당한 뒤 디스크 저장소에 쓴다. 브로커는 컨슈머의 파티션 읽기 fetch 요청 역시 처리하고 발행된 메시지를 보내준다.

카프카 브로커는 클러스터의 일부로서 작동하도록 설계되었다. 하나의 클러스터 안에 여러 개의 브로커가 포함될 수 있으며, 그 중 하나의 브로커가 클러스터 컨트롤러의 역할을 하게 된다.(컨트롤러는 클러스터 안의 현재 작동중인 브로커 중 하나가 자동으로 선정된다). 컨트롤러는 파티션을 브로커에 할당해주거나 장애가 발생한 브로커를 모니터링하는 등의 관리 기능을 담당한다. 파티션은 클러스터 안의 브로커 중 하나가 담당하며, 그 브로커를 ***파티션 리더(partition leader)***라고 부른다. 복제된 파티션이 여러 브로커에 할당될 수도 있는데 이것들은 ***파티션의 팔로워(follower)***라고 부른다. 모든 프로듀서는 리더 브로커에 메시지를 발행해야 하지만, 컨슈머는 리더나 팔로워 중 하나로부터 데이터를 읽어올 수 있다.

카프카의 핵심 기능 중에 일정 기간 동안 메시지를 지속성(durability)있게 보관하는 보존retention 기능이 있다. 특정 기간동안 메시지를 보관하거나 파티션의 크기가 특정 사이즈에 도달할 때까지 데이터를 보존한다. (중략) 토픽에는 로그 압착(log compaction) 기능을 설정할 수도 있는데, 이 경우 같은 키를 갖는 메시지 중 가장 최신의 것만 보존된다. 이 기능은 마지막 변경값만이 중요한 체인지로그 형태의 데이터에 사용하면 좋다.

1.2.6 다중 클러스터

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

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

(중략) 카프카 클러스터의 복제 메커니즘은 다중 클러스터 사이에서가 아닌 하나의 클러스터 안에서만 작동하도록 설계되었다. 카프카 프로젝트는 데이터를 다른 클러스터로 복제하는 데 사용되는 미러메이커(MirrorMaker)라는 툴을 포함한다. 근본적으로 미러메이커도 단지 큐로 연결된 카프카 컨슈머와 프로듀서에 불과하다. 하나의 카프카 클러스터에서 메시지를 읽어와서 다른 클러스터에 쓴다.

1.3 왜 카프카인가?

1.3.1 다중 프로듀서

카프카는 자연스럽게 여러 프로듀서를 처리할 수 있다.

1.3.2 다중 컨슈머

카프카는 많은 컨슈머가 상호 간섭 없이 어떠한 메시지 스트림도 읽을 수 있도록 설계되었다.

1.3.3 디스크 기반 보존

메시지를 지속성 있게 저장할 수 있다

1.3.4 확장성

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

1.3.5 고성능

발행된 메시지가 컨슈머에게 전달될 때까지 1초도 안 걸림

1.3.6 플랫폼 기능

카프카 커넥트, 카프카 스트림스

1.4 데이터 생태계

모든 클라이언트에 대해 일관된 인터페이스를 제공, 프로듀서는 누가 데이터를 사용하는지, 컨슈머 애플리케이션이 몇 개인지와 같은 것에 신경 쓸 필요가 없다.

1.4.1 이용 사례

• 활동 추적
• 메시지 교환
  • 같은 룩앤필을 사용해서 메시지를 formatting 혹은 decorating 해 준다.
  • 여러 개의 메시지를 모아서 하나의 알림 메시지로 전송한다.
  • 사용자가 원하는 메시지 수신 방식을 적용한다.
• 지표 및 로그 수집
  • ELK
• 커밋 로그
  • change-log, log-comapction
• 스트림 처리
  • 하둡은 누적된 오래된 스트림 데이터를 처리, 카프카는 실시간 스트림 데이터 처리

1.5 카프카의 기원

카프카는 링크드인 내부에서의 데이터 파이프라 문제를 해결하기 위해 개발되었다. 카프카는 다양한 종류의 데이터를 다루고 고성능 메시지 교환 시스템 역할을 할 수 있도록 설계되었다.

1.5.1 링크드인이 직면한 문제

(중략) .. 처음에 개발팀은 데이터에 실시간으로 접근할 수 있도록 해주면서도 필요한 만큼의 메시지 트래픽을 처리할 수 있을 정도로 scale-out이 가능한 새로운 시스템을 찾기 위해 이미 나와 있는 오픈소스 솔루션들을 면밀하게 조사했다. ActiveMQ는 확장성이 떨어지고 브로커를 정지시킬 수 있는 결함들이 많았다. 결론은 데이터 파이프라인을 구축하기 위한 커스텀 인프라스트럭처를 자체 개발하는 것이었다.

1.5.2 카프카의 탄생

모니터링 시스템과 사용자 추적 시스템의 요구 조건을 모두 만족시킬 수 있으며 추후 확장도 가능한 메시지 교환 시스템을 개발하기 시작했다.

• 푸시-풀 모델을 사용함으로써 프로듀서와 컨슈머를 분리한다.
• 다수의 컨슈머가 사용할 수 있도록 메시지 교환 시스템의 데이터를 영속적으로 저장한다.
• 높은 메시지 처리량을 보일 수 있도록 최적화한다.
• 데이터 스트림의 양이 증가함에 따라 시스템을 수평 확장할 수 있도록 한다.

메시지 직렬화를 위해 아파치 Avro와 함께 사용되면서 많은 메시지를 처리하고 있다

1.5.3 오픈소스

• 2010년말에 깃헙에 공개
• 2011년 7월 아파치 인큐베이터 프로젝트
• 2012년 10월 아파치 정식 프로젝트

1.5.4 상업적 제품

• 클라우드를 통한 카프카 메니지드 서비스 제공

1.5.5 이름

• 유래? 프란츠 카프카

1.6 카프카 시작하기