[설계이론] 마이크로서비스 아키텍처(MSA)는 언제 고려해야하는가?

복수전공시절 MSA에 대한 세미나를 들었을 때 장점만 들어서 막연히 MSA가 좋다고만 생각했다.

MSA로 설계하지 못하는건 실력부족이라고만 생각을 했었는데,

김영한님의 '배달의민족 마이크로서비스 여행기' 테크콘서트 영상을 보고 개념을 다시 한번 잡은 것 같다.

 

CQRS가 궁금해서 본거였는데, 아직 어떻게 설계해야될지 감도 못잡았다는 것은 비밀 😢

 

 

# 마이크로서비스 아키텍처로의 전환을 고려해야 할 시점

기존 서비스의 규모가 많이 커졌을 때 (시스템규모 + 트래픽 + 인력)

 

해당 영상에서는 시스템 안정성(장애격리)가 최우선 과제 였고, 그로 인해 MSA로의 전환이 선택이 아닌 필수 느낌이었다고 말씀하신다.

 

MSA 로 전환으로 인해 성능과 장애격리에선 이점을 얻을 수 있는 반면, 데이터동기화를 위한 비용도 있으므로

 

무작정 MSA로 전환하면 작은 규모의 서비스에서는 데이터동기화를 위한 비용이 더 커질 수 있다.

 

이러한 비용을 상쇄하고 남는 경우에 MSA 로의 전환을 고려하는 것이 바람직하다.

 

Netflix도 MSA로의 전환이 7년걸렸다고 한다. 

 

그러니까 비즈니스가 쪽박이 날 수도 있으므로 초기부터 MSA로 설계하진 않는다. 

 

레거시코드를 수없이 리팩토링하며 개선시키는 것이 개발자의 역할인가보다. (재밌겠다....)

 

# 이벤트 기반 설계

API기반의 설계가 아닌 AWS SNS, SQS 를 이용한 이벤트기반 설계를 했을 경우 시스템 회복력이 좋아진다.

(서비스가 죽었다가 살아나서 큐에서 이벤트를 다시 consume하면 되기때문) 

 

해당 방식으로 다른 내부서비스(가게/광고)나 DB에 장애가 발생해도 고객서비스를 유지하고 주문도 가능해진다.

 

DB가 죽어도, 고객서비스의 이벤트는 SQS에 차곡차곡 쌓이기 때문 :D

 

 

---

 

# CQRS

(Command and Query Responsibility Segregation [명령과 조회의 책임 분리] )

 

 

명령(command)에서 이벤트를 발생시키면 조회(query)에서 이벤트를 consume해서 갱신하는 방법으로 설계하는 것인가...?

 

---

 

# Zero-PayLoad

 

 

# 데이터 최소보관 원칙

zero-payload 방식으로 조회(Query)서비스에서 명령(Command)서비스를 호출하면 명령서비스에서 해당 데이터의 모든 필드를 가지고 있어 조회쪽에서 모든 데이터를 가져도 물리적으로는 문제가 되지는 않으나 논리적 문제로 인해 해당 원칙을 지킨다?

 

사실 이 부분이 잘 이해가 되지 않는다... CQRS 는 CUD와 R의 분리가 아니었나...?

 

명령(Command)쪽에서 Read를 하는것은 zero-payload 방식이기 때문에 어쩔 수 없는것인가..? 

 

그렇다면 가게/업주에서 장애 발생시, 가게노출도 장애회복까지 기다려야되지 않는가..? (??????????)

 

아니면 가게/업주에서 데이터를 주기적으로 동기화해주니 믿고 마이크로서비스 자체 DB에서 Read 하는 것인가?

 

CUD는 가게/업주에서 하고! 동기화해준 데이터를 R하는 것은 자체서비스에서 하는것인가!!!!!

 

하하하... 이게 제일 신빙성 높은 추측이긴 한데 정확히는 잘 모르겠다...;;;;;;

 

 

# DB 선택지 및 데이터 싱크 장애대응 (AWS SNS, SQS 에 장애발생 시)

 

---

 

# [우아콘] 배달의민족 마이크로서비스 여행기 (feat. 김영한님)