본 글은 MSA를 적용하면서 느낀 내용을 공유하는 글입니다. 다소 틀린 부분이 존재할 수 있습니다. 댓글로 알려주시면 감사해요!
들어가며..
처음 DDD를 접했을 때는 손에 잡히는 기분이 전혀 들지 않았다. 하지만 서버를 분산화하여 토이 프로젝트를 진행하면서 나 스스로가 여러가지 문제를 겪었고, 그 다음 DDD를 읽어보니까 너무나 공감이 간다.
아주 방대한 이야기가 될 것 같다. DDD에 관해서는 여러 편의 글로 쓸 예정이다. 오늘은 내가 느낀 DDD에 대해서 공유를 해볼까 한다.
MSA?
MSA는 마이크로 서비스 아키텍쳐의 줄임말이다.
간단하게 말하자면 모놀로식 아키텍쳐를 분해하여서 여러가지의 마이크로 서비스로 나눈 것을 말한다.
자세한 내용은 다른 글에서 찾아보길 바란다!
여러가지 마이크로 서비스로 나누는 것은 이해를 했다. 근데 다음과 같은 문제가 생긴다.
마이크로 서비스를 어떻게 분리해야하나?
마이크로 서비스를 분리하는 방법은 아주 많을 것이다.
- 기술마다 나누기
- 기능마다 나누기
- 도메인마다 나누기
- 아무렇게나 나누기
위와 같이 나누는 방법은 개발자 마음대로다. 무엇이 정답인지는 판단하기가 정말 어려운 것 같다. 하지만 큰 기업 및 많은 기업에서 성공적인 비즈니스를 구축하기에 적합한 방법은 널리 알려졌다.
그 방법이 "DDD"라고 판단이 된다.
DDD란?
DDD는 "도메인"을 중심으로 설계를 시작하는 방식을 말한다.
도메인이 뭔데?
도메인은 사전적 의미로 "영토", "분야", "영역"을 말한다.
말 그대로 서버를 마이크로화 하는 기준이 "도메인" 기준으로 분리를 진행하는 것이다.
다음으로 예시를 들어가면서 DDD가 필요한 이유를 적어보겠다!(예시가 잘못되었을 수도 있음)
여러가지 문제
개발팀이 자기들 마음대로 서버를 나누었다.
여기서는 PM 입장에서 일을 한다고 해보자.
다음의 말을 던질 것이다.
-
PM : "주문 api 부분에서 이러한 문제가 생겼는데 이거 해결이 안될까요?"
-
개발자1 : "아 ~ 그거 개발자2가 전담했을거에요. 그 분한테 물어보시면 됩니다!"
-
개발자2 : "어 그거 제 담당아니에요. 서버를 나누어서 누가 하는지 잘모르겠습니다."
-
개발자3 : "주문 api요? 아.. 그거 아마도 카드 관리 서버에서 진행했을 겁니다."
-
위와 같은 상황이 벌어졌다고 생각해보자. 그럼 다음과 같은 문제가 보인다.
-
개발자1 : PM 입장에서 누가 어떤 일을 하고있는지 파악이 안된다.
-
개발자2 : 개발자 사이에서도 누가 어떤 일을 하고있는지 파악이 안된다.
-
개발자3 : 기술적으로 서버를 나누어서 개발자도 어디 서버에 어느 로직이 있는지 판단이 힘들다.
결과적으로 업무가 분담이 되긴했는데 정확히 파악하기 힘들고 너무 거미줄처럼 엉켜있는 기분이 든다.
그래서 DDD에서는 실제 팀과 아주 유사한 형태로 서비스를 구축하라고 한다. 그렇게 되었을 때 다음과 같은 기대효과가 있다.
PM은 "주문" 팀에게 가서 주문에 대한 API를 물어보면된다.
이와 마찬가지로 "유비쿼터스 언어"도 개발에 국한된 언어를 쓰지않고 팀 모두가 이용하는 언어로 수행하라고 한다.
뭔가 애매한 기능
이번에도 다음의 상황을 보자.
- a 기능은 "영어 서버"에 넣는게 좋나요? 아니면 "글자 서버에" 넣는게 좋나요?
위의 상황은 도메인을 아주 애매하게 나누어서 기능을 어디에 적용할 지 모르는 상황이다.
- a 기능을 호출해야하는데 "영어 서버", "글자 서버", "언어 서버" 중 어디로 호출해야하나요?
위의 상황은 서버가 너무나 애매해서 a 기능이 어디에 구현되어있는지 판단이 서지 않은 상황이다.
단순한 1개의 질문이지만 엄청난 파급효과가 생길 것이다.
DDD에서는 위와 같은 상황을 "Bounded Context"를 제대로 나누지 않았기 때문이라고 말한다. 그리하여 "Bounded Context"를 제대로 나누어 서비스를 구성하도록 이야기한다.
서비스간 결합도
좋다. 서비스를 완벽히 잘~ 나누었다고 생각해보자.
무수히 많은 서비스들이 존재한다.
각 서비스들은 다른 서비스와 유기적으로 협력하여 특정 기능을 수행한다.
이 경우에 서비스끼리 API 호출이 거미줄처럼 엮인다.
한마디로 서비스간 결합도가 너무나 크다.
이 경우에는 어떻게 해야하는가?
그래서 DDD에서는 CQRS와 이벤트 소싱이 언급이 된다.
마이크로 서비스를 도입하면서 생길 수 있는 문제들을 다루는 것이다.
이벤트 방식으로 서비스 간 기능을 수행하게 되면 엄청난 효과를 얻을 수 있는 것이다.
- 서비스간 결합도 완화
- 고가용성 제공
하지만 이벤트를 수행하면서 다음과 같은 단점도 있다.
- 더 정교한 장애 시스템 구축
- 더 정교한 로그 시스템 구축
- 더 많은 인적자원 필요
결론
위에서 아주 살짝 DDD에 대해서 다루었다. 더 많은 내용도 존재한다. 그리고 나의 수준에서 느낀 내용이다. (더 심도 깊은 내용도 분명 존재한다.)
대부분의 회사가 MSA를 구축하려고 노력한다. 마이크로 서비스화를 진행하며 모두가 비슷한 고민과 비슷한 문제를 겪을 것이라고 본다.
그래서 "DDD"라는 개념이 중시되게 되었고, 그 개념을 적용하면서 자기 회사만의 특성에 따라 커스텀도 진행하는 것으로 보인다.
면접에서 묻는 이유 또한 다음과 같다.
우리 회사는 MSA를 진행하고 있어, 너는 MSA에서 가장 중시되는 DDD에 대해서 알고있니?
