MSA 설계는 뭐가 다른가요?

기존 설계와 뭐가 다를까?
기존 Monolith 설계와 어떤 부분이 가장 차이가 날까?

 

 

위의 그림과 같이 제일 큰 차이는 분산환경이다.

Application 뿐 아니라 DB 서버까지 분리되어 있고, 각 서비스별 Data 가 필요한 경우 API 또는 Event로 주고 받아야 한다.

이렇게 서비스별로 물리적으로 분리된 분산환경을 어떻게 극복할 것인가? 데이터 정합성을 어떻게 맞추고, 독립적으로 작동하기 위해서 어떤 처리를 할 것인지에 대한 How, 방법을 찾는 것이 가장 큰 설계의 차이점이다.

이러한 분산환경을 받아들일 수 없다면, 우측과 같은 서비스별/물리적으로 분리된 아키텍처를 적용하지 않아도 확장성, 장애격리, 독립적 설계/개발/테스트/배포/운영이 가능하다면 굳이 MSA를 도입할 이유가 없다.

 

 

API First Design

이렇게 분리된 서비스간의 Communication 을 통해서 서로의 기능을 호출, 데이터를 주고 받으면서 일을 하게 된다. 그러므로 이 Communication에 대한 협의, 약속이 제일 중요하다.

 

Monolith에서도 내부 컴포넌트간의 Method/Procedure Call은 있었고 이 역시 타 파트에서 제공을 언제, 어떻게 할 것인지 조율하고 테스트하는게 쉬운 일은 아니었다. 그 쉽지 않았던 파트간의 협의/약속이 더욱 중요해 진 것이다.

 

Provider 제공자의 입장, Consumer 소비자의 입장에서 각각 필요한 것을 정의하고 맞는지 상호간에 확인하고, 필요한 경우 추가/변경해서 약속해야한다. 누가, 언제까지, 무엇을, 어떻게 제공할 것인지. 이게 바로 API First Design 이고 이러한 개념으로 (뼈대)설계된 것을 정리하면 프로그램 목록이다. 각 서비스별로 설계, 개발, 테스트를 누가 언제까지 할 것인지 정리해 두어야 전체 프로그램에 대한 공수를 (어느정도) 예측할 것이다. 이를 바탕으로 Iteration Planning까지 마쳐야 한다.

 

 

분석단계 ‘서비스 정의’부터 ‘설계’까지 연결

MSA를 도입하겠다고 결정했다면 분석단계 중 또는 말에 ‘서비스 식별/검증/정의’하고 그렇게 정의된 서비스를 구성요소를 바탕으로 위의 API First Desing을 이용한 ‘기본(뼈대)설계’, 그리고 ‘상세설계 및 개발’까지 연결할 수 있어야 한다. 따로 따로 생각할 일이 아니다. 당연히 흐름이 이어져야하고 각 단계가 진행되면서 정련/보완 되어야 한다.

 

그럴려면 이러한 연결 진행/정련/보완할 수 있는 도구가 필요하다. 이는 설계도구편에서 따로 이야기하도록 하자.