[MSA] MSA란?

몇년전부터 심심찮게 보이던 용어였는데 최근에는 굉장히 많은 기업에서 MSA 구조로 서비스를 만들고 있는 것 같다. 그래서 최근 Spring Cloud를 이용하여 MSA를 공부하고 있어 정리하고자 한다.

---

MSA를 이해하기 위해선 당연하게도 MSA 구조가 아닐 때의 한계점에 대해 알아야한다.
가장 흔하고 전통적인 웹 애플리케이션의 구조는 Monolithic Architecture이다.

좌측처럼 하나의 DB와 하나의 큰 애플리케이션으로 구성되어 있는 구조가 Monolithic한 구조인데 MSA와의 비교에 앞서 Monolithic 구조의 장단점을 살펴보자. 조금만 생각해보면 너무 당연한 이야기들이 많으니 편하게 읽어보자!

---

Monolithic Architecture 장점

1. 배포 파이프라인 구성의 간편함
   • 하나의 어플리케이션만을 관리하면 되기 때문에 배포 파이프라인이 비교적 간단하다.
2. 통합시나리오 테스트 진행이 수월
   • 서비스의 필요한 로직이 같이 관리되므로, 단위테스트가 아닌 통합테스트에 유리하다.
3. 유지보수의 간편함
   • 이 부분은 약간 애매한데, 정확히는 일정 규모 이하로는 유지보수가 간편하지만, 규모가 커질수록 복잡성은 비약적으로 증가한다.

---

Monolithic Architecture 한계

1. 전체 시스템 구조 파악의 어려움
   • micro service 하나와 비교할 때 아무래도 서비스가 덩치가 크다 보니 전체 구조를 파악하는데 상대적으로 난이도가 더 높다.
2. 빌드 시간 및 테스트 ,배포 시간의 급증
   • 서비스의 규모가 크다 보니 당연하게도 빌드, 테스트, 배포에 더 많은 시간이 소요된다.
3. 서비스의 특정 부분만 scale-out 어려움
   • 서비스를 운영하다보면 유저의 트래픽이 모든 부분에 고르게 집중되지 않는다. 그래서 특정 모듈만 성능을 높일 필요성이 생기는데, 모놀리틱 구조의 경우 쉽게 해결하기 어렵다.
4. 개발 기술의 종속
   • 전체 서비스가 하나의 언어, 프레임워크로 구성
5. 내부 모듈 간 결합도가 높기 때문에, 특정 모듈에 문제가 생기면 다른 모든 모듈에도 영향을 끼칠 가능성이 높다.

여기까지 Monolithic 구조의 장점과 한계점에 대해 알아보았다.
그렇다면 MSA는 당연히 이런 구조의 한계점을 극복할 수 있는 구조이다.
(물론 그렇다고 MSA가 무조건 좋다는건 아니고 MSA도 단점이 있다.😅)

Micro Service Architecture(MSA)

-> 독립 된 각각의 모듈을 조립하여 만드는 하나의 서비스를 위한 아키텍처

제프 베조스의 2002년 메일 내용

1) 모든 팀은 서비스 인터페이스로 데이터와 기능을 공개하세요.
2) 팀들은 이 인터페이스로 통신 하세요.
3) 직접 링킹, 다른팀 저장소에 직접 억세스, 공유메모리, 백도어 등, 다른 어떤 통신방법도 허용되지 않습니다. 네트워크를 통한 서비스 인터페이스 호출만 허용합니다.
4) 어떤 기술을 사용하는가는 중요하지 않습니다. HTTP, Corba, Pubsub, 커스텀 프로토콜 다 괜찮습니다.
5) 모든 서비스 인터페이스는 예외없이 기초부터 모두 외부에서 사용 가능하도록 설계되어야 합니다. 즉, 팀들은 인터페이스를 외부 개발자가 이용가능하도록 계획하고 설계해야 한다는 것입니다. 예외는 없습니다.
6) 이를 지키지 않는 사람은 해고 될것입니다.
7) 고맙습니다. 좋은 하루 되세요!

위는 2002년 아마존의 제프 베조스가 모든 직원들에게 보넀던 메일이다. MSA의 본질에 대해 잘 설명한 사례라고 생각되어 흥미로웠다. 지금으로부터 약 20년전부터 이런 통찰력을 갖고 있었다는게 대단하기도 하고..

MSA 장점

1. 서비스 별 개별 배포 가능(배포 시 전체 서비스의 중단이 없고 빠름)
2. 특정 서비스에 대한 확장성에 유리
3. 일부 서비스의 장애가 전체 장애로 확장 될 가능성이 낮음
4. 각 서비스에 새로운 기술을 적용하기 유연(새로운 언어, 프레임워크 사용 등)
5. 특정팀에 배치 된 신규 인력은 해당 팀이 맡고 있는 서비스를 빠르게 이해 가능
6. 문제사항을 고립시켜 살펴볼 수 있음(우리팀이 맡고 있는 부분만 보면 됨)

MSA 단점

1. 서비스 간 호출 시 API 사용하므로 통신에 대한 비용 latency에 대한 이슈 항상 고려
2. 서비스가 분리되어 있어 통합테스트가 어렵고 트랜잭션의 복잡도가 증가
3. 데이터베이스가 분산되어 관리되므로 데이터 관리의 어려움
4. 서비스가 많아짐에 따라 로깅, 모니터링, 배포 등이 더 복잡해질 수 밖에 없음(관리의 어려움)
5. 시스템간의 의존성을 분리하는것이 쉽지 않은 작업.. 오히려 치명적이 될 수 있음
6. 다양한 개발언어를 사용하는 장점 역시 독이 될 수 있음. 다양한 시스템을 운영할 수 있는 devops전문가도 필요하고, 운영인원의 부재가 치명적일 수 있음

장단점에 대해 따로 부가설명 하지 않아도 대부분 자연스럽게 이해가 되는것 같다.
조금만 생각해보면 왜 장점이 생기고 단점이 생기는지 알 수 있다.

그렇다면 MSA 전환이 언제나 옳을까? 무엇을 고려해봐야할까?

위에서 언급한 두 아키텍쳐는 무엇이 더 좋고 나쁘고를 말할 수 있는 것은 아니다.
만약 MSA 전환을 고려하고 있다면 먼저 Why에 대한 대답이 명확하게 나와야 한다.
MSA가 현재 우리 조직에 적합한 구조인지, 어떻게 도입할 것이며, 어떤 기술을 사용 할 것인지 명확한 계획이 필요하다. MSA는 단순 기술의 영역이 아닌 조직구조와 운영의 영역이 포함되어 있기 때문이다.

나 역시도 MSA 구조로 개발하는 경험을 하고싶다. 새로운 기술을 사용해보고 싶은 개발자들이라면 누구든 욕심이 나겠지만, 많은 부분을 고려해야되는것 같다!

이번 포스팅에서는 MSA에 대한 숲을 먼저 살펴보았다. 다음 포스팅부터는 MSA를 가능하게 만드는 많은 기술들에 대해 차근차근 살펴보고자 한다.