Maru's Study Memo

[ 컨슈머 ]

컨슈머는 파티션에서 레코드를 가져와(Subscribe) 데이터를 처리할 수 있습니다.

컨슈머를 역할에 따라 묶은 것을 컨슈머 그룹이라고 부릅니다. 컨슈머 그룹에는 1개 이상의 컨슈머가 있어야 합니다.

컨슈머 그룹은 아래와 같이 어떤 특정 토픽에 대해 데이터를 병렬 처리할 수 있습니다.

단, 아래와 같이 컨슈머가 파티션의 개수보다 많다고 해도 파티션은 최대 하나의 컨슈머에 할당 가능합니다.

[ 목적에 따른 컨슈머 그룹 ]

서로 다른 역할에 따라 컨슈머 그룹을 나누고 데이터를 처리하면, 커플링 약하게 동일한 데이터를 여러 번 처리할 수 있습니다. 둘중 하나의 컨슈머 그룹의 장애가 생기더라도 나머지 컨슈머 그룹이 영향 없이 데이터를 처리할 수 있는 것입니다.
** 엘라스틱 서치는 시간 순서대로 데이터를 검색하던가, 문자열 데이터로 데이터를 검색할 때 사용
** 하둡 적내는 데이터를 오랜 기간 안전하게 적재하기 위한 용도로 사용

[ 컨슈머의 오프셋 커밋 ]

컨슈머는 오프셋 커밋을 통해서 데이터를 어디까지 처리했는지 저장합니다. 예를들어 컨슈머가 파티션#0의 1번 오프셋 레코드를 처리 완료하면, 컨슈머는 "커밋"이라는 명령어를 통해 1번까지 처리했고, 다음 처리할 레코드는 2번이라는 것을 알 수 있습니다. 그리고 2번 오프셋 레코드를 처리하는 도중 이슈가 발생하면, 마지막 커밋이 된 오프셋이 1번임을 보고 2번 레코드부터 다시 처리를 시작합니다.

그러므로 컨슈머를 구현할 때에는 정말로 데이터 처리가 완료되었을 때에 오프셋 커밋을 해야 데이터의 유실 없이 안전하게 처리할 수 있습니다.

[ 어느 오프셋부터 가져갈까? ]

** 기본 설정은 auto.offset.reset = latest
  . 가장 최신 오프셋의 레코드부터 가져감
  . 컨슈머는 파티션#0의 5번 오프셋 레코드, 파티션#1의 3번 오프셋 레코드 부터 가져감
감

** auto.offset.reset = earlist 로 설정하면
  . 각 파티션의 오프셋 중 가장 낮은 숫자부터 가져감
  . 컨슈머는 파티션#0의 0번 오프셋 레코드, 파티션#1의 0번 오프셋 레코드 부터 가져감

이미 데이터들이 토픽에 들어와 있는 상태에서, 새로운 컨슈머를 실행시킨다면 auto.offset.reset = earlist 로 설정해야 모든 데이터를 다 처리할 수 있을 것입니다 ^^;

[카프카 브로커 간의 데이터 복제]

카프카에서는 서버 단위로 데이터를 복제해서 데이터를 안전하게 보관합니다.
리더 파티션은 프로듀서나 컨슈머와 직접 데이터 통신을 하는 단위이고, 나머지 팔로워 파티션이 복제본입니다.

만약 리더 파티션이 있는 브로커 0번에 장애가 났다고 가정하면, 브로커 1번 혹은 2번에 있던 팔로워 파티션이 리더 파티션으로 승급됩니다.

[메타데이터로 리더 파티션을 구별한다]

프로듀서나 컨슈머와 같은 카프카 클라이언트는 직접 데이터를 주고받기 전에 메타데이터를 요청합니다. 이 작업을 통해 브로커가 가지고 있는 메타데이터 캐시를 응답값으로 돌려받습니다. 그럼 클라이언트는 어느 브로커로 데이터를 보내야 할지 알게 되고 통신을 수행하게 됩니다.

그런데 이런 메타데이터가 일부 상황에서 적절히 update되지 않는 오류가 발생할 때도 있습니다. 프로듀서나 컨슈머가 가지고 있는 메타데이터가 적절하게 update되지 않으면 리더 파티션이 존재하지 않는 브로커와 통신을 할 때도 있습니다. 이런 경우에는 NotLeaderForPartitionException이 발생합니다.

[ISR]

프로듀서가 데이터를 리더 파티션으로 보내고 나면 나머지 팔로워 파티션에 데이터가 복제되는데 이 때 모두 데이터가 복제되어 동기화된 상태를 ISR(In-Sync-Replicas)라고 부릅니다. 즉, 모든 리더 파티션의 데이터가 팔로워 파티션에 복제 완료 되었다는 뜻입니다.

데이터를 복제하는 데에는 지연이 발생하게 됩니다. 프로듀서는 리더 파티션에 데이터를 보내고 데이터를 저장하는 동안에 그리고 저장이 완료되는 시점에 팔로워 파티션들에는 그 데이터가 없습니다. 왜냐하면, 리더 파티션에 데이터가 안전하게 저장된 이후에 데이터를 팔로워 파티션에 복제하기 때문입니다.

즉, 어떤 시점에는 리더와 팔로워 간에 데이터가 동기화되지 않은 시점이 존재하고 그럴 때 리더 파티션에 장애가 발생하게 되면 팔로워 파티션이 리더로 승급할 때 일부 데이터가 유실될 수 있습니다.

[min.inssync.replicas]

토픽 단위로 설정 가능한 min.inssync.replicas 옵션은 프로듀서가 데이터를 보낼 때 얼마나 안정적으로 데이터를 보낼지 설정하는 값으로 사용됩니다. 참고로 이 값은 acks라는 옵션을 all로 설정했을 때만 유효합니다.

min.inssync.replicas 값이 2일 때는 데이터가 최소 리더 파티션과 팔로워 파티션 1개에 안전하게 데이터를 저장하는 것을 보장합니다. 때문에 리더 파티션에 데이터가 저장된 직후 데이터가 복제되지 않은 상태에서 브로커 0번에 장애가 발생하면, 프로듀서는 데이터가 정상적으로 보내지지 않았다는 것을 감지하고 다시 데이터를 보내게 됩니다.

min.inssync.replicas 값이 3일때는 리더 파티션과 팔로워 파티션 2개에 모두 데이터가 복제 완료되었을 때 데이터가 정상적으로 전송되었음을 보장합니다. 그리고 브로커 개수만큼 min.inssync.replicas 값을 설정하면 브로커가 한 대라도 죽으면 프로듀서는 더 이상 데이터를 보내지 않습니다. 때문에 min.inssync.replicas 값은 브로커 개수보다 작게 설정해야 합니다.

[unclean.leader.election.enable]

** unclean.leader.election.enable = true: 데이터 유실을 감안해도 지속 운영하겠다
** unclean.leader.election.enable = false: 데이터 유실을 절대 허용하지 않겠다

unclean.leader.election.enable은 만에하나 팔로워 파티션들이 ISR로 묶이지 못한 경우에 설정할 수 있는 값입니다.

브로커급 장애가 발생했을 때, 데이터의 유실을 감수하고서라도 데이터를 지속 처리할지 결정하는 옵션입니다.

unclean.leader.election.enable 값이 false인 경우 리더 파티션이 있는 브로커에 장애가 발생하면,

리더 파티션이 있는 브로커가 다시 정상화될때까지 영원히 기다리게 됩니다.

[프로듀서 내부 동작]

** ProducerRecord로 메시지 키, 값 초기화.
** Partitioner는 메시지 키 유무에 따라 어느 토픽으로 보낼 것인지 지정
** Partitioner가 파티션을 지정한 후 Accumulator는 최대한 배치로 데이터를 모으고 나서 Sender는 데이터를 클러스터로 발송

프로듀서는 데이터를 저장해야하는 토픽의 리더 파티션이 위치한 프로커와 직접 통신합니다

카프카 클라이언트들은 리더 파티션이 위치한 브로커와 직접 통신하기 전에 이미 연결되어 있는 브로커와 통신해서, 리더 파티션이 위치한 브로커의 정보를 가져오는 작업을 합니다.

[메시지 키가 없는 레코드를 발송하는 프로듀서]

** 프로듀서 = 특정 토픽 + 특정 파티션에 데이터를 전송하는 주체
** 프로듀서가 브로커로 데이터 전송을 요청하면 브로커는 파일시스템에 데이터를 저장
** 레코드가 어느 파티션에 저장되었는지 프로듀서는 브로커로부터 응답 받음

레코드를 정의할 때, 실제로 사용하는 데이터를 메시지 값에 저장하고 데이터를 보내면 토픽의 파티션들 중 하나에 데이터가 저장되는데, 메시지 키가 없는 레코드를 보내면 파티션들에 Round-Robin으로 데이터가 돌아가면서 저장됩니다.

** 메시지 키가 없는 레코드
  . 기본적으로 라운드 로빈 형태로 파티션에 데이터를 전송
** 메시지 키가 있는 레코드
  . 해쉬 형태로 변환하여 특정 파티션에 지정되어 저장됨

[기본 파티셔너]

** 기본 파티셔너는 2개를 제공함
  . UniformStickyPartitioner, RoundRobinPartitioner
  . 2.4.0부터는 파티셔너를 지정하지 않을 경우 UniformStickyPartitioner가 기본 설정됨

** UniformStickyPartitioner
  . 배치로 묶어 전송되어야 하는 데이터를 Accumulator에 최대한 묶어서 발송함(메시지 키가 없는 경우)
  . 이전의 RoundRobinPartitioner는 Accumulator의 배치와 무관하게 ProduceRecoder가 들어오는대로 모두 순회하면서 전송했기 때문에 성능이 느렸음(네트워크 사용량이 높음)
  . 메시지 키가 있는 경우에는? -> 메시지 키를 해시 값으로 변환하여 파티션을 지정

[언제 메시지 키를 넣어야 할까?]

** 기본 파티셔너를 사용하는 경우에 "동일 메시지 키는 동일 파티션으로 들어간다"
  . 처리해야 하는 데이터가 컨슈머에 분산되면 안되는 경우 (ex. 상태가 있는 처리를 할 때; Stateful)
  . 처리해야 하는 데이터가 ordering을 만족해야 하는 경우 (ex. 은행 데이터, 결제 데이터)

[메시지 키를 넣으면 안되는 경우]

** 충분히 분산될 만한 메시지 키가 아닌 경우
  . Ex) 레코드의 메시지 값(json)의 스키마 버전 -> 스키마 버전은 빈번히 바뀌는 값이 아니고 분산되지 않기 때문에 일부 컨슈머에는 데이터처리를 하지 않고 계속해서 쉴 수도 있습니다.

다양한 종류가 아닌 데이터에 메시지 키를 사용하면 데이터가 일부 파티션에만 몰릴 수 있습니다. 데이터가 일부 파티션에 몰리게 되면 일부 컨슈머만 데이터가 처리되기 때문에, 컨슈머 측이 데이터를 최대의 성능으로 처리할 수 없습니다.
 
** 파티션 개수가 빈번히 변할 경우
  . 파티션의 개수가 변하면서 메시지 키와 파티션의 할당이 변경됩니다.
  . 이로 인해서 메시지 키를 넣어서 예상하는 동작과 다르게 동작할 수도 있습니다.

[커스텀 파티셔너]

** 메시지 키 뿐만 아니라 메시지 값, 토픽 이름 등을 이용하여 파티션 지정 가능
** 카프카 클라이언트 라이브러리에서 제공하는 Partitioner 인터페이스 사용

기본 파티셔너 2개 외에 다른 파티셔너를 활용하고 싶다면, 카프카 클라이언트 라이브러리의 partitioner 인터페이스를 사용해서 커스텀 파티셔너를 개발, 프로듀서 옵션을 추가하면 됩니다. 커스텀 파티셔너를 사용하면 메시지 키 뿐만 아니라 메시지 값, 토픽 이름, 클러스터 이름을 토대로 파티셔너를 지정할 수 있습니다.

커스텀 파티셔너를 이용하면 여타 메시징 브로커에서 사용하는 것 처럼 우선순위 큐를 만들 수도 있습니다.

위 그림처럼 일반 고객은 파티션 2개에 할당하고, VIP 고객은 파티션 4개에 할당하는 방식을 예로 들 수 있습니다.

1개의 파티션은 최대 1개의 컨슈머에 할당되는 특징을 사용하여 일반 고객 대비 VIP 고객의 데이타 처리를 2배 빠르게 할 수 있다는 장점이 있습니다.

[카프카 클러스터]

프로듀서, 컨슈머는 리더 파티션과 직접 통신해서 데이터를 처리하게 됩니다.

팔로워 파티션은 리더 파티션에 있는 데이터를 확인해서 자신에게 없는 데이터를 복제해갑니다.

리더 파티션의 위치가 Round-Robin 방식으로 적절히 분배되기 때문에 프로듀서, 컨슈머가 클러스터와 통신을 할 때 네트워크 비용이 각 서버(브로커)에 분산된다는 장점이 있습니다. 앞단에 로드 밸런서를 놓는 방식이 아니라 컨슈머, 프로듀서가 직접 분산해서 통신하는 것입니다. 

복제 개수가 늘어나면 데이터를 안전하게 저장할 수 있지만, 팔로워 파티션이 지속적으로 리더 파티션에 있는 데이터를 복제해야하기 때문에 브로커들 간의 네트워크 통신이 많아진다는 단점이 있습니다. 때문에 일반적인 경우에는 복제 개수를 2로 운영하는 것이 브로커의 리소스 관리에 좋습니다.

리더 파티션이 특정 브로커에 몰려있는 경우, 파티션 밸런싱을 맞추는 명령어 (kafka-reassign-partisions.sh)를 적용할 수 있습니다. 때문에 카프카 클러스터를 운영하다가 서버 관련 리소스 사용 비율이 특정 브로커에 몰려있다고 판단되면, 리더 파티션이 밀집되어 있지 않은지 확인하는 것이 중요합니다.

[1주키퍼 + 다중 카프카 클러스터]

카프카 클러스터를 상황에 따라 분리해서 데이터를 격리할 수 있습니다. 한 개의 주키퍼에 주문 로그, 데이터 분석, 웹 로그 등과 같이 목적에 따라 나누는 것도 좋은 방법일 수 있습니다. 하지만 주키퍼가 데이터를 많이 저장하고 통신량이 많아지면 병목 지점이 될 수 있다는 부분을 유의해야 합니다.

[ 카프카 브로커 ]

카프카에서 브로커는 카프카를 저장하는 공간이고 가장 핵심이 되는 애플리케이션입니다.

카프카 브로커를 실행하기 위해서 반드시 주키퍼가 필요합니다.

주키퍼는 카프카에서 사용되는 다양한 메타데이터를 저장하고 사용되는데 토픽의 파티션 위치, 컨슈머 그룹 이름과 같은 메타데이터가 저장되고 사용됩니다. 이러한 메타데이터는 카프카 브로커 운영을 위해 내부에서 사용될 뿐 아니라 프로듀서와 컨슈머가 토픽을 클러스터와 통신을 하는데 중요한 역할을 합니다.

** 카프카 브로커의 역할
  . 데이터 복제, 삭제, 컨트롤러, 코디네이터 등
** 주키퍼의 역할
  . 카프카를 운영하는데 필요한 메타데이터 저장
  . 토픽의 파티션 위치, 컨슈머 그룹 이름 등

프로듀서가 보낸 데이터는 브로커에 저장되는데, 이 브로커라고 불리는 애플리케이션(or 프로세스)는 서버 1대에 1개의 브로커로 실행됩니다. 만약 여러 브로커로 분산 운영하고 싶다면 서버를 여러 대 발급받아서 각 서버당 브로커 프로세스를 실행시켜서 클러스터로 운영하는 구조입니다.

(1개의 서버에 여러 브로커를 띄울 수 있지만, 서버의 장애의 대비해서 클러스터로 서버를 이중화/삼중화하는 것입니다.)

프로듀서가 보낸 데이터는 브로커 애플리케이션이 있는 서버의 파일 시스템에 저장합니다. 파일 시스템에 저장함으로써 데이터를 안전하게 저장하고, 브로커가 중단되더라도 다시 브로커를 실행시켜서 데이터를 사용할 수 있는 구조라고 볼 수 있습니다.

[브로커:데이터 복제]

카프카에서는 데이터를 안정적으로 분산 저장하기 위해, 브로커를 여러 대 운영합니다.

데이터를 분산 저장하기위해 카프카에서는 파티션을 복제해서 여러 서버에 분산 저장합니다.

이렇게 복제한 파티션은 리더 파티션과 팔로워 파티션으로 구성되어 있습니다.

** 파티션은 리더 파티션과 팔로워 파티션으로 구성되어 있습니다.
  . 리더: 프로듀서, 컨슈머와 직접 통신하는 브로커에 위치
           브로커로 전송된 데이터는 가장 처음 리더 파티션에 저장된다
  . 팔로워: 리더가 있는 브로커와 다른 브로커에 저장됨
              (팔로워 파티션을 구성하기 위해서는 브로커가 2개 이상인 클러스터를 운영해야 합니다)
              리더 파티션을 계속 복제하여 데이터를 분산 저장하는 용도

[브로커:그룹 코디네이터]

여러 브로커 중 한대는 코디네이터 역할을 하게 됩니다.

** 컨슈머 그룹 상태를 체크
  . 컨슈머에 장애가 발생하여 더이상 파티션이 소비되지 않을 경우 정상 컨슈머에 파티션 할당을 변경함(리밸런스)
** 파티션 변경 상태를 체크
  . 파티션이 변경되면 리밸런스
이런 상태에 따라 컨슈머와 파티션의 할당을 변경해주는 리밸런싱을 발생시키는 역할을 합니다.

코디네이터 역할을 하는 브로커는 토픽과 연계된 파티션과 컨슈머의 상태에 따라 컨슈머와 파티션의 할당을 변경해주는 리밸런싱을 일으켜 데이터가 지속적으로 처리되도록 도와줍니다.

[브로커:컨트롤러]

클러스터를 구성하는 브로커 중 한대는 컨트롤러 역할을 합니다.

클러스터에서 시작하는 첫 번째 브로커가 컨트롤러가 되고, 나머지 브로커들에게 파티션들에 대한 정보를 나눠가질 수 있도록 전송해서 프로듀서나 컨슈머가 정상적으로 브로커와 통신할 수 있도록 도와줍니다.

또한 컨트롤러 브로커는 리더 파티션을 선출합니다. 이는 데이터가 분산 저장되어 있을 때, 안전하게 데이터를 지속적으로 처리할 수 있도록 하는 데 핵심적인 역할을 합니다.

[주키퍼가 가지고 있는 메타데이터들]

** 컨트롤러 정보: /controller

** 브로커 ID와 토픽 정보들: /brokers/ids, /brokers/topics

** 토픽 설정 정보: /config
  . 이런 데이터는 직접 주키퍼 명령어들을 통해서 노드를 조회하고 확인할 수 있습니다.

** 필요할 경우 하나의 주키퍼로 다른 용도의 카프카 클러스터(브로커)를 운영할 수 있습니다.
  . /data/...
  . /marketing/...
  . 와 같이 root node의 이름을 다르게 만들고 지정해서 여러 클러스터를 한꺼번에 운영할 수 있음

주키퍼와의 통신으 브로커, 클러스터를 운영하는 데 데이터 통신이 지속적으로 일어나 운영상의 허들이 되어왔습니다.
그래서 카크파 클러스터를 운영할 때 주키퍼 없이 운영할 수 있도록 개발중에 있습니다(3.0에서는 주키퍼 삭제 예정)

토픽 이름은 영대소문자와 언더바, 대시, 마침표로 구성할 수 있는데 

이외에 브로커의 버전에 따라 불가능한 이름이 있을 수 있습니다. (마침표 하나, 마침표 2개 등..)

때문에 제약사항을 정확히 알고 싶다면 깃허브에 올라가있는 아파치 카프카 오픈소스를 받아서, 토픽 생성 관련 코드를 확인해보는 것이 좋습니다.

[토픽 이름을 어떻게 지정해야 할까?]

1) 어떤 개발환경이고, 어떤 데이터 타입이 사용되는지 유추 가능한 토픽 이름이 좋습니다.
토픽에 넣을 수 있는 데이터는 직렬화되어 들어갑니다. 즉, 들어갈 수 있는 데이터 타입이 무한하다고 볼 수 있습니다.

토픽에 들어가는 데이터가 JSON인지 POJO인지에 따라 컨슈머에서 어떻게 역직렬화해서 데이터를 읽을지 정해야 하기 때문에, 토픽에 들어가는 데이터 타입을 명확히 표시하기 위해 토픽 이름에 데이터 타입이 들어가는 것이 좋은 방법일 수 있습니다.

2) 만약 회사에서 공용 카프카 클러스터를 사용한다면, 여러 팀이 동시에 토픽을 만들고 사용할 수 있습니다.
이런 경우에 특정 토픽이 어느 서비스에서, 어떤 팀에서 사용되는 것인지 파악이 힘들 수 있는데
그런 경우에는 토픽의 오너십(ownership)을 가진 이름을 토픽 이름에 추가하는 것도 고려할 수 있습니다.

3) 카프카 클러스터를 2개 이상 운영(개발 환경, 상용 환경)하는 경우 굳이 동일한 이름의 토픽 이름을 만들기보단, 클러스터의 환경에 따라 토픽 이름을 다르게 넣어서 토픽이 위치한 환경을 명확히 파악하는 것이 좋습니다.

[좋은 토픽 이름을 짓는 방법]

1) 대소문자를 섞어 쓰지 않는 것이 좋습니다.
  . 휴먼 에러로 실수할 가능성이 높음
  . kafka-console-consumer, kafka-console-producer로  테스트를 위해 cli를 작성할 때 번거로움

2) 마침표(.)와 언더바(_)를 섞어 쓰지 않는 것이 좋습니다.
  . 마침표와 언더바를 섞어쓰면 카프카에서 사용하는 메트릭 이름과 충돌이 일어날 수 있음

3) 카프카 클러스터 운영자는 규칙을 정하고 전파하는 것이 좋습니다.

** 좋은 토픽 이름 예시
  . advertise-sender-notification-prod
  . android-application-sms-prod

  . data-jira1234-dev

[레코드와 파티션]

** 파티션은 데이터가 저장되는 공간이고, 이 데이터가 레코드라고 불립니다.

레코드마다 고유한 타임스탬프, 메시지 키, 메시지 값, 오프셋이 지정되서 파티션에 들어가게 됩니다.

타임스탬프
  . 레코드를 생성할 시점이 Unix time으로 들어가게 됨, 브로커에 들어갈 시간, 사용자가 설정한 시간도 들어갈 수 있음
메시지 키 
  . 데이터를 구분하는 값 -> 레코드가 들어갈 파티션을 정하거나, 순서를 정할때 사용하기 유용함
  . 보통의 경우 메시지 키를 따로 설정하지 않으면 NULL 값으로 들어가게 됨

메시지 값  
  . 실제로 사용할 데이터. 직렬화 되어 저장됨

오프셋 
  . 파티션에 저장될 때 레코드 별로 저장되는 번호
  . 한 개의 파티션에는 오프셋이 중복될 수 없음

[토픽과 파티션]

** 토픽은 파티션들의 묶음으로, 한 개의 토픽은 일반적인 DB의 Table과 유사한 개념입니다.

토픽의 파티션에 저장된 데이터는 브로커가 데이터를 지우기 전까지는 삭제되지 않습니다.

토픽은 파티션을 한 개 이상 가져야 합니다. 그리고 파티션 개수가 많아질 수록 병렬 처리량을 늘릴 수 있습니다.
-> 컨슈머 그룹을 통해서 파티션 개수가 많을수록 병렬로 처리되는 데이터량, 시간당 처리되는 데이터량을 늘릴 수 있음

토픽 이름은 영대소문자, 숫자, 점, 언더바, 대시로 만들 수 있습니다.

[파티션 개수의 변경]

** 토픽에 있는 파티션 개수를 변경할 수(늘릴 수) 있음

데이터 처리량을 늘리고 싶을 때, 파티션 개수를 늘려서 처리할 수 있습니다.
-> 파티션 개수만큼 컨슈머 그룹을 늘릴 수 있기 때문
단, 이미 가지고 있는 파티션을 줄이는 것은 불가능합니다.

[토픽의 데이터 삭제]

** 토픽(파티션)에 저장된 데이터는 개별 삭제가 불가능합니다.

** 데이터의 삭제는 브로커가 관장하며, 토픽 단위로 데이터가 삭제되는 시점을 정할 수 있습니다.
각각의 레코드를 로그(Log)로 보기 때문에, insert/update가 불가능합니다.

데이터 삭제는 아래와 같이 2가지 옵션이 있습니다.
  . cleanup.policy = delete (데이터 레코드의 삭제)

     - retention.ms : 얼마정도 시간이 지나고 나면 삭제 처리
     - retentions.bytes : 얼마정도 데이터가 차고 나면 삭제 처리
  . cleanup.policy = compact (메시지 키 단위로 이전의 데이터를 삭제)
     - 주로 스트리밍 애플리케이션을 만들 때 사용

[데이터 파이프라인에 필요한 4가지]

- 높은 처리량, 확장성, 영속성, 고가용성

[카프카 특징#1 - 높은 처리량]

** 컨슈머/프로듀서가 브로커와 통신할 때 데이터를 묶어(배치) 전송
** 파티션 개수만큼 컨슈머를 늘려서 병렬 처리량을 늘릴 수 있음

카프카는 프로듀서가 브로커로 데이터를 보낼 때와 컨슈머가 브로커로부터 데이터를 받을 때, 데이터를 묶어서(배치) 전송합니다.
많은 양의 데이터를 송/수신할 대 맺어지는 네트워크 비용은 무시할 수 없는 규모입니다. 동일한 양의 데이터를 보낼 때 네트워크 통신 횟수를 최소한으로 줄이면, 동일 시간 내에 더 많은 양의 데이터를 전송 가능합니다.

많은 양의 데이터를 묶음 처리하는 배치로 빠르게 처리할 수 있기 때문에, 카프카는 대용량 실시간 로그 데이터를 처리하는데 적합합니다. 또한 카프카는 파티션과 컨슈머 개수를 늘려서, 병렬 처리량을 늘려서 동일 시간당 처리량을 극대화할 수도 있습니다.

[카프카 특징#2 - 확장성]

** 데이터의 양이 많아지거나 적어짐에 따라 무중단 스케일인/아웃 가능
** 처음에는 작은 서버 개수로 시작
** 데이터의 양이 많아지면 서버를 늘려서 대응 가능

데이터 파이프라인에서, 데이터가 얼마나 들어올지 예측하기는 매우 어렵습니다. 예상치 못한 특정 이벤트로 인해 100만 건 이상의 데이터가 갑자기 들어올 수도 있습니다. 카프카는 이러한 가변적인 환경에서도 데이터를 안정적으로 확장 가능하도록 설계되어 있습니다.

데이터가 적을 때는 카프카 클러스터의 브로커를 최소한의 개수로 운영하다가, 데이터가 많아지면 브로커 개수를 늘려서 스케일 아웃(Scale-out)할 수 있습니다. 반대로 데이터가 적어지고, 추가 서버들이 필요 없어지면 브로커 개수를 줄여서 스케일 인(Scale-in) 할 수 있습니다.

카프카의 스케일인/아웃 과정은 클러스터의 무중단 운영을 지원하기 때문에, 365일-24시간 데이터를 처리해야 하는 커머스와 은행 같은 BM에서도 안정적인 운영이 가능합니다.

[카프카 특징#3 - 영속성]

** 파일 시스템에 데이터를 저장
** 브로커에 이슈가 발생하여 종료되더라도 데이터 재사용 가능

영속성이란 데이터를 생성한 프로그램이 종료되더라도, 사라지지 않는 데이터의 특성을 의미합니다.

카프카는 다른 메시징 플랫폼과 다르게 전송받은 데이터를 메모리에 저장하지 않고, 파일 시스템에 적재합니다.

파일 시스템에 데이터를 적재하고 사용하는 것은, 보편적으로 느리다고 생각될 수 있지만 카프카는 OS 레벨에서 파일 시스템을 최대한 활용할 수 있는 방법을 적용했습니다.

OS에서는 파일 I/O 성능 향상을 위해 페이지 캐시 영역을 메모리에 따로 생성해서 사용하는데, 페이지 캐시 메모리 영역을 사용하여 한 번 읽은 파일 내용은 메모리에 저장시켰다가 다시 사용하는 방식이기 때문에 카프카가 파일 시스템에 데이터를 저장하고 전송 하더라도, 처리량(속도)이 높은 것입니다.

디스크 기반의 파일 시스템을 활용한 덕분에, 브로커와 애플리케이션이 장애 발생으로 갑자기 종료되더라도, 프로세스를 재시작하여 안전하게 데이터를 다시 처리할 수 있다는 장점이 있습니다.

[카프카 특징#3 - 고가용성]

** 일부 브로커에 이슈가 생기더라도 데이터 처리 지속 가능
** 온 프레미스/퍼블릭 클라우드에 적합한 브로커 옵션들이 준비됨

3개 이상의 서버들로 운영되는 상용 환경의 카프카 클러스터는, 일부 서버에 장애가 생겨도 무중단으로 안정하고 지속적으로 데이터를 처리할 수 있습니다.

클러스터로 이루어진 카프카는 데이터의 복제를 통해, 고가용성의 특징을 가집니다. 프로듀서로 전송받은 데이터를 여러 브로커 서버들 중 1대에만 저장하는 것이 아니라, 또 다른 브로커 서버에도 저장하는 것입니다.

한 서버에 장애가 발생하더라도, 복제된 데이터가 나머지 브로커 서버에 저장되어 있으므로 저장되어 있는 브로커 서버를 기준으로 지속적으로 데이터 처리가 가능합니다.