대신 발행자가 어떤 형태로든 메시지를 구분해서 발행/구독 시스템에 전송하면 구독자가 특정 부류의 메시지를 구독할 수 있게 해준다.
이 때 발행된 메시지를 저장하고 중계하는 역할을 브로커가 수행한다
초기의 발행/구독 시스템
간단한 메시지 큐나 프로세스 간 통신 채널을 갖는 형태
발행자와 구독자가 직접 연결되기 때문에 복잡하게 연결 될 수 있음
위와 같은 아키텍쳐는 개선이 필요함. 모든 어플리케이션의 메트릭을 하나의 어플리케이션이 수신하게 하고, 하나의 서버로 제공하면 해당 메트릭이 필요한 어떤 시스템에서도 쉽게 조회할 수 있음
개별적인 메시지 큐 시스템
과거 TV스토어와 비슷함
카프카 살펴보기
분산 커밋 로그 또는 분산 스트리밍 플랫폼이라고 함
파일 시스템이나 데이터베이스의 커밋로그는 시스템의 상태를 일관성 있게 유지할 수 있도록 모든 트랜잭션을 지속적으로 기록하는 기능을 제공한다.
시스템 장애에 대비하고 확장에 따른 성능 저하를 방지하기 위해 데이터가 분산 처리 될 수 있음
메시지와 배치
메시지 : 데이터의 기본단위 (db의 row, record)
배치 : 여러개의 메시지를 모아 배치 형태로 파티션에 수록, 네트워크로 부터 매번 각 메시지를 받아서 처리하는데 따른 부담을 줄일 수 있음
스키마 : 단순 바이트 배열로 처리하지만 스키마도 사용할 수 있음
XML
JSON : 일반로그 저장시 json으로 serialize하고 있음
AVRO 지원 : 통합 log 저장시 flume avro event로 저장 함
custom avro 사용할 경우 repository에 저장하여 사용할 수 있다. (현재 구축은 안되어 있음)
토픽과 파티션
토픽 : 데이터베이스 테이블이나 파일 시스템의 폴더와 유사, 하나의 토픽은 여러 개의 파티션으로 구성될 수 있다.
대게 하나의 토픽은 여러개의 파티션을 갖는다. 메시지 처리는 토픽이 아닌 파티션별로 유지 관리 됨
하나의 토픽이 여러 서버에 걸쳐 수평적으로 확장 될 수 있음을 의미 -> 성능이 우수
스트림 : 스트림은 파티션의 개수와 상관없이 하나의 토픽 데이터로 간주되며, 데이터를 쓰는 프로듀서로 부터 데이터를 읽는 컨슈머로 이동되는 연속적인 데이터를 나타냄.
프로듀서와 컨슈머
카프카의 클라이언트는 시스템의 사용자이며 기본적으로 프로듀서와 컨슈머라는 두가지 형태가 있다.
Kafka Connect API, Kafka Streams client API도 있음
프로듀서
새로운 메시지를 생성, 다른 발행/구독 시스템에서는 프로듀서를 발행자 또는 작성자 라고도 한다.
메시지는 특정 토픽으로 생성, 프로듀서는 메시지가 어떤 파티션에 수록되는지 관여하지 않는다.
특정파티션에 메시지를 직접 쓸수도 있다. (메시지 키와 파티셔너를 이용, 파티셔너는 키의 해시값을 생성하고 그것을 특정 파티션에 대응시켜 항상 특정 키가 같은 파티션에 수록되게 해준다)
컨슈머
메시지를 읽으며, 다른 발행/구독 시스템에서는 구독자 또는 독자라고 한다.
하나이상의 토픽을 구독하여 메시지가 생성된 순서로 읽으며, 메시지의 오프셋을 유지하여 읽는 메시지의 위치를 알 수 있다.
오프셋은 지속적으로 증가하는 정숫값이며, 메시지가 생성될 때 카프카카 추가해줌
주키퍼나 카프카에서는 각 파티션에서 마지막에 읽은 메시지의 오프셋을 저장하고 읽으므로 컨슈머가 메시지 읽기를 중단했다가 다시 시작하더라도 언제든 그 다음부터 읽을 수 있다.
컨슈머 그룹
컨슈머 그룹은 하나 이상의 컨슈머로 구성되며, 한 토픽을 소비하기위해 같은 그룹의 여러 컨슈머가 함께 동작한다.
한 토픽의 각 파티션은 하나의 컨슈머만 소비 할 수 있다.
컨슈머가 각 파티션을 소비, 특정파티션에 대응 되는 것을 파티션 소유권 (ownership)이라고 한다.
이를 가지고 컨슈머를 수평적으로 확장 할 수 있다. 한 컨슈머가 자신의 파티션 메시지를 읽는 데 실패하더라도 같은 그룹의 다른 컨슈머가 파티션 소유권을 재조정 받은 후 실패한 컨슈머의 파티션 메시지를 대신 읽을 수 있다.
브로커와 클러스터
하나의 카프카 서버를 브로커라고 한다.
브로커는 프로듀서로부터 메시지를 수신하고 오프셋을 지정한 후 해당메시지를 디스크에 저장한다.
컨슈머의 파티션 읽기 요청에 응답하고 디스크에 수록된 메시지를 전송
하나의 브로커는 초당 수천개의 토픽과 수백만 개의 메시지를 처리할 수 있음
카프카의 브로커는 클러스터의 일부로 동작하도록 설계되었다.
여러개의 브로커가 하나의 클러스터에 포함될 수 있으며, 하나는 자동으로 선정되는 클러스터 컨트롤러 기능 수행.
컨트롤러
같은 클러스터의 각 브로커에게 담당 파티션을 할당 하고 브로커들이 정상적으로 동작하는지 모니터링하는 관리 기능을 맡는다.
각 파티션은 클러스터의 한 브로커가 소유하며, 그 브로커를 파티션 리더(leader)리고 한댜 또한, 같은 파티션이 여러 브로커에 지정될 수도 있는데, 이때는 해당 파티션이 복제(replication)된다 이 경우 해당 파티션의 메시지는 중복으로 저장되지만, 관련 브로커에 장애가 생기면 다른 브로커 가 소유권을 인계받아 그 파티션을 처리할 수 있다
보존(retention)
일정기간 메시지를 보존
브로커는 기본적으로 토픽 보존 설정을 하도록 구성 (보통 7일정도)
로그량이 많은 경우 일정 기간 메시지를 보존하거나 지정된 토픽 크기가 될때까지 보존가능
log compacted 경우 같은 키를 같은 메시지들은 가장 최신 것만 보존 됨. 마지막으로 변겨된 것이 중요한 로그데이터에 유용함
다중클러스터
카프카가 많이 설치되어 사용될 때 다중 클러스터를 고려하면 다음과 같은 장점이 있다
데이터 타입에 따라 구분해서 처리할 수 있음
보안 요구사항을 분리해서 처리할 수 있음
재해 복구를 대비한 다중 데이터센터를 유지할 수 있음
카프카를 사용하는이유
다중 프로듀서 : 여러 클라이언트가 많은 토픽을 사용하거나 같은 토픽을 같이 사용해도 카프카는 무리없이 많은 프로듀서 메시지 처리 가능
다중 컨슈머 : 많은 컨슈머가 상호간섭 없이 어떤 메시지 스트림도 읽을 수 있도록 지원
디스크 기반의 보존 : 지속해서 메시지 보존 가능, 항상 실시간으로 실행되지 않아도 됨. 데이터 유실 위험이 없다. 컨슈머가 일정기간 동작하지 않아도 메시지는 카프카에 보존되므로 메시지 백업 필요없음, 컨슈머의 유지보수도 자유롭게 수행가능
확장성 : 어떤 크기의 데이터도 처리가능, 처음에는 소규모 클러스터 -> 트래픽이 많아 질때 대규모 클러스터로 업무용 환경 구축, 동시에 여러 브로커에 장애가 생겨도 정상적으로 처리할 수있는 replication facor를 더 큰값으로 지정하여 구성가능
고성능 : 위의 장점을 합쳐 고성능 메시지 발행/구독 시스템으로 만들어줌
데이터 생태계
모든 클라이언트에 대해 일관된 인터페이스를 제공하면서 데이터 기반 구조의 다양한 멤버간에 메시지를 전달
이용사례
활동추적
메시지 전송
메트릭과 로깅
커밋로그
스트림 프로세싱
카프카의 기원
링크드인에서 데이터 파이프라인 문제를 해결하기 위해 개발됨. 고 성능의 메시징 시스템을 제공하도록 설계됨.