1) apache kafka

1.kafka 개념

카프카란? 카프카(Kafka)는 파이프라인, 스트리밍 분석, 데이터 통합 및 미션 크리티컬 애플리케이션을 위해 설계된 고성능 분산 이벤트 스트리밍 플랫폼이다.
Pub-Sub 모델의 메시지 큐 형태로 동작하며 분산환경에 특화되어 있다.

 

2. kafka 사용 장점

kafka 적용 전kafka 적용 후

각 애플리케이션과 DB가 end-to-end 로 연결되어 있음(각 파이프라인이 파편화 되어있음) 요구사항이 늘어남에 따라 데이터 시스템 복잡도가 높아지면서 다음과 같은 문제가 발생  1. 시스템 복잡도 증가 (Complexity) - 통합된 전송 영역이 없어 데이터 흐름을 파악하기 어렵고, 시스템 관리가 어려움 특정 부분에서 장애 발생 시 조치 시간 증가 (=> 연결 되어있는 애플리케이션들을 모두 확인해야 하기 때문에) HW 교체 / SW 업그레이드 시 관리포인트가 늘어나고, 작업시간 증가 (=> 연결된 애플리케이션에 side effect 가 없는지 확인해야 함)  2. 데이터 파이프라인 관리의 어려움 - 각 애플리케이션과 데이터 시스템 간의 별도의 파이프라인 존재하고, 파이프라인 마다 데이터 포맷과 처리 방식이 다름 새로운 파이프라인 확장이 어려워지면서, 확장성 및 유연성이 떨어짐 또한 데이터 불일치 가능성이 있어 신뢰도 감소

카프카를 적용함으로써 앞서 말했던 문제점들이 어느정도 완화되었다. 모든 이벤트/데이터의 흐름을 중앙에서 관리할 수 있게 됨 새로운 서비스/시스템이 추가돼도 카프카가 제공하는 표준 포맷으로 연결하면 되므로 확장성과 신뢰성이 증가 개발자는 각 서비스 간의 연결이 아닌, 서비스들의 비즈니스 로직에 집중 가능 → 대규모 트래픽 처리 및 분산 처리에 효과적 → 클러스터 구성, fail-over, replication 같은 기능이 있음 → 100kb/sec 정도의 속도 (다른 메세지 큐 보다 빠름) 디스크에 메시지를 특정 보관 주기동안 저장하므로 데이터의 영속성이 보장되고 유실 위험이 적음. 또한 consuermer장애 시 재처리가 가능.

3. kafka 무엇을 위해 사용하면 좋은지

1. 서로 다른 구성 요소 간의 안정적인 데이터 교환
2. 데이터 처리를 위한 실시간 스트리밍
3. 어플리케이션 요구 사항 변경에 따라 메시징 워크로드를 분할
4. 데이터/메시지 재생에 대한 기본 지원
5. 데이터 허브( Line 에서 kafka 사용하는 방법 中 1 )

 

4.kafka 동작 방식 및 특징

• kafka는 pub-sub 모델의 message Queue 형태로 동작

정보를 제공하는 자                               producer의 데이터를 임시 저장 및 consumer에게 제공             정보를 제공받아서 사용하려는 자

 

→ mesaage Queue에서 메세지는 endpoint 간에 직접적으로 통신하지 않고, queue를 통해 중개 된다.

message queue : 비동기 메세징 전송 방식으로, 메세지에는 수신자가 정해져 있지 않은 상태로 publish 함. 이를 subscribe한 수신자만 정해진 메세지(topic)을 받을 수 있음.

수신자는 발신자 정보가 없어도 원하는 메세지만 수신할 수 있음 ( 높은 확장성 확보 可 )

 

• 구성 요소

용어의미 및 특징

Event	kafka에서 producer 와 consumer가 데이터를 주고받는 단위. 메세지
Producer	kafka에 이벤트를 게시(post, pop)하는 클라이언트 어플리케이션 메시지를 만들어서 카프카 클러스터에 전송 메시지 전송 시 batch 처리 가능 key 값을 지정하여 특정 partition으로 전송 가능 전송 acks 값을 설정하여 효율성 증가
	ACKS=0 : 매우 빠르게 전송, 파티션 리더가 받았는지 모름  ACKS=1 : 파티션 리더가 받았는지 확인 (default)  ACKS=2 : 파티션 리더 뿐만 아니라, 팔로워까지 메시지를 받았는지 확인
Consumer	Topic을 구독하고 이로부터 얻어낸 이벤트를 받아(Sub) 처리하는 클라이언트 어플리케이션 카프카 클러스터에서 메시지를 읽어서 처리 메세지를 batch 처리할 수 있음 한 개의 컨슈머는 여러 개의 토픽을 처리할 수 있음 메시지를 소비하여도 메시지를 바로 삭제하지 않음 (kafka  delete policy에 의해 삭제) 한 번 저장된 메시지를 여러 번 소비도 가능 consumer는 consumer group에 속함 한 개의 파티션은 같은 컨슈머 그룹의 여러 개의 컨슈머에서 연결 불가
Topic	이벤트가 모이는 곳. producer는 topic에 이벤트를 게시하고, consumer는 topic을 구독해 이로부터 이벤트를 가져와 처리. 게시판 같은 개념 각각의 메시지를 목적에 맞게 구분할 때 사용 consumer는 자신이 담당하는 topic의 메시지를 처리하며 한개의 토픽은 한 개 이상의 파티션으로 구성
Partition	Topic은 여러 Broker에 의해 분산되어 저장되며, 이렇게 분산된 topic을 partition이라고 함 topic 생성 시 partition의 개수를 지정할 수 있음(파티션 개수 변경 가능, 단 추가만 가능) 파티션 내부에서 각 메세지는 offset(고유 번호) 로 구분 파티션이 여러 개라면 kafka 클러스터가 round robin 방식으로 분배해서 분산처리되기떄문에 순서가 보장되지 않음 파티션이 많을수록 처리량이 좋지만 장애 복구 시간이 늘어남
Zookeeper	분산 메시지의 큐의 (메타)정보를 중앙에서 관리, 분산 application 관리를 위한 코디네이션 시스템
broker	실행된 카프카 서버. producer와 consumer는 별도의 AP로 구성되는 반면, broker는 카프카 자체임.  broker(각 서버)는 kafka cluster 내부에 존재 서버 내부에 메시지를 저장하고 관리하는 역할 수행
controller	kafka cluster 내의 broker 중 하나가 controller가 됨 controller는 zookeeper를 통해 broker liveness를 모니터링 controller는 leader와 replicat 정보를 cluster내의 다른 broker들에게 전달 controller는 zookeeper에 replicas 정보의 복사본을 유지한 다음 더 빠른 액세스를 위해 클러스터의 모든 broker들에게 동일한 정보를 캐시함 controller의 leader 장애시 leader Election을 수행 controller가 장애가 나면 다른 Active broker들 중에서 재선출됨

 

• 동작 원리

publisher는 전달하고자 하는 메세지를 topic을 통해 카테고리화 함. subscriber는 원하는 topic을 구독함으로써 메세지 수신

publisher와 subscriber는 오로지 topic정보만 알 뿐, 서로에 대해 알지 못함. kafka는 broker들이 하나의 클러스터로 구성되어 동작하도록 설계.

클러스터 내 borker에 대한 분산처리는 zookeeper가 담당

 

5. 주요 설계 특징

• 왜 하나의 topic을 여러 개의 partition으로 분산시키는가?

→ 병렬로 처리하기 위해 분산 저장. 카프카의 토픽에 메세지가 쓰여지는 것도 어느정도 시간이 소비되는데, 몇 천 건의 메세지가 동시에 카프카에 write 되면 병목현상 발생 可

    따라서 파티션을 여러 개 두어서 분산 저장함으로써 write 동작을 병렬로 처리할 수 있음

    (다만, 한 번 늘린 파티션은 절대 줄일 수 없기 때문에 운영 중에 파티션을 늘려야 하는 경우 충분히 검토 후 실행되어야 함. 일단 최소한의 파티션으로 운영하다가 사용량에 따라 늘리는 것을 권장)

→ 파티션을 늘렸을 떄 메세지는 Round-Robin 방식으로 쓰이므로 하나의 파티션 내에서는 메세지 순서가 보장되지만, 파티션이 여러 개일 경우 순서가 보장되지 않음

 

• 컨슈머 그룹은 왜 존재할까?

→ consumer 묶음을 consumer group이라고 일컫음

    컨슈머 그룹은 하나의 topic에 대한 책임을 갖고 있음, 따라서 어떤 consumer가 down된다면, 파티션 재조정(rebalancing_을 통해 다른 컨슈머가 해당 파티션의 sub을 맡아서 함

    offset 정보를 그룹 간에 공유하고 있기 때문에, down되기 전 마지막으로 읽었던 메세지 위치부터 시작