데브원영- 아파치 카프카 for beginners 수강 정리

2024, Dec 28    
kafka

강의 정보

  • 아파치 카프카 for beginners
  • 수강료: 무료
  • 수강 시간: 총 1시간 31분
  • 과정
    • 아파치 카프카 기초
    • 아파치 카프카 개발
    • 아파치 카프카 미래

개념

  1. 토픽
    1. 정의 및 특징
      1. 데이터가 들어가는 공간
      2. db의 테이블처럼 여러개의 토픽 생성가능
      3. 컨슈머는 이 데이터를 가져가게 된다.
      4. 토픽은 이름을 지정할 수 있으며, 목적에 맞게 활용한다. (예: center_register_event)
    2. 구조
      1. 하나의 토픽은 여러개의 파티션으로 구성될 수 있다.
      2. 첫번째 파티션 번호는 0번 부터 시작한다.
      3. 파티션에 저장되는 데이터는 끝에서부터 누적되어온다.
      4. 그리고 컨슈머는 데이터가 가장 오래된 것부터 가져가게 된다.
      5. 가져갈 데이터가 없으면 컨슈머는 대기한다.
      6. 컨슈머가 데이터를 가져가더라도 파티션의 데이터는 삭제되지 않는다.
      7. 새로운 컨슈머가 생기면 기존에 다른 컨슈머가 가져갔던말던 0번부터 가져갈 수 있다. 다만 이럴려면 컨슈머 그룹이 기존꺼랑 달라야하고 auto.offset.reset설정이 earliest로 설정되어있어야 한다.
      8. 토픽의 파티션이 여러개인 경우,
        1. 어느 파티션으로 데이터를 보내야할지 결정하는 것은, 프로듀서가 key를 통해서 설정할 수 있다.
          1. 만약 key를 설정하지 않았고 기본 파티셔너를 사용할 경우 → 라운드 로빈으로 할당
          2. key가 있고, 기본 파티셔너를 사용할 경우 → key의 hash값을 구하고 특정 파티션에 데이터를 저장한다.
      9. 파티션을 늘리는 것은 조심해야한다
        1. 늘리는 것은 가능하지만, 줄이는 것은 안된다.
        2. 파티션을 늘리는 이유는?
          1. 파티션을 늘리면, 컨슈머 개수를 늘려서 데이터 처리를 분산시킬 수 있기 때문이다.
      10. 파티션의 데이터는 언제 삭제될까?
        1. log.retention.ms : 최대 record 보존 시간
        2. log.retention.byte : 최대 record 보존 크기
  2. replication
    1. 파티션 복제 수를 말한다.
    2. 예를 들어
      1. replication이 1이면 파티션은 1개만 존재한다는 뜻
      2. replication이 2이면 파티션은 원본 1개와 복제본 1개라는 뜻
      3. replication이 3이면 파티션은 원본 1개와 복제본 2개라는 뜻 = 한개의 브로커에 원복 + 나머지 브로커들에 복제본 2개
    3. 브로커 개수에 따라 replication개수가 제한된다.
      1. 즉 브로커가 3이면, replication은 4가 될 수 없다.
    4. 원본 파티션을 leader 파티션이라고 한다.
    5. 복제본 replication 파티션을 follower 파티션이라고 한다.
    6. 왜 replication을 사용할까?
      1. 파티션의 고가용성을 위해 사용한다.
      2. 예를 들어
        1. 브로커가 3대인데, replication이 1이고 partition이 1인 토픽이 있다고 했을때, 브로커 한대가 사용불가 상태가 되면 해당 파티션은 복구가 불가능해진다.
          1. 이때 replication이 2라고 한다면, 다른 브로커에 follower partition이 존재하기 때문에 복구가 가능하다. (즉 follower 파티션이 leader파티션의 역할을 승계하게 된다.)
    7. replication 수가 많아지면, 브로커의 리소스 사용량도 올라간다.
    8. replication 수는?
      1. 데이터 양과 보관일수등을 고려해서 정해야한다.
      2. 3대 이상의 브로커일 경우 replication은 3을 추천
  3. broker 브로커
    1. kafka가 설치되어 있는 서버 단위를 말한다. (3대 이상 설치 권장)
    2. 만약, 파티션이 1개이고, replication(파티션 복제)이 1인 토픽이 있는데, 브로커가 3대라면 그 중 1대 서버에만 데이터가 저장된다.
  4. ISR (= In Sync Replica)
    1. leader 파티션과 follower파티션을 합친 것을 말한다.
  5. leader partition vs follower partition
    1. 프로듀서가 데이터를 전달할때, 데이터를 받는 주체가 leader partition이다
  6. 프로듀서의 ack 옵션
    1. 0일 경우
      1. leader partition에 데이터를 전송하고 응답값은 받지 않는다.
      2. 복제되었는지 알수 없어서 유실 가능성이 있다
      3. 속도는 빠르다.
    2. 1일 경우
      1. leader partition에 데이터를 전송하고 응답값을 받는다.
      2. 이 또한 복제되었는지 알 수 없다.
      3. 0과 마찬가지로 유실 가능성 있다
    3. all
      1. follower partition까지 복제가 잘 되었는지 응답값을 받는다.
      2. 데이터 유실은 없다
      3. 0,1에 비해 속도가 느리다
  7. 파티셔너
    1. 프로커가 데이터를 전송할때 파티셔너를 거쳐서 브로커로 전송된다.
    2. 파티셔너는 데이터를 토픽의 어떤 파티션에 넣을지 결정하는 역할을 한다
      1. 레코드의 key 또는 데이터에 따라서 파티션의 위치가 결정된다.
      2. 만약에 key를 정하지 않고 보내면 uniformStickyPartitioner로 설정이 된다
    3. uniformStickyPartitioner란?
      1. 메시지의 key가 있을때
        1. key를 특정한 해시값으로 생성시키는데, 이 해시값으로 어느 파티션에 들어갈지 결정하게 된다.
        2. 동일한 key일 경우 동일한 해시값이기 때문에 동일한 파티션에 들어가게 된다. (= 이 말은, key가 같으면 데이터간에 순서 보장이 된다.)
      2. 메시지의 key가 없는 경우
        1. 라운드로빈 방식으로 파티션에 들어간다.
        2. 다만 일반적인 라운드로빈방식이 아닌, uniformStickyPartitioner는 프로듀서에서 배치로 모을수 있는 최대한의 데이터를 모아서 배치단위로 파티션으로 보내게 된다.
        3. 이 방식은 파티션별로 적절히 분배하기 위한 방식이라 보면 된다.
    4. 커스텀 파티셔너
      1. Partitioner 인터페이스를 상속받아서 어느 데이터를 어느 파티션으로 보낼지 정할 수 있다.
      2. 활용 예)
        1. vip고객의 데이터 처리와 일반 고객의 데이터 처리량을 달리가져가서 파티션별로 점유를 vip를 더 높게 할 수 있다.
  8. consumer lag
    1. 정의
      1. 데이터가 파티션에 들어갈때마다 오프셋이라고하는 숫자가 0부터 붙게된다.
      2. 프로듀서가 데이터를 넣는 것이 컨슈머가 데이터를 가져가는 것보다 빠르게 되면, 프로듀서가 마지막으로 넣은 offset과 컨슈머가 마지막으로 읽은 offset간에 차이가 발생하게 되는데, 이것을 consumer lag이라고 한다.
    2. lag은 적을 수도 있고 많을 수도 있다.
    3. 토픽에 여러개의 파티션이 존재할경우, lag은 파티션마다 존재할 수 있다.
    4. 만약에 컨슈머 그룹이 1개이고, 파티션이 2개인 토픽에서 데이터를 가져왔다면 lag은 2개가 생길 수 있다.
    5. 한개의 토픽과 컨슈머 그룹에 대한 lag가 여러개 존재할때, 그 중 가장 큰 수의 lag을 records-lag-max라고 부른다
  9. 카프카 프로듀서
    1. 프로듀서는 데이터를 카프카로 보내는 역할을 한다.
    2. 역할
      1. 토픽에 해당하는 메시지를 생성
      2. 특정 토픽으로 데이터를 publish
      3. 처리 실패/재시도
        1. 전송 실패 여부에 따라서 재시도할 수 있다.
    3. Producer.send()
      1. 파티션이 2개이고 key가 지정되어있다면 key별로 순차적으로 각각의 파티션에 들어가지만, 해당 토픽에 파티션을 추가하는 순간 키↔ 파티션의 일관성은 보장되지 않는다. (그래서 나중에 파티션을 추가하는 것은 되도록이면 하지 않는다.)
  10. 카프카 컨슈머
    1. 컨슈머가 데이터를 가져가도, 해당 데이터는 사라지지않는다.
    2. 역할
      1. 토픽의 파티션으로부터 데이터 polling
      2. 파티션 오프셋 위치 기록(commit)
      3. 컨슈머 그룹을 통해 병렬처리
    3. poll()
      1. 브로커로부터 연속적으로 많은 데이터를 읽는 것
      2. poll메서드에 지정한 시간만큼 대기한 다음에 데이터를 가져온다.
    4. 컨슈머 그룹이 동일하고, 파티션이 2개인 경우
      1. 만약 컨슈머가 한개인 경우 2개의 파티션에서 데이터를 가져온다.
      2. 컨슈머가 2개인 경우는 각 컨슈머가 각각의 파티션을 할당하여 데이터를 가져온다.
      3. 만약 컨슈머가 3개인 경우는 마지막 컨슈머는 동작하지 않는다. (컨슈머의 개수는 파티션 개수보다 적거나 같아야한다.)
    5. 컨슈머 그룹2개 이고, 파티션이 2개인 경우
      1. 컨슈머 그룹끼리는 영향을 미치지 않는다.
      2. 왜냐하면 _consumer_offset토픽에는 에는 컨슈머 그룹별로 토픽별로 offset을 나누어 저장하기 때문이다.
  11. 카프카 멀티 클러스터링이란?
    1. 멀티 클러스터링이 되려면, 각각의 서버(또는 그룹)가 서로 독립적인 Kafka 클러스터를 형성해야 한다.
      1. 예를 들어:
        1. 서버 1~3 → 클러스터 A
        2. 서버 4~6 → 클러스터 B
        3. 이 경우에만 멀티 클러스터링으로 볼 수 있다.
    2. 단일 클러스터 vs 멀티 클러스터링의 차이

| 구성 요소 | 단일 클러스터 | 멀티 클러스터링 | | — | — | — | | 브로커 개수 | 모든 브로커가 하나의 클러스터에 속함 | 각 클러스터는 독립된 브로커 집합을 가짐 | | 토픽 관리 | 모든 브로커에서 동일한 토픽 관리 및 복제 | 각 클러스터는 독립적인 토픽 세트를 가짐 | | 운영 목적 | 단일 워크로드를 지원 | 지역 분산, 부하 분산, 운영 독립성 등 다양한 목적 | | 구성 | Spring Kafka 설정에 단일 클러스터 정보만 포함 | 각 클러스터에 대해 별도의 설정 필요 |

  1. 우리의 구성은?
    1. 3대의 서버에 Kafka와 Zookeeper가 설치되어 있음.
    2. Spring Kafka 설정에 3대의 서버 정보를 포함하여 클러스터를 구성.
    3. 브로커의 개수
      • Kafka는 각 서버에 하나의 브로커가 실행 (기본적으로 서버당 하나의 Kafka 프로세스)
      • 이 경우, 3대의 서버에 각각 브로커가 설치되어 있으므로 총 3개의 브로커가 있습니다.
      • 이 3개의 브로커는 하나의 클러스터를 구성합니다

    d. 현재 구성은 단일 Kafka 클러스터

    • 3개의 브로커가 하나의 클러스터로 작동하며 동일한 토픽을 관리하고, 서로 리더-팔로워 관계로 데이터 복제를 수행하는 구조
  2. 앞으로 적용해볼만한 것
    1. 카프카 커넥트를 통한 파이프 라인 구성