1. 기본적인 동작 원리

    Untitled

    1. Producer가 Source Application(데이터 전송) 역할을 하게 됨
    2. Consumer가 Target Application(데이터 수신) 역할을 하게 됨

  2. 토픽

    Untitled

    1. 데이터가 들어가는 폴더와 같은 역할(여려 개 생성 가능)
    2. 각 토픽의 이름은 명확하게 명시하는 것이 좋음(예 : send_sms)

  3. 토픽의 내부 구성

    Untitled

    1. 여러개의 파티션으로 구성되며 번호는 0부터 시작되며 큐 형식으로 Producer에 의해 내부 레코드가 저장됨
    2. Consumer는 데이터를 오래된 순서대로 가져가게 되며 가져간 레코드는 사라지지 않는데, 이 남은 데이터는 다른 Consumer가 사용할 수 있음(단, 컨슈머 그룹이 달라야하며, auto.offset.reset = earlier 옵션을 사용한 경우)
    3. 레코드를 다 가져가고 다음 레코드가 없으면 리스닝 대기함
    4. 파티션을 여러개 설정 가능하며, Producer가 레코드를 넣을 때 key를 지정하지 않는다면, round-robin 방식으로 번갈아가며 저장하게 됨
    5. 하지만, 파티션을 늘리는 것은 신중해야함 늘리는 것은 가능하지만, 줄이는 것을 불가능하기 때문임
    6. 파티션 내 레코드는 최대 보존 시간, 크기를 지정할 수 있는데 이를 초과하면 삭제됨
      1. log.retention.ms : 최대 레코드 보존 시간
      2. log.retention.byte : 최대 레코드 보존 크기(byte)

  4. 프로듀서

    1. 역할

      1. 토픽으로 전송할 데이터 생성
      2. 특정 토픽으로 데이터 전송(publish)
      3. 데이터 전송에 대한 성공/실패 처리 (재전송도 가능)

    2. 라이브러리

      Untitled

      1. 카프카 브로커와 클라이언트 각 버전 호환성을 확실히 해야함

    3. 예시 코드

      Untitled

      1. configs 변수는 설정을 정의하는 부분

      2. 첫번째 줄은 부트스트랩 서버 설정을 로컬 호스트의 카프카를 바라보도록 설정(카프카 브로커의 주소 목록은 최소 2개의 IP와 PORT를 가지도록 권장)

      3. 2, 3번째줄은 key와 value를 String으로 직렬화 한다고 선언하는 부분

        1. 여기서 키는 파티션을 지정할 때 쓰이는 부분

      4. producer변수를 통해 카프카 프로듀서 인스턴스 생성

      5. record는 전송할 객체를 만드는 부분이며 토픽, 키, 값 순서로 파라미터를 넣을 수 있음

        1. 예제 코드는 key를 사용하지 않아 round-robin방식으로 사용되도록 함
        2. key가 있는 경우
         new ProducerRecord<String, String> (”click_log”, “1”, “login”);

      6. send()메서드를 통해 레코드를 전송하게 됨

      7. 마지막으로 close를 통해 프로듀서를 종료함

    4. 예제 코드 작동 방식

      Untitled

      Untitled

      1. 밑의 사진처럼 key는 1,2, 이지만 파티션이 3개일 경우 매칭이 되지 않아 원하는 대로 안들어 갈 수 있음

  5. 카프카 브로커

    1. 카프카가 설치되어 있는 서버 단위를 말함

    2. 보통 3개 이상을 구성하여 사용하는 것을 권장

    3. 만약 partition: 1, replication : 1 인 경우 3개의 브로커가 있는 경우 1대에 데이터가 저장됨

      Untitled

    4. partition : 1, replication: 2인 경우 원본 1개와 복제본 1개로 다른 브로커에 구성됨

      Untitled

    5. 여기서 replication개수는 브로커의 개수보다 많을 수 없음

    6. 원본의 경우 Leader partition이라고 부름(read/write 수행)

    7. 복제본들의 경우 Follewer partition이라고 부름(주기적으로 리더의 데이터를 보고 복제만 함)

    8. 이 Leader, Follewer partition을 합쳐서 ISR(In Sync Replica)라고 칭함

    9. ISR은 현재 리플리케이션 되고 있는 리플리케이션 그룹을 말함

      1. ISR규칙 중 중요한 규칙은 ISR에 속해 있는 구성원 만이 리더 가능
      2. 리더는 팔로워들이 주기적으로 데이터를 확인하고 있는지 확인 일정 주기(replica.lag.time.max.mx)만큼 확인하고 요청이 오지 않는다면, 리더는 해당 팔로워 이상을 감지하고 해당 팔로워를 ISR에서 추방
      3. 위를 위해 ISR의 리더와 팔로워간의 데이터 동기화 작업을 매우 중요하게 처리함

    10. ISR을 사용하는 이유는 partition : 1, replication: 1인 경우 해당 브로커를 사용할 수 없게 된 경우 데이터 복구가 불가능 하게 됨을 방지하기 위함

    11. partition: 1, replication : 2인 경우 Leader partition이 위치한 브로커를 사용할 수 없게 된 경우 복제본인 Follewer partition이 Leader partition이 되며 데이터를 보존할 수 있음

    12. ack(프로듀서의 옵션)

      1. ack = 0 : 옵션을 사용할 경우 프로듀서는 Leader partition으로 데이터를 전송하고 응답을 받지 않음(속도는 빠르지만 데이터 유실 가능성 있음)
      2. ack = 1 : 프로듀서는 Leader partition으로 데이터를 전송하고 정상적으로 전송되었는지 응답을 받음 하지만 follower partition에도 정상적으로 전송되었는지 알 수 없음
      3. ack = all : 프로듀서는 Leader partition에 데이터를 전송하고 Follower partition까지도 제대로 전송되었는지에 대한 응답을 받음(속도는 느리지만, 데이터 유실 가능성 낮음)

  6. 컨슈머

    1. 다른 메세지 브로커와 큰 차이점은 큐 내부의 데이터를 가져가도 사라지지 않는다는 점

    2. 폴링 : 컨슈머가 파티션의 데이터를 가져오는 과정을 칭함

    3. 역할

      1. 토픽의 파티션에서 데이터를 폴링(가져와서 DB에 저장하는 등의 처리)
      2. 파티션 offset 위치 기록(offset : 파티션 내부 데이터의 위치)
      3. 컨슈머 그룹을 통해 병렬 처리 가능함

    4. 컨슈머 라이브러리

      Untitled

    5. 컨슈머 예시 코드

      Untitled

      1. 먼저 config 프로퍼티에 기본 설정을 해줘야함

      2. 프로듀서와 다른 점은 groud.id를 설정해주는 데 이부분이 컨슈머 그룹이며 예시코드에서는 click_log_group이라는 컨슈머 그룹에 속하게 됨

      3. subscribe()메서드를 통해 어떤 토픽에서 데이터를 가져올 지 선언함

      4. 특정 파티션의 데이터만 가져오려는 경우 작성하는 코드, assign을 통해 할당

        Untitled

      5. 폴링 루프 구문

        1. 폴링 루프는 poll메서드를 가진 무한 루프를 말함
        2. poll()메서드에서 파라미터로 주는 시간동안 데이터를 기다리게 됨, 해당 예시 코드는 500밀리세크 동안 기다리고 데이터를 가져옴

      6. 컨슈머가 데이터를 읽을 경우 컨슈머가 읽은 데이터의 offset을 저장하는 데 __consumer_offset에 저장되게 됨

    6. 멀티 컨슈머

      Untitled

      1. 같은 컨슈머 그룹의 경우 각 컨슈머는 서로 다른 파티션을 할당해야함
      2. 위의 이유로 파티션 개수보다 컨슈머가 많은 경우 남는 컨슈머는 작동을 하지 않으므로 파티션보다 컨슈머 개수가 작거나 같게 되도록 해야함

    7. 멀티 그룹 컨슈머

      Untitled

      1. 어떤 토픽에 대해 2개의 컨슈머 그룹이 존재하는 경우 서로의 컨슈머 그룹에는 영향을 미치지 않는다
      2. 즉, 서로 다른 컨슈머 그룹의 컨슈머는 같은 파티션에 대해 접근할 수 있음
      3. 각각의 offset을 따로 저장하기 때문에 서로 영향을 신경쓰지 않아도 됨

  7. 카프카 설치 및 실행(2.8.0 기준)

    1. 참조 블로그 : https://herojoon-dev.tistory.com/118
    2. 설치 : https://kafka.apache.org/
    3. DOWNLOAD KAFKA → 2.8.0 → Binary donwloads → Scala 2.13
    4. 다운로드 받은 파일 압축해제 하면 kafka_2.13-2.8.0 폴더생김
    5. 해당 폴더에서 집중해야 햐는 부분은 bin, config 패키지
    6. bin/windows:zookeeper, kafak 실행 bat파일 들어있음
      1. kafka 실행, 종료 파일
        1. kafka-server-start
        2. kafka-server-stop
      2. zookeeper 실행, 종료 파일
        1. zookeeper-server-start
        2. zookeeper-server-stop
    7. config:zookeeper, kafka config 파일 들어있음
      1. 프로퍼티 정보 담은 cofnig 파일 이름
        1. server.properties
        2. zookeeper.properties
    8. 실행

      1. zookeeper 실행(폴더 경로에서 그대로 입력)

        bin\\windows\\zookeeper-server-start.bat config\\zookeeper.properties

      2. zookeeper실행 후 정상 작동하는지 port 확인

        netstat -na | findstr “2181”

      3. 새로운 cmd창 실행

      4. kafka 실행

        bin\\windows\\kafka-server-start.bat config\\server.properties

      5. kafka 실행 후 정상작동하는지 port 확인

      6. 만약 실행 중 오류 발생 시 c:/tmp위치에 로그 생성됨 이전에 설치했던 경우라면 해당 폴더 삭제하고 다시 실행(이후에도 오류난다면 재설치)

      7. kafka topic 생성

      8. kafka topic 생섬 확인

      9. 위 코드로 토픽이 생성된다면 C:/tmp/kafka-logs위치에도 topic폴더가 생성

      10. 카프카 cmd 기본 명령어

  8. 간단한 테스트

  9. 컨슈머 Lag이란

  10. 카프카 Lag 모니터링

  11. 카프카를 설치하지 않고 사용하는 방법

  12. 카프카 구성요소 정리

  13. 구현