MSA 적응기 — 모놀리식과의 차이, API Gateway, 전환 시 주의할 점

2022.05.11약 6분 소요최종 수정: 2026.10.21

서론의 서론

MSA(Micro Service Architecture)를 다루게 되면서 겪었던 의문점들 및 느낀점들을 정리해보려고 합니다. 내용이 조금 길어질 것 같아 여러 포스트로 나누어 진행하게 되었습니다.

서론
- MSA란 무엇인가?
- MSA가 자주 언급되는 배경은?
- MSA를 공부하게 된 이유?
본론
- MSA와 모놀리식의 차이점?
- 어떻게 MSA 구조로 사용하고 있는가?
결론
- MSA로 프로젝트 구성 시 주의할 점
- 느낀 점

으로 구성하였습니다.

MSA란 무엇인가?

MSA(Micro Service Architecture)란
하나의 큰 어플리케이션을 여러개의 작은 어플리케이션으로 쪼개어 변경과 조합이 가능하도록 만든 아키텍쳐 라고 할 수 있습니다.

기존의 모놀리식(한 프로젝트내에서 구성) 어플리케이션을 여러개의 마이크로 서비스들로 나누고, 각각을 느슨한 구조로 만들어 RestAPI와 같은 서비스간 가벼운 통신을 통해 데이터 및 요청/응답을 주고 받는 구조입니다. 즉, 마이크로 서비스는 스스로 돌아갈 수 있으며(의존하지 않는 느슨한 구조) 독립적으로 배포가 가능한 서비스라고 할 수 있습니다.

MSA 는 강제하는 방식이 아니기 때문에 각자의 서비스 환경에 맞는 여러가지 형태로 구성될 수 있습니다. 여러개의 엔드포인트가 각자의 마이크로 서비스에 분산되어 있는 형태일 수도 있고, API Gateway같은 앞 단의 최전방 서버를 통해서 단일 엔드포인트 서버로부터 마이크로서비스들을 호출하는 방식 등 다양한 형태로 구현할 수 있습니다.

MSA가 자주 언급되는 배경?

최근 들어 클라이언트 디바이스들이 다양해지고(iOS, Android, 태블릿 등), 빅데이터 등으로 인해 과거와는 다르게 데이터량이 기하급수적으로 늘어남에 따라 어플리케이션은 점차 무거워지게 되었습니다. 여러 개발자들이 한 프로젝트에서 작업하다 보니 스파게티 코드도 늘어날 뿐더러, 실 사용자가 사용하는 운영 시스템에 서비스가 배포되려면 굉장히 많은 시간이 소요되게 되었습니다.

이러한 문제점들을 극복하기 위해 아마존, 넷플릭스 와 같은 거대 IT기업들 사이에서 MSA 구조를 적용하였고, 실제로도 MSA 구조로의 전환과정을 널리 알리는 IT 공룡기업들의 기술력 어필 과정에서 MSA 구조는 차츰 주목받기 시작하였습니다.

아마존과 넷플릭스가 MSA 구조를 도입하여 좋은 효과를 내기 시작하자, 서비스 규모가 큰 국내IT기업들도 앞다투어 적용하기 시작하였습니다. 저는 특히 11번가에서 제작한 MSA 전환기를 아주 재미있게 보았습니다. 배달의민족 마이크로서비스 여행기 등등

MSA를 공부하게 된 이유?

대학교때 배우던 JAVA만 생각하고 있다가 처음 Spring Framework를 맞닥뜨렸을 때 느꼈던 거대한 벽처럼, 모놀리식 구조에서만 개발하던 저는, 지금의 회사로 이직을 한 후 MSA구조를 처음 맞닥뜨리고 상당한 충격을 받았습니다.

당시의 저는 mysql/oracle만 사용했었기 때문에 각각의 마이크로 서비스 환경에 맞는 여러가지 DB를 접하게 된 것, 안정적인 서버 간 통신을 위한 여러가지 고려사항, 마이크로 서비스들마다 다른 여러가지 배포 전략, MSA를 효율적으로 사용하기 위한 AWS 클라우드 서비스 등을 마주하고서 꽤나 혼란스러운 시기를 보냈습니다. ~적응하는 데 생각보다 오래 걸렸습니다…~

MSA와 모놀리식의 차이점?

모놀리식이라는 표현이 원래부터 존재했었던게 아니라, MSA(Micro Service Architecture) 개념이 생겨나면서부터 전통의 아키텍쳐를 지칭하기 위해서 생겨난 단어로 알고 있습니다.

모놀리식 구조

모놀리식 아키텍쳐는 한마디로 한 프로젝트 내에서 UI, 비즈니스로직, DB Handler 등이 한데 모여있는 구조입니다. 모놀리식 구조는 내부 모듈간 Dependency 가 MSA 구조 대비 강할 수 밖에 없습니다. 즉 Coupling이 강력하게 유지됩니다.

장점 :

단순한 구조, 개발의 용이함.
테스트 코드 작성 용이함.
MSA 대비 운영이 용이함.
내부 메소드 호출이기 때문에 네트워크를 통한 API 호출 대비 작은 구조에서는 성능이 좋음.
트랜잭션 관리가 용이

단점 :

규모가 커질수록 복잡도가 심각하게 증가.
유지보수가 어려워짐.
- 결합도가 강력하므로 지엽적인 코드 분석을 위해 전체를 분석해야 할 경우도 생김
배포의 어려움(장애가 났을 시 즉시 적용이 쉽지 않음)
SPOF(Single Point of Failure, 한 부분의 장애로 전체서비스가 장애가 날 수 있는 포인트)가 너무 큼.
서비스/기능 별 적합한 언어 및 프레임워크를 채택하기가 어려움.

MSA(Micro Service Architecture) 구조

장점 :

서비스별로 시스템이 독립적이기 때문에, 하나의 기능을 개발할 때 봐야할 코드 수도 적고, 이해하기 쉽다. → 유지보수하기 편하다
서비스가 독립적이기 때문에 장애 및 수정사항이 발생했을 경우 빌드 및 배포가 편하다
기능 별 적합한 언어 및 프레임워크를 선택할 수 있다.
서비스별 확장성에 용이함(주로 SaaS 제품 회사가 MSA를 택하는 이유, 트래픽이 몰리는 서비스만 Scale-out 가능)
서비스별 독립적이기 때문에 신기술 적용에 용이

단점 :

구현 복잡도가 증대
트랜잭션 관리 복잡(보상 트랜잭션, Saga 패턴 적용 고려)
테스트코드 구현 복잡
서비스 간 Dependency가 있는 경우 릴리즈가 복잡(ex. Nexus)

그렇다고 모놀리식이 걷어내야할 레거시, 안티 패턴은 절대 아닙니다. 경우에 따라 충분히 모놀리식도 좋은 효율을 낼 수 있습니다. 하지만 급변하는 비즈니스 상황에 유연하게 대처할 수 있는 구조는 MSA구조이기 때문에 많은 회사들이 MSA 구조를 택하고 있는 것은 사실입니다.

어떻게 MSA 구조를 사용하고 있는가?

앞서 말했듯, MSA 구조에 정답은 없지만 서비스 형태별로 유용한 구조는 몇가지 있습니다.

사실 다른 회사에서 어떤식으로 적용하고 있는지도 잘 모르지만, CSP(Cloud Solution Provider)에서 제공하는 서비스를 통해서 클라우드 상품을 개발하는 경우에는 아마 API Gateway 방식을 많이들 적용할 것 같습니다.

API Gateway란?

MSA 구조에서 API 게이트웨이는 클라이언트에서 백엔드 서버들 사이에 있는 미들웨어 성격을 가지고 있습니다. API Gateway는 API 서버로 넘어오는 요청들의 접근 제어 및 트래픽을 모니터링하고 보안 기능을 제공하며, 전체적인 마이크로 서비스를 보호하는 유입점을 담당합니다. API에 대한 인증/인가 기능을 가지고 있으며, 메시지의 내용에 따라 어플리케이션 내부에 있는 마이크로 서비스로 라우팅하는 역할도 담당합니다.

MSA 서비스 호출 패턴

마이크로서비스에서 서비스 호출 패턴이 API Gateway 방식만 있는 것은 아닙니다.

LoadBalancer To Microservice 방식

API Gateway To MicroService 방식

API Gateway + BFF(Backend For Frontend) 방식

등의 방식들이 있습니다. 관련글 MSA SCHOOL

API Gateway의 주요 기능

1. 인증 및 인가

인증이란 유저가 누구인지 확인하는 절차, 인가란 어떠한 자원에 인증받은 유저가 접근할 때 권한이 있는지 확인하는 절차입니다.
각각의 마이크로 서비스들이 요청을 받을 때 인증/인가 절차를 따로 처리한다면, 인스턴스들마다 같은 소스코드를 심어주어야 할 것입니다. 유지 보수가 어려워짐은 물론, 로깅 및 모니터링도 아주 힘들어질 것입니다.
인증서관리, 인증, SSL, 프로토콜 변환 등과 같은 기능을 API Gateway에 일임함으로써 각각의 마이크로 서비스들의 부담을 줄이고 관리포인트를 한 곳에 모으는 효과를 볼 수 있습니다.

2. 다수의 요청들을 단일 요청으로 축소 가능

여러 내부 마이크로 서비스를 대상으로 하는 여러 클라이언트의 요청들을 단일 클라이언트 요청으로 집계할 수 있습니다.
이를 통해 클라이언트앱과 백엔드 API간에 통신량을 줄임으로써 대기시간을 줄여 성능상의 이점이 발생합니다.
클라이언트에서 어느 마이크로서비스 인스턴스로 요청을 보낼지 고민하지 않아도 됩니다.
백엔드 마이크로서비스의 복잡도를 외부에 노출하는 것이 아닌, 숨길 수 있게 됩니다.

3. API 라우팅

API 라우팅 기능을 이용해 다음과 같은 서비스가 가능합니다.

로드 밸런싱(Load Balancing)
서비스 및 클라이언트 별 엔드포인트 라우팅
메시지 혹은 헤더 기반 라우팅

4. 로깅

API 호출시 API 게이트웨이는 공통적으로 호출되는 서비스이므로 모든 로그를 중간에서 수집하기 좋습니다.
API 호출 로그는 사용자 사용 패턴 분석이나 문제 발생시 문제를 추적하기 위한 자료로 사용됩니다.

API Gateway 적용 시 고려해야 할 사항

API Gateway의 Scale-out이 문제가 생길 경우 모든 Reqeust에 대한 병목지점이 될 위험이 있습니다.

API Gateway라는 추가적인 계층이 만들어지는 것이므로 그만큼 네트워크 latency와 SPOF(장애유발지점)가 증가합니다.
1. API Gateway는 마이크로 서비스들의 최전방에 존재하기 때문에 최대한 가볍게 설계되어야 합니다. 무거워진 API gateway로 인해 모든 서비스들의 Latency가 증가될 수 있기 때문입니다.

API Gateway와 내부 마이크로 서비스들간의 결합도가 증가하게 됩니다.

MSA로 프로젝트 구성 시 주의할 점

앞서 MSA 의 단점에서 언급했던 내용들이지만 다시 정리해봅니다.

서버 간 통신에서의 성능저하
1. 모놀리식에서는 내부 메소드 호출이었기에 문제가 되지 않았지만, MSA 구조에서는 API통신을 통해 마이크로서비스들 간의 통신이 이루어지기 때문에 네트워크 비용이 발생한다.
2. 상황에 맞는 통신방법(gRPC, GraphQL 등)을 택해 네트워크 통신 비용을 최소화 할 수 있도록 해야 합니다.

트랜잭션 처리
1. 모놀리식에서는 트랜잭션에 문제가 생기면 DB에서 제공하는 트랜잭션 제어방법(ACID)를 통해 처리했지만, MSA 구조에서는 요청이 실패하거나 처리 중 오류가 발생했을 경우 별도의 대책이 필요합니다.
2. SAGA 패턴
  1. 보상 트랜잭션이라는 개념으로 각 서비스별 존재하는 트랜잭션들을 한데 묶는 거시적인 트랜잭션이라고 이해하면 편합니다.
  2. 각 서비스별로 성공/실패가 발생할 경우 여러 로컬 트랜잭션들에서 다음 단계로 이벤트를 전송하고 마지막 트랜잭션 과정에서 데이터의 유효성을 검사한 후 영속처리합니다.
  3. 즉, 여러 로컬 트랜잭션들 중 하나에서 문제가 발생하면 데이터를 원상복구시키기 위한 롤백을 어플리케이션 레이어에서 처리하기 위한 방법입니다.
  4. 물론 모든 단계가 다 보상 트랜잭션이 존재해야 하는 것은 아니므로 구현 복잡도는 생각보다 높습니다.

인증/인가를 어떻게 처리할 것인지
1. 기존 모놀리식에서는 서버쪽에 유저 정보를 저장하는 서버기반 인증을 많이 사용하였습니다.
2. 토큰 기반 인증방식을 사용하는 것이 좋습니다.
  1. 확장성이 뛰어납니다.
  2. 서버가 늘어나도 토큰을 인증하는 방식만 알고 있으면 상관없습니다.
  3. 토큰을 클라이언트에 저장하기 때문에, 토큰을 탈취 당한다면 토큰의 유효시간 안에 토큰을 알고있는 누구나 인증이 유효해지는 위험이 존재합니다.
    1. 토큰의 유효시간을 짧게 가져가자.
    2. refresh token으로 새로운 토큰을 요청하는 등의 방어로직 필요.

느낀점

당연한 말이지만 모든 프로젝트들이 MSA구조로 전환할 필요는 없습니다.

단지 전 백엔드 사이드를 공부하는 개발자 입장에서, MSA 구조를 맞닥뜨리며 많은 성장을 했다고 생각합니다. 모놀리식 구조에서는 깊게 고민하지 않았던 여러가지 도전적인 과제들을 만나게 되었고, 학습해보고 실무에서 부딪히고 깨지며 얻는 바가 적지 않았습니다.

좀 더 안정적인 설계에 고민하는 시간이 많아지게 되었고, 여러 클라우드 인프라, 여러 개발 언어, 여러 DB를 사용하게 되면서 선택할 수 있는 선택지가 많아졌다고 생각합니다.

비즈니스 측면에서 MSA구조로의 전환이 무조건 정답은 아니지만, 개발자의 측면에서는 MSA 구조를 겪어봄으로써 한층 더 성장할 수 있는 백엔드개발자가 되지 않을까 합니다.

참고 :

https://brunch.co.kr/@maengdev/3
https://www.samsungsds.com/kr/insights/msa_architecture_edm.html
https://www.msaschool.io/

읽어주셔서 감사합니다.🖐

Written byRamsbaby

이 블로그는 직접 개발/운영하는 블로그이므로 당신을 불쾌하게 만드는 불필요한 광고가 없습니다.

#My Github #소개 페이지 #Blog OpenSource Github