MSA란 무엇인가

By Aria on December 21, 2018

기초적인 Monolithic

Monolithic은 일반적으로 한 프로젝트(서비스)에서 모든 기능을 서빙하는 것을 이야기한다. 매우 기초적인 방법론으로 빠르고 쉽게 서비스를 구성할 수 있지만, 서비스에 요구되는 것들이 점점 무거워짐에 따라 하나의 프로젝트에서 모든 기능을 서빙하는 것을 비효율을 야기하게 된다.

Monolithic의 문제점

100명 정도가 모여 하나의 앱을 서비스한다고 가정해보자. 하나의 앱이므로 monolithic하다는 것은 하나의 프로젝트에 모든 기능을 담고 서빙하는 것으로 생각하면 된다. 하나의 레포지터리에 100 명의 개발자가 붙어서 여기저기 수정하고 배포한다면 어떨까?

  • 부분의 장애가 전체 서비스의 장애로 확대될 수 있다.
  • 배포가 잦다. 너도 나도 그대도 배포를 한다면 배포가 잦겠다. 한 번의 배포(file changes)가 전체 프로젝트의 몇 %의 코드/기능을 수정하는 것일까? 프로젝트의 규모가 크기에, 굳이 배포가 되지 않아도 되는 부분이 더 많을 경우가 대부분일 것이다. 불필요한 부분에 대해 배포를 할 필요는 없어보이는데 말이다.
  • 배포 속도가 느리다. 프로젝트의 크기가 커짐에 따라 배포 대기 시간이 비약적으로 증가하게 된다.
  • 프로젝트의 크기가 크다. 디렉토리 구조가 엄청나게 복잡해진다. 읽어야 할 라인 수나 파일 수가 부담되는 순간 가독성과 유지보수성은 떨어지기 마련이다.
  • 기능 분리가 명확하지 않다. 여러 팀에서 공통으로 사용하는 모듈이 있는데, 이 부분을 변경한다면 어떻게 될까? 한 부분의 코드를 변경하면 monolithic의 다른 부분에 영향을 미칠 수 있다. 점점 legacy가 된다. 테스트 코드를 촘촘히 짜는 것도 한계가 있다. 테스트가 어려워진다.
  • 데이터베이스의 규모가 거대하다. Monolithic 서비스에는 하나의 데이터베이스가 붙어있고, 프로젝트의 규모가 커질수록 데이터베이스의 크기도 같이 커지는데, 스케일 업/다운 문제가 발생하기 쉽다.
  • 좋은 최신 기술을 적용하기 어렵다. 기술을 도입하든 버전업을 하든 한 번 건들이기 시작하면 대규모 작업이 되기 때문이다. 새로운 기술을 적용하는데 있어서 개발자들이 보수적이게 된다.

MSA

Micro Service Architecture의 약자로, 비지니스 로직 단위로 잘게 쪼개어 서비스하는 설계 패턴을 의미한다. 한 서비스에 온갖 것을 다 올리는 Monolithic과는 상반되는 개념이다. 코드를 객체 단위로 작성하는 측면에서 OOP의 목적과도 비슷하다고 볼 수 있겠다. 소프트웨어의 원칙 중 하나는 ‘작게 유지하는 것‘이다. Micro-service는 이 원칙을 확장한 것으로 소규모 기능을 기반으로 독립적으로 배포할 수 있는 서비스를 구축하는데 중점을 둔 설계 패턴이다.

어떻게 쪼개는가?

  • 모듈은 비지니스 기능을 기반으로 쪼개져야 한다.
  • SRP(Single Responsibility Principle) 원칙을 따라야 한다.

MSA의 특징

  • 마이크로서비스의 각 모듈은 명확한 경계를 가지고 있다.
  • 각 서비스는 독립적으로 배포할 수 있다.
  • 한 서비스는 한 데이터베이스에 연결되어 있다.
  • Stateless. 서비스 간 요청 간에 정보를 저장하지 않는다.
  • 각 서비스를 이어주는 Gateway 서버가 별도로 존재한다. Gateway 서버에서는 라우팅, 캐싱, 프록싱을 한다.
  • 보통 한 팀에서 하나의 서비스를 관리하게 된다.

MSA API Gateway


장점은 뭘까?

  • 기술 부채를 해소하기 더 쉬워진다. 서비스 단위가 작게 유지되므로, 다른 서비스를 방해를 하지 않고 다양한 기술을 적용해 볼 수 있다.
  • 서비스 별로 다른 트래픽을 관리하기 쉬워진다. 호출 횟수가 엄청나게 많은 API가 하나 있다고 하자. Monolithic으로 구현하게 되면, 이 부하를 소화하기 위해 큰 덩어리의 코드를 여러 대의 서버에 다 올려야 한다. 하지만 MSA 구조라면, 호출 횟수가 많은 서비스에 대해서만 서버를 증설하면 된다.
  • 서비스 별 모니터링이 용이해진다.
  • 한 서비스에서 장애가 나도 전체 서비스에 영향을 주지 않게 된다.

단점도 있다.

  • 느리다!
    • 개발 속도가 느리다. API를 서빙하기 위해서는 Gateway를 통해야 하기 때문에 서비스 쪽만 개발해서 되는 것이 아니라 gateway에 대한 개발도 필요하게 되므로 개발자들 간의 커뮤니케이션 코스트가 증가하게 된다. 작업량도 늘어나게 된다.
    • 응답 속도도 느리다. 최소 한 번 이상의 request가 더 필요해지므로 monolithic에 비해 API 응답 속도가 느려지게 된다.
  • 서비스의 경계를 정의하는 것이 쉽지 않을 때도 있다. 결제 서비스 내에서 복잡한 쿠폰 기능을 처리 vs 결제 서비스 + 쿠폰 서비스
  • 서비스 호출이 다른 서비스를 연속적으로 호출한다면 디버깅이 어렵다.

정리

MSA가 어디에서나 정답은 아니다.

대규모의 복잡한 기능을 서빙하는 수십, 수백명의 개발자가 달려들어야 하는 서비스를 만드는 것이 아니라면 MSA는 오히려 개발을 더 복잡하게 만들 수 있다. Monolithic architecture와 MSA가 내게 필요한 순간인지를 알아야 한다.

Back to blog