2010 년대 초반, 아마존, 넷플릭스, 구글 등 글로벌 테크 기업들은 대규모 트래픽 처리와 빠른 서비스 배포를 위해 모놀리식(Monolithic) 아키텍처에서 마이크로서비스 아키텍처(MSA)로의 전환을 시작하였다. 2014 년 이후 MSA 개념이 대중화되었고, 한국에서는 2016 년 파스타 (PaaS-TA) 오픈을 기점으로 카카오, 네이버, 쿠팡, 배달의 민족 등 주요 기업들이 클라우드 전환과 함께 MSA 도입을 가속화하였다.
현재 MSA 는 대규모 트래픽을 처리하는 표준 아키텍처로 자리 잡았으며, 금융권을 포함한 많은 기업이 적극적으로 도입하고 있다. 그러나 기업 내부의 아키텍처 역량이 부족하거나 부적절한 설계로 인해 성능 저하와 운영 복잡성이 발생하는 사례가 빈번하다. 본고에서는 MSA 의 구조적 특성을 분석하여 성능 저하의 주요 원인을 규명하고, 이를 극복하기 위한 실용적인 해결 방안을 제시하고자 한다.
1. MSA (Microservices Architecture) 개요
MSA는 하나의 거대한 애플리케이션을 여러 개의 독립적인 서비스로 분해하여 구성하는 소프트웨어 아키텍처 스타일이다. 각 서비스는 자체적인 데이터베이스를 보유할 수 있으며, 독립적으로 개발, 배포, 확장될 수 있다는 것이 가장 큰 특징이다.
[그림 1] MSA 구성도
가. MSA의 도입 배경
MSA 도입의 핵심 동기는 사용자 수의 급증과 서비스 요구사항의 변화에 있다. MSA가 도입된 중요한 배경으로는 사용자 수 증가에 있다.
1) 트래픽 증가
대면 중심의 업무 처리에서 모바일 및 온라인 서비스 활성화로 시스템 처리량이 폭발적으로 증가하였다.
2) 확장성 확보
서비스의 독립적인 배포와 유연한 확장을 위해 MSA 가 필수적인 대안으로 부상하였다.
나. MSA 환경의 구조적 특징
MSA 환경은 일반적으로 클라우드 기반이며, 확장성 향상과 비용 절감을 위해 리눅스 기반의 컨테이너 기술을 주로 활용한다.
1) 서비스 분산구조
각 마이크로서비스는 독립적인 프로세스로 실행되며, 특정 기능 (예: 인터넷뱅킹, 메시지 발송, 사용자 인증 등) 에 집중한다. 이는 장애 격리 (Fault Isolation) 를 가능하게 하고 특정 서비스의 확장을 용이하게 한다.
2) 서비스 간 통신 방식
Kafka, RabbitMQ, NATS 등의 메시지 큐 (Message Queue) 를 활용하여 서비스 간 결합도를 낮추고 처리 속도를 향상시킨다.
2. MSA 기반 시스템의 성능 저하 주요 요인
MSA 는 확장성과 유연성 측면에서 큰 장점을 가지지만, 분산 시스템의 특성상 기존 모놀리식 방식 대비 성능 저하를 초래할 수 있는 여러 요인이 존재한다. MSA 도입 전 이러한 요인을 이해하고 설계에 반영하는 것이 필수적이다.
가. 서비스 호출 증가
모놀리식 방식에서는 내부 메서드 호출로 처리되던 로직이 MSA 에서는 네트워크를 통한 API 호출로 전환된다. 이로 인해 네트워크 지연 (Latency)이 누적되고, 수많은 마이크로 서비스 간의 통신으로 인해 네트워크 병목 현상이 발생할 수 있다. 특히 특정 서비스에 트래픽이 집중될 경우 전체 시스템의 성능이 크게 저하될 수 있다.
나. 분산 트랜잭션
데이터베이스가 서비스별로 분산되면 DB 의 ACID(원자성, 일관성, 고립성, 지속성) 트랜잭션을 보장하기 어려워진다. 여러 서비스에 걸친 데이터 변경 시 2PC(Two-Phase Commit) 와 같은 분산 트랜잭션 메커니즘을 사용하면 성능이 급격히 떨어진다. 이를 해결하기 위해 보상 트랜잭션 (SAGA 패턴 등)을 도입하게 되는데, 오류 발생 시 복구 로직이 복잡해지고 데이터 일관성 유지 비용이 증가한다.
다. 서비스 의존성
MSA 는 서비스 간 결합도를 낮추지만, 한 서비스의 성능 저하나 장애가 발생하면 이를 의존하는 다른 서비스들까지 연쇄적으로 영향을 받아 전체 시스템 성능이 떨어지는 연쇄 장애 위험이 존재한다.
라. 모니터링 및 오류 해결의 어려움
MSA 는 운영 복잡성이 기본적으로 높다. 쿠버네티스 (Kubernetes) 와 같은 오케스트레이션 도구가 자원을 관리하기 위해 CPU 와 메모리를 지속적으로 소모한다. 또한, 개별 서비스에서 생성된 로그를 통합 분석하기 위해 GUID 와 같은 추적 ID 를 활용해야 하며, 이를 집계하는 과정에서 추가적인 부하가 발생한다.
3. 성능 저하 문제 해결을 위한 주요 방법
MSA 의 핵심은 분산, 독립성, 그리고 서비스 단위 설계에 있다. 반드시 HTTP 를 사용해야 할 이유가 없다면, 통신 오버헤드를 줄이기 위해 HTTP 계층을 생략하거나 대체하는 전략도 고려할 수 있다.
가. 캐싱 전략
캐싱은 DB 접근 빈도를 줄여 성능을 획기적으로 향상시킬 수 있는 가장 효율적인 방법이다. MSA 환경에서는 다음과 같은 캐싱 전략을 적용할 수 있다.
1) 서비스 로컬 캐싱 (Local caching)
개별 마이크로서비스 내부 메모리에 데이터를 저장하여 DB 접근 없이 데이터를 반환하는 방식이다. 공통 코드, 일/주/월 단위 변경 데이터와 같이 변경 빈도가 낮고 빈번하게 조회 되는 데이터에 대해서 사용한다. DB 부하 감소와 응답 속도가 향상되지만 데이터 변경 시 모든 서버의 인스턴스를 갱신해야 하며, 인스턴스 간 데이터 불일치(Data Inconsistency) 위험이 존재한다.
[표1] 실무적으로 많이 쓰이는 캐시라이브러리
| 캐시 명 | 설명 | 특징 |
| Caffein | 자바 진영에서 가장 많이 쓰이는 고성능 캐시 | 힙메모리 사용, 매우 빠름컨테이너별 메모리 사용 |
| Redis | 메모리 기반의 다양한 자료구조를 지원클러스터링 캐싱이 가능함 | 서버간 분산이 필요할 때 사용 |
| Chronicle Map | 자바의 GC 영향을 거의 받지 않는 키-값 저장소 | 초저지연, 서버별 메모리 사용 |
2) 분산 캐싱 (Distributed caching)
여러 인스턴스가 공유하는 외부 캐시 서버를 사용하는 방식이다. 대표적으로 Redis 가 있으며 모든 마이크로 서비스가 하나의 분산 캐시를 공유한다. 모든 서비스 인스턴스가 동일한 데이터를 참조하게 되므로 서비스 로컬 캐시와는 달리 데이터 불일치 문제는 발생하지 않는다. 하지만 약간의 네트워크 오버헤드가 있으며 캐시 서버 장애 시 전체 서비스에 영향이 갈 수 있다.
나. 데이터베이스 확장 전략
MSA 환경에서의 데이터베이스 확장은 기존 모놀리식과 다른 접근법을 요구한다. 그 중 중요한 기본 원칙은 서비스 당 하나의 DB를 가지는 것이다. 각 마이크로 서비스는 독립적인 DB를 가지며 확장에 유연성을 가진다. 트래픽이 많은 서비스만 별도로 확장하여 비용을 절감할 수 있다. 기본적으로 MSA에서는 DB의 수평적 확장이 핵심이며, CPU 증설 등의 직접적인 수직적 확장보다 우선된다. 이로 인해 DB간의 일관성은 실시간으로 맞추기 힘들고, 성능을 위해 데이터의 중복 저장이 허용되며 보상 트랜잭션이 필요하게 된다.
MSA의 가장 좋은 성능 향상 방법은 DB간의 의존성을 없애는 것이다. DB 끼리의 조인이 어려우므로 독자적인 설계를 통해 데이터 복제로 여러 서비스를 동시에 처리할 수 있게 하면 성능 저하 문제를 줄일 수 있다. MSA를 도입한다고 해서 데이터베이스를 무조건 물리적으로 분리할 필요는 없다. MSA와 DB 분리는 별개의 문제이며 핵심은 서비스의 분리이다. 데이터의 소유와 격리를 위해서 DB 분리를 수행하는 것이며 성능의 향상이 없고 서로간의 결합도가 있음에도 분리하는 것은 MSA의 설계 원칙을 위배하게 되는 것이다. DB를 분리하였을 때 복잡도가 증가하거나 ACID 속성을 보장하기 어려울 경우에는 공유 DB를 사용하는 것이 성능의 저하를 줄일 수 있는 전략이 된다.
[표2] DB 확장 시 고려해야할 주요 아키텍처 패턴
| 패턴 | 설명 | 특징 |
|---|---|---|
| CQRS | CUD가 가능한 모델과 읽기 전용 모델 분리 | 조회 처리에 특화 |
| Saga | 분산 트랜잭션을 보상 트랜잭션으로 관리 | 데이터 일관성 보장 |
참고) CQRS : Command Query Responsibility Segregation, 명령/조회 책임 분리
[그림2] Saga 보상 트랜잭션
다. 비동기 처리
HTTP는 서버에서 기본적으로 동기 처리방식이다. HTTP 요청을 한 후 응답이 수신될 때까지 대기하여야 한다. 클라이언트에서는 AJAX 등을 이용하여 비동기 방식으로 처리할 수 있지만 전통적인 웹서버에서는 WAS 에서 응답이 올 때까지 프로세스나 스레드가 대기상태로 기다리고 있었다. 만일 수많은 요청이 오고 있는데 WAS에서 응답이 느리다면 웹서버의 응답도 느려질 수 밖에 없다. 이러한 단점을 제거하기 위해 현재 대부분의 웹서버에서 비동기 방식을 지원하고 있다. MSA도 비동기 방식을 고려하여 설계되어야 한다.
REST 호출은 동기방식이 많이 쓰이는데 만일 수많은 요청을 처리해야 하는 서비스라면 중간에 메시지 큐(MOM)를 두어 시스템의 유연성과 확장성을 향상시키는 것이 중요하다. 메시지 큐에는 여러가지 종류가 있는데 스트리밍, 대용량 로그 처리에 특화된 Kafka, 인메모리DB이면서 큐로도 사용할 수 있는 Redis 등이 있다. 만일 초고속처리가 필요하다면 하드웨어적으로 메시지 큐를 처리할 수 있는 솔라스가 있다. 메시지 큐를 이용하면 토픽을 기준으로 데이터 요청이 가능하며 서버간의 결합도를 없애어 확장을 용이하게 해준다. 오케스트레이션에서 경로 설정 기능도 토픽을 잘 설계하면 대체가 가능하다.
[표3] 대표적인 오픈소스 메시지 큐
| 메시지 큐 | 설명 | 특징 |
| Apache Kafka | 데이터 스트리밍 플랫폼 | 설정과 운영이 비교적 복잡 |
| RabitMQ | AMQP 기반 메시지 브로커 | 대용량 처리성능은 낮음 |
| Redis | 인메모리DB를 메시지큐로 쓸 수 있음 | Pub/Sub 지원 |
| NATS | 간단한 Pub/Sub 구조 | 경량, 고성능, 매우 빠름 |
4. 사례 분석
서비스의 종류에 따라 MSA가 적절하지 않은 경우가 존재한다.MSA의 특징중 하나가 바로 서비스 영역마다 자신의 DB를 가지는 것인데 이것이 단점으로 나타날 수 있다. 실시간 데이터의 변경이 많고 서로간의 데이터 의존성이 엮여 있거나 MSA 사상에 맞지 않게 설계를 하는 경우에 서비스 처리 시간은 느려지게 되고 자원을 더 소모하게 된다.
가. 실패 사례
A 기업은 2,000억원 대의 예산을 투자하여 기존 모놀리식 구조에서 MSA로 전환 하는 프로젝트를 시작하였다. 기존 오라클 DB 환경에서 오픈소스 DB로의 전환을 구상하였으나 성능 등의 이유로 기존 DB를 그대로 사용하기로 한다. DB 확장에 제약이 있는 상황에서 개발은 진행이 되었고 서비스별 DB는 MSA 사상을 고려하여 스키마별로 분리하여 연결되었다.
업무별 DB 변경에 대해 접근통제를 가져가고 서로 연관있는 업무는 2 PC(Phase Commit)와 유사하게 사가(Saga) 패턴을 이용한 보상 트랜잭션으로 설계하였다. 해당 기업의 업무는 서로 간의 결합도가 높아서 하나의 업무 변경에 대한 취소가 여러 업무의 보상 트랜잭션으로 이어지게 되므로 이를 고려한 복잡한 설계가 이루어지게 되었다. 서비스 분리설계로 데이터도 분산이 되었으며 트랜잭션의 복잡도가 함께 증가하였다. 결국 개발 복잡도는 폭증하게 되었고 해당 프로젝트는 사실상 중단되었다.
나. 성공 사례
B 기업은 A 기업과 유사하게 초기에 MSA 방식을 검토하였으나 업무간 결합도가 높고 서비스 처리 시간에 민감한 업무였으므로 전체 아키텍처를 그대로 가져가지 않고 장점만 수용하여 적용하기로 하였다. API G/W 영역을 생략하여 발생하는 지연을 없앴고 서비스 호출 경로 결정은 메시지큐 기반의 MOM (Message Oriented Middleware) 토픽을 활용하였다.
또한, 이를 이용하여 기존의 동기 호출 방식에서 비동기 호출로 변경하여 불필요한 대기 자원을 최소화할 수 있었다. 불필요한 HTTP 레이어를 제거하여 파싱 속도도 줄였다. 사용자 수가 급격히 증가할 때 부하가 집중되는 DB는 MSA설계와 동일하게 격리환경으로 가져갈 수 없었으므로 읽기전용 DB를 별도로 만들어 확장이 용이하게 만들었다. 조회만 발생하여 모델의 변경이 불필요한 서비스에 대해 MOM 의 토픽을 활용하여 DB 리소스를 분산시켰다.
[그림3] 메시지 큐(MOM)을 활용한 MSA 설계
5.결론
MSA 는 대규모 트래픽과 빠른 서비스 개발을 위한 강력한 아키텍처이지만, 무조건적인 도입은 성능 저하와 운영 복잡성을 초래할 수 있다. 본고에서 분석한 바와 같이, 네트워크 지연, 분산 트랜잭션, 서비스 의존성 등은 MSA 고유의 성능 병목 지점이다. 성공적인 MSA 도입을 위해서는 비즈니스 도메인을 정확하게 분석하여 적절한 서비스 경계를 설정하고, 캐싱, 비동기 처리, 데이터베이스 확장 전략 등을 상황에 맞게 적용해야 한다.
또한, 철저한 모니터링 체계와 장애 대응 전략을 수립하는 것이 필수적이다. MSA 는 단순히 기술 스택을 변경하는 것이 아니라, 조직의 아키텍처 사고방식과 운영 프로세스를 함께 변화시키는 과정임을 명심해야 한다.