대규모 트래픽 시스템 아키텍쳐 : 개요와 핵심 요소

대규모 트래픽을 처리하는 시스템을 설계하는 것은 웹 개발자와 인프라 엔지니어들에게 중요한 주제입니다.

이 글에서는 <가상면접 사례로 배우는 대규모 시스템 설계 기초> 책의 첫 번째 단원을 참고해서, 대규모 트래픽 시스템의 전반적인 아키텍쳐와 핵심 개념과 기법을 정리하고자 합니다.

대규모 트래픽을 대응하기 위해 단계적으로, 부분적으로 도입하는 것이 좋지만, 시스템 전반적으로 도입할 수 있는 부분에 대해 간략히 살펴보는 것이 이번 글의 목적입니다. 😀

1. 단일 서버의 한계

초기에는 하나의 서버로 웹 애플리케이션을 운영할 수 있습니다. 하지만 트래픽이 증가하면 단일 서버로는 다음과 같은 문제에 직면합니다:

• CPU, RAM 등의 리소스 부족
• 데이터베이스 쿼리 지연
• 장애 발생 시 서비스 중단

이러한 문제를 해결하기 위해 수직적 규모 확장(Scale-Up) 과 수평적 규모 확장(Scale-Out) 개념이 필요합니다.

• 수직적 규모 확장(Scale-Up): 서버 성능 향상
  • 기존 서버의 CPU, RAM, 디스크 용량을 증가시켜 성능을 향상시키는 방법입니다. 하지만 하드웨어의 물리적 한계로 인해 일정 수준 이상 확장이 어렵습니다.
• 수평적 규모 확장(Scale-Out): 서버 수 증가
  • 여러 대의 서버를 추가하여 부하를 분산하는 방법입니다. 로드 밸런서를 활용하여 요청을 여러 서버에 나누어 처리할 수 있어 확장성이 뛰어납니다.

2. 로드 밸런서 (Load Balancer)

단일 서버의 부하를 줄이기 위해 로드 밸런서를 도입하여 요청을 여러 웹 서버로 분산합니다.

• DNS 기반 로드 밸런싱을 통해 www.mysite.com, api.mysite.com 요청을 분리.
• 사용자는 로드밸랜서에게 공개IP 주소로 접속 -> 로드밸런서는 사설IP 주소를 통해 웹 서버 통신 (보안 향상 <- 사설IP는 서버 사이 통신에만 사용하기 때문)
• 웹서버의 트래픽을 균등하게 배분하여 특정 서버가 과부하 상태가 되는 것을 방지.
• 장애를 자동복구할 수 있음 - 서버1 다운 시, 서버2로 트래픽 전송하면 되기 때문

3. 데이터베이스 구조

대규모 시스템에서는 데이터베이스 부하를 줄이고 성능을 최적화하기 위해 다양한 데이터베이스 확장 기법을 사용합니다.

3.1 데이터베이스 다중화

• 리플리케이션(Replication): 읽기 부하를 여러 노드로 분산.
• 마스터-슬레이브 구조: 한 개의 마스터 노드가 쓰기를 담당하고, 여러 슬레이브 노드가 읽기를 담당.
• 마스터-마스터 구조: 다중 마스터 노드가 쓰기 연산을 처리.

3.2 데이터 샤딩 (수평적 확장)

• 대규모 데이터 베이스를 샤드(Shard) 라고 부르는 작은 단위로 분할
• 단, 같은 샤드 내에서는 데이터 중복이 없음! <= 샤딩 키(파티션 키)를 통해 컬럼 단위로 분리
• Shard 1, Shard 2, Shard 3 처럼 데이터 서버를 증설하여 나누어 관리.
• 문제 발생-해결법
  • 데이터 재샤딩(한 샤드 내 데이터 과다, 데이터 분포 불균형) => 샤드 키 계산 함수 수정 => 데이터 재배치
  • Celebrity문제(핫스팟 키 문제, 한 샤드 내 인기 많은 키 과다) => 샤드 분리
  • 여러 샤드를 걸쳐 조인 불가능 하기에, 데이터베이스 비정규화 필요할 수 있음

4. 캐시 (Cache)

응답 시간 향상을 위해 캐시를 적극 활용합니다. 애플리케이션의 성능은 “데이터베이스를 얼마나 자주 호출하느냐”에 따라 크게 좌우됩니다.

DB 연동이 잦은 데이터인 경우, 메모리 안에 두어 요청이 빨리 처리될 수 있도록 합니다.

캐시 계층은 데이터가 잠시 보관되는 곳! (성능 개선 및 DB 부하 줄이고, 캐시계층을 독립적으로 확장 가능)

• 웹 캐시 (CDN): 정적 콘텐츠(이미지, CSS, JavaScript)를 CDN을 통해 제공하여 성능을 향상.
• 애플리케이션 캐시: Redis, Memcached 같은 인메모리 캐시를 활용하여 DB 부하 감소.
• 쿼리 캐시: 자주 사용하는 쿼리 결과를 저장하여 재사용.

데이터 방출 정책 수립 필요

• LRU: Least Recently Used - 사용 시점 오래된 순
• LFU: Least Frequently Used - 사용 빈도 낮은 순
• FIFO: First In First Out - 먼저 캐시 저장된 순

5. 콘텐츠 전송 네트워크 (CDN)

• CDN을 통해 정적리소스의 경우는 웹서버에 가지 않아도 받아올 수 있음
• CDN을 사용하여 전 세계 사용자가 빠르게 콘텐츠를 로드할 수 있도록 함. (클라이언트에게 지리상으로 가장 가까운 CDN 서버에서 정적콘텐츠 전달)
• 정적 콘텐츠를 네트워크 엣지에서 제공하여 서버 부담 감소.

6. 무상태 웹 계층

• 웹 서버를 무상태(Stateless) 로 설계하여, 세션 정보를 개별 서버에 저장하지 않음.

  왜 웹 서버에 세션 정보(상태)를 저장하지 않을까?

  • 웹 서버 분리 시, HTTP 요청이기 때문에 HTTP는 기본적으로 무상태성을 가진다.
  • 즉, HTTP 요청에는 사용자의 상태 정보가 없으며, 웹 서버는 분리되어 상태를 공유할 수 없다.
  • 별도의 사용자의 상태(세션) 정보를 가진 공유 저장소가 필요하다.

• 공유 저장소는 웹 서버와 물리적으로 분리되며, 여러 웹 서버에서 하나의 공유 저장소를 통해 상태 정보를 받아온다.
• 공유 저장소는 RDBMS, 캐시 시스템(Memcached/Redis), NoSQL 등 필요에 따라 선택 가능하다.

7. 메시지 큐 (Message Queue)

• 메시지 큐의 특징
  1. 메시지 무손실: MQ에 보관된 메시지는 소비자(서비스프로세스)가 꺼낼 때까지 안전히 보관됨
  2. 비동기 통신: 메시지의 버퍼 역할, 비동기적 전송
• 동작 원리
  • 발행자(사용자)가 메시지(작업)를 생성하여, 메시지 큐에 발행(요청)을 한다. 큐는 구독자(서비스 또는 서버)이 구독하고 있따가, 메세지를 받아 그에 맞는 동작을 수행한다.
• 장점
  • 서비스 또는 서버 간 결합이 느슨해지고 => 각 각의 서버에서 각자 요청을 처리하리 때문
  • 규모 확장성이 보장되어야 하는 안정적 애플리케이션 구성이 좋음
• 생산자와 소비자 서비스의 규모는 각기 독립적으로 확장 가능: 큐가 많아지면, 소비자(작업 프로세스) 추가. 큐가 없으면 소비자(작업 프로세스) 감소
• 예: 결제 시스템, 이메일 알림, 대용량 데이터 처리 등.

8. 데이터 센터와 장애 대응

• 하나의 데이터 센터에 장애가 발생하더라도 다른 데이터 센터가 서비스를 유지하도록 설계.
• 멀티 리전 배포를 통해 고가용성 확보.

9. 로그, 모니터링, 자동화

• 로그 수집: ELK Stack(Elasticsearch, Logstash, Kibana) 또는 AWS CloudWatch를 활용.
• 메트릭 모니터링: 메트릭 수집을 통해 사업 현황 유용 정보 획득, 시스템 현재 상태 파악
  • 호스트 단위 메트릭: CPU, 메모리, 디스크 I/O
  • 종합 메트릭: DB 계층 성능, 캐시 계층 성능 등
  • 핵심 비즈니스 미트릭: 일일 활성화 사용자, 수익, 재방문 등
• 자동화: CI/CD(Continuous Integration & Deployment) 도구 등을 활용하여 빌드, 테스트, 배포 절차 자동화

📝 정리

대규모 트래픽을 처리할 때 고려해야 할 핵심 기법

• 웹 계층은 무상태(Stateless) 로 설계 (상태 저장 보관소 분리)
• 모든 계층에서 다중화 (로드 밸런서, 웹 서버, 데이터베이스, 캐시 등)
• 가능한 한 많은 데이터에 캐시 적용, 단 캐시 보관기간 유의!
• 여러 데이터 센터 지원으로 장애 대비
• 정적 콘텐츠는 CDN 활용하여 서비스할 것!
• 데이터베이스는 샤딩을 통해 규모 확장
• 각 계층을 독립적인 서비스로 분할 (마이크로서비스 아키텍처 고려) => MQ 활용
• 시스템의 지속적인 모니터링과 자동화 도구 활용을 통한 운영 최적화

---

참고

• 책: <가상면접 사례로 배우는 대규모 시스템 설계 기초> 1장