안녕하세요! 이노베이션 아카데미 인턴 이인평 입니다.

저는 매 주마다 진행했던 자체 세미나에서 ‘MSA’ 라는 주제로 발표를 했던 적이 있는데요. 그때 발표 내용을 블로그에 정리해서 기록 해볼까 합니다. 많이 부족한 내용들이지만 ‘이런 걸 했구나~’라고 생각해주시면서 봐주세요..^^

당시 발표에 사용했던 PPT를 이용하여 설명드릴게요!

MSA?

MSA(MicroServices Architecture)를 정확히 알아보기 전에, Monolithic Architecture부터 알아봅시다!

Monolithic는 사전적으로 ‘단단히 짜여 하나로 되어 있는’ 라는 뜻을 갖고 있습니다. 그렇다면 Monolithic Architecture의 뜻이 어느 정도 예상 되시나요?

Monolithic Architecture란 ‘소프트웨어의 모든 구성 요소가 한 프로젝트에 통합되어 있는 형태’를 말합니다. 간단한 구조이고 유지보수가 용이하기 때문에 소규모 프로젝트에 적합하다고 볼 수 있습니다!

많은 개발자들과 기업들은 Monolithic Architecture를 잘 이용하고 있었습니다. 하지만 점점 애플리케이션의 규모가 커질수록 Monolithic Architecture의 한계점이 나타났습니다.

서비스, 프로젝트가 커질수록 시스템구조 파악의 어려움이 있다.
빌드 시간 및 테스트 시간, 그리고 배포 시간이 기하 급수적으로 늘어나게 된다.
부분 장애가 전체 서비스의 장애로 이어지는 경우가 발생한다.
특정 서비스에 대한 부분적인 확장이 힘들다.
개발 언어에 종속적이다.

앞서 말씀드린 Monolithic Architecture의 한계점을 극복하기 위해 많은 기업들은 해결 방법을 찾기 위해 노력 했었는데요, 이때 등장한 개념이 바로 Microservices Architecture입니다!

MicroServices Architecture는 Monolithic Architecture와는 달리, ‘하나의 큰 애플리케이션을 특정 목적을 가진 애플리케이션 단위(서비스)로 나누어 변경과 조합이 가능하도록 만든 형태‘입니다.

MSA의 특징을 살펴볼까요?

각각의 서비스는 크기가 작을 뿐, 서비스 자체는 하나의 Monolithic Architecture와 유사한 구조를 가진다.
각각의 서비스는 독립적으로 배포가 가능해야 한다.
각각의 서비스는 다른 서비스에 대한 의존성이 최소화 되어야 한다.
각 서비스는 개별 프로세스로 구동되며, REST같은 가벼운 방식으로 통신되어야 한다.

Monolithic Architecture와 MicroServices Architecture를 나타내는 이미지를 보시면 확연한 차이를 느끼실 수 있을 겁니다.

따라서 MSA를 채택하면 다음과 같은 이점들이 있다고 하네요!

배포관점
- 서비스 별 개별로 배포가 가능하기 때문에 전체 서비스의 중단이 없다.
- 요구 사항을 신속하게 반영하여 각 서비스마다 빠른 배포가 가능하다.
확장 관점
- 특정 서비스에 대한 확장성이 용이하다.
장애 관점
- 장애가 전체 서비스로 확장될 가능성이 적다.
- 부분적 장애에 대한 격리가 수월하다.
그 외
- 신기술의 적용이 유연하다.
- 서비스를 Polyglot하게 개발, 운영할 수 있다.
- 각각 서비스의 부하에 따라 개별적으로 Scale-out이 가능하다.

MSA 구조

Inner Architecture

미국의 정보 기술 연구 및 자문 회사, 가트너에서 예전에 정의한 MSA 의 이미지를 가져와봤습니다. 크게 Inner Architecture, Outer Architecture로 나누어 설명드릴게요.

(이미지가 많이 작네요..확대해서 크게 봐주세요!)

오른쪽에 있는 이미지는 MSA에서 Inner Architecture를 뜻하는, 남색 부분들을 확대한 것입니다. 이는 애플리케이션 내부의 서비스를 어떻게 쪼개는 지에 대한 설계와 관련이 있는데요, 여기서 고려해야 할 사항은 다음과 같다고 합니다.

Micro Service를 어떻게 정의할 것인가?
DB Access 구조를 어떻게 설계할 것인가?
Micro Service 내 API를 어떻게 설계할 것인가?
등등..

Inner Architecture는 비즈니스 마다, 서비스 마다, 시스템 마다 각각의 특성이 있어서 딱히 표준이 정해져 있지는 않다고 합니다. 따라서 MSA 를 설계하는 데에 가장 어려운 부분이라고 하네요..!

Outer Architecture

Outer Architecture의 종류는 다음과 같습니다.

External Gateway
Service Mash
Backing Services
Telemetry
CI/CD Automation\

이제 MSA의 Outer Architecture에 대해 간단히 알아보도록 하겠습니다!

External Gateway

전체 서비스 외부로부터 들어오는 접근을 내부 구조를 드러내지 않고 처리하기 위한 요소이며, 사용자 인증과 권한 정책 관리를 수행합니다.

API Gateway가 여기서 가장 핵심적인 역할을 담당한다고 하는데요, 서버 최 앞 단에 위치하여 모든 API 호출을 받고, 받은 API 호출을 인증한 후, routing과 같은 역할을 합니다.

Services Mash

MSA 내부에서 Micro Service 간의 통신을 담당하며, 이를 위해 Service Discovery, Routing, 트래픽 관리 등을 진행합니다. 오른쪽 이미지는 Sidecar pattern으로 구현한 Service Mash의 예시입니다.

여기서 Sidecar pattern이란, 마이크로 서비스와 독립적으로 동작하는 별도의 컨테이너를 붙이는 패턴이라고 합니다..!

이미지에 나와있는 Sidecar proxy는 서비스에 들어오거나 나가는 / 모든 네트워크 트래픽을 처리합니다. 마이크로 서비스와 sidecar Proxy가 병렬로 구성되어있기 때문에, 서비스 호출 시 서비스가 직접 서비스를 호출하는 것이 아니라 proxy 를 통해서 호출하게 됩니다.

이러한 특징 때문에 큰 규모의 마이크로서비스 환경이라고 하여도 개발자가 별도의 작업 없이 서비스의 연결 뿐만 아니라, 로깅, 모니터링, 보안, 트래픽 제어와 같은 다양한 이점을 얻을 수 있다고 해요!