개요
싸피 공통 프로젝트를 진행하는데
인프라 담당 친구가 우리는 MSA로 간다고 했다.
얼추 알고는 있었지만, 상세히 알아보는 것은 처음이어서 조금 알아볼 필요가 있다고 생각하였다.
개념정리겸 우리 프로젝트 구조 구성에 대해 얘기해보려 한다!
MSA란?
MicroServiceArchitecture의 줄임말이다.
마이크로서비스(microservice)는 애플리케이션을 느슨하게 결합된 서비스의 모임으로 구조화 하는 서비스 지향 아키텍처(SOA) 스타일의 일종인 소프트웨어 개발 기법이다.
결합도가 느슨하고 응집도가 높아야 좋은 서비스란 말을 들어봤을 것이다. 결합도가 느슨하다는 것은 하나의 서비스가 다른 서비스에게 영향을 받지 않는다는 것을 뜻하고, 응집도가 높다는 것은 기능별로 잘 모여있다는 뜻이다. 따라서 MSA에서 낮은 결합도와 높은 응집도를 위한 설계는 도메인을 어떤 단위로 분리하냐에 달린 문제다!
MSA의 장점은 다음과 같다.
- 배포
- 서비스별 개별 배포가 가능하다(배포시 전체 서비스의 중단이 없다)
- 특정 서비스의 요구사항만을 반영하여, 빠르게 배포가 가능하다.
- 확장
- 특정 서비스에 대한 확장성(scale-out)이 유리하다.
- 클라우드 기반 서비스 사용에 적합하다.
- 장애
- 일부 장애가 전체 서비스 장애로 확장될 가능성이 적습니다.
- 부분적으로 발생하는 장애에 대한 격리가 수월합니다.
- 그 외
- 새로운 기술을 적용하기 유연합니다.(전체 서비스가 아닌 특정 서비스만 별도의 기술 또는 언어로 구현 가능)
- 각각의 서비스에 대한 구조 파악 및 분석이 모놀리식 구조에 비해 쉽습니다.
MSA의 단점은 다음과 같습니다.
- 설계의 어려움
- 서비스가 모두 분산되어 있기 떄문에 개발자는 내부 시스템의 통신을 어떻게 가져가야 할지 정해야 합니다.
- 성능
- 서비스 간 호출 시 API를 사용하므로, 통신 비용이나 Latency에 대해 이슈가 존재한다.
- 테스트/데이터 트랜잭션
- 모놀리식에서는 단일 트랜잭션을 유지하면 됐지만 MSA에서는 비즈니스에 대한 DB를 가지고 있는 서비스도 각기 다르고, 서비스의 연결을 위해서는 통신이 포함되기 때문에 트랜잭션을 유지하기가 어렵다.
- 통합 테스트가 어렵다.
- 데이터 관리
- 데이터가 여러 서비스에 분산되어 있어 조회하기 어렵습니다.
- 데이터를 관리하기 어렵습니다.
이토록 MSA는 서비스를 분산시킨 만큼 낮은 결합도와 높은 응집도를 보이고 서비스 간 독립이 가능하여 확장, 장애, 추가에 유리하다.
반면 서비스가 분산되어 있는 만큼 통합 단위의 동작과 복잡도면에서는 단점이 존재한다.
그리고 결국 MSA의 중점은 도메인 분석 설계를 어떻게 하냐가 핵심이고, MSA의 서비스 분리는 DDD(Domain Driven Design)과 직결된다.
DDD란?
DDD는 Domain Driven Design이다.
먼저 Domain은?
1. 사전적 의미론 영역, 집합
2. DDD에서의 Domain은 비즈니스 Domain
3. 비즈니스 Domain은 유사한 업무의 집합이다.(높은 응집도)
그럼 DDD는?
1. 비즈니스 Domain 별로 나누어 설계하는 방식이다.
현업과 IT의 쌍방향 커뮤니케션을 매우 핵심으로 생각하는 방식이다.
2. DDD의 핵심 목표는 Loosly coupling, High cohesion이다.
어플리케이션 또는 그 안의 모듈간의 의존성은 최소화하고, 응집성은 최대화한다.
3. DDD는 Strategic Design과 Tactical Design으로 나뉜다.
Strategic Design는 개념설계이고, Tactical Design은 프로그래밍을 위한 구체적 설계이다.
프로젝트 도메인의 변경
기존에 MSA를 생각하지 않고 우리가 나눈 도메인은
user, child, game, etc였다.
요구사항 명세 관점에서 한 분류였는데
MSA와 DDD에 대해 읽고 우리의 도메인 분류를 봤을 때 가장 먼저 든 생각은, etc가 너무 어색해 보였단 것이다.
도메인에 대해 응집도가 높지 못하단 느낌이었다.
그래서
- etc의 플레이 이력조회는 child 도메인으로 옮겼고
- etc 도메인은 assets(재화) 도메인으로 변경하였다.
해당 도메인에 있기에 어색한 api를 이동하고, 이름을 수정하였다.
여전히 도메인 단위로 분류했다기엔 단위가 크지만, 당장의 헌저히 떨어지는 응집도는 개선한 것 같다.
프로젝트 설계단계에서부터 MSA와 DDD를 생각했다면, 자녀와 포인트, 아이템까지 분류하여 7~8개 정도의 도메인으로 나눴을 것이라 생각하였다.
또 서비스 간의 잦은 통신을 야기하는 것이 좋은 방식은 아니기에, 지금 api 명세를 수정하는 단계에선 이정도로 마무리 하는 것이 우리의 도메인 설계에선 최선이라고 생각하였다.
MSA와 DDD의 개념에 대해 공부할 수 있어 좋았고
이미 설계가 완료된 상태여서 완전히 갈아엎을 시간은 없었지만
명세를 크게 해치지 않는 선에서 결합도를 낮추고 응집도를 높이기 위해 노력해본 경험은 뜻깊었다.
다음 프로젝트에선 처음부터 MSA 도입과 DDD에 대해 얘기하여 조금 더 높은 완성도의 도메인 설계를 해보고 싶다.
변동사항
MSA로 개발할때 공통된 Entity의 이슈를 어떻게 해결해야 하냐로 얘기하다가
- 서비스마다 필요한 Entity를 들고있자.
- 서비스마다 필요한 Entity의 FK값만 들고있자.
- MSA를 없애버리자.
의견으로 좁혀졌다.
3번 의견이 나온 이유가 1, 2번 방식으로 해결할거면 MSA의 사용 의미가 없어지지 않냐? 였다.
MSA를 쓰는 장점이 독립된 서비스로 한 서비스의 장애가 다른 서비스로 퍼지지 않는다는 장점이 있는건데, Entity를 다 똑같이 들고있는 순간, DB에 장애가 일어나면, 공통된 서비스들이 다 죽어버리기 때문이다.
그래서 1, 2번을 써서 MSA스러움을 잃어버리는 것 보단
MSA자체를 허무는게 더 낫다고 생각하여 MSA가 아닌 기존처럼 한 서비스에서 도메인별로 패키지를 나눠 작업하기로 합의하였다.
