아시나요? 마이크로 서비스와 도메인 주도 설계 (1)

개요

답 보다는 질문을 베껴야 한다. - Jessica Ker -

이 시리즈는 아래 도서를 읽고 요약한 시리즈 입니다.

• 마이크로서비스 패턴(크리스 리처드슨, 길벗 출판사)

짧은 지식으로 작성되었으니, 잘못된 점이 있다면 댓글로 따끔한 지적 부탁드립니다!

목표

• 마이크로 서비스의 개념과 필요성, 적용 방안을 알아본다.
• 도메인 주도 설계의 필요성과 다양한 적용 사례를 알아본다.

---

여정

마이크로 서비스란 무엇인가?

마이크로 서비스(Micro Service)는

• 비즈니스 도메인을 중심으로 모델링된
• 독립적으로 배포 가능한 서비스를 말한다.

 

즉, 마이크로 서비스는 아키텍쳐의 목표 지점이 아니다.

기존 아키텍쳐로 이룰 수 없는 무언가를 달성하기 위해 채택하는 전략일 뿐이다.

 

이 책의 저자는 

'모든 사람이 마이크로 서비스를 하기 때문에 따라 해야 한다는 생각은 끔찍하다.

마이크로 서비스는 무엇이든 해결해주는 은탄환(Silver Bullet)이 아니다.

라고 말한다.

 

따라서, 마이크로 서비스를 채택하기 전,

다음 3가지 질문에 답할 수 있어야 한다.

• 무엇을 성취하기를 바라는가?
• 마이크로 서비스 사용이 아닌 다른 대안을 고려했는가?
• 전환이 작동하고 있는지 확인할 수 있는가?

 

그렇다면, 전통적인 아키텍쳐와 무엇이 다른지 비교해보자.

---

비즈니스 아키텍쳐 간 비교

기존 아키텍쳐

• 주로 3계층 : UI(표현) - 백엔드(애플리케이션) - DB(데이터)
• 팀 간 프로세스 경계를 넘어서는 변경에는 비용이 많이 든다.
• 조직의 커뮤니케이션 구조를 본떠 시스템 구조를 만들어낸다.(콘웨이의 법칙)
• 나쁜 것은 아니다. 기술 관점의 응집력은 높지만 비즈니스 관점은 아니다.
• 쉬운 변경을 위해서는 비즈니스 기능의 응집력을 선택할 필요가 있다.

 

마이크로 서비스 아키텍쳐

용어 설명
*집계(Aggregate) : 실제 도메인 개념의 표현(주문, 송장, 재고 등)
*경계 컨텍스트(Bounded Context) : 하나 이상의 집계를 포함한 조직적인 경계

• 일반적으로 집계*는 수명주기가 있고, 상태머신으로 표현할 수 있다.
• 외부 시스템이 집계 내의 상태전이를 요청하면 거절할 수도 있다.
• 일부 집계를 공개하거나 내부적으로 숨길 수도 있다.
• 집계와 경계 컨텍스트*는 모두 서비스 경계로 작동할 수 있다.

즉, 마이크로 서비스는 독립적인 배포 가능성을 반드시 포용하는 것이 좋다.

이를 위해서는 서비스가 느슨하게 결합되어 있음을 보증할 필요가 있다.

 

용어 설명
*독립적인 배포 가능성 :
다른 서비스를 활용하지 않고서 마이크로 서비스에 변경을 가하는 방식으로 운영 환경에 배포할 수 있다는 개념

 

---

왜 마이크로 서비스인가?

아래 항목들은 일반적으로 마이크로 서비스를 채택하는 대표적인 이유다.

 

 

마이크로 서비스는 팀 자율성을 향상시킨다.

• 아마존 ‘피자 두 판의 법칙’은 제대로 작동한다면 구성원을 성장시키고 더 빠른 업무 처리를 돕는다.

 

마이크로 서비스는 시장 출시 기간을 단축시킨다.

• 개별 서비스가 출시되기 위해서 느슨한 결합만 잘 유지한다면 독자적이고 더 빠른 배포가 가능하다.

 

마이크로 서비스는 효율적인 비용 확장이 가능하다.

• 병목 현상이 걸리는 특정 부분을 쉽게 확장할 수 있다. (수평 확장)
• 그러나 확장 작업은 마이크로 서비스 외에 다른 대안이 많다.
• 또한 병목 현상이 DB에 있는 경우 큰 도움이 되지 않을 수 있다.

 

마이크로 서비스는 회복 탄력성을 제공한다.

• 알려지거나 알려지지 않은 실패 원인을 분리할 수 있도록 해준다.
• 이는 실험하는 문화를 만드는 것도 포함해 잠재적 문제를 스스로 대비할 수 있도록 한다.

 

마이크로 서비스는 신기술을 안전한 방법으로 사용할 수 있게 해준다.

• 서비스 경계에서 기술 변화를 분리함으로써 새로운 기술의 장점을 가져올 수 있다.
• 현재 기술이 수명이 다해가는 기술이라면 더욱 효과적이다.
• 코드 재사용이 불가능해진다는 말은 전혀 의미가 없다.
• Util 클래스와 같은 코드 재사용은 서로 연관이 없는 곳에서 결합도를 증가시키고 각 팀 간 변경 프로세스를 엉키게 만든다.

---

그럼 어떤 경우에 나쁜 선택일까?

불분명한 도메인

• 너무 조기에 시스템을 분해한다면, 다시 결합하는 불상사가 일어날 수도 있다.
• 아직 도메인 파악이 부족하다면, 분해보다는 도메인에 집중하자

 

스타트업

• 스타트업은 절대 도입하지 말라는 이야기가 아니다.
• 초기 아이디어가 나쁘다면, 마이크로 서비스 여부는 전혀 중요하지 않다.
• 모놀리스도 관리하기 어렵다면, 마이크로 서비스 10개는 더욱 어렵다.
• 완전 미 개발 시스템에서 시작하는 것보다, 기존 시스템을 분해하는 편이 쉽다.

 

설치형, 관리형 소프트웨어

• 고객에게 관리를 위한 기술과 플랫폼을 기대할 수 없다.
• 관리해야 할 프로세스 1개가 10개 20개로 늘어날 수 있다.
• 설령 Kubernetes 설치가 가능하다고 해도, 버전과 OS 마다 차이가 크다.

 

좋은 이유를 찾지 못한 경우

• 모든 사람이 마이크로 서비스를 하기 때문에 따라 해야 한다는 생각은 끔찍하다.

---

우리가 시작해야 할 지점은?

아마존 CEO 제프 베조스의 말에 따르면, 의사결정은 2가지로 나뉜다.

• 비가역적 의사결정 (1종 의사결정)
  • 전반적인 승인이 필요하고, 의사결정을 변경하기 거의 불가능함
  • 호스팅 회사 변경, API 변경 등
• 가역적 의사결정(2종 의사결정)
  • 즉흥적인 의사결정도 가능한 수준
  • 오픈소스 라이브러리 선정, 새로운 프로그래밍 언어 실험 등

예를 들어, 데이터베이스 분리를 추진했다가 롤백하는 과정은 굉장히 복잡하다.

따라서, 쉬운 단계의 변경부터 추진하는 것이 바람직하다.

이 때, 필요한 것은 화이트보드와 도메인 주도 설계(DDD) 이다.

---

마무리

이번 시간에는 마이크로 서비스의 정의와 개념에 대해 알아보았다.

또한, 전통적인 아키텍쳐와의 비교로 어떤 이유로 채택해야 하는지 필요성을 학습했다.

 

다음 시간에는 규모별 마이크로 서비스를 채택해서 발생하는 문제 사례와

이에 대한 해법에 대해 알아보자

---

참고자료

DDD, Aggregate Root란? + JPA CasecadeType 영속성전이 (tistory.com)