[아키텍처] MSA

 

  나는 지금 구직 중이라 많은 이력서를 내고 있고 종종 면접을 보는 중에 있다. 그중 한 면접에서 여러 가지 질문을 받았다. 그런데, 사실 거의 대부분의 질문에 대답하지 못하는 참사가 벌어졌다. 내가 느낀 참담함과 아쉬움을 글로 다 표현하기 힘들 것이다. 물론 면접관께서는 아직 나의 레벨에서 대답하기 어려운 질문이고, 알면 좋은 거라는 말씀을 해주셨지만 그 말이 별로 위로가 되지 못했다. 아직 갈길이 멀구나라는 생각이 머리를 차지했다. 오늘은 그 여러 질문 중 하나인 MSA에 대해 알아보고자 한다. 막상 학습을 해보니 사실 조금이라도 아키텍처에 관심이 있다면 충분히 대답할 수 있는 내용이라 아직 갈 길이 멀다는 생각을 한다.

 

• 학습 내용

  MSA란 하나의 큰 앱을 여러 개의 작은 앱으로 쪼개어 변경과 조합이 가능하도록 만든 아키텍처를 말한다. 이것은 작은 레고 블록(Microservice) 하나하나를 붙여 큰 결과물을 만드는 형태이다.

Monolithic Architecture는 완전히 하나로 통합된 건물과 같다.

  이 MSA는 Monolithic Architecture의 한계를 극복하기 위해 등장했다. Monolithic Architecture는 소프트웨어의 모든 구성요소가 한 프로젝트에 통합되어있는 형태이다. 과거의 프로젝트에 규모가 크지 않았고 간단했던 때에는 이런 형태가 훨씬 유리했었다. 왜냐하면 통합되어 있기 때문에 유지 보수가 용이하기 때문이다. 하지만 현대에 들어 일정 규모 이상의 서비스 혹은 수백 명의 개발자가 투입되는 프로젝트가 다양해지고 많아졌다. 여기에 있어 Monolithic Architecture는 분명한 한계를 보인 것이다. 

  서비스/프로젝트가 커질수록 영향도 파악 및 전체 시스템 구조의 파악에 어려움이 있고, 빌드 시간 및 테스트 시간과 배포 시간이 기하급수적으로 늘어난다. 그리고 서비스를 부분적으로 scale-out(장비를 추가해서 확장하는 방식, 기존 서버만으로 용량이나 성능의 한계에 도달했을 때, 비슷한 사양의 서버를 추가로 연결해 처리하는 것)에 어려움이 있고, 일부의 장애가 전체 서비스의 장애로 이어지는 경우가 발생한다.

MSA는 이런 블럭형태의 건물과 같다.

  그러나 Micro Service Achitecture는 각각의 서비스는 크기가 작을 뿐 서비스 자체는 하나의 모놀리틱 아키텍처와 유사한 구조를 가진다. 그래서 각각의 서비스가 독립적으로 배포가 가능하다. 그리고 각각의 서비스가 다른 서비스에 대한 의존성이 최소화되어 있고, 각 서비스는 개별 프로세스로 구동되며, REST와 같은 가벼운 방식으로 통신된다는 특징들을 가진다. 

  그러다 보니 MSA는 모놀리틱 아키텍처의 문제점들을 많이 보완해주는 것이다. 배포에 있어 서비스 별로 배포가 가능하기 때문에 배포 시 전체 서비스의 중단이 없다. 또한 요구사항을 신속하게 반영하여 배포할 수 있다는 큰 장점이 있다. 또 확장에 있어서 특정 서비스에 대한 확장성이 용이하고 클라우드를 사용할 때 매우 적합하다. 장애가 발생할 때는 장애가 전체 서비스로 확장될 가능성이 적고, 부분적 장애에 대한 격리가 수월하다는 장점들이 있다.

  그러나 이런 완벽해 보이는 MSA도 단점이 있는데, 아키텍처가 복잡하고 전체 서비스의 크기가 크기 때문에 성능에 있어 서비스 간에 호출 시 통신 비용과 부하가 많다는 단점이 있다. 또한 테스트와 트랜잭션의 복잡도가 증가하고 많은 자원을 소모한다. 마지막으로 여러 서비스에 분산되어 있기 때문에 한 번에 조회하는 것이 쉽지 않고 데이터의 정합성 도한 관리하기 어렵다는 단점이 있다.