Monolitic to MSA

아키텍처란?

• 컴퓨터 공학에서는 개념의 설계로, 컴퓨터 시스템의 근간이 되는 운영 구조를 의미한다.
• 소프트웨어적 의미로는 소프트웨어의 구성요소들 사이에서 유기적 관계를 표현하고, 소프트웨어 설계와 업그레이드를 통제하는 지침과 원칙이다.

• 아키텍처는 진화중!

모노리틱 아키텍처

• 개념

  전통적인 웹 개발 아키텍처로,

  하나의 애플리케이션 내에 모든 로직이 몽땅 들어가 있는 통짜 구조이다.

• 장점

  • 하나의 애플리에키션만 개발하면 되어 간편하다.
  • 배포도 쉽고, 테스트도 쉽다.
  • 트랜잭션관리 등이 용이하다.

• 단점

  • 작은 크기의 애플리케이션에선 괜찮지만, 큰 크기가 되면 빌드와 배포에 오래 걸린다.
  • 다수의 사람이 협업하기 어렵다.
  • 잦은 배포가 있을 경우 컴파일 해야 하는 양이 많아 비효율적이다.

결국, 규모가 작은 애플리케이션의 경우 상관없지만, 규모가 커질 경우 부담이 될 수 있는 구조이다.

마이크로 서비스 아키텍처

• 개념

  대용량 서비스를 위해 정의된 아키텍처이다.

  SOA를 근간으로 하면서, 대용량 웹서비스에 맞게 사상이 경량화되었다.

  • 수직적 분할 (Vertical Slicing) : 데이터부터 비즈니스 로직까지 독립적으로 상호 컴포넌트 간 의존성이 없게 나눈다.

  서비스 간 통신은 Rest API와 같은 표준 인터페이스로 한다.

  배포 과정에서도 독립된 서버로, 다른 컴포넌트와 의존성을 가지지 않고 독립적으로 배포된다.

• 장점

  • 배포가 유연하다. 각 서비스가 서로 독립적이기 때문에, 변경이 있는 서비스만 따로 배포할 수 있다.
  • 확장성이 좋다. 부하가 많은 특정 서비스만 확장할 수 있다.
  • 협업 시, 팀간의 의존성이 제거되어 애자일 방법론에 적합하다.

• 단점

  • 서비스가 각자 분리가 되어 있기 때문에 테스팅이 불편하다!
  • 성능상 문제가 생긴다. 서비스 간 호출을 API로 하기 때문이다.
  • 서비스간 트랜잭션 처리가 까다로워진다.

MSA는 대용량 웹서비스에 맞춰 개발된 API 기반의 아키텍처지만, 이게 무조건 정답은 아니다. 각자 상황에 맞는 아키텍처를 선택하는 것이 중요!

참고 문헌

• 이미지 출처 - Kencoder Blog : My perspective about Software Architecture
• 이미지 출처 - 판교 개발자 데이 : AWS가 제안하는 서버리스 아키텍처
• 이미지 출처 - Hash#Include : Microservices vs Monolithic architecture
• 조대협의 불로그 : 대용량 웹서비스를 위한 마이크로 서비스 아키텍처의 이해