콘텐츠로 바로가기
HY_TECH_BASE

Scalability & High Availability Design

폭발적인 트래픽 증가에 대응하는 확장 전략과 단일 장애점(SPOF)을 제거하여 중단 없는 서비스를 보장하는 고가용성 설계 역학을 다루는 학습 노드입니다.

sys.entry
M

Me

hyunyoun's Blog

posts6 min read

1. Overview

확장성 및 고가용성 설계(Scalability & High Availability Design, SHA)는 시스템의 물리적 한계를 인지하고, 자원을 동적으로 확장하거나 장애 상황에서도 서비스 지속성을 유지하는 고수준 인프라 전략을 다룹니다.

성공한 서비스는 반드시 트래픽 폭주와 물리 장비 고장이라는 시련을 겪습니다. 학습자는 수직 확장(Scale-up)의 물리적 벽을 넘어서는 수평 확장(Scale-out) 기법, 트래픽을 고르게 분산하는 로드 밸런싱 물리, 그리고 단일 장애점(SPOF)을 제거하는 다중화(Redundancy) 전략을 학습합니다. 이를 통해 '99.99%(Four Nines)' 이상의 가용성을 가진 견고한 시스템을 구축합니다.

2. Scope & Boundaries

In-Scope

  • Scale Models: Vertical vs Horizontal scaling의 물리적/비용적 트레이드오프
  • Load Distribution: L4/L7 로드 밸런싱 하드웨어/소프트웨어 메커니즘, DNS 라우팅
  • Availability Physics: 장애 조치(Failover), 헬스 체크(Health Check), 무중단 배포(Blue-Green, Canary)
  • Bottleneck Analysis: 암달의 법칙(Amdahl's law)을 통한 확장성 한계 도출

Out-of-Scope

  • 데이터베이스 샤딩 기법 상세 (06-02 NoSQL 영역으로 위임)
  • 특정 클라우드 서비스(AWS Auto Scaling 등)의 CLI 명령어 (07-07 Cloud-Native 영역으로 위임)

Boundaries

  • SHA vs. Cloud-Native: Cloud-Native(07-07)가 '클라우드 도구를 활용한 구현'에 주력한다면, SHA는 '도구와 무관한 확장과 가용성의 아키텍처적 원리'에 집중합니다.

3. Counterexample

  • 단순히 서버를 여러 대 띄운다고 확장성이 좋아지는 것은 아닙니다. 시스템의 특정 지점(예: 공유 DB의 쓰기 락)이 병목이 되어 서버를 늘려도 성능이 나지 않는 확장성 포화(Scalability Saturation) 현상을 분석하고, 하드웨어 다중화가 실제로는 데이터 정합성을 깨뜨리는 실패 시나리오를 방지할 수 있는 설계를 제시해야 합니다.

4. Prerequisites

  • 네트워크 기초 및 OSI 스택 (Basic): IP, 포트, HTTP 요청의 흐름을 알아야 로드 밸런싱을 이해할 수 있습니다. (08. Network)
  • 프로세스 및 동시성 메카니즘 (Recommended): 서버 내 자원 경합과 병렬 처리 이해가 확장성 분석에 도움이 됩니다. (03. PCM)

5. Learning Map

  1. Identifying Limits: 현재 시스템이 왜 더 많은 사용자를 받지 못하는지 물리적 병목을 진단합니다.
  2. Horizontal Growth: 무상태(Stateless) 설계를 통해 서버를 무한히 늘릴 수 있는 구조를 만듭니다.
  3. Erasing Frailty: 하드웨어는 언제든 고장 난다는 전제하에 장애 복구(Failover) 경로를 매핑합니다.
  4. Fluid Traffic: 로드 밸런서와 무중단 배포를 통해 사용자에게 중단 없는 경험을 제공합니다.

6. Learning Topics

Basic

Core: 확장 전략과 암달의 법칙 (Scaling Strategy)

  • Why to Learn: 무작정 장비를 늘리기 전에 최대 기대 성능 향상폭을 예측하기 위함입니다.
  • What to Learn:
    • Scale-up vs Scale-out의 정의와 물리적 한계점
    • 암달의 법칙(Amdahl's Law): 병렬화 불가능한 영역이 전체 성능에 미치는 영향
    • 응답 시간(Latency) vs 처리량(Throughput)의 비정상적 상관관계 분석
  • How to Learn:
    • 서버 CPU 점유율이 90%일 때 장비를 2배로 늘려도 처리량이 2배가 되지 않는 사례 연구
    • 온라인 계산기를 통해 특정 로직의 병렬화 비율에 따른 성능 개선 한계 그래프 작성
  • Implement: 현재 시스템 아키텍처에서 물리적 확장 한계를 예측한 성능 분석 보고서

Core: 로드 밸런싱과 트래픽 분산 (Load Balancing)

  • Why to Learn: 수백 대의 서버로 들어오는 요청을 지능적으로 배분하여 특정 서버의 과부하를 막기 위해서입니다.
  • What to Learn:
    • L4 (IP/Port 기반) vs L7 (Application/HTTP 기반) 로드 밸런싱 차이
    • 라운드 로빈, Least Connection, Consistent Hashing 알고리즘 물리
    • 헬스 체크(Health Check)와 능동적 노드 격리 메커니즘
  • How to Learn:
    • Nginx나 HAProxy 설정을 통해 여러 백엔드로 요청이 분산되는 과정 로그 확인
    • 세션 불일치 문제를 해결하기 위한 Sticky Session의 득실 분석
  • Implement: 특정 해시 알고리즘을 사용한 부하 분산 시뮬레이터 및 설정 파일

Practical

Core: 고가용성과 장애 복구 (Availability & Failover)

  • Why to Learn: 서버 한 대의 장애가 서비스 전체의 몰락으로 이어지지 않게 하기 위함입니다.
  • What to Learn:
    • 가용성 계산: 'N개의 9'와 허용 중단 시간 산출
    • Active-Active vs Active-Passive 다중화 구성의 물리적 차이
    • 서킷 브레이커(Circuit Breaker) 패턴을 통한 장애 전파(Cascading Failure) 차단
  • How to Learn:
    • 임의의 노드를 강제로 다운시키고 대기 노드로 서비스가 전환되는 시간(MTTR) 측정
    • 공유 자원(DB) 장애 시 애플리케이션의 재시도 전략(Exponential Backoff) 시뮬레이션
  • Implement: 장애 발생 시 자동으로 트래픽을 전환하는 액티브-스탠바이 구성도 및 스크립트

Advanced

Core: 글로벌 확장과 무중단 운영 (Global Scale & Zero-down)

  • Why to Learn: 전 세계 사용자에게 지연 없는 서비스를 제공하고 배포 중에도 사용자를 보호하기 위해서입니다.
  • What to Learn:
    • 글로벌 서버 부하 분산(GSLB)과 지연 시간 기반 라우팅 물리
    • 무중단 배포: Blue-Green 배포의 하드웨어 스위칭 vs Canary 배포의 점진적 전파
    • 리전 간 복제(Multi-Region)와 재해 복구(Disaster Recovery) 전략
  • How to Learn:
    • 대형 글로벌 서비스(Netflix, AWS 등)의 아웃이지 대응 사례 분석
    • 배포 파이프라인에서 신규 버전 오류 감지 시 자동 롤백(Rollback)되는 과정 하드닝
  • Implement: 트래픽 유실 없이 구버전에서 신버전으로 전환되는 롤링 업데이트 파이프라인 설계

7. Terminology

Term (EN / ko, abbr) 1문장 정의 단계(기본/권장/실무/심화) 역할/맥락 관련 개념 유사/대비/함께 사용 오해 포인트 Evidence(Primary/Secondary/Industry) Flags(core/misused/legacy)
Scalability (확장성) 시스템이 자원을 추가함으로써 증가된 작업량을 처리할 수 있는 능력입니다. 기본 용량 계획 Throughput Performance 성능(Speed)과 동일시함 P1:CS2023 core
High Availability 시스템이 장애 없이 정상적으로 서비스를 제공할 수 있는 시간의 비율입니다. 기본 신뢰성 지표 SLA / 99.9% Reliability 완벽한 '무장애'로 오해 P1:CS2023 core
Load Balancer 중앙에서 들어오는 네트워크 트래픽을 여러 서버로 분산시켜 주는 물리/논리 장치입니다. 추천 부하 분산 L4 / L7 Proxy 단순한 '게이트웨이'로 오해 Industry/Nginx/AWS ELB core
SPOF 해당 컴포넌트가 고장 나면 시스템 전체가 중단되는 취약한 지점을 의미합니다. 추천 위험 관리 Redundancy Failover '복잡한 버그'와 혼동함 P1:CS2023 core

8. References

Primary References

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)을 설정 가능한가?

Concepts & Tags

#scalability#high-availability#load-balancing#failover