마이크로서비스 아키텍처과 모놀리틱 아키텍처의 장단점

MSA(micro service Architecture)↔Monolithic Architecture

---

MSA는 Monolithic Architecture와 반대되는 개념이다. 여러 기업들이 서비스를 MSA기반으로 변경하는 과정을 수행했고, 현재에도 진행 중인 기업들이 많은 것으로 알고 있다. 아키텍처를 수정하는 것은 기반 자체를 변경하는 과정이기에 많은 인력과 시간을 요구로 하는 작업인데 왜 많은 기업에서 MSA기반의 서비스를 지향하는 것인지에 대해 알아보기 위해 두 아키텍처의 장단점을 정리하였다.

 

Monolithic Architecture 장단점

• 장점
  • 개발 초기에 단순한 아키텍처 구조로 인해 개발에 용이
  • 어떤 서비스든지 개발되어 있는 환경이 같아서 복잡하지 않음
  • 배포가 간단함
  • 확장성
    • 로드밸런스를 이용하여 로드 부하를 나눠 가지는 방식으로 진행
  • 쉽게 고가용성 서버 환경 조성 가능
  • End-to-End 테스트에 용이
• 단점
  • 프로젝트의 규모가 커짐에 따라 애플리케이션 구동 시간이 늘어나고 빌드 및 배포 시간이 길어짐
  • 조그마한 수정 사항이 있어도 전체를 다시 빌드 및 배포
  • 많은 양의 코드가 몰려 있어서 개발자가 모든 코드를 이해하기 힘들며, 유지 보수가 어려움
  • 일부분의 오류가 전체에 영향을 미침 (장애 전파)
  • 기술 스택이 한 번 정해지면 바꾸기 어려움
  • 전체 애플리케이션 확장은 쉽지만, 부하 분산을 위해 각 컴포넌트를 독립적으로 확장하기 어려움

---

Micro Service 특징

• 각각의 서비스는 그 크기가 작을 뿐, 서비스 자체는 하나의 모놀리식 아키텍처와 유사한 구조를 가짐
• 각각의 서비스는 독립적으로 배포가 가능해야 함
• 각각의 서비스는 다른 서비스에 대한 의존성이 작아야 함
• 각 서비스는 개별 프로세스로 구동되며, REST API와 같은 가벼운 방식으로 통신되어야 함

Micro Service 장점

• 배포 관점
  • 서비스 별 개별 배포 가능(배포 시 전체 서비스의 중단이 없음)
  • 독립 배포가 가능하므로 개발자의 자율성 증가
  • 요구 사항을 신속하게 반영하여 빠르게 배포 가능
• 확장 관점
  • 특정 서비스에 대한 확장성에 용이
  • 클라우드 사용에 적합
• 장애 관점
  • 장애가 전체 서비스로 확장될 가능성\낮음
  • 부분적 장애에 대한 격리 수월
• 코드 / 유지 보수 관점
  • 팀 별로 프로젝트가 분리되어 있으므로 코드의 이해도가 증가하고, 그에 따라 유지 보수하기 쉬움
• 신기술의 적용이 유연하고, 서비스를 polyglot하게 개발 및 운영할 수 있음
  • polyglot 개발: 여러 프로그래밍 언어, 패러다임 등을 사용

Micro service 단점

• 성능 관점
  • 서비스 간 호출 시 API를 사용하기 때문에 통신 비용 및 지연 시간 증가
• 데이터 관리 관점
  • 데이터가 여러 서비스에 걸쳐서 분산되므로 한 번에 조회하기 어렵고, 데이터의 정합성 또한 관리하기 어려움
• 테스트 / 트랜잭션 관점
  • 단위 테스트는 쉽지만, 통합 테스트 및 End-to-End 테스트 단위로 들어가면 여러 서비스의 API를 검증해야 하므로 시간과 비용이 많이 듦
  • 각 서비스 별로 데이터베이스가 있으므로 트랜잭션을 구현하기 까다로움
• 아키텍처가 다소 복잡하므로 개발 및 관리가 어렵고, 비용이 많이 듦

---

많은 기업에서 MSA 도입을 수행 중이지만 현재 기업 및 프로젝트에 적합한지에 대해 잘 분석할 필요가 있다. 이러한 장단점에 대해 분석하다 보니 MSA도입은 대기업 위주로 이뤄졌으며 가장 기억에 남는 기업은 넷플릭스와 우아한 형제들이었다. (넷플릭스는 완전한 MSA도입에 8년이 걸렸다고 한다.. )

이 기업들은 서버가 중단되거나 이에 준하는 위협이 엄청난 손실을 야기하기에 MSA를 도입하는 것이 필수적이었겠지만, 이러한 대규모 프로젝트가 아닐 경우에는 서비스의 방향을 고려하여 아키텍처를 설계해야 한다.