마이크로 서비스 아키텍처 (MSA) 그리고 모놀리식 아키텍처

 

요즘 웹 개발 프로젝트를 진행함에 있어 어떠한 프레임워크를 사용하는 것이 좋을지 고민하고 조사를 하던 중 MSA 라는 개념을접하게 되었다. MSA 라는 개념이 많이 대두되고 있는데 그렇다면 도대체 MSA란 뭘까? 

그리고 이러한 아키텍처가 프레임워크와 무슨 관계가 있을까? 

 

궁금증을 해소 해보도록 하자.

 

그전에, 마이크로 서비스 아키텍처의 반대 개념인 모놀리식 아키텍처에 대해 먼저 알아볼 필요가 있다.

두 개념모두 애플리케이션을 구성하는 구조에 대한 개념이다.

 

 

모놀리식 아키텍처 (Monolithic Architecture) 

---

모놀리식 아키텍처란? 

 

전통적인 아키텍처를 지칭한다. 애플리케이션의 모든 구성요소가 한 프로젝트 안에 통합되어 있는 형태를 말한다.

모놀리식 아키텍처는 모든 프로세스가 결합되고 연동되어 있으며 이 모든 구성요소가 단일 서비스로 배포가 된다.

보통 백엔드 개발을 입문한다 하면 10명 중 9명은 이러한 구조를 처음 접하게 될 것이다. 

이 구조는 우리가 흔히 알고있는 구조이다. 하나의 프로젝트안에 모든 구성요소가 포함되어 있다.

 

Java와 Python의 대표적인 프레임워크인 Spring과 Django가 이러한 아키텍처로 구현되어 있다.

 

 

모놀리식 아키텍처의 장점

• 단순한 아키텍처 구조로 개발 초기에 개발이 용이하다.
• 배포가 간편하다.
• E2E(End-To-End) 테스트가 용이하다.
  => (E2E 테스트란 사용자 중심으로 처음부터 끝까지 어플리케이션 흐름을 테스트하는 방법론)
• 개발 환경이 같아서 복잡하지 않다.

 

살펴보면 결국 이 모든 장점은 "구조가 단순하다" 라는 부분에서 오는 비슷한 결의 장점들이다.

 

 

모놀리식 아키텍처의 단점

• 작은 수정사항이 있어도 전체를 다시 빌드하고 배포 해야 한다.
• 일부 서비스의 장애가 전체 서비스 장애로 이어진다.
• 대규모 팀 작업이 어려움 (많은 양의 코드가 몰려있기 때문에 모든 개발자가 전체를 이해할 수 없다.)
• 각 기능에 적합한 언어와 프레임워크를 선택할 수 없다.

 

이 모든 단점들을 이해할 수 있는 함축적인 한 단어가 생각났다. => 비효율적 

 

그렇다 결국 모놀리식 아키텍처의 한계점은 비효율적이라는 것이다.

 

극단적으로 예를 들어보겠다.

한 회사에 A팀과 B팀이 있다고 가정을 해보자.

A팀 기능은 빈번하게 수정이 발생하고 업데이트를 해줘야한다.

그에 반해 B팀 기능은 초기 개발 이후 오랫동안 수정과 업데이트를 해주지 않아도 된다.

그럼에도 불구하고 B팀은 A팀이 수정과 업데이트를 할 때, 함께 서버를 내리고 켜야하기 때문에 이 과정에서 신경을 써야하고 불필요한 시간이 낭비된다.

 

그렇기 때문에 이런 생각을 해볼 수 있다. 

이 두 팀을 독립적으로 배포가 가능하도록 분리할 수는 없을까? 

 

 

이러한 관점에서 떠오르게 된 개념이 마이크로 서비스 아키텍처이다.

 

 

마이크로 서비스 아키텍처 (Micro Service Architecture) 

---

마이크로 서비스 아키텍처란? 

큰 애플리케이션을 여러 개의 작은(micro) 서비스로 조각해서 나누어 연결한 구조이다. 각각의 작은 가벼운 모놀리식 아키텍처와 유사한 구조를 갖는다. 각 서비스는 독립적으로 배포가 가능해야하며 서로 의존성이 낮아야 한다.

이러한 아키텍처로 설계된 프레임워크는 Flask와 Fast-API 등이 있다.

Flask와 Fast-API를 공부해 보신 분들이라면 아시겠지만 이 두 프레임워크는 상대적으로 가볍고  API 서버를 중점으로 구현된다. 이는 Flask와 Fast-API가 마이크로 서비스 아키텍처를 지향하는 철학이 반영된 것이다.

 

마이크로 서비스 아키텍처의 장점

• 서비스 일부의 장애가 전체 서비스에 영향을 미치지 않는다.
• 각 서비스는 독립적인 소규모 팀 조직이 분산되어 개발을 하기 때문에 개발 주기가 단축된다.
• 각 기능별 스케줄에 맞춘 빠른 배포 및 업데이트 가능
• 유연하다. 즉, 각 기능에 맞는 언어와 프레임워크를 사용할 수 있다.

 

마이크로 서비스 아키텍처의 단점

• 규모가 커질수록 아키텍처의 복잡함으로 인해 관리가 어렵다.
• 데이터가 분산되어 있기 때문에 통합하여 조회하기 쉽지않다.
• 개별 서비스의 테스트는 쉽지만 전체 서비스 즉 E2E 테스트가 어렵다.
• 각 서비스간 호출시 지연시간이 증가한다.
• 분산으로 인한 트랜잭션 관리, 에러 트래킹등이 어렵다.

 

 

 

그래서 모놀리식 아키텍처 VS 마이크로 서비스 아키텍처, 무엇을 선택할까?

---

이 부분은 사실 애매한 부분이 많다. 조사를 하다 보면 대부분 초기에는 모놀리식 아키텍처로 개발을 하고 서비스를 구현함에 있어 규모가 커지면 마이크로 서비스로 전환하는 것이 바람직하다고들 얘기한다.

 

그렇지만 나는 그렇게 생각하지 않는다. 모놀리식 아키텍처로 개발된 애플리케이션을 마이크로 서비스 아키텍처로 전환하는 것이 과연 쉬울까? 절대 그렇지 않을것이다. 물론 불가피 하게 중간에 전환해야하는 경우는 어쩔 수 없지만... 처음부터 선택해서 하는것이 좋지 않을까라고 생각해본다.

 

프로젝트의 규모, 특성을 고려하여 결정하는 것이 바람직하다. 

• 본 프로젝트가 유연하게 확장을 요구하는가?
• 배포를 자주 할 예정인가? 
• 한팀이 개발과 운영을 동시에 할 수 있을만큼의 준비가 되어 있는가?
• 어느쪽을 선택하는것이 더 비용이 절감될 것인가? ( 여기서 비용이란 전체 서비스 장애로 인한 기회비용도 고려되어야 한다고 생각한다. )

 

마치며

---

MSA가 요즘 대세라고 해도 본인이 진행하는 프로젝트에 적합하지 않음에도 불구하고 선택하는 것은 잘못된 일이다.  

위에 언급된 특성들을 고려하고 선택하는 것이 바람직하다.

기존의 전통적인 모놀리식 방식 또한 꾸준한 안전성으로 역사가 증명해왔기 때문에 모놀리식 방식을 선택한다고 해서 시대에 뒤떨어지는 것은 아니다. 또한 프레임워크 별로 지향하는 아키텍처가 있기 때문에 그에 알맞는 프레임워크를 선택하는 것 또한 중요하다고 생각한다.