LLM Wiki

시스템 디자인 핵심 개념

8 min read

한 줄 정의

분산 시스템의 성능 병목과 물리적 장애(Downtime)를 예방하기 위해 설계 수준에서 고려해야 하는 28가지 컴퓨터 공학 및 인프라 아키텍처 핵심 개념 모음이다.

핵심 요지

  1. 요청 진입과 라우팅: 클라이언트 요청은 DNS 계층을 거쳐 리버스 프록시와 로드 밸런서에 의해 중계·분배되며, 이 과정에서 TLS 종단, 헬스 체크, 지연 시간(Latency) 조절 및 무상태(Stateless) 아키텍처가 구현된다.
  2. 데이터 스토리지 다원화: 정밀 트랜잭션을 보장하는 SQL(ACID)과 확장성을 극대화한 NoSQL(Key-Value, Document 등)을 활용한 Polyglot 스토리지 설계를 적용하고, 대용량 파일은 블롭 스토리지로 분리한다.
  3. 인프라 수평 확장: 단일 머신의 한계(수직 확장)를 극복하기 위해 복제(Replication)를 활용하여 읽기 부하를 분산시키고, 인덱싱과 캐싱(Cache-Aside)을 적용하여 풀 스캔을 방지하며, 최종 병목 단계에서 샤딩(Sharding)과 수직 파티셔닝을 검토한다.
  4. 분산 신뢰성 및 무결성 제어: CAP 정리가 규정하는 CP/AP 트레이드오프를 인지하고, 실시간 통신(WebSockets, Webhooks) 도입 시 발생할 수 있는 중복 이벤트를 멱등성(Idempotency Key)으로 차단하며, 처리율 제한(Rate Limiting)으로 내부 시스템 자원을 보호한다.

상세

1. 요청 전송 및 흐름 제어 (Part I)

  • 클라이언트-서버 및 IP/DNS: 우편 주소와 같은 고유 식별자인 IP 주소(IPv4의 43억 개 주소 제한 및 무한에 가까운 IPv6 체계)를 도메인으로 매핑하는 DNS의 분산 계층 구조를 활용한다. raw/28 Core System Design Concepts, Explained Through the Failures They Prevent.md#L25 DNS 캐싱의 TTL 만료 이전에 발생하는 전파 지연(Propagation Delay)을 예방하기 위해 변경 전 TTL을 낮추는 실천 사항이 요구된다.
  • 리버스 프록시: 웹 애플리케이션 방화벽(WAF), TLS 종단, 정적 캐싱, 경로 기반 라우팅을 수행하는 리버스 프록시(NGINX, Envoy 등)를 서버 전면에 배치해 공격 표면을 차단한다.
  • 물리적 지연: 지연 시간(Latency) 단축을 위해 광케이블 물리 한계(1,000km당 수 ms 소요)를 극복하는 지리적 분산과 CDN 에지 캐싱을 도입한다. raw/28 Core System Design Concepts, Explained Through the Failures They Prevent.md#L61
  • REST vs GraphQL: 엔드포인트 캐싱이 쉽고 구조가 단순한 REST와, 클라이언트가 직접 필요한 필드를 질의하여 Over-fetching/Under-fetching을 예방하는 GraphQL의 캐싱 난이도 및 N+1 복잡도 트레이드오프를 통제한다.

2. 영속성 레이어 설계 (Part II & III)

  • SQL vs NoSQL: 데이터 정합성과 트랜잭션 원자성(ACID)이 요구될 경우 SQL을, 유동적인 JSON 기반 도큐먼트나 대용량 쓰기 최적화 및 분산 성능이 요구될 때는 NoSQL을 도입한다.
  • 인덱싱과 N+1 문제: 풀 테이블 스캔을 B-tree 기반 인덱스 탐색(Index Seek)으로 전환해 조회 시간을 획기적으로 개선하며, 연관 관계 데이터 순회 시 쿼리가 대폭 누적되는 N+1 문제를 방지하기 위해 Eager Loading(includes)을 필수로 내장한다.
  • 캐싱(Cache-Aside): 썬더링 허드나 캐시 스탬피드에 대비한 무작위 편차(Jitter) 설계를 가미하고 Redis 등의 고속 메모리에 데이터를 적재한다.

3. 분산 확장 및 신뢰성 유지 (Part IV)

  • 복제와 샤딩: 쓰기(Primary)와 읽기(Replica)를 분리하는 복제 구조에서는 비동기 동기화로 인한 복제 지연(Replication Lag)을 감수해야 하며, 데이터 분할 기법인 샤딩(Sharding)은 노드 간 조인 비용과 리밸런싱 비용이 크기 때문에 캐싱과 복제를 모두 소모한 뒤 최종적으로 구현해야 한다.
  • CAP 정리: 분산 네트워크 파티션(Partition) 상황 시 가용성(A)과 일관성(C)이 물리적으로 대립함을 인지하여, 데이터가 일시적으로 불일치하는 최종 일관성(AP) 모델을 수용할 것인지, 서비스 응답을 차단하는 CP 모델을 구축할 것인지 명확히 선택한다.
  • 멱등성과 처리율 제한: 실시간 이중 호출 및 네트워크 재시도로 인한 중복 트랜잭션을 멱등키(Idempotency Key) 조회를 통해 우회 처리한다. 또한 고정 윈도우, 슬라이딩 윈도우, 토큰 버킷(Token Bucket) 등의 알고리즘을 사용해 처리율 제한을 걸고 429 Too Many Requests 상태 코드를 반환함으로써 디도스 및 내부 버그의 전파를 예방한다. raw/28 Core System Design Concepts, Explained Through the Failures They Prevent.md#L414

예시

  • 멱등키 활용 결제 로직: 
    def process_payment(idempotency_key, amount)
  # 1. 멱등키 존재 여부 조회
  if Payment.exists?(key: idempotency_key)
    return render_success("Already processed") # 처리 우회(Short-circuiting)
  end
  # 2. 거래 기록 및 외부 PG 결제 요청
  Payment.create!(key: idempotency_key, amount: amount)
  PG.charge(amount)
end

충돌

  • 확장성 vs 아키텍처 복잡도: 수평 확장(Scale-out)은 인프라 가용한계와 고가용성 문제를 해결하지만, 상태 외부화(Stateless), 데이터 복제 지연, 세션 소실, 분산 트랜잭션 제어(Saga Pattern 등)와 같은 설계 난이도의 급격한 스파이크를 동반한다. 이에 따라 트래픽 규모가 임계점에 도달하기 전까지는 수직 확장(Scale-up)의 단순성을 우선해야 한다.

관련 노트

그래프 뷰

백링크