시스템 설계(모놀리식 vs 마이크로서비스 아키텍처)

 

최근에 Spring Batch와 RabbitMQ를 활용하며 대규모 트래픽 처리와 대용량 데이터 처리에 관심이 생겼다. 그러다

“이런 트래픽이 실제 서비스에서 발생한다면, 시스템을 어떻게 설계해야 안정적이고 효율적으로 운영할 수 있을까?”

라는 고민이 들었고, 그 궁금증을 계기로 시스템 설계에 대해 본격적으로 공부하게 되었다.

 

 

 

---

 

시스템 설계란?

시스템 설계는 웹 서비스가 트래픽이 많아지거나 데이터량이 커지더라도

안정적으로 동작할 수 있도록 구조를 설계하는 과정이다.

• 서비스가 커질수록 단순한 CRUD 구조만으로는 한계가 생긴다.
• 성능, 확장성, 신뢰성, 유지보수성을 고려하여 구조를 잡아야 한다.
• 실제로는 하나의 서버/DB로는 부족해지며 여러 컴포넌트를 나누고 연결해야 한다.

 

시스템 설계를 공부하면서 가장 먼저 접하게 된 개념이 모놀리식 아키텍처와 마이크로서비스 아키텍처(MSA)다.

 

 

 

 

---

 

 

 

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

모든 기능(UI, 비즈니스 로직, 데이터 처리 등)을 하나의 애플리케이션 코드베이스로 구성한 구조이다.

모든 것이 한 프로젝트 안에서 실행되며, 하나의 프로세스로 배포된다.

• 일반적으로 단일 DB와 단일 서버 구조를 사용한다
• 동일 애플리케이션을 여러 서버에 배포하면 로드밸런싱은 가능하지만, 구조는 여전히 일체형이다

 

 

장점

• 초기 개발과 배포가 간단하다
• 모든 코드가 한곳에 있어 테스트 및 디버깅이 쉽다
• API 통신이 필요 없어서 성능 측면에서 단순하다

 

단점

• 코드가 커지면 변경이 어렵고, 한 부분 수정 시 전체 빌드/배포가 필요하다
• 특정 기능에 트래픽이 몰려도 전체 애플리케이션을 확장해야 한다
• 한 서비스의 장애가 전체 시스템에 영향을 줄 수 있다 (단일 장애점)

 

 

마이크로서비스 아키텍처 (Microservices Architecture, MSA)

 

애플리케이션을 작은 단위의 독립적인 서비스들로 나누어 구성하는 구조이다.

각 서비스는 하나의 도메인(예: 인증, 주문 등)을 책임지고 독립적으로 개발·배포된다.

• 각 서비스는 자신의 데이터베이스를 갖는다 (Database per Service)
• 공통 인프라: API Gateway, Service Discovery, Message Queue 등과 함께 구성된다
  • API Gateway: 모든 요청의 진입점, 라우팅 처리
  • Service Discovery: 각 서비스의 위치(IP/포트) 동적 관리
  • Message Queue: 비동기 이벤트 처리 (예: Kafka, RabbitMQ)

 

장점

• 기능 단위로 독립 배포 가능하여 빠른 릴리즈와 롤백이 가능하다
• 특정 서비스만 선택적으로 확장(수평 확장)할 수 있다
• 서비스마다 적절한 기술 스택을 선택할 수 있다
• 한 서비스 장애가 전체에 영향을 주지 않도록 격리 가능하다

 

단점

• 서비스 간 통신(API)으로 인한 지연 및 장애 전파 가능성
• 인프라/운영 복잡도 증가 (서비스 디스커버리, 모니터링, 로깅 등 필요)
• 설계 미숙 시 데이터 정합성과 트랜잭션 문제가 발생할 수 있음

 

 

 

---

 

 

 

로드 밸런싱 (Load Balancing)

수평 확장을 통해 특정 서비스의 서버 수를 늘렸다고 해도,

트래픽이 고르게 분산되지 않으면 확장의 효과를 제대로 누릴 수 없다.

이러한 문제를 해결하기 위한 대표적인 방법이 바로 로드밸런싱(Load Balancing)이다. 로드밸런싱은

사용자 요청을 여러 서버에 균등하게 분산하여 과부하를 방지하고, 응답 속도를 향상시키는 핵심 기술이다.

 

장점

• 서버의 부하 분산으로 처리 성능 향상
• 하나의 서버가 죽더라도 나머지 서버로 트래픽을 자동 전환 (고가용성)

 

구현 방식

• L4 (IP 기반), L7 (경로/헤더 기반)
• 라운드로빈, 최소 연결 수, 가중치 기반 분산
• Nginx, HAProxy, AWS ELB 등으로 구현

 

 

 

---

 

 

데이터베이스 설계 (SQL vs NoSQL)

로드밸런싱을 통해 애플리케이션 레벨의 트래픽을 효과적으로 분산시켰다면,

마지막으로 중요한 설계 요소는 데이터베이스(DB)다.

DB는 대표적으로 SQL과 NoSQL로 나뉘며, 데이터의 특성과 목적에 따라 유연하게 선택하는 것이 중요하다.

 

SQL (관계형 DB)

• 스키마 기반 테이블 구조, 엄격한 데이터 정합성
• 복잡한 쿼리, 트랜잭션 처리에 적합
• 대표: MySQL, PostgreSQL, Oracle

 

NoSQL (비관계형 DB)

• 스키마가 유연하며, 대용량 분산 저장에 적합
• 키-값, 문서, 그래프 등 다양한 형태
• 대표: MongoDB, Redis, Cassandra

 

선택 기준 및 조합 사례

• 사용자 정보, 결제 등 정합성이 중요한 데이터 → SQL
• 캐시, 로그, 추천 등 대량 처리/성능 중심 데이터 → NoSQL
• 실제 시스템에서는 두 가지 DB를 혼합하여 사용하는 경우가 많다

 

 

 

---

 

 

내결함성 (Fault Tolerance)

아무리 잘 설계된 시스템이라도 서버나 데이터베이스에 장애가 발생할 수 있다.

그렇기 때문에 시스템 일부에 문제가 생기더라도 전체 서비스는 문제 없이 동작할 수 있도록 하는

내결함성(Fault Tolerance) 역시 중요한 설계 요소다.

실제 서비스 환경에서는 서비스의 신뢰성과 직결되기 때문에 반드시 고려되어야 한다. 

이를 구현하기 위한 대표적인 방법으로는 

서버 및 DB의 이중화, 헬스 체크, 장애 발생 시 자동 전환(Failover) 등이 있다.

 

 

 

---

 

마무리하며

최근 Spring Batch와 RabbitMQ를 활용한 프로젝트를 진행하며

많은 양의 데이터와 요청이 한꺼번에 몰릴 경우 시스템이 어떻게 병목될 수 있는지 고민하게 되었고,

그 과정을 통해 자연스럽게 시스템 설계에 관해 찾아보고 학습하게 되었다.

이를 계기로 단순한 코드 작성보다 서비스를 안정적으로 운영할 수 있는 설계가 중요하다는 걸 느꼈다.

공부를 통해 막연했던 개념들이 실제 구조 속에서

어떻게 연결되고 역할을 하는지 이해되기 시작했다.

작은 프로젝트라도 직접 구조를 설계해보며 감각을 익히고,

앞으로는 설계가 서비스에 끼치는 영향을 몸소 체험해보고 싶다.