[Kafka] Kafka 기본 개념

이홍준·2024년 2월 22일
Apache KafkaMessagebrokerkafkamessage brokermsazookeeper
0

Kafka

목록 보기
2/2
post-thumbnail

대규모 프로젝트에 사용하는 각 서비스들의 통신 방법 중에 대표적인 사례로 kafka가 있다. 해당 기술에 대한 개념과 실습 예제로 간단히 작성하고자 한다.

카프카를 구성하는 요소

  • ZooKeeper: 카프카의 메타데이터 관리 및 브로커의 health check를 담당한다.
  • Kafka cluster: 여러 대의 브로커를 구성한 클러스터
  • Broker: 카프카 애플리케이션이 설치된 서버 또는 노드를 말한다.
  • Producer: 카프카로 메시지를 보내는 역할을 하는 클라이언트
  • Consumer: 카프카에서 메시지를 꺼내가는 역할을 하는 클라이언트
  • Topic: 카프카는 메시지 피드들을 토픽으로 구분하고, 각 토픽의 이름은 카프카 내에서 공유한다.
  • Partition: 병렬 처리 및 고성능을 얻기 위해 하나의 토픽을 여러 개로 나눈 것
  • Segment: 프로듀서가 전송한 실제 메시지가 브로커의 로컬 디스크에 저장되는 파일
  • Message or Record: 프로듀서가 브로커로 전송하거나 컨슈머가 읽어가는 데이터 조직

예제로 사용할 docker-compose

# compose 파일 버전
version: '3'
services:
  # 서비스 명
  zookeeper:
    # 사용할 이미지
    image: wurstmeister/zookeeper
    # 컨테이너명 설정
    container_name: zookeeper
    # 접근 포트 설정 (컨테이너 외부:컨테이너 내부)    
    ports:
      - "2181:2181"
  # 서비스 명
  kafka:
    # 사용할 이미지
    image: wurstmeister/kafka
    # 컨테이너명 설정
    container_name: kafka
    # 접근 포트 설정 (컨테이너 외부:컨테이너 내부)
    ports:
      - "9092:9092"
    # 환경 변수 설정
    environment:
      KAFKA_ADVERTISED_HOST_NAME: localhost     
      KAFKA_CREATE_TOPICS: "Topic:1:1"
      KAFKA_ZOOKEEPER_CONNECT: zookeeper:2181
    # 볼륨 설정
    volumes:
      - /var/run/docker.sock
    # 의존 관계 설정
    depends_on:
      - zookeeper

ZooKeeper로 kafka 클러스터를 관리해줘야 하기 때문에 docker-compose로 실행함으로써 네트워크를 연결한다.

Replication

카프카에서는 각 메시지들을 여러 개로 복제해서 클러스터 내 브로커들에 분산 시키는 동작을 한다.

그래서 하나의 브로커가 종료되더라도 나머지가 살아있기 때문에 안정성을 유지할 수 있다.

  • Replication factor 파티션 복제본의 개수에 대한 설정이다. 복제본의 개수를 설정하는 방식이므로 2개로 지정하면 총 개수는 3(1+2)개이다.

    • factor 값이 클수록 실행되는 파티션이 많으므로 안정성은 증가한다.

    • 당연히 그만큼 리소스를 많이 사용하므로 오버헤드를 고려해야 한다.

      factor 수를 정하는 기준을 나름대로 정리해 보면,

    • 테스트 or 개발 환경: 1개

    • 운영 환경(log 관련 메시지로 약간의 유실 허용): 2개

    • 운영 환경(유실 허용하지 않음): 3개

      그 이상도 사용할 수 있지만 일반적으로 3까지만 사용해도 충분하다고 한다.

Partition

기본적으로 토픽 하나당 하나의 처리만 가능하다. 그래서 토픽 하나를 파티션으로 여러개 나눔으로써 병렬 처리를 가능하도록 해주는 것이다. 그래서 분산 처리도 가능하게 한다.

파티션 수도 직접 설정할 수 있다. 파티션을 정하는 기준은 어느정도 공식이 존재한다고 하지만 메시지 크기 또는 초당 메시지 건수에 따라 달라지는 조건도 고려해야 한다.

  • 주의 사항
    • 위 그림과 다르게 파티션 번호는 0부터 시작한다.
    • 파티션 수는 늘릴 수는 있지만 반대로 줄일 수는 없다.
    • 파티션의 개수는 2 or 4 정도로 생성한 후에 모니터링하며 조금씩 늘리는 방법을 권장
    • LAG(producer가 생성한 메시지 수 - consumer가 받을 메시지 수 ) 지표에 따른 기준으로함
    • https://eventsizer.io/ 에서 적절한 파티션 수를 계산해준다.

Segment

프로듀서를 이용해 보낸 메시지는 토픽의 파티션에 저장된다. 그리고 Segment라는 log파일 형태로 브로커의 로컬 디스크에 저장된다.

  • 예시

    1. kafka 컨테이너로 접근 후에 kafka log 폴더로 이동

    2. ls 로 디렉토리 확인후 cd로 해당 디렉토리로 이동

    3. 해당 디렉토리 확인

    4. offset이 아닌 설정한 “토픽이름-0” 디렉토리로 이동(예시:rooms-0)

    5. ls 출력: 해당 디렉토리는 rooms라는 토픽의 0번 파티션 디렉토리를 나타낸다.

    6. xxd 명령어로 해당 log파일 출력(없으면 xxd 설치)

      해당 출력 오른쪽에 보면 kafka를 통해 통신했던 메시지들이 기록되어 있다.

핵심적인 개념 정리

  1. 분산 시스템
    • 네트워크상에 연결된 컴퓨터 그룹으로 높은 성능을 목표로 한다.
    • 다수의 시스템으로 인해 SPOF(단일 장애점)를 방지한다.
    • 리소스 초과시 Broker의 수를 늘리기만 하면 되기 때문에 Scale-out에 용이하다.
  2. Page cache
    • 직접 디스크에 읽고 쓰는 대신 물리 메모리 중 애플리케이션이 사용하지 않는 일부 잔여 메모리를 사용한다.
    • 디스크 I/O에 대한 접근 빈도가 줄어들어서 성능을 높일 수 있다.
    • 원래 OS에서 사용하던 방식이다.
  3. Batch
    • 통신을 묶어서 보냄으로써 네트워크에 대한 오버헤드를 줄일 수 있음
    • 장기적으로 더욱 빠르고 효율적으로 처리함
  4. 압축 전송
    • 메시지 전송 시 좀 더 성능이 높은 압축 전송을 사용한다. → gzip, snappy, lz4, zstd등 사용
  5. 고가용성
    • Replication을 통해 안정적인 서비스가 가능해져서 안정성 증가

References

profile
이홍준
I'm a web developer.
이전 포스트

[Kafka] Message Queue

0개의 댓글