목적: 면접에서 '규모 확장성 있는 시스템'을 설계할 수 있는 적용 전략을 제시하는 것
-> 즉, "규모가 커졌을 때 시스템을 어떻게 확장하고 안정적으로 유지할 것인가"를 이해하는 것이 핵심

단일 서버 구조에서 시작하기

• 모든 컴포넌트가 한 서버에 몰려 있는 구조로 시작하자.
• 웹 애플리케이션, 데이터베이스, 캐시가 한 대의 서버에서 실행되는 형태다.
• 이 구조는 단순하지만, 사용자가 늘어나면 곧 한계가 드러난다.
  👉 이 구조는 직접 도식화(아이패드나 노트 필기)해서 그리면 훨씬 이해가 쉬움.

웹 서버와 데이터베이스의 분리

• 트래픽이 증가하면 웹 서버와 데이터베이스 서버를 분리하게 된다.
  - 웹 서버: 사용자 요청을 처리 (HTTP 요청, API, 페이지 렌더링 등)
  - DB 서버: 데이터 저장, 질의 처리
• 이때 선택해야 할 데이터베이스는 두 가지 계열로 나뉜다.

관계형 데이터베이스(RDBMS) vs 비관계형 데이터베이스(NoSQL)

구분	관계형 DB	NoSQL
구조	테이블, 스키마 명확	유연한 구조
장점	트랜잭션/정합성 우수	대규모 확장, 다양한 데이터형
예시	MySQL, PostgreSQL	Redis, MongoDB, Cassandra

• NoSQL은 아래의 경우에만 선택하는 것이 합리적이다.

1. 매우 낮은 응답 지연이 필요할 때
2. 비정형 데이터(예: JSON, 로그, 이벤트)를 다룰 때
3. 직렬화된 형태로 저장해도 충분할 때
4. 데이터 양이 매우 많아 관계형 구조로는 관리가 어려울 때

✅ 정리: 신입 단계에서는 대부분의 상황에서 RDBMS가 적합하다.
NoSQL은 특정 요구사항(속도, 유연성, 데이터 규모)에 부합할 때만 선택해야 한다.

규모 확장: 수직적 확장 vs 수평적 확장

구분	수직적 확장(Scale-Up)	수평적 확장(Scale-Out)
방법	한 대의 서버 성능 업그레이드	여러 서버를 추가
장점	구현 간단	확장성, 안정성 우수
단점	물리적 한계, 단일 장애점	복잡한 분산 처리 필요

👉 단일 서버에서 벗어나야 하는 이유는 장애 대응과 확장 한계 때문이다.
대규모 서비스를 위해서는 결국 수평 확장 + 부하 분산기(로드밸런서) 구조로 가야 한다.

로드밸런서 (Load Balancer)

• 로드밸런서는 트래픽을 여러 웹 서버로 분산하는 장치다.

• 사용자는 웹 서버의 IP로 직접 접속하지 않고, 로드밸런서의 공개 IP를 통해 접속한다.

• 이후 로드밸런서는 내부 사설 IP로 트래픽을 분배한다.

• 서버 1이 다운되면 자동으로 서버 2로 트래픽을 우회

• 서버가 추가되면 자동으로 부하를 분산

• 트래픽이 급증해도 확장성을 유연하게 유지

• 로드밸런서는 마치 “웹 서버 팀의 팀장”처럼, 트래픽을 적절히 배분해 웹 서버의 과부하를 막는다.

데이터베이스 다중화 (Replication)

• 데이터 계층에서의 확장 개념이다.
• 보통 주(Master) - 부(Slave) 구조로 설정한다.
  - 주(Master): 쓰기 연산 (insert, update, delete)
  - 부(Slave): 읽기 전용 (select), Master의 사본 유지
• 읽기 요청이 압도적으로 많을 경우 부 서버를 여러 대 두어 병렬 처리 성능을 높인다.

장점

1. 성능 향상: 읽기/쓰기 분리로 병렬 질의 가능
2. 안정성: 재해 발생 시 데이터 유실 방지
3. 가용성: 장애 시 다른 서버로 빠른 대체 가능

캐시 (Cache)

• 캐시는 비싼 연산 결과나 자주 조회되는 데이터를 메모리에 저장하여 재사용하는 기술이다.

• DB 호출 횟수를 줄여 성능 개선

• 빠른 응답, 부하 분산

• 캐시 계층(Cache Tier)을 별도로 두어 독립 확장 가능

캐시 사용 시 주의점

• 데이터 변경이 자주 일어나지 않고 조회가 잦을 때 적합
• 만료 정책(TTL) 필수
• 원본과 캐시 간 일관성 문제 발생 가능
• 단일 캐시 서버는 단일 장애 지점(SPOF)이 될 수 있음
• 캐시 메모리 과할당으로 미스율 최소화 필요
• 방출 정책(Eviction Policy): LRU, LFU 등 선택 중요

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

• 정적 콘텐츠(이미지, JS, CSS 등)를 사용자와 가까운 지리적 위치의 서버에서 제공하는 기술이다.
  => 즉, CDN 서버가 캐시 역할을 하여 전송 속도를 단축한다.

❓ 의문점 해답:
CDN 서버는 “캐싱 서버” 역할을 한다.
원본 서버(origin)에서 정적 파일을 받아 저장하고,
사용자 요청 시 가장 가까운 CDN 노드에서 해당 데이터를 전달한다.

CDN 고려 사항

• 비용: 자주 접근하지 않는 파일은 캐싱하지 말 것
• 만료 정책: TTL 설정 중요
• 장애 대비: CDN 장애 시 원본 서버 fallback
• 무효화(invalidation): CDN API나 버저닝으로 즉시 갱신 가능

무상태(Stateless) 웹 계층

❓ 의문점 해답:
로드밸런서 도입이나 캐시/DB 분리는 수평 확장의 일부다.
하지만 “무상태 웹 계층”은 그중에서도 웹 서버의 상태(세션)를 분리해
수평 확장을 극대화하는 핵심 전략이다.

무상태 아키텍처

• 웹 서버가 세션 상태를 보관하지 않음
• 모든 상태 정보는 DB나 Redis 등 외부 저장소에 저장
• 어떤 서버로 요청이 가도 동일한 응답 가능
  이로써 서버 간 결합이 줄어들고, 서버 증설/감축이 훨씬 자유로워진다.

데이터 센터 (Data Center)

• 서비스가 급성장하면 여러 지역에 데이터 센터를 분산 배치해야 한다.
• GeoDNS: 사용자의 지리적 위치에 따라 가장 가까운 데이터 센터로 트래픽 분산
• Failover: 장애 발생 시 다른 데이터 센터로 즉시 전환

기술적 과제

1. 트래픽 우회
2. 데이터 동기화 (다중 DB 간 consistency 보장)
3. 테스트 및 배포 자동화

메시지 큐 (Message Queue)

• 서비스 간 비동기 통신을 가능하게 하는 핵심 컴포넌트다.
• 생산자(Producer)가 메시지를 보내면, 소비자(Consumer)는 나중에 이를 처리한다.

장점

• 서비스 간 결합도 낮춤
• 비동기 처리로 성능 향상
• 장애 시에도 메시지 유실 없이 복구 가능

로그, 메트릭, 자동화

• 규모가 커지면 관측(Observability)이 필수다.

• 로그: 에러 감지 및 디버깅

• 메트릭: 성능, 트래픽, 장애 추세 분석

• 자동화: 배포, 모니터링, 알림 자동화로 운영 효율성 향상

데이터베이스의 수평적 확장 (샤딩)

❓ 의문점 해답:
다중화(Replication)는 “같은 데이터를 여러 곳에 복사”
샤딩(Sharding)은 “한 데이터를 여러 조각으로 나누어 분산”
즉, 다중화는 “복제”, 샤딩은 “분할”이다.

샤딩의 핵심

• 샤드 키(Shard Key)를 잘 정해야 데이터가 고르게 분배됨.
• 각 샤드는 동일한 스키마를 가지지만, 데이터는 중복되지 않는다.

문제점

• 재샤딩(Re-sharding): 데이터 분포 불균형 시 재배치 필요
• 유명인사(Hotspot): 특정 키로 트래픽 집중
• 조인 불가 → 비정규화로 해결

1장에서 배운 기법 총정리

• 웹 계층은 무상태 계층으로
• 모든 계층에 다중화 도입
• 가능한 한 많은 데이터를 캐시
• 여러 데이터 센터 지원
• 정적 콘텐츠는 CDN을 통해 서비스할 것
• 데이터 계층은 샤딩을 통해 그 규모를 확장할 것
• 각 계층은 독립적 서비스로 분할할 것
• 시스템을 지속적으로 모니터링하고, 자동화 도구를 활용할 것