Architecture - Micro Service Architecture - 서론
Architecture - Micro Service Architecture
이전에 회사에 다녔을 때 서비스를 운용하고 개발하는 방식은 모놀리딕 방식이었다. 지금 포스팅하고자하는 Micro Service 구조의 반대 방식이고 전통적인 방식이었는데, 여러가지 문제가 있었다. 그때의 기억을 되살려 이번에는 Micro service Architecture가 무엇인지 포스팅해보고자 한다.
1. 개요
IT 시스템이 점차 복잡해지고 트래픽 규모가 기하급수적으로 증가하면서, 전통적인 모놀리식(monolithic) 방식으로는 서비스 유지·운영에 한계가 드러나기 시작했다. 특히 기능 추가나 수정 시 전체 애플리케이션을 재배포해야 하는 불편함, 특정 모듈의 장애가 전체 서비스 중단으로 이어지는 위험성, 그리고 대규모 팀이 하나의 코드베이스를 함께 작업하며 발생하는 충돌 문제 등이 대표적이라고 할 수 있다. 이러한 문제를 해결하기 위해, 각각의 비즈니스 도메인을 작고 독립적인 서비스 단위로 분리하여 개발·배포·확장할 수 있는 ‘마이크로서비스 아키텍처(MSA)’가 부상하기 시작했다.
2. 모놀리식 아키텍처의 한계
1) 배포·확장 유연성 저하
서비스의 일부분만 수정해도 전체를 다시 빌드·배포해야 하므로, 릴리즈 주기가 길어지고 롤백 리스크가 커지게된다. (그냥 빌드하고 배포하면 되지라고 생각할 순 있겠지만 정말 긴급한 버그가 터졌을때 1분 1초가 식은땀 나는 상황을 겪는다면 그런 소리는 안나올거다) 또한 특정 기능에만 트래픽이 몰려도 애플리케이션 전체를 수평 확장해야 하므로 리소스 낭비가 발생한다.
2) 개발·운영 복잡도 증가
코드베이스가 거대해지면서 새로운 개발자가 프로젝트에 합류할 때 전체 구조를 이해하는 데 많은 시간이 소요된다. 서로 다른 팀이 충돌 없이 협업하기 어려워지고, 코드 충돌이나 의존성 문제로 인해 병목 현상이 자주 발생한다.
실제로 이전에 다니던 회사의 경우 코드가 약 10만줄이 넘어갔었는데, 나름 컴포넌트별로 분리를 한다고 했었지만 의존성 문제는 남아있었기 때문에 새로 들어온 개발자들이 코드 구조를 전체적으로 파악하는데 시간이 엄청 걸렸었다.
3) 장애 격리 어려움
하나의 모듈에서 발생한 장애가 서비스 전반으로 확산되어 전체 시스템 가용성을 위협한다. 특정 기능의 이슈를 파악·디버깅하는 과정에서도 전체 로그를 뒤져야 하므로 문제 해결 속도가 느려진다.
3. 마이크로서비스 아키텍처란?
1) 정의 및 개념
마이크로서비스 아키텍처(Microservice Architecture, MSA)는 애플리케이션을 비즈니스 기능 단위로 잘게 분할하여 각각 독립적인 서비스로 개발·배포·운영하는 설계 방식이다.
- 독립 실행 단위: 각 마이크로서비스는 자체 프로세스로 실행되며, 서로 다른 언어나 데이터 저장소를 선택할 수 있다.
- 경량 통신: 서비스 간에는 주로 RESTful API, gRPC, 메시지 큐 등을 통해 가볍게 통신한다.
- 단일 책임 원칙: 하나의 서비스는 하나의 비즈니스 캡슐(도메인)만을 책임지고, 내부 구현을 외부에 노출하지 않는다.
이로써 변경이 필요한 서비스만 재배포할 수 있고, 장애가 발생해도 문제 범위를 국소화할 수 있어 전체 시스템의 유연성과 안정성이 높아진다.
2) 핵심 특징
a. 독립 배포(Independently Deployable)
각 서비스가 서로의 배포 주기나 개발 속도에 영향을 주지 않으며 CI/CD 파이프라인을 서비스별로 구축하여, 수정된 서비스만 자동 빌드·테스트·릴리즈할 수 있다.
b. 경량화된 서비스 경계(Lightweight Service Boundary)
명확한 API 계약(API contract)을 통해 서비스 간 의존성을 최소화한다. 개발 언어나 프레임워크 자유도가 높아, 팀별 기술 선택이 가능하다.
c. 분산 데이터 관리(Distributed Data Management)
각 서비스는 자신의 데이터베이스를 소유하며, 중앙 집중형 DB 대신 분산된 형태로 관리한다. 데이터 일관성을 위해 동기식 호출(Saga 패턴)이나 비동기 메시징(Event-driven)을 활용한다.
d. 장애 격리(Isolation of Failures)
한 서비스가 과부하나 오류를 일으켜도, 서킷 브레이커(Circuit Breaker)와 타임아웃 설정을 통해 전체 시스템으로 전파되는 것을 방지한다. 개별 서비스 로그·모니터링 체계를 갖춰 문제 발생 시 빠르게 원인 분석 및 복구가 가능하다.
e. 확장성(Scalability)
특정 서비스에만 트래픽이 몰릴 경우, 해당 서비스만 수평 확장(horizontal scaling)하여 리소스를 효율적으로 사용할 수 있다. 클라우드 환경에서 오토스케일링(Auto Scaling)을 적용해 트래픽 변화에 탄력적으로 대응한다.
※ 추가 업데이트 및 검증 예정이다.