메세지 발행과 구독하기
메세지 발행/구독 시스템에서는 데이터를 발행자가 구독자에게 직접 보내지 않는다.
대신 메세지를 구분해서 발행구독 시스템 에게 보내면 구독자가 특정 메세지를 구독 하게 된다.
발행된 메세지를 저장하고 중계하는 역할을 브로커라고 한다.
초기의 발행 구독 시스템의 발전과정
phase 1 초기 프론트엔드 서버에서 대시보드를 보여주는 메트릭 서버로 직접 데이터를 밀어 주는 방식 단순하기 때문에문제가 없다
phase 2 데시보드를 보여주는 서버 이외에 데이터 분석 서버등 데이터를 수신받기 위한 서버 요구가 추가 된다면 아래와 같이 아키텍쳐가 복잡해지고 운영에 문제가 생긴다.
phase 3 모든 어플리케이션의 메트릭을 하나의 애플리케이션이 수신하게 하고 하나의 서버로 제공하면 어떤 시스템에서도 쉽게 조회가 가능해진다.
phase 4 이러한 발행 구독 서비스는 매트릭 뿐만 아니라 로그메세지, 유저 행동 추적 메세지 등 의 브로커 역할을 할 수 있다.
하지만 여전히 시스템 종류에 따라 다른 메세지 처리 시스템을 운영해야 하므로 한계가 있다.
이것을 일반화된 유형의 메세지 데이터를 구독/발행하는 하나의 집중 처리 시스템을 만들면 유연성과 확장성 모두 좋아질 것이다. → 따라서 kafka 다!
카프카 살펴보기
위와 같은 이유로 카프카가 설계되었다
카프카는 분산커밋로그 혹은 분산 스트리밍 플랫폼이라고 한다.
→ FS나 DB 처럼 트랜잭션을 지속적으로 기록하는 커밋로그 기능 제공
→ 시스템 장애, 성능저하에 대비하여 데이터 분산 처리가 가능
메세지와 배치
카프카에서의 데이터 기본단위 : 메세지 == row == record
카프카는 메세지를 항상 바이트 단위의 배열로 간주하며, 특정 형식과 타입이 없다.
메세지의 구조 : 바이트 단위 배열, 형식 타입, *키 포함 가능
*키 : 카프카의 메세지에 메타데이터로써 키 포함 가능
키는 토픽내에 어떤 파티션에 수록될 것인지 결정
같은 키는 같은 파티션에 수록된다.
카프카는 데이터 전송의 효율성을 위해 여러 메세지를 모아 배치 처리를 한다.
이 경우 처리량과 대기시간 사이에 트레이드 오프가 발생한다. 즉, 배치의 크기가 클 수록 처리량이 늘어나지만, 개별 메세지의 대기시간은 길어진다.
스키마
카프카는 바이트 배열 단위로 메세지를 처리하지만, 이해하기 쉽도록 메세지의 구조를 나타내는 스키마(JSON, XML)를 사용할 수 있다.
직렬화를 위해 카프카 개발자들은 Avro를 선호한다. avro 는 JSON, XML 대비 강력한 데이터 타입 지원, 메세지와 별도로 스키마를 유지 관리 하므로 스키마 버전간 호환성을 제공 한다.
스키마 레지스트리에 id와 함께 스키마 버전들이 정해져 있고 애플리케이션은 그 id를 가지고 스키마 적용한다. (챕터3 내용)
토픽과 파티션
- 카프카의 메세지는 토픽으로 분류됨 (= DB의 테이블, FS의 폴더)
- 하나의 토픽은 여러개의 파티션으로 구성될 수 있다.
- 메세지는 파티션에 추가되는 형태로만 수록된다.
- 맨앞에서 끝까지 순서대로 읽힌다.
- 메세지 처리 순서는 토픽이 아닌 파티션 별로 유지 관리된다.
- 아래 그림처럼 메세지는 파티션의 끝에 수록된다.
- 파티션은 서로 다른 서버에 분산될 수 있다.
스트림
스트림은 파티션의 개수와 상관없이 하나의 토픽 데이터로 간주된다.
스트림은 데이터를 쓰는 프로듀서로부터 데이터를 읽는 컨슈머로 이동되는 연속적인 데이터를 나타낸다.
오프라인에서 데이터를 처리하도록 설계된 하둡과 다르게 카프카 스트림즈는 프레임워크에서 실시간으로 메세지를 처리하는데 주로 사용되는 방법이다. (스트림은 챕터 11 내용)
프로듀서와 컨슈머
프로듀서
새로운 메세지를 생성 메세지는 특정 토픽으로 생성,
기본적으로 어느 파티션에 수록되는지는 관여하지않음 그러나 때로는 프로듀서가 특정 파티션에 직접 쓰는 경우도 있음 이때는 메세지 키와 *파티셔너를 사용한다.
*파티셔너 : 키의 해시 값을 생성하고 그것을 특정 파티션에 대응 시킴으로써 지정된 키를 갖는 메시지가 항상 같은 파티션에 수록되게 해준다.
컨슈머
메세지를 읽는다.
컨슈머는 하나이상의 토픽을 구독하여 메세지가 생성된 순서로 읽는다.
메세지의 *오프셋을 유지하여 읽는 메세지의 위치를 알 수 있다.
컨슈머는 *컨슈머 그룹의 멤버로 동작한다.
오프셋
메타데이터인 오프셋은 지속적으로 증가하는 정수 값이다.메세지가 생성될 때 카프카가 추가해준다. 파티션 내에 메세지들은 고유의 오프셋을 갖는다.
주키퍼나 카프카에서는 각 파티션의 마지막 읽은 오프셋 값을 저장하고 있으므로 컨슈머가 메세지 읽기를 중단했다가 다시 시작하더라도 언제든 그 다음 메세지부터 읽을 수 있다.
컨슈머 그룹
컨슈머 그룹은 하나 이상의 컨슈머로 구성된다. (컨슈머그룹은 ch 4 )
한 토픽을 소비하기 위해 같은 그룹의 여러 컨슈머가 함께 동작한다.
한 토픽의 각 파티션은 하나의 컨슈머만 소비할 수 있다.
각 컨슈머가 특정 파티션에 대응 되는 것을 파티션 소유권(ownership)이라고 한다. (컨슈머 1은 파티션1과 파티션2의 소유권을 가지고 있다.)
컨슈머 그룹을 통해 토픽 내 대량의 메세지를 소비하기 위한 컨슈머를 수평 확장할 수 있으며, 실패한 컨슈머 발생시 리밸런싱(파티션 소유권 재조정)을 통해 실패한 컨슈머의 메세지를 대신 읽을 수 있다.
*컨슈머가 하나일 경우 파티션이 여려개 여도 순서 보장이 될까 → NO
브로커와 클러스터
브로커 : 하나의 카프카 서버를 브로커라고 한다.
-브로커는 프로듀서로부터 메세지를 수신하고 오프셋을 지정한 후 해당 메시지를 디스크에 저장한다. 또한, 컨슈머의 파티션 읽기 요청에 응답하고 디스크에 수록된 메세지를 전송한다.
-클러스터의 여러 브로커 중 선정되는 하나는 클러스터 *컨트롤러의 기능을 수행한다.
*컨트롤러 : 같은 클러스터의 각 브로커에게 담당 파티션을 할당 및 브로커들이 정상적으로 동작하는지 모니터링 한다.
-각 파티션은 하나의 브로커가 소유하며, 그 브로커를 파티션 리더(leader)라고 한다.
-같은 파티션이 여러 브로커에 할당될 수도 있는데 이때는 파티션이 복제(replication) 된다. 이 경우 파티션의 메세지는 중복 저장되지만 관련 브로커에 문제가 생기면 다른 브로커가 인계받아 그 파티션을 처리할 수 있다.
-각 파티션을 사용하는 모든 컨슈머와 프로듀서는 파티션 리더에 연결해야 한다. (파티션 복제 등의 클러스터링은 6장)
*리텐션 : 이것은 일정 기간 동안 메세지를 보존하는 것이다. 카프카 브로커는 기본적으로 토픽의 보존설정을 하도록 구성되는데, 일정기간의 메세지들을 보존하도록 설정하거나, 지정된 용량만큼만 보존하도록 설정할 수 있다. 한도에 도달하면 만료 메세지들이 삭제된다. 또한 토픽마다 다르게 리텐션을 설정할 수 도 있다. 압축로그 설정을 할 경우에는 키를 갖는 메세지들은 가장 최신 것만 보존된다.
다중 클러스터
다중 클러스터 카프카를 구현하면 다음과 같은 장점이 있다.
-데이터 타입에 따라 구분해서 처리할 수 있음
-보안 요구사항을 분리하여 처리할 수 있음
-재해복구 대비 다중 IDC 유지 가능
다중 클러스터를 구현하기 위해서 메세지가 데이터센터 간에 복제되어야 한다. 카프카 클러스터의 리플리케이션은 단일 클러스터내에서만 사용가능 하므로 이를 위해서 미러메이커 라는 도구가 포함되어 있다.
미러메이커
-근본적으로는 미러메이커도 컨슈머와 프로듀서임
-각 미러메이커는 큐로 상호연결된다.
-하나의 카프카 클러스터에서 소비된 메세지를 다른 클러스터에서도 사용할 수 있도록 생성해준다.
-아래는 미러메이커를 사용하는 데이터 센터 아키텍처의 예를 보여준다.
다중 데이터센터 아케텍쳐
분석 → 책에는 디테일하게 안나와있지만 유추해본 바로는 DC A와 DC B 는 로컬 망에서 P/C 가 일어나고 이를 어그리게이트 카프카가 복제하여 들고 있으며, DC C 에서는 A,B 에서 만들어낸 어크리게이트 카프카를 컨슈밍 해가는 구조이다 (아마 로컬망이 아닌듯?)
카프카를 사용하는 이유
다중 프로듀서
많은 토픽을 사용하거나 토픽을 같이 사용해도 카프카는 무리없이 처리할 수 있다.
(ex. MSA 어플리케이션의 여러 프론트 페이지에서 정의한 page view 를 하나의 토픽으로 받아 하나의 스트림으로 처리할 수 있다.)
다중 컨슈머
많은 컨슈머가 상호간섭 없이 어떤 메세지 스트림도 읽을 수 있게 지원한다. 일반 큐 시스템과는 다르게 한 클라이언트가 메세지를 소비해도 다른 컨슈머가 메세지를 컨슘할 수 있다.
또한, 컨슈머 그룹의 멤버가 되면 메세지 스트림을 공유할 수 있다.
디스크 기반의 보존
→ 카프카는 메세지 처리 뿐 아니라 지속해서 메세지를 보관할 수 있다.(memory가 아닌 disk) 따라서 컨슈머 어플리케이션이 항상 실시간으로 실행되지 않아도 된다.
→ 토픽마다 리텐션 옵션이 있어, 컨슈머의 요구에 맞게 각각 보관기간을 설정할 수 있다.
→ 메세지 유실 위험, 유지보수가 쉽다.
확장성(scalable)
→ 카프카는 워크로드의 규모에 따라 브로커를 확장하는 것이 쉽다. 10개에서 수백개까지 쉬운 확장이 가능하다.
→ 확장작업은 온라인상태에서도 무중단으로 가능하다.
→ 장애가 생겨도 정산적으로 처리할 수 있는 복제본 구성도 구성할 수 있다.
고성능
위의 장점들이 합해져서 카프카를 고성능으로 만들어준다고 함......? 프로듀싱/컨슈밍 이 대용량 메세지 스트림을 쉽게 처리할 수 있게 하고 sclable 도 1초 미만의 짦은 시간에 가능하다.
데이터 생태계
카프카는 데이터 생태계의 순환시스템을 제공한다.
클라이언트 간에 일관된 인터페이스 제공으로 프로듀서와 컨슈머 간에 디커플링을 구현하므로 새로운 비즈니스가 생기거나 없어질 때 컴포넌트만 추가하거나 제거 하기만 하면된다.
프로듀서는 또한 컨슈머의 어플리케이션이 몇개인지 신경쓰지 않아도 된다.
이용사례
활동추적
웹페이지의 프론트 페이지에 유저가 접속하여 행하는 액션 (페이지 이동 or click) 에 대한 메세지를 추적하는 애플리케이션이 돌고있고, 이러한 것이 하나이상의 토픽으로 생성되어 카프카에 저장된 후 백엔드 어플리케이션에서 소비된다. (ex. 리포트 생성, 머신러닝 트레이닝 데이터셋, UX 제공 등)
메세지 전송
카프카는 또한 메세지를 전송하는데에 사용될 수 있으므로 알림메세지 전송 하는 어플리케이션(이메일 등)에 유용하다.
→ 같은 룩앤필을 사용해서 메세지 형식을 만든다
→ 여러 어플리케이션의 메세지들을 하나의 알림 메세지로 전송하기 위해 합친다.
→ 사용자가 원하는 메세지 수신방법을 적용한다.
하나의 메세지 애플리케이션에서 구현하면 각 애플리케이션에서 똑같은 기능을 구현하지 않아도 되며(high cohesion), 메세지 집중처리( ?) 와 같은 기능도 수행 가능
메트릭과 로깅
카프카는 애플리케이션의 메트릭과 로그데이터를 모으는 데 이상적이다.
여러 애플리케이션에서 같은 타입의 메세지를 생성하는 대표적인 이용사례.
각 애플리케이션에서 정기적으로 메트릭을 생성하여 카프카 토픽으로 저장한 후 모니터링이나 보안 시스템에서 활용할 수 있다.
또한 하둡에서 데이터 증가 예측 같은 장기적인 분석을 위해 사용될 수 있다.
로그 메세지는 ES 같은 로그검색 전용시스템으로 전달될 수 있다.
이외에도 컨슈머쪽에 특정 시스템을 변경해야 할 때에도 프론트엔드 애플리케이션이나, 메세지 수집 방법을 변경할 필요 없다.
커밋로그 : 데이터가 변경됭 사항을 로그메세지로 모아둔 것
카프카는 데이터베이스의 변경사항을 카프카 스트림으로 생성할 수 있다.
change log stream 이라고 하며, 변경데이터를 하나의 데이터베이스 뷰로 통합하거나 원격 시스템에 복제하는 데 사용할 수 있다.
스트림 프로세싱 (카프카 스트림 ch 11)
→ 여러 종류의 애플리케이션에서 스트림 프로세싱을 지원한다. 일반적으로 하둡의 맵리듀스처리와 유사한 기능을 제공하는 애플리케이션에 활용된다. 하둡은 긴시간 적재된 데이터를 쓰지만, 스트림 프로세싱은 메세지가 생성되자마자 실시간으로 데이터를 처리한다는 점이 다르다.
→ 스트림 프로세싱을 하는 프레임워크에서는 작은 크기의 어플리케이션을 기능별로 여러개 작성하여 카프카 메세지를 처리할 수 있다.
Referances
싸니까 믿으니까 인터파크도서
데이터를 처리하기 위해 구축한 환경에는 많은 애플리케이션이 있다. 그리고 데이터를 생성하는 애플리케이션에 맞춰 입력 형식이 정의되며, 메트릭, 리포트 등으로 출력 형태가 정의된다. 또
book.interpark.com
싸니까 믿으니까 인터파크도서
※ 코로나19로 인한 항공편 감소로 해외주문원서의 배송이 평소보다 최대 일주일 정도 지연될 수 있으니 주문에 참고 부탁드립니다. 감사합니다. ※ 미국 내 코로나19 확산으로 특정 상품에 한해
book.interpark.com
'일 > kafka' 카테고리의 다른 글
| 카프카 프로듀서 (0) | 2021.09.26 |
|---|---|
| Kafka 리밸런싱 리스너 동작 test (0) | 2021.09.04 |
| Kafka 성능측정 툴 (0) | 2021.09.04 |
| Kafka consumer 개발 (0) | 2021.09.04 |
| Kafka Consumer 개념 :: 컨슈머, 컨슈머그룹, 리밸런싱 (0) | 2021.08.28 |
