강연정리) EKS + Kinesis = CQRS

EKS + Kinesis = CQRS (강남언니) 2024.6.6

EKS를 이용한 SAAS 서비스 아키텍쳐

해결해야 했던 문제

• Saas 효율화를 위한 → Multi Tenancy 환경을 구축해야 한다
  • Multi Tenancy → 단일 인스턴스가 여러 고객에게 서비스를 제공하는…
• 복잡한 도메인 서비스를 빠르게 개발 → 운영할 수 있어야 한다
• 각 제품의 대한 분리된 인프라 제공
  • 데이터 분리

Architecture

• IRSA
  • 서비스 권한 분리
  • https://somaz.tistory.com/238
• Secrets Store CSI Driver
  • 비밀키 관리

어떻게 시스템 분리를 하였는가? → Namespace 분리

EventSourcing + CQRS

• 강남언니는 어떤 요구때문에 CQRS를 적용했는가?
• 병원의 요구사항
  • 누가, 언제, 어떤 작업을 했는지 → 감사로그 → 필요
  • 매출 통계, 결제 내역 등 과거의 기반한 통계 → Zent에서도 필요
• 제품적 요구사항
  • 발생한 이벤트의 따라 달라지는 프로세스
  • 이벤트별로 제공되어야 하는 푸쉬알림이나 문자 메시지 → Zent랑 얼추 비슷함?

EventSourcing

• 일반적인 DB는 상태를 저장하고 → 상태를 계속 변경함 (Update…)
• EventSourcing 상태를 발생하기위한 모든 이벤트를 저장 → 상태 자체를 이벤트기반으로…
  • 이 이벤트를 차례대로 재생하면 현재의 상태를 알수있다
  • 계속 남긴다 그냥

디테일한 예시 (예약변경)

1. 고객은 예약변경을 하고싶어 한다 → 예약변경 API를 호출한다

2.예약변경이란 명령이 HeadSpring으로 전달된다. ( 이건 SQS인가? )

3. HeadSpring은 변경명령이 왔다면 → EventStore를 통해서 지금까지 모든 이벤트를 조회를 한다

4. 조회된 이벤트를 스케쥴 이란 상태로 만들어낸다

• 가장 최신의 이벤트로 만들어 낸다.
• 스케쥴이란 → 고객이 점유한 데이터를 그냥 스케쥴이라고 명명

5.예약변경 명령 실행기에 전달해서 → 이벤트를 만들고 → 이벤트 스토어에 저장한다. → MessageBus를 이용해서 Kinesis에 전달한다

• Kinesis를 Message Broker로 사용함

 

그런데, 허들이 있었다.

• 예를들어서 2월 13일의 스케쥴을 알고싶어
• 그럼 2월 13일에 모든 데이터를 읽어서 → 스트림 재생과정을 거쳐서 → 필터링 → 부하

허들을 극복 → CQRS (효율적인 조회모델)

• 명령과 조회를 각각의 모델을 사용함
• EventSourcing → EventSourcing 모델
• 조회 → 조회모델
• Kinesis DataStream을 구독하기 위해서 → Spring Cloud + Kinesis Client Library

왜 Kinesis Data Stream을 Message Broker로 사용했을까?

• MSK, Kafka, SQS 많은 서비스가 있는데 왜? KDS일까?
• 원래는 Apache Kafka를 고민했지만 → Kafka Cluster를 관리하는 리소스가 너무 큼
• 그리고 Kineiss가 더 쌈
• 메시지 처리량
  • SNS + SQS 기준은 선입선출 (초당 처리량의 한계가 존재함)
  • Kinesis는 충분한 Shard가 존재한다면 → 무제한임

Reference

• https://blog.gangnamunni.com/post/saas-enterprise-multi-tenancy