6th Oracle Developer Meetup
작성일 | In

[6th] Oracle Developer Meetup 카프카(Kafka) 제대로 이해하기 후기

[6th] Oracle Developer Meetup 카프카(Kafka) 제대로 이해하기 후기

  • Oracle Developer Meetup에 올해만 벌써 세 번째 참석하게 되었다. 이번 Meetup의 주제는 최근 핫이슈인 카프카(제가 늦었을 수도..)였다.
  • 평소에 많이 궁금해하던 주제여서 망설임 없이 바로 신청하고 다녀왔다.
  • 1시간 30분 동안 진행되었던 고승범 님의 세션을 짧게 정리해보았다.

[Main Session] 카프카, 데이터 플랫폼의 최강자 | 고승범, 카카오 시스템셀 인프라팀

  • KAFKA 실시간 비동기 스트리밍 솔루션 KAFKA의 기본부터 확장 응용까지

  • 고승범(일명 피터)
    • 카카오 인프라팀 소속
    • 카프카, 데이터 플랫폼의 최강자 저자
    • 페이스북 KAFAKA 한국 사용자 그룹 개설자
    • Popit.kr 저자, 개인 브랜치 운영 중
  • 오늘 나눌 이야기
    • KAFKA와 첫 만남
    • KAFKA 란?
    • USE Cases
    • Producer
    • Consumer
    • Operational tip

KAFKA와 첫 만남

  • 시스템 엔지니어랑 업무, Kafka 요청이 많이 들어와서 알아보기 시작함
  • message 브로커, A service -> B services ? 의미가 잘 와닿지 않아 학습 시작
  • 카프카를 운영해달라는 요청 들어옴 -> 전사 공용 KAFKA 오픈하자

KAFKA 란?

  • 시작은, Linkedin
    • Linkedin에서 2011년대에 개발해서 오픈소스로 공개 하게 됨
    • Linkedin 초기에는 http 요청과 응답, 요을청에 대해 응답 지연이 발생할 수 있음 -> 연쇄적인 문제가 발생할 수 있음
    • 배치작업 실시간 처리 필요 등의 이유로
    • 액티브 MQ 도입 But, 처리랑 한계 도달.
    • 따라서, 높은처리량을 목표로 설계
      • High Throughput
      • 실시간 로그 통합
      • 무중단(장비의 장애)
      • 이기종과의 호환성
      • 간단한 스케일 아웃
      • 프로듀서의 컨슈머 역할 분리
      • 프란치 카프카의 이름을 따서 카프카로 이름 지음
  • Producer, 프로듀서(카프카로 메시지 보내는 역할)
  • Kafka Clustor, 카프카(메시지가 저장되는 곳)
    • 가장 작은 단위 offset
    • 실제 메세지는 파티션 안에 저장됨
    • offset을 이용한 위치 기록 ( offset 번호로 처리)
    • 파티션 여러개 모여서 토픽
    • 토픽여러개 모여서 브로커
    • 브로커 여러개 모여서 카프카 클러스터
    • offset < 파티션 < 토픽 < 브로커 < 카프카 클러스터
  • Consumer, 컨슈머(메시지를 받는 곳)
  • Zookeeper, 주키퍼(별도의 코디네이터 프로그램)

USE Cases

  • 마이크로 서비스 아키텍처, RabbitMQ

실제 사례

  • 로그를 통합하고 싶어요
  • CS때문에 각 서버에서 GREP 하고 있어요
    • 구조는 MSA 아키텍처였음
    • 추가 API 개발 및 배포에서 관리가 어려움
    • 백엔드 시스템 장애가 나서 응답을 못주게 되면 백엔드 뿐만 아니라 서비스 쪽에도 영향을 미치게 됨
  • 해결
    • 실시간, RealTime
      • 로그 수집기를 통해 KAFKA에 실시간으로 넣음 (라인단위로)
      • 각각의 서버에서 KAFKA에 있는 로그 가져감 (엘라스틱 서치, 키바나 같이 사용)
    • 유연성
    • 확장 가능성

Producer

  • 카프카로 메세지를 보내는 역할
  • 카프카로 메시지를 안전하게 보내줘야함
  • Producer 옵션
    • ACKS
    • ACKS = 0
      • 매우 빠르게 전송할 수 있지만, 파티션의 리더가 받앗는지 알 수 없음.
    • ACKS = 1 (Strongly Recommend)
      • 메시지 전송도 빠른 편이고, 파티션의 리더가 받았는지 확인
      • 가장 많이 사용되고, 대부분 기본값으로 설정
    • ACKS = ALL
      • 메시지 전송은 느리지만, 손실 없는 메시지 전송 가능

Consumer (가장 중요)

  • 카프카에서 메시지를 꺼내오는 역할
  • 프로듀서는 카프카로 push, 컨슈머는 카프카로부터 pull
  • 컨슈머가 파티션에 붙어서 메시지를 가져갈 때는 파티션의 오프셋 순서대로 가져감
  • 컨슈머는 메시지 내용을 알 수 없음, 오프셋 번호만 알고 가져 올 수 있음
  • 파티션이 1개면 순서가 보장됨
  • 토픽의 파티션이 2개 이상이 되면 컨슈머가 메시지를 가져오는 순서가 보장이 안 됨
    • 하나의 파티션에 있는 오프셋은 순서가 보장됨.
    • 타임스탬프 등을 사용하여 순서 보장할 수 있음
  • 하나의 파티션에는 하나의 컨슈머만 가능
    • 컨슈머 추가시 파티션을 같이 추가 해줘야 함
    • 컨슈머 수와 파티션 수를 일치시켜줘야 최대 성능 낼 수 있음
      • 아니면 노는 컨슈머가 생김
    • 컨슈머 그룹은 그룹 - Oracle Developer Meetup에 올해만 벌써 세번째 참석하게 되었다. 이번 Meetup의 주제는 최근 핫이슈인 카프카(제가 늦었을 수도..)였다. 내에서 정보를 공유
      • 다른 컨슈머가 죽으면 그 죽은 컨슈머의 정보를 다른 컨슈머가 받아서 처리하게 됨
      • 2개의 컨슈머 역할을 하므로 일시적인 처리량이 떨어지긴 함
    • 카프카는 메시지를 기본값으로 7일간 보관
      • 전통적인 amqp에 위배되긴함.
    • 컨슈머 그룹을 이용한 멀티 컨슈머 가능
      • 여러 컨슈머 그룹들이 카프카로부터 메시지를 가져갈 수 있음

OPERATIONAL TIP

  • Monitoring
    • JMX enable
  • kafka manager
    • yahoo 에서 공개한 툴
    • 클러스터 관리
    • 토픽, 오프셋, 브로커, 파티션 정보 확인
    • 깃헙 존재
  • LAG (뒤에 처지다, 뒤떨어지다.)
    • 프로듀서가 10개의 메시지를 보내고 컨슈머가 10개의 메시지를 다들고가면 LAG=0
    • 프로듀서가 10개의 메시지 보내고 컨슈머가 5개만 가져가면 LAG=5
    • COMMAND로 확인 활 수 있음
    • Burrow
      • kafka consumer lag checking
      • http, json 형태로 화인
      • go lang으로 만듬
  • 카프카 데이터 저장방식은 log file로 파일 단위로 저장됨.

후기

  • 다음 세션(관리형 Kafka 서비스 Oracle Event Hub Service)은 개인적인 사정으로 참석하지 못했다.
  • 추가적인 Q&A 시간에 ELK 스택에서 Logstash와 카프카가 의미적으로 다른지 어떻게 사용하면 좋을지에 대한 질문이 오갔었는데, 현재 사내에서 ELK 스택으로 로그 분석 시스템을 도입할려고 준비 중인 나로서는 많은 도움이 되었다.
    • ELK 스택과 카프카를 같이 사용하면 좋다는 답변.
  • 카프카가 무엇인지 앞으로 어떻게 공부하면 좋을지에 대해 어느 정도 감을 잡아준 유익한 시간이었던 것 같다.
  • 마지막으로 좋은 자리 마련해주신 모든 분들께 감사합니다 :)

본문의 내용은 제가 이해한 대로 작성하였기 때문에 틀린 부분이 있다면 댓글로 피드백을 부탁드리겠습니다. 감사합니다.

facebook share twitter share
0%