[kafka] 4.카프카 상세 개념 설명

토픽과 파티션

---

• 토픽 생성시 파티션 개수 고려사항
  - 데이터 처리량 : 프로듀서 전송 데이터량(.초당 1000개) < 컨슈머 데이터 처리량(초당 100개) x 파티션 개수(10개)
  - 메시지 키 사용 여부
  - 브로커, 컨슈머 영향도
• 토픽 정리 정책(cleanup.policy)
  - 토픽 삭제 정책(delete policy) : 토픽의 데이터를 삭제할 때는 세그먼트 단위로 삭제를 진행한다. 세그먼트는 토픽의 데이터를 저장하는 명시적인 파일 시스템 단위이다. 세그먼트는 파티션마다 별개로 생성되며 세그먼트의 파일 이름은 오프셋 중 가장 작은 값이 된다. 세그먼트는 여러 조각으로 나뉘는데 segment.bytes 옵션으로 1개의 세그먼트 크기를 설정할 수 있다. segment.bytes 크기보다 커질 경우에는 기존에 적재하던 세그먼트 파일을 닫고 새로운 세그먼트를 열어서 데이터를 저장한다. 데이터를 저장하기 위해 사용 중인 세그먼트를 엑티브 세그먼트라고 한다.
  삭제 정책이 실행되는 시점은 시간 또는 용량 기준이 된다. retention.ms는 토픽의 데이터를 유지하는 기간을 ms(밀리초)로 설정 할 수 있다. retention.bytes는 토픽의 최대 데이터 크기를 제어 한다. retention.bytes를 넘어간 세그먼트 파일들은 삭제 된다. 삭제된 데이터는 복구할 수 없다.
  - 토픽 압축 정책(compact policy) : 토픽의 압축 정책은 일반적으로 생각하는 zip이나 tar 압축과는 다른 개념이다. 여기서 압축이란 메시지 키별로 해당 메시지 키의 레코드 중 오래된 데이터를 삭제하는 정책을 뜻한다. 예를 들어 1~10까지 오프셋이 있고 4,5,6이 동일한 메세지 키를 가질 경우 오프셋과 관계 없이 중간에 있는 4,5번 오프셋 레코드가 삭제 될 수 있다는 뜻이다.
• ISR(In-Sync-Replicas)
  ISR은 리더 파티션과 팔로워 파티션이 모두 싱크가 된 상태를 뜻한다.

카프카 프로듀서

---

프로듀서는 카프카에 데이터를 저장하는 첫 단계이다. 카프카 클러스터는 3대 이상의 브로커로 이루어져 있어서 일부 브로커에 이슈가 생기더라도 데이터의 유실을 막을 수 있다. 그러나 유실을 막기 위해서는 프로듀서에서 제공하는 다양한 옵션을 함께 사용해야 한다. 

• acks 옵션
  카프카 프로듀서의  acks 오션은 0,1,all(또는 -1) 값을 가질 수 있다. 이 옵션을 통해 프로듀서가 전송한 데이터가 카프카 클러스터에 얼마나 신뢰성 높게 저장할지 지정할 수 있다.
  acks=0 : 프로듀서가 리더 파티션으로 데이터를 전송했을 때 리더 파티션으로 데이터가 저장되었는지 확인하지 않는다는 뜻이다. 리더 파티션은 데이터가 저장된 이후에 데이터가 몇 번째 오프셋에 저장되었는지를 리턴하는데, acks가 0으로 설정되어 있다면 프로듀서는 리더 파티션에 데이터가 저장되었는지 여부에 대한 응답 값을 받지 않는다. 속도가 빠름
  acks=1 : 프로듀서는 보낸 데이터가 리더 파티션에만 정상적으로 적재되었는지 확인한다. 만약 리더 파티션에 정상적으로 적재되지 않았다면 리더 파티션에 적재될 때까지 재시도할 수 있다. 그러나 리더 파티션에 적재되었음을 보장하더라도 팔로워 파티션에는 동기화가 안될수 있기 때문에 데이터가 완전하게 적재되었다고 보장 할 수는 없다. only 리더 파티션의 데이터 적재 여부만 알 수 있다. acks=0보단 느림
  acks=all 또는 acks=-1 : 프로듀서가 보낸 데이터가 리더 파티션과 팔로워 파티션에
•  
• 모두 정상적으로 적재되었는지를 확인한다. 일부 브로커에 장애가 발생하더라도 프로듀서는 안전하게 데이터를 전송하고 저장할 수 있음을 보장할 수 있다. 속도는 느림
• 멱등성(idempotence) 프로듀서
  멱등성이란 여러 번 연산을 수행하더라도 동일한 결과를 나타내는 것을 뜻한다. 이러한 의미에서 멱등성 프로듀서는 동일한 데이터를 여러 번 전송하더라도 카프카 클러스터에 단 한 번만 저장됨을 의미 한다. 멱등성 프로듀서는 기본 프로듀서와 달리 데이터를 브로커로 전달할 때 프로듀서 PID(Producer unique ID)와 시퀀스 넘버를 함께 전달 한다. 그러면 브로커는 프로듀서와 PID와 시퀀스 넘버를 확인하여 동일한 메시지의 적재 요청이 오더라도 단 한번만 데이터를 적재함으로써 프로듀서의 데이터는 정확히 한번 브로커에 적재되도록 동작한다.
• 트랜잭션(transaction) 프로듀서
  트랜잭션 프로듀서는 다수의 파티션에 데이터를 저장할 경우 모든 데이터에 대해 동일한 원자성을 만족시키기 위해사용된다. 원자성을 만족시킨다는 의미는 다수의 데이터를 동일 트랜잭션으로 묶음으로써 전체 데이터를 처리하거나 전체 데이터를 처리하지 않도록 하는 것을 의미 한다.

카프카 컨슈머

---

컨슈머는 카프카에 적재된 데이터를 처리한다. 컨슈머를 통해 데이터를 카프카 클러스터로부터 가져가고 처리해야 한다. 

• 멀티 스레드 컨슈머
  카프카는 처리량을 늘리기 위해 파티션과 컨슈머 개수를 늘려서 운영할 수 있다. 파티션을 여러 개로 운영하는 경우 데이터를 병렬처리하기 위해서 파티션 개수와 컨슈머 개수를 동일하게 맞추는 것이 가장 좋은 방법이다. 파티션 개수가 n개라면 동일 컨슈머 그룹으로 묶인 컨슈머 스레드를 최대 n개 운영할 수 있다. 그러므로 n개의 스레드를 가진 1개의 프로세스를 운영하거나 1개의 스레드를 가진 프로세스를 n개 운영하는 방법도 있다.
  - 워커 스레드(worker thread) 전략 : 컨슈머 스레드는 1개만 실행하고 데이터 처리를 담당하는 워커 스레드를 여러 개 실행하는 방법
  - 컨슈머 스레드 전략 : 컨슈머 인스턴스에서 poll() 메서드를 호출하는 스레드를 여러개 띄어서 사용하는 컨슈머 멀티 스레드 전략
• 카프카 컨슈머 멀티 워커 스레드 전략
  브로커로부터 전달받은 레코드들을 병렬로 처리한다면 1개의 컨슈머 스레드로 받은 데이터를 더욱 향상된 속도로 처리할 수 있다. 데이터를 for 반복문으로 처리할 경우 이전 레코드의 처리가 끝날 때까지 다음 레코드는 기다리게 된다. 만약 레코드별로 처리해야 하는 시간이 길 경우에는 더욱 오래 기다리게 되므로 처리 속도는 더 느려진다. 멀티 스레드를 사용하면 각기 다른 레코드들의 데이터 처리를 동시에 실행할 수 있기 때문에 처리 시간을 현저히 줄일 수 있다. 멀티 스레드를 생성하는 ExecutorService 자바 라이브러리를 사용하면 레코드를 병렬처리하는 스레드를 효율적으로 생성하고 관리할 수 있다. Executors를 사용하여 스레드 개수를 제어하는 스레드 풀(thread pool)을 생성할 수 있는데, 데이터 처리 환경에 맞는 스레드 풀을 사용하면 된다. 작업 이후 스레드가 종료되어야 한다면 CachedThreadPool을 스레드를 실행한다. 
• 카프카 컨슈머 멀티 스레드 전략
  하나의 파티션은 동일 컨슈머 중 최대 1개까지 할당된다. 그리고 하나의 컨슈머는 여러 파티션에 할당될 수 있다. 이런 특징을 가장 잘 살리는 방법은 1개의 애플리케이션에 구독하고자 하는 토픽이 파티션 개수만큼 컨슈머 스레드 개수를 늘려서 운영하는 것이다. 컨슈머 스레드를 늘려서 운영하면 각 스레드에 각 파티션이 할당되며, 파티션의 레코드들을 병렬처리할 수 있다.
• 컨슈머 랙
  컨슈머 랙은 토픽의 최신 오프셋(LOG-END-OFFSET)과 컨슈머 오프셋(CURRENT-OFFSET) 간의 차이다. 프로듀서는 계속해서 새로운 데이터를 파티션에 저장하고 컨슈머는 자신이 처리할 수 있는 만큼 데이터를 가져간다. 컨슈머 랙은 컨슈머가 정상 동작하는지 여부를 확인할 수 있기 때문에 컨슈머 애플리케이션을 운영한다면 필수적으로 모니터링해야 하는 지표이다.
  컨슈머 랙은 컨슈머 그룹과 토픽, 파티션별로 생성된다. 1개의 토픽에 3개의 파티션이 있고 1개의 컨슈머 그룹이 토픽을 구독하여 데이터를 가져가면 컨슈머 랙은 총 3개가 된다.