찰떡개발자 코딩

Kafka .. 요즘 개발자 공고를 보면 쉽게 볼 수 있는 기술이다.

그렇다면 Kafka가 무엇이고, 어디에 쓸수있을지 한번쯤은 생각해봐야된다!!.

Kafka Document : https://kafka.apache.org/documentation/

1). Kafka란?

Pub/Sub 모델을 기반으로 한 Message Queue이다. 요즘 MSA (Micro Service Architecture)가 유행..? 처럼 자리 잡고있는데, 이때 많이 사용하고 있다.

Kafka는 분산환경에 특화되어있는 특징을 가지고있다.

Scalable하다. (클러스터 구성 가능하다)

2). Kafka에서 사용되는 구성요소

2-1). Event or Message

Producer ( Publisher) 와 Consumer(Subscriber)가 주고받는 데이터(정보) 의 단위라고 생각하면 될것같다. 본인은 보통 메세지라고 사용한다.

2-2). Producer

Pub/Sub 모델 중 Publisher를 담당한다. Producer는 Kafka broker에 Topic을 정하여 해당 Topic을 기준으로 메세지를 발행하는 Client이다.

2-3). Consumer

Pub/Sub 모델중 Subscriber를 담당한다. Producer가 발행한 메세지 중 구독하고 있는 Topic에 발행된 메세지를 처리하는 Client이다. Producer가 Broker에 발행한 메세지를 당겨와 해당 데이터로 필요한 로직 / 프로세스를 수행한다.

2-4). Consumer Group

말그대로이다. 하나의 Topic을 구독하는 Consumer 들의 그룹인데, Topic 하나하나를 각각 한개의 Consumer가 처리하는 것보다 여러일꾼들이 처리시키는것이 효율적이지 않나!

그렇기 때문에 Group화 시켜서 Consumer를 사용하는데, Group화 된 Consumer들은 하나의 Topic을 기준으로 각각 다른 Partition의 메세지만 처리할 수 있다. 이방식을 통해 메세지를 처리하는 순서를 보장할수 있는데, 여기서 Kafka의 또다른 개념이 나오게된다. => Rebalance

Rebalance란?

Partition을 담당하던 Consumer가 멍청이가 된다면 해당 Partition의 메세지는 처리가 안됄거고,,, 그렇다면 해당 Partition 입구가 막혀서 못쓰게 되는것인가??

아니다.

Kafka는 똑똑하다.. Rebalance 즉 Consumer가 처리 불가한 멍청이 상태가 된다면 Consumer Group 내의 Consumer를 재조정(Rebalance) 하여 멍청이가 되지 않은 Consumer들이 해당 Partition의 일을처리하게 만든다.

2-5). Topic

Producer가 메세지를 발행하는 주제이며, Consumer가 구독(Event Listening)하고있는 주제이다.

Topic별 Producer와 Consumer를 각각 사용해서 원하는 이벤트별로 어플리케이션을 발행/구독하여 처리 시킬수 있다.

2-6). Broker

Producer와 Consumer가 메세지를 발행하고, 가져오고, 관리하는 Message Queue Broker이다. Broker에 올라온 메세지는 Topic별로 나뉘어 쌓이게 되고, 해당 Topic은 또다시 여러Partition으로 나뉘어 관리를 할수 있다. Queue이기 때문에 적재(?)정확히는 저장은아니다.. 메세지는 FIFO 순으로 처리되게 된다.

3). Commit & Offset

메세지가 Topic에 전달되고, Topic안에서 Partition으로 나뉘어 append될때 그 메세지의 상대위치를 Offset이라고 지칭한다.

Consumer가 Poll() 을 실행하면, 마지막으로 Commit한 메세지의 Offset을 기준으로 그다음 메세지를 읽어오게된다. 그 이후 방금 읽어온 메세지의 Offset을 다시 Commit하게 되는데, 이런방식으로 이전 메세지, 읽을 메세지를 구분하게 된다.

위와 같은 구조를 갖기 때문에 생기는 발생하는 문제점이있다.

만약 Consumer가 Broker에게서 메세지를 가져갈때마다 해당 메세지가 바로 소비(Used) 된것으로 기록되어진다면 Consumer가 정상적으로 메세지를 가져오지 못하거나 처리를 제대로 하지 못하면 해당 메세지는 의미없이 손실된다.

이때 멱등성이라는 말을 처음 듣게 되는데,,,

만약 위와 같이 손실되는것을 방지하기 위해 Broker가 Consumer에게 제대로 처리했다 라는 승인(Approval)을 받고 다됬으면 메세지가 소비된걸로 사용하면 되지않을까?  라고 생각하게 된다.

하지만 Consumer가 정상적으로 메세지를 처리했는데 Broker가 실패로 간주하여 다시 메세지를 보낸다면? Consumer는 중복 처리를 하게되는데, 이때 고려해야될 것이 바로 멱등성(idempotence) 이다.

메세지가 중복으로 들어왔더라도 한번 들어온것처럼 간주할수 있는 구조로 개발을 해야된다.

Producer를 멱등성 Producer로 만들어주는 Config가 있는것 같은데 차후에 사용시 다시 알아보도록 할래..

멱등성Producer Config Doc Url : https://kafka.apache.org/documentation/#producerconfigs

MQTT를 사용할때랑 비슷하게 메세지 전달 전략이 존재한다.

상기 전략은 다음에 다시 알아보도록 하자...!

기본 테스트 코드를 작성해놓았는데, 설치부터 설정 등 한번 정리하는 시간도 가져야겠다..