대용량 트래픽 아키텍쳐 정리

먼저 우리가 배울 실시간성 아키텍쳐가 왜 중요한지 예시를 통해 알아보자

 

실시간성의 중요성과 아키텍처 진화

1. 전통적인 모놀리식 아키텍처

이미지 처럼 하나의 서비스에서 주문, 결제, 배송 기능이 있고, 이는 하나의 DB를 참조하는 구조

단점

• 서비스간 높은 결합도: 한 서비스의 변경이 다른 서비스에 즉각적인 영향을 준다. (장애도 마찬가지)
• 확장성 한계 : 서비스에 다른 기능 추가시 기존 주문 서비스 코드를 수정해야해서 확장성이 좋지 않다.
• 주문 > 결제 > 제고 > 배송 같은 동기 API 호출 체인에서 응답이 느려지고 장애 전파가 쉽다.

2. 배치 처리 중심의 아키텍처

단점

• 높은 지연 시간: 배치 주기를 기다려야함 (실시간 데이터 확인 어려움)

“결제가 완료돼도 재고 정보가 다음 배치 때까지 안 맞는” 상황이 자주 발생.

• 배치 실패: 전체 재처리 과정 필요
• 특정 시간대 부하 집중 (DB 부하 핸들링 필요)

3. MSA (Microservice Architecture)

현대 시스템은 주문, 결제, 재고, 배송 서비스가 각각의 독립된 DB 를 가집니다.
이를 코어 MSA 구조라고 합니다.

 

단점

• 데이터 불일치: 각 서비스마다 DB를 따로 관리하기때문에 모든 서비스에 반영해야하는 불편함이 있음
• 시스템간 의존성 증가: 결제 완료 이벤트를 재고 서비스가 "즉시" 알아야 함

4. 공유 DB 기반의 MSA (Microservice Architecture)

단점

• DB 성능 병목: 모든 서비스가 한 DB에 접근 하다보니 성능이 좋지않음
• 확장성 한계: 수평 스케일링이 어려움 (하드웨어 용량 모자람 등)
• 단일 장애지점 (SPOF)
• DB 락 경쟁 증가

4. 이벤트 기반 EDA (Event-Driven Architecture)

EDA의 핵심

- 메시지 전달이 아니라 "상태의 히스토리 자체를 이벤트로 관리"

• 서비스간에 공유되는 자원은 카프카 메세지 뿐 (느슨한 결합)
• 이벤트 소싱이 존재함
  • 모든 상태 변경 (주문 생성, 결제 완료, 배송시작)을 이벤트로 기록할 수 있음
  • 시스템이 재시작 되더라도 이벤트 로그를 적용해 복구 가능
  • 이벤트 활용해 감사 추적가능 (어떤 이벤트가 어떤 시간에...등)
  • CQRS 패턴 구현 가능 (쓰기, 읽기를 분리한다)

 

참고 블로그

https://toss.tech/article/22563