마이크로서비스 아키텍처(MSA) 알아보기

🛠

📌

3줄 요약

1. MSA는 은탄환이 아니다.

2. 마지막 수단이 MSA일 때 도입해야 가장 이상적이다.

3. 많은 시행착오를 겪은 선배 개발자 분들에게 감사함을 전합니다.

---

• Index

  MSA란 무엇인가?

  그래서 이게 왜 그렇게 핫한데?

  MSA는 은탄환인가?

  MSA의 진실

  MSA 장/단점

  성공적인 MSA 사례 - 우아한형제들

  모놀리스 환경의 치킨 디도스

  마이크로서비스로 도달하기 위한 첫걸음

  이벤트 전파와 동기화

  안정단계

  마무리

---

MSA란 무엇인가?

MSA는 마이크로 서비스 아키텍쳐의 줄임말입니다.

그렇다면 사전적 정의는 무엇일까?

세계에서 유명한 기업인 aws에서 내린 정의를 살펴보자.

마이크로서비스는 소프트웨어가 잘 정의된 API를 통해 통신하는 소규모의 독립적인 서비스로 구성되어 있는 경우의 소프트웨어 개발을 위한 아키텍처 및 조직적 접근 방식입니다.

꽤나 답변이 어렵게 적혀있는 것 같지만 핵심적인 부분만 추출해보자.

API를 통해 통신하는 소규모의 독립적인 서비스 이것이 핵심!

여기서 API는 http 통신이 될수도 있고 메세지기반의 이벤트방식이 될수도 있습니다.

제 나름대로(?) 생각한 정의는 아래와 같습니다.

💡

복잡한 비즈니스를 해결하는 서비스(Monolith)를 독립적인 서비스 단위로 잘게(Micro) 나누어 각각의 서비스가 서로 상호작용(API, Message)하여 거대한 서비스를 이루는 것

여기서 잘게(Micro)의 단위는 적용대상에 따라 단위가 달라질 수 있는데, 여기서 설명하는 단위는 가장 흔히 사용되는 서버 단위라 생각하시면 될 것 같습니다.

그래서 이게 왜 그렇게 핫한데?

요즘 백엔드 개발자 채용공고를 보면 우대사항에 빠지지 않고 적혀있는 것을 쉽게 확인할 수 있습니다.

• MSA 환경의 대규모 트래픽, 고 가용성 시스템 개발에 관심이 많은 분

• MSA 기반 대용량 처리 시스템 디자인 설계

• MSA, SOA 기반 백엔드 개발을 경험해 보신 분

그렇다면, 왜 이렇게 마이크로서비스 아키텍쳐가 이렇게 핫한것일까요?

제 나름대로의 결론을 먼저 말씀드리자면, 사용자가 많은 서비스들이 해결해야하는 대용량 트래픽에 대해 대응하기위한 필수조건이 아닌 필요조건 이라고 생각합니다.

넷플릭스와 같이 이용자가 압도적으로 많다면 그것은 필요조건이 아닌 필수조건이 되겠지요

결국 대용량 트래픽을 감당하기 위한 ← 장애를 극복하기 위한 생존의 문제라고 생각하셔야합니다.

그렇다고 무조건적으로 MSA가 좋다고 처음부터 서비스를 나누는 것은 매우매우 안좋습니다.

MSA는 은탄환인가?

절대 절대 은탄환이 될 수 없습니다.

상황에 따라 모놀리스가 적합한 경우도 많습니다.

단적인 예를 들어, 이용자가 별로 없는 사내서비스를 MSA로 구축한다면 어떻게 될까요?

(사내서비스 중에서도 트래픽이 넘치는 서비스들은 제외합니다.)

모놀리스라면 간단하게 @Transactional로 해결할 수 있는 것들을 분산된 환경에선 트랜잭션을 관리해야합니다.

깊게 생각하지 않고도, 벌써 롤백을 어떻게하지? 곤란하네.. 라고 생각이 드실겁니다.

(상세한 내용은 https://waspro.tistory.com/734 이 블로그의 글을 확인해보세요)

이처럼 모놀리스로 개발하되 점진적으로 MSA 환경으로 가게되는 것이지, 시작부터 MSA환경은 매우 옳지 못한 설계입니다.

So my primary guideline would be don't even consider microservices unless you have a system that's too complex to manage as a monolith. The majority of software systems should be built as a single monolithic application. Do pay attention to good modularity within that monolith, but don't try to separate it into separate services. - Martin Fowler

따라서 저의 주요 지침은 마이크로 서비스를 고려하지 않는 것입니다. 모놀리스로 관리하기에는 너무 복잡한 시스템을 가지고 있지 않다면 말이죠. 대부분의 소프트웨어 시스템은 모놀리스로 구축되어야 합니다. 모노리스 내의 모듈화에 주의를 기울이되, 이를 별도의 서비스로 분리하려고 하지 마십시오. - 마틴 파울러

이처럼 서비스가 커지면서 시스템이 복잡해지고 MSA로 넘어갈때 필요한 배포, 모니터링, 장애처리, 최종 일관성, 분산 시스템등등 것들 보다 비용이 크다면 MSA를 적용해야되는 순간일 것입니다.

MSA의 진실

마이크로서비스가 잘못 설계되었을 때 확장하는 것은 어렵지만 확장한 다음 마이크로서비스화하는 것은 쉽습니다.

서비스 간에 안정적인 경계(bounded context)를 가질 때 잘 동작합니다.

비즈니스가 추가되고 변경된다면 리팩토링의 복잡도는 모놀리스보다 마이크로서비스가 훨씬 어렵습니다.

그렇기 때문에 먼저 모놀리스를 구축하여 올바른 경계가 무엇인지 파악한 후 마이크로서비스를 적용해야 합니다.

MSA 장/단점

마이크로 서비스는 대용량 트래픽에 대응하기 위한 아키텍쳐 입니다.

장애가 날 것으로 예상하고 서비스간 장애의 전파를 막고 단일장애지점을 없애 장애 내성을 강하게 합니다.

예를 들어, 이커머스 서비스가 물건을 구매하는데 결제DB에 문제가 생겨 장애가 발생했다고 가정해봅시다.

그렇다면 결제DB에 문제가 생겨 상품 검색도 연쇄적으로 장애가 발생해 모든 서비스가 다운되는 상황이 발생할 수 있습니다.

하지만 DB를 각 독립적인 컨텍스트를 구성하여 결제, 검색, 주문 등으로 나누어 마이크로서비스를 한다면 결제의 서비스가 다운되어도 상품 검색은 가능하게하여 장바구니 등 결제 전까지의 프로세스는 정상으로 돌아가야합니다.

그 이후 결제 서비스가 정상작동되면 들어온 이벤트 순서대로 자동으로 처리가 되게 구성하는 것이 마이크로서비스의 큰 장점입니다.

또한 선착순 이벤트처럼 트래픽이 몰려 부하가 예상되는 시간에 오토스케일을 통해 대용량 트래픽을 쉽게 대응할 수도 있습니다.

하지만 좋은점이 있으면 따라오는 단점도 존재하는데, 그것은 바로 위에서 설명한 비용발생입니다.

모놀리스 서비스론 고민할 필요없는 상황들을 많은 비용을 발생시켜 구성해야하기 때문에 최후의 수단으로 생각하여 도입해야 합니다.

성공적인 MSA 사례 - 우아한형제들

배달의민족에서 매우 감사하게도 마이크로서비스로 전환했던 배경과 기술 이야기를 매우 간략하고 핵심만 정리하여 설명해준 영상이 있습니다.

💡

이 영상은 매우매우 유익하니 꼭! 시청하길 바랍니다.

https://youtu.be/BnS6343GTkY

영상 내용을 요약해보자면 크게 4가지의 서사로 이뤄집니다.

모놀리스 환경의 치킨 디도스

• 2015년 배달의 민족은 루비DB 하나로 전체 서비스를 운영중이었음

• 치킨이벤트(치킨디도스) 공격에 프론트서버가 죽음

• IDC → AWS 하루만에 이전

• AWS 이전했기때문에 스케일아웃 100대증설

• 그랬더니 주문 서버가 죽음

• 주문 AWS 이전

• 스케일아웃해서 성공

• 그랬더니 결제 → 외부 PG, 카드사 죽음

• 그 다음날 장비 2배 투입해서 대응함

마이크로서비스로 도달하기 위한 첫걸음

• 2017년 모놀리스 구조에서 하나씩 뗴어냄

• 가게 목록+검색을 떼어내서 ES로 붙임 → 루비 DB로 가는 부하가 확실히 줄어듬
  • CQRS 패턴
  • 명령과 쿼리를 분리하기 시작

• 가게 상세 페이지도 트래픽을 감당할 수 없어 떼어냄 → aws 다이나모 DB(nosql)로 select에 특화된것을 사용 → 루비 DB에서 배치가 계속돌면서 색인을함

• 가게상세, 가게목록+검색 분리가 완료됨

• 그다음 주문, 리뷰를 분리
  • 사실 주문이 비즈니스가 제일 복잡함
  • 외부 API연동이 굉장히 많이 엮여있었음
  • 단적으로 주문이 완료되면 리뷰 시스템에 전달해서 리뷰를 해달라는 앱푸시를 날려야하는 api가 있었음
  • 주문이 완료됐는데 리뷰 시스템이 죽어버리면 주문이 안되는 이상한 현상이 발생함
  • 그래서 이 많은 외부 api를 완벽한 이벤트 기반으로 변경하기로 함

• aws - sqs 를 통해서 주문시스템에서 발생되는 이벤트(생성, 접수, 배달완료, 취소 등)들을 메세지큐로 전달

• 이렇게되면 기존에 리뷰시스템이 죽어도 동작하게되고 api콜이 유실된 부분도 api 가 살아나면 다시 재처리 할수 있게 개선됨

• 시스템 회복력이 급격히 좋아짐

• 크게 3가지의 속성을 가진 이벤트 큐를 발생시킴
  • 리뷰 시스템 전달(외부 API)
  • 레거시DB 싱크(데이터 동기화)
  • 라이더스 시스템(DB write ← 데이터 동기화?)

• 하나의 db에서 msa구조로 가면서 별개의 db가 되어 같은 컬럼을 분리할 수 밖에 없음

• 데이터 동기화 이슈 발생
  • 검색, 색인, nosql 조회에 특화된 곳(Q)
  • 명령(C)이 발생해 데이터가 변경되면 이벤트를 발행해서 조회DB에 알림
  • 조회 DB는 알림을 받고 쿼리모델에서 갱신

이벤트 전파와 동기화

• Eventually consistency(최종적 일관성)
  • 데이터는 언젠가는 다 맞추어진다
  • 데이터 싱크 1~3초

• 문제 발생시 해당 시스템이 이벤트만 재발행

• 대부분 zero-payload 방식 사용
  • 이벤트에 식별자(ex 가게ID)와 최소한의 정보만 발행
  • 이벤트를 받은 시점에 조회 API로 필요한 데이터를 조회해서 저장
  • 그럼 이렇게 하는 이유는?
    • 변경된 데이터를 갱신해야하는데 갱신해야될 데이터가 2개 동시에오면 어떤게 우선인지 비교해야되고 많은 고민이 들어감(비용 발생)
    • 그러지 말고 id값만 발생시키고 이벤트가 발생되면 무조건 갱신하자 (비용감소) 항상 최신으로 보고 갱신하자
    • 팀마다 원하는 데이터가 다를수밖에 없는데 그러면 팀마다 다른 정보를 전달해줘야함(비용발생)
    • 그래서 id값만 이벤트 메세지로 발행하고 각팀에서 필요한 정보들의 조회 API를 스펙에맞게 열어둠
  • 최소 데이터 보관 원칙
    • 각 시스템에서 필요한 최소한의 데이터만 보관한다
    • 데이터를 다가지고 있으면 물리적인 관계는 없지만 논리적인 관계가 성립되어 데이터를 다 비교해서 처리해야함
      • 필요없는 데이터도 들고있다면 특정 시스템에서 데이터를 변경하고자 할때 데이터를 비교해봐야되는 상황이 발생함 (비용발생)
        • A 시스템에서 데이터를 변경하고자하는데 B 시스템에 똑같은 정보가 있는데 다른값을 가지고 있을때 어떻게 비교할것인가? (비용발생)
        • B 시스템에선 필요없는 정보인데도 불구하고 데이터가 존재하면 비교해봐야 되는 비용을 줄임

• 각 시스템들은 폴리글랏 데이터베이스를 사용할 수 있는 장점
  • 성능이 중요한 노출쪽은 레디스나 nosql
  • 검색이나 광고리스팅쪽은 es
  • 실질적은 write가 주시스템인 곳은 rdb

안정단계

DB

• 조회(고성능)
  • 가게노출: dynamo db, mongo db(nosql), redis(cache)
  • 광고리스팅, 검색: es(검색엔진)
  • 바로결제 라이브: redis(cache)

• 명령(안정성)
  • 광고: 오로라 db(rdb)
  • 가게/업주: 오로라 db(rdb)

• 대용량트랙픽이 빡 몰려도 cqrs 구조이기떄문에 살아남을 수 있음

• msa 구조로 개별 스케일링 가능

장애 격리

• 각 시스템이 내부에 필요한 데이터 보관

• 내부 서비스(광고, 검색)의 모든 변경 내역이 이벤트로 전달

• 장애시 데이터 싱크가 늦어져도 고객 서비스 가능

데이터 싱크 장애 대응

• 이벤트 재발행

• 큐 장애 발생시
  • 전체 IMPORT API 제공
  • 부분 IMPORT API 제공
    • 최근 업데이트 데이터를 분단위로 부분 제공 (배치성)

기타

• 적극적인 캐시 사용

• 서킷 브레이커

• 비동기 논블럭킹 시스템 적용
  • 스프링 웹플럭스, 리액터
  • 가게노출, 광고리스팅, 검색

정리

• 배민은 거대한 CQRS

• 성능이 중요한 외부 시스템(조회)과 비즈니스 명령이 많은 내부 시스템(명령)으로 분리

• 이벤트 발행을 통한 Eventually consistency(최종적 일관성)

• 각 시스템은 API 또는 이벤트 방식으로 연동
  • 주문시 마지막 validation은 api를 통해 진행함
    • 진짜 맞는가 확인
    • 이벤트 방식은 최종적 일관성이지만, 실시간 동기화가 아니기 때문

총평

• MSA 꼭해야되나?
  • 말했다시피 생존의 문제
  • 트래픽이 많고
  • 사용자도 많고
  • 장애도 많다면
  • 생존의 수단으로 해결해야함
  • MSA 하기전엔 단순히 조인하나만 해서 해결이 될거를 데이터 동기화신경써야되고 트랜잭션 신경써야되고 그런 비용이 10배정도 더넘음
  • 그런 비용을 상쇄할만큼의 이점이 있을때 → 생존의 수단

마무리

마이크로서비스에 대해 알아보기 전엔 무조건 좋은줄로만 알았던 반성의 시간이 되었습니다.

배민에서 올린 마이크로서비스 여행기는 앞으로 곱씹으면서 영상을 시청하게 될 것 같네요.. 🫠

생존의 수단으로 사용되기 전까지 바운디드컨텍스트를 분류하고 멀티모듈로 구성하는 것부터 진행한 후 마이크로서비스를 도입해야 안정적인 서비스를 구성할 수 있다는 말에 큰 공감을 합니다..

이 글에선 실패사례를 다루진 않았지만, 많은 기업들이 시행착오를 겪었고, 그 시행착오 뒤에 제가 있는 것에 선배 개발자들에게 깊은 감사함을 느끼며.. 이만 글을 마무리 짓겠습니다.

다음 글은 마이크로서비스에서 자주 등장하는 CQRS 패턴에 대해 알아보겠습니다.

끝!

Uploaded by N2T