Scalability & High Availability Design

1. Overview

확장성 및 고가용성 설계(Scalability & High Availability Design, SHA)는 시스템이 마주하는 두 가지 피할 수 없는 물리적 재앙—'예측 불가능한 트래픽 폭주'와 '반드시 일어나는 하드웨어/네트워크 고장'—을 정면으로 돌파하여, 비즈니스가 24시간 365일 멈추지 않게(99.99% Uptime) 지탱하는 인프라 아키텍처의 정수입니다.

서버를 무작정 늘린다고 10배 빨라지지 않습니다(암달의 법칙). 학습자는 무상태(Stateless) 설계를 통해 서버를 공장식으로 찍어내는 수평 확장(Scale-out)의 마법과, 로드 밸런서(Load Balancer)를 통한 정교한 트래픽 분산 물리를 배웁니다. 나아가 단 하나의 서버가 죽어도 전체가 죽는 단일 장애점(SPOF)을 찾아내 박살 내고, 넷플릭스처럼 의도적으로 서버를 죽이더라도(Chaos Engineering) 시스템이 자가 치유(Self-healing)되며 살아남는 궁극의 고가용성 네트워크를 설계합니다.

2. Scope & Boundaries

In-Scope

• 확장성 물리 (Scalability Physics): 스케일 업(Scale-up, 수직) vs 스케일 아웃(Scale-out, 수평), 암달의 법칙(Amdahl's Law), 무상태(Stateless) 아키텍처.
• 부하 분산 역학 (Load Balancing): L4(TCP/UDP) vs L7(HTTP) 로드 밸런싱, 라운드 로빈(Round Robin), 최소 연결(Least Connection), 일관된 해싱(Consistent Hashing).
• 고가용성 아키텍처 (High Availability): SPOF(Single Point of Failure) 제거, 액티브-액티브(Active-Active) 다중화, 페일오버(Failover), 서킷 브레이커(Circuit Breaker).
• 글로벌 라우팅과 무중단 배포: GSLB(Global Server Load Balancing), 블루/그린 배포(Blue-Green), 카나리 배포(Canary), 재해 복구(Disaster Recovery, RTO/RPO).

Out-of-Scope

• 데이터베이스의 수평 확장(Sharding): RDBMS의 쓰기(Write) 병목을 해결하기 위한 샤딩이나 파티셔닝 기술 $\rightarrow$ 06-02. NoSQL & Polyglot 영역으로 위임.
• 클라우드 오토스케일링(Auto Scaling) 셋업: AWS ASG(Auto Scaling Group) 셋업이나 Kubernetes HPA(Horizontal Pod Autoscaler) 설정법 $\rightarrow$ 07-07. Cloud-Native Evolution 영역으로 위임.

Boundaries

• SHA vs. Cloud-Native (07-07): Cloud-Native가 '쿠버네티스나 AWS 같은 특정 도구를 사용해 확장을 자동화하는 기술'이라면, SHA는 **'서버가 늘어나거나 줄어들 때, 그리고 죽었을 때 트래픽이 어떻게 스위칭(Switching)되어야 데이터 유실과 사용자 에러가 발생하지 않는지'**를 다루는 순수 아키텍처 원리입니다. 도구가 바뀌어도 SHA 원리는 변하지 않습니다.

3. Counterexample

• 상태 보존형(Stateful) 서버의 무지성 확장 (Scaling Fallacy): 웹 서버의 로컬 메모리에 사용자의 '로그인 세션'을 저장해 두고, 트래픽이 몰리자 똑같은 웹 서버를 5대로 늘려버리는 행위. A 서버에 로그인한 유저가 다음 요청 시 로드 밸런서에 의해 B 서버로 라우팅되면 "로그인이 풀렸다"며 에러가 터집니다. 확장을 위해서는 반드시 서버를 **무상태(Stateless)**로 만들고 세션을 Redis 같은 외부 캐시로 분리하거나 클라이언트(JWT)에 쥐여주어야 한다는 대원칙을 위반한 안티패턴입니다.
• 단일 장애점(SPOF) 방치 (Availability Fallacy): 웹 서버 10대, 앱 서버 10대를 두어 화려하게 수평 확장을 해놓고는, 정작 그 모든 트래픽을 분산해 주는 앞단의 로드 밸런서(L4 Switch)를 달랑 1대만 설치하는 구성. 웹 서버 10대가 아무리 튼튼해도 로드 밸런서의 파워 서플라이가 터지는 순간 전체 서비스가 100% 다운됩니다. 고가용성은 **"모든 계층에 이중화(Redundancy)가 되어 있는가?"**라는 질문을 단 하나라도 통과하지 못하면 0점입니다.

4. Prerequisites

• 컴퓨터 네트워크 (Basic): L4(전송 계층, IP/Port)와 L7(응용 계층, HTTP URL)의 구조적 차이를 알아야 트래픽 라우팅을 쪼갤 수 있습니다. (08-01. Network)
• 운영체제 프로세스와 메모리 (Recommended): CPU 병목인지 메모리 병목인지를 구별할 수 있어야 스케일 업(Scale-up)의 효율성을 계산할 수 있습니다. (03-02. PCM)

5. Learning Map

6. Learning Topics

Basic

Core Topic 01: 확장 전략과 병목의 수학 (Scaling Strategy)

• Why to Learn: 무작정 돈을 들여 서버 스펙을 올리기 전에, 내 코드가 과연 확장 가능한(Scalable) 구조인지 성능의 천장을 미리 계산하기 위함입니다.
• What to Learn:
  • Concepts: 수직 확장(Scale-up) vs 수평 확장(Scale-out).
  • Skills: 암달의 법칙(Amdahl's Law) 계산, 시스템 병목(Bottleneck) 식별, 응답 시간(Latency)과 처리량(Throughput)의 비례/반비례 관계.
  • Tools: CPU/Memory 모니터링, 부하 테스트 도구 (JMeter, Artillery).
  • Trade-offs: 코드를 안 고쳐도 메모리만 꽂으면 당장 빨라지지만 어느 순간 부품 한계에 부딪히는 Scale-up vs 무한 확장이 가능하지만 분산 트랜잭션과 캐시 동기화라는 소프트웨어적 헬게이트가 열리는 Scale-out.
• How to Learn:
  • 1단계: 어떤 작업의 20%가 순차적으로(직렬로) 실행되어야만 하는 데이터베이스 락(Lock) 작업이라면, 서버를 100만 대 늘려도 전체 성능 향상은 최대 5배(1 / 0.2)를 넘지 못하는 암달의 법칙 수학을 코드로 증명합니다.
  • 2단계: 유저 10명이 올 때 지연시간이 100ms였는데, 100명이 오자 1,000ms로 치솟는 현상을 보고, "이 시스템은 동시성에 비례해 처리량(Throughput)이 늘지 못하는 확장 불가 상태"라고 진단 내리는 벤치마크 그래프를 그립니다.
• Implement: 특정 API 엔드포인트에 초당 1,000개의 요청을 쏘는 스크립트를 작성하고, CPU 1코어 서버와 4코어 서버에서의 응답 속도 차이를 수집해 '완벽한 선형 확장'이 이루어지지 않는 병목 지점을 추론하는 리포트.

Recommended

Core Topic 02: 부하 분산과 라우팅 물리 (Load Balancing)

• Why to Learn: 티켓팅이나 수강신청 등 초당 수만 명이 몰려드는 트래픽의 파도를 수백 대의 서버로 쪼개어 서버의 폭발을 막아내기 위해서입니다.
• What to Learn:
  • Concepts: L4 로드 밸런싱(IP/TCP 레벨) vs L7 로드 밸런싱(HTTP 헤더/URL 레벨).
  • Skills: 라운드 로빈(Round Robin), 가중치(Weighted), 최소 연결(Least Connection) 알고리즘 물리, 일관된 해싱(Consistent Hashing), 상태 확인(Health Check)과 노드 퇴출.
  • Tools: Nginx, HAProxy, AWS ALB/NLB.
  • Trade-offs: 패킷의 내용물(HTTP)을 보지 않고 IP만 보고 즉시 넘겨주어 수백만 TPS를 감당하는 압도적 속도의 L4 vs 속도는 L4보다 느리지만, /api는 A 서버로, /image는 B 서버로 보내고 쿠키(Cookie)까지 조작할 수 있는 극강의 라우팅 지능 L7.
• How to Learn:
  • 1단계: Nginx를 앞단에 두고 백엔드 서버 3대를 띄운 뒤, 라운드 로빈 설정으로 1-2-3-1-2-3 순서대로 정확히 분배되는 액세스 로그를 시각화합니다.
  • 2단계: 사용자 세션을 유지하기 위해 'Sticky Session'을 걸었더니, 특정 유저가 하드비비(Heavy) 요청을 날릴 때 특정 서버 하나만 CPU가 100%로 타버리는 트래픽 쏠림(Hotspot) 현상의 물리적 취약점을 도식화합니다.
• Implement: 직접 구현한 소형 로드 밸런서 서버에 5개의 더미 워커 노드를 붙이고, 특정 노드가 10초 이상 응답이 없으면 즉시 라우팅 풀(Pool)에서 제외(Eviction)하고 복구되면 다시 투입하는 헬스 체크 데몬 스크립트.

Practical

Core Topic 03: 고가용성과 단일 장애점 제거 (High Availability & SPOF)

• Why to Learn: "서버 한 대가 죽었다고 서비스가 멈추는 일은 어떠한 경우에도 없어야 한다"는 99.99% 무중단 멘탈 모델을 인프라에 물리적으로 이식하기 위함입니다.
• What to Learn:
  • Concepts: SPOF(Single Point of Failure), 고가용성(High Availability, HA) 9의 개수(Five Nines = 99.999%), 액티브-액티브(Active-Active) vs 액티브-스탠바이(Active-Standby).
  • Skills: 페일오버(Failover), 서킷 브레이커(Circuit Breaker), 폴백(Fallback), 카오스 엔지니어링(Chaos Engineering) 기초.
  • Tools: Keepalived (VIP 스위칭), Resilience4j.
  • Trade-offs: 평소에도 두 대를 모두 돌려 효율이 높지만 DB 동기화에서 지옥을 맛보는 Active-Active vs 평소에는 한 대를 놀리느라 장비값이 2배로 들지만 장애 발생 시 스위칭이 명확하고 안전한 Active-Standby.
• How to Learn:
  • 1단계: 웹 서버 $\rightarrow$ 로드 밸런서 $\rightarrow$ DB 아키텍처를 그리고, 로드 밸런서가 1대일 때 이를 공격하면 전체가 죽는 SPOF를 확인합니다. 이에 로드 밸런서 2대 사이에 '가상 IP(VIP)'를 두고 메인이 죽으면 스탠바이가 0.5초 만에 VIP를 탈취(MAC 주소 브로드캐스트)하는 L2 네트워크 레벨의 이중화 물리를 분석합니다.
  • 2단계: 마이크로서비스 A가 B를 호출할 때 B가 장애가 나 응답을 주지 않으면, A의 스레드 풀이 모두 고갈되어 A마저 죽는 '장애 전파(Cascading Failure)'를 막기 위해, 에러율이 50%를 넘으면 즉시 B로의 요청 통로를 차단(Open)하고 캐시를 응답하는 서킷 브레이커(Circuit Breaker) 방어막을 칩니다.
• Implement: 2대의 Nginx 컨테이너를 띄워두고 Keepalived를 설정한 뒤, 마스터 컨테이너를 docker kill 로 죽였을 때 슬레이브가 가상 IP를 낚아채어 클라이언트 측에서는 ping 손실이 단 1번만 일어나고 지속 연결되는 페일오버 시연.

Advanced

Core Topic 04: 무중단 배포와 글로벌 트래픽 제어 (Zero-Downtime & GSLB)

• Why to Learn: 전 세계 사용자가 사용 중인 라이브 서비스의 심장(코드)을, 사용자가 눈치채지 못하게 수술(업데이트)하는 극강의 배포 파이프라인을 구축하기 위해서입니다.
• What to Learn:
  • Concepts: 롤링 업데이트(Rolling Update), 블루/그린 배포(Blue-Green Deployment), 카나리 배포(Canary Release), GSLB(Global Server Load Balancing).
  • Skills: DNS 레벨의 지리적 라우팅(Geo-Routing), 연결 배수(Connection Draining) 및 그레이스풀 셧다운(Graceful Shutdown), 재해 복구(DR: RTO, RPO).
  • Tools: AWS Route 53, Kubernetes 배포 전략.
  • Trade-offs: 트래픽의 10%만 신규 버전에 흘려보내 버그 발생 시 피해를 최소화하지만 배포 완료까지 모니터링 비용이 극심한 카나리(Canary) vs 똑같은 인프라를 한 벌 더 띄워놓고 로드 밸런서 스위치만 딱 딸깍(0초) 바꾸어 배포가 제일 깔끔하지만 클라우드 요금이 2배로 터지는 블루/그린(Blue-Green).
• How to Learn:
  • 1단계: 배포 스크립트에서 기존 서버를 죽일 때, 현재 처리 중인 사용자의 파일 업로드가 끊어지는 참사를 막기 위해, 로드 밸런서가 신규 유저 유입을 막고 기존 트래픽이 완전히 끝날 때까지 30초간 기다려주는 'Connection Draining'의 우아한 종료 물리를 추적합니다.
  • 2단계: 한국 리전에 화재가 발생했을 때, DNS가 이를 감지(Health Check 실패)하고 api.company.com의 연결 IP를 일본 리전의 예비 서버 IP로 즉시 덮어써 버리는 GSLB의 재해 복구(Disaster Recovery) 토폴로지를 스케치합니다.
• Implement: 무중단 롤링 업데이트 쉘 스크립트 작성 (총 3대의 백엔드 중 1대를 로드 밸런서에서 제거 $\rightarrow$ 신규 코드 배포 $\rightarrow$ 헬스 체크 통과 확인 $\rightarrow$ 로드 밸런서 재투입 과정을 3회 반복하여 단 1건의 트래픽 유실도 없이 V1 $\rightarrow$ V2로 교체).

7. Terminology

8. References

Primary References

• [P1] CS2023 - AR/Performance and Scalability — System constraints.
• [P5] SFIA - System Integration / Availability Management — Industry operations.

Secondary References

• [Scalability Rules] Abbott & Fisher — Practical architecture wisdom.
• [Site Reliability Engineering (SRE Book)] Google — Availability at scale.

Industry References

• [AWS Well-Architected Framework - Reliability Pillar] — Industrial HA standard.
• [Netflix Tech Blog on Traffic Steering] — Leading edge scalability cases.

9. Final Checklist

Primary Checklist

• 현재 시스템에 서버를 10배 추가해도 전체 성능이 10배가 되지 않는 이유를 물리적 자원 경합 관점에서 설명 가능한가? (P1, P5)
• 99.9% 가용성을 보장하는 시스템이 1년 동안 허용하는 최대 중단 시간을 계산할 수 있는가? (P5)

Secondary Checklist

• 로드 밸런서의 상태 확인(Health Check) 주기가 너무 짧거나 길 때 각각 발생하는 물리적 시스템 리스크를 인지하는가?
• 무상태(Stateless) 애플리케이션 설계가 왜 수평 확장의 선행 조건인지 논리적으로 변론할 수 있는가?

Industry Checklist

• 갑작스러운 트래픽 폭주(Thundering Herd) 상황에서 서버 보호를 위한 '처리량 제한(Rate Limiting)' 설계를 제안 가능한가? (SFIA)
• 리전 단위의 대규모 물리적 장애 시에도 서비스를 복구하기 위한 데이터 백업 및 복구 목표 시간(RTO/RPO)을 설정 가능한가?