[빗썸테크아카데미] 열한번째, 열두번째 - Event Driven Microservice와 Kafka

 

 

[빗썸테크아카데미] 열한번째, 열두번째 - Event Driven Microservice와 Kafka

 

 

열한번째 시간인 월요일에는

저번주에 과제 리뷰하고 발표하느라 하지 못했던

질문들을 다 모아서 답변을 해주시고

 

이주간 배웠던 내용들을 복습하고

강사님은 어떻게 DDD를 설계하시는지 예시들을 보여주시며

리프레시 하는 시간을 가졌다.

 

2주동안 달려서

조금 힘들었는데

쉬어가는 타임이라 좋았다.

 

이날은 진도를 나간게 없어서

간단하게 끝

 

 

---

 

열한번째 시간에는

EDA 복습과 Event Driven Microservice, kafka에 대한 수업 진도를 나갔다.

원래 코드를 보여주면서

실습을 하면서 수업을 진행하시려고 하셨었는데

 

강사님이 손목이 너무 아프셔서

예제 진행은 못하고

준비해오신 강의자료만 설명해주시고

일찍 끝났다!

 

 

 

 

---

 

 

 

1. MSA

1.1 MSA의 특징

• 전통적인 하나의 큰 Application을 여러개로 쪼개는 설계
• Loosely Coupling

 

 

1.2 MSA 시도

첫 의도는 좋았다.

-> 처음에 의도한 MSA 설계. 하나의 큰 어플리케이션을 세개로 쪼개어 사용했다.

 

 

 

 

-> 그러나 마이크로 서비스들이 많아지면서 서로가 서로를 참조하는게 너무 많아지고, 내부 호출도 많아지고, 모놀로틱에서는 발견되지 않았던 여러가지의 문제점이 발생함.

 

 

 

1.3 MSA의 문제점

구조적 문제점

• 개발 복잡도
• 운영에 필요한 숙련도
• 트랜잭션 관리
• 통합 테스트의 고난
• 배포 복잡도

 

 

 

2. EDA

-> MSA만으로는 너무 힘들어서 나온 아키텍쳐

 

Event Driven이란

Event를 생성하는 서비스(Producer)가 Event를 만들어서 Event Bus에 넣어두면 Event 소비하는 서비스(Consumer)가 필요한 Event를 가져다 사용하는 구조

 

 

 

3. Event broker와 Message broker

Event broker

• 대규모 엔터프라이즈 환경의 미들웨어로서 기능
• Message 처리 후 바로 삭제
• Redis, RabbitMQ...

 

Message broker

• Message broker에 기능을 추가한 것
• Event별로 관리
• Access Offset 통해 접근 -> 뭘 읽고있는지 저장해 두었다가 걔를 통해 접근
• Event 처리 후 삭제 X
• 장애 발생 시 재처리 가능
• 대량 스트리밍 처리
• kafka, Kinesis

 

 

 

4. Event broker - kafka

     kafka : Event Bus 구현체의 하나(무려 LinkedIn이 만든 오픈소스)

 

 

카프카를 사용하면 이렇게 이쁘게 만들 수 있음

로깅과 모니터링이 필요한 애들은 kafka에 들어가서 쌓이고, monitor와 logger는 본인이 해야할 Event들을 kafka에서 가져다가 사용

 

 

4.1 kafka의 장점

• MSA의 복잡도 해결

      Source <> target coupling 끊기

• Topic으로 event 관리
• 짧은 시간에 많은 데이터를 Consumer로 전달
• Scalability
• Fault Tolerant
• Undeleted log

 

-> 사실 Kinesis도 똑같은 특성이 있지만, kafka가 더 먼저 나와서 더 많이 사용

 

 

 

4.2 kafka의 주요 개념

4.2.1 Topic 

 

• kafka에서 다루는 이벤트 묶음
• 이름 지정해서 구별

 

 

 

• Partitioning 확장 가능 (축소 X)
• Partition이 여러개 일때 key 지정해서 구분 가능
• Key : Partition = 1 : 1
• Key와 Partition의 개수가 다르면 hashing이 해제 됨
• Key가 지정되어 있지 않으면 Round Robbin(파티션이 N개 있으면 하나씩 돌아가면서 수행)

 

 

4.2.2 Broker

• Kafka Server
• Topic이 저장되는 곳
• 삼중화 이상 권장

 

 

 

4.2.3 Producer

• Broker로 Topic을 발행하는 App
• Apache kafka library dependency 추가 -> kafka broker와 client version 호환 확인
• Broker ip, port는 2개 이상 설정 -> Fault Tolerant

kafka producer 예제

 

 

 

 

4.2.4 Consumer

• Topic data poling 하는 App
• 읽은 후 Partition offset 위치 commit
• Consume해도 offset만 변경될뿐, Event가 사라지는것은 아님
• Producer와 같은 Apache kafka library dependency 추가

 

 

Consumer Group

• Consumer는 Group으로 관리 가능
• Partition이 Consumer보다 많을 경우 비효율적이기 때문에 같은 consumer를 여러개 복제해서 그룹으로 사용
• Consumer1이 Partition1의 3번째 offset을 읽으면, Consumer2는 Partition2의 3번째 offset을 읽는다.
• Consumer가 Partition보다 많을 경우 노는 Consumer가 생기니 주의!

 

 

 

4.2.5 Replication

• kafak의 고가용성 확보의 핵심 기능
• Partition 복제 -> Broker 갯수만큼

 

• 원본 1을 다른 broker에 복제
• Leader를 사용할 수 없는 이슈 발생 시 Follower 하나가 Leader가 됨

 

Replication 운영정책

• Producer가 broker로 send할 때 ACK 수신
• ACK 0 : 보내고 끝. 속도 높음. 신뢰도 낮음
• ACK 1 : 적재 완료 확인
• ACK 2 : 적재 완료 및 Replication까지 확인. 속도 낮음. 신뢰도 높음

 

 

 

 

 

 

 

 

 

---

 

 

카프카 말로만 들었을 때는 뭔가

엄청 어려운건줄 알았는데

 

실제로 코드를 보니

생각보다 간단했다.

 

요즘 새로운 개념들을 도입해보면서 느끼는건데

진짜 라이브러리들이 잘되어있어서

 

디펜던시 한개 추가해주고

컨피그 파일 한두개 만들어주고

어노테이션이면

웬만한 개발은 다 되는것 같다는 것을 느낌...