20. TCP/IP 기본 용어(기능 매칭 출제)

21. 네트워크 명령어(기능 매칭이 점수)

22. 네트워크 설정 파일(경로 문제 단골)

23. 포트 번호(암기 세트: 90점이면 확장)

23.1 필수 포트

23.2 추가 포트(자주 나오거나 함정)

24. 원격 접속/서비스 보안

24.1 SSH 설정(경로/옵션 매칭 출제)

• 설정 파일: /etc/ssh/sshd_config

25. TCP Wrapper(단골)

26. xinetd / inetd (서비스 슈퍼데몬 개념)

27. 방화벽(iptables) — 90점 방어 필수

27.1 iptables 핵심 개념

• 체인: INPUT, OUTPUT, FORWARD
• 정책/룰 기반 필터링

27.2 기본 명령(개념/명령 매칭)

시험은 실무 깊이보다 “iptables가 방화벽 도구” + “체인 이름”을 묻는 경우가 많음.

28. 파일/서비스 공유(NFS/Samba) — 개념+경로가 점수

28.1 NFS

• 설정 파일: /etc/exports

28.2 Samba

• 설정 파일: /etc/samba/smb.conf

29. 로그(네트워크/보안 연계로 출제 가능)

배포판에 따라 로그 파일명/위치가 달라질 수 있으나, 시험은 위 경로로 자주 출제됨.

🎯 90점 체크리스트(실수 방지용)

네트워크/보안

• 포트(21/22/23/25/53/80/443/110/143/123/3306) 암기
• /etc/hosts / resolv.conf / services 암기
• SSH 설정 파일 경로 + 3옵션(Port, PermitRootLogin, PasswordAuthentication)
• TCP Wrapper allow/deny 경로
• iptables 체인(INPUT/OUTPUT/FORWARD) 키워드
• NFS/Samba 설정 파일 경로

메시지 큐 (Message Queue)

• 애플리케이션 간 비동기 통신을 위한 중간 저장소

"처리 완료 시 삭제되는 전달 모델에 최적화되어 있으며, 보존은 부가 기능"

• 메시지 전달(Delivery)이 주 목적
• 소비 후 삭제가 기본값이지만, 보존 모드도 지원 가능
• 생산자와 소비자의 시간적 결합 해제

대표 플랫폼:

• RabbitMQ (AMQP 기반)
• Amazon SQS (관리형 서비스)
• ActiveMQ (JMS 기반)
• ZeroMQ (브로커리스)

이벤트 스트리밍 (Event Streaming)

• 시간순으로 이벤트를 기록하고 보존하는 분산 로그 시스템

"보존이 본질이고, 소비는 로그에 대한 뷰(View)"

• 이벤트 기록(Recording)이 주 목적
• 소비는 "읽기 위치(offset/cursor)의 이동"일 뿐, 데이터는 보존됨
• 같은 이벤트를 여러 소비자가 독립적으로 읽을 수 있음
• 재처리(Replay)가 핵심 기능

대표 플랫폼:

• Apache Kafka
• Amazon Kinesis
• Apache Pulsar
• Redpanda

2. 주요 특징 비교

개념 다이어그램

메시지 큐 - 전달 중심

                    ┌─────────────────┐
Producer ──────────▶│  Queue (버퍼)    │──────────▶ Consumer
                    │  M1 → M2 → M3   │     처리 완료 → 삭제
                    └─────────────────┘

• 메시지가 목적지에 "도착"하면 임무 완료 • 삭제가 기본, 보존은 선택

이벤트 스트리밍 - 기록 중심

                    ┌─────────────────────────────────┐
Producer ──────────▶│  Log (영구 기록)                  │
                    │  [M1][M2][M3][M4][M5]...        │
                    │        ↑           ↑            │
                    │   Consumer A   Consumer B       │
                    │   (offset=2)   (offset=4)       │
                    └─────────────────────────────────┘

• 메시지가 "기록"되면 임무 완료 • 소비자는 각자 읽기 위치만 관리 • 보존이 기본, 삭제는 정책에 따라

3. 메시지 보존과 재처리

플랫폼별 구현

재처리(Replay)가 필요한 상황

• 재처리가 필요한 아래의 예시 상황을 이벤트 스트리밍은 일상적 운영으로 처리, 메시지 큐는 예외적 상황으로 처리

4. 순서 보장

정확한 순서 보장 범위

Kafka의 순서 보장 범위

• 파티션 내부의 순서만 보장
• 멀티 파티션에서 전역 순서는 보장되지 않는다

플랫폼별 순서 보장

순서 보장 시나리오

시나리오: 주문 M1 → M2 → M3 순서로 발행

Case 1: 단일 큐/파티션 + 단일 소비자

┌─────────────┐     ┌────────────┐
│ M1 → M2 → M3│ ──▶ │ Consumer A │ → 처리: M1, M2, M3
└─────────────┘     └────────────┘

Case 2: 단일 큐 + 다중 소비자 (RabbitMQ)

┌─────────────┐     ┌────────────┐
│ M1 → M2 → M3│ ──┬▶│ Consumer A │ → M1 처리
└─────────────┘   │ └────────────┘
                  │ ┌────────────┐
                  └▶│ Consumer B │ → M2 처리 (M1보다 먼저 완료될 수 있음) ⚠️
                    └────────────┘

Case 3: 다중 파티션 (Kafka)

┌─ Partition 0: M1, M3 ─┐     ┌────────────┐
│                       │ ──▶ │ Consumer A │ → M1, M3 순서 보장
└───────────────────────┘     └────────────┘
┌─ Partition 1: M2 ─────┐     ┌────────────┐
│                       │ ──▶ │ Consumer B │ → M2
└───────────────────────┘     └────────────┘
→ M1, M2, M3 전역 순서는 보장되지 않음 ⚠️

전역 순서가 필요할 때

해결책 1: 단일 파티션/큐 사용

• 장점: 완벽한 순서 보장 • 단점: 병렬성 포기, 처리량 제한

해결책 2: 키 기반 파티셔닝

• 같은 키(예: user_id)는 같은 파티션으로 • 해당 엔티티 내에서만 순서 보장 • 예: user_123의 주문은 항상 순서대로

해결책 3: 애플리케이션 레벨 정렬

• 타임스탬프 기반 재정렬 • 시퀀스 번호 부여 • 복잡도 증가

5. 전달 보장 (Delivery Guarantees)

개념적 정의

Exactly-once의 범위

Kafka의 Exactly-once 범위

• 외부 시스템까지는 RabbitMQ와 동일한 한계를 가지므로 멱등성 구현이 필수적

Producer ──▶ Kafka Broker ──▶ Kafka Streams ──▶ Kafka Broker
   │              │                 │                │
   └──────────────┴─────────────────┴────────────────┘
              Exactly-once 가능 영역
              (Idempotent Producer + Transactions)


Kafka ──▶ 외부 DB    → Exactly-once 보장 안됨
Kafka ──▶ Redis      → Exactly-once 보장 안됨  
Kafka ──▶ REST API   → Exactly-once 보장 안됨

플랫폼별 Exactly-once 지원

6. 라우팅

조직 구조에 미치는 영향

플랫폼별 라우팅 기능

• RabbitMQ는 네트워크 중앙집중형 라우팅
• Kafka는 데이터 배치 규칙을 클라이언트에게 강제하는 모델

라우팅 비교

RabbitMQ - 브로커 중심 라우팅

Producer ──(routing_key="order.created")──▶ Exchange
                                              │
                    ┌─────────────────────────┼─────────────────────────┐
                    │                         │                         │
                    ▼                         ▼                         ▼
             order.* 바인딩            order.created 바인딩             # 바인딩
              ┌─────────┐                ┌─────────┐                ┌─────────┐
              │Order Svc│                │Analytics│                │ Logging │
              └─────────┘                └─────────┘                └─────────┘

• Producer는 routing_key만 지정 • 어디로 갈지는 Exchange 설정이 결정 • 런타임에 바인딩 변경 가능

Kafka - 생산자 중심 라우팅

Producer ──(key="user_123")──▶ Partitioner ──▶ Topic "orders"
                                    │
                    ┌───────────────┼───────────────┐
                    │               │               │
                    ▼               ▼               ▼
               Partition 0     Partition 1     Partition 2
               (user_1xx)      (user_2xx)      (user_3xx)
                    │
                    ▼
              Consumer Group

• Producer가 키와 파티션 전략 결정 • Custom Partitioner로 복잡한 로직 구현 가능 • Header에 메타데이터 포함 (KIP-82) • 소비자가 필요시 필터링

7. 소비자(Consumer) 모델

개념적 차이

플랫폼별 구현

확장의 숨은 비용

RabbitMQ - 운영적 확장

Queue ──┬──▶ Consumer 1
        ├──▶ Consumer 2
        ├──▶ Consumer 3
        └──▶ Consumer N  ← 그냥 추가하면 됨

• Consumer만 늘리면 즉시 부하 분산 • 인프라 변경 없음

Kafka - 구조적 확장

파티션 증설 시 발생하는 일:
  1. 파티션 재할당 (Reassignment)
  2. 디스크 간 데이터 이동
  3. Consumer Rebalance
  4. 순간적인 Lag 발생
  5. 처리 지연 가능성

• 파티션 수는 초기 설계 시 신중하게 결정해야 함 • 나중에 늘리면 비용이 따름

8. 성능 특성

개념적 차이

성능 병목의 원인

• RabbitMQ: 메시지마다 ACK 처리, 삭제, 큐 재배치, 인덱스 갱신 필요
• Kafka: Append만 하고, 삭제는 Segment 단위로 통째로 수행 (개별 삭제 없음)

플랫폼별 성능

9. 상황별 선택 가이드

• 단순히 "데이터 줄이기"가 아니라 데이터 분포를 재조정하여 모델이 학습해야 할 목표 분포를 만드는 과정

자동완성에서 실제로 쓰이는 샘플링 기법들

1. Subsampling

• 과다 등장 쿼리/토큰의 등장 확률 제어
• 단순히 “빈도가 높은 쿼리를 일정 비율로 줄이기”가 아니라, 아래 두 가지 문제를 해결하기 위한 확률적 다운샘플링
  • Zipf's Law로 인해 상위 몇백 개 쿼리가 전체 데이터의 50% 이상 차지하는 문제 해결
  • Transformer 학습 시 loss가 특정 패턴에 과도하게 최적화되는 것 방지
• 결과
  • 데이터 다양성 증대
  • 상위 쿼리 편향 감소
  • 모델이 "날씨", "뉴스", "유튜브" 같은 패턴만 배우는 문제 완화 ```text 예)
• “날씨”가 하루 50만 번 → 50만 개 모두 사용 X
• 확률 0.01로 줄여서 약 5천 개만 학습

2. Weighted Time Sampling(Temporal Decay Sampling)

• 자동완성은 트렌드 민감도가 매우 높기 때문에 단순 시간 가중치가 아니라, 대부분 지수 감쇠(Exponential Decay) 기법을 사용
• 특징
  • 최근 검색 데이터는 거의 100% 유지
  • 오래된 데이터는 자동으로 가중치 감소
  • 일간/주간 트렌드 반영이 매우 빠름
• 실제 구현은 연속적인 decay curve 형태로 시간별 sampling weight가 달라짐

3. Frequency-Aware Balanced Sampling(구간 기반 균형 샘플링)

• Zipf 분포를 flatten 하기 위해 쿼리 빈도 로그를 구간(bin) 으로 나누고, 각 구간별 target distribution을 맞추는 방식
• 자동완성 모델의 목표: “다양한 패턴 + 충분한 희귀 패턴 + 과다 패턴 억제”
  • 다양성을 확보하기 위해 인기 검색어/드문 검색어 구간을 만들어 균형 있게 샘플링
• rare query oversampling 시 노이즈 비율이 증가할 수 있어서,
  • 정제된 rare bucket만 100% 사용하고 raw 로그 rare bucket은 일부만 retention 하기도 함

4. Negative Sampling (Contextual Negative Mining)

• 단순 랜덤 샘플링이 아니라, 문맥적으로 "헷갈릴 만한" 잘못된 후보를 생성하는 것이 핵심

(1) 유형

• Random negative

  • 가장 기본적인 수준
  • "치킨" → "축구" 같은 무관 negative

• Hard negative

  • 최근 모델들은 “문맥은 비슷하지만 자연스럽지 않은 continuation”을 생성한다

"치킨" → "치킨 가격"은 긍정
"치킨" → "치킨 반지름"은 hard negative 

• In-batch negative
  • Transformer 학습에서 가장 많이 씀
  • batch 내 다른 라벨을 negative로 재사용
  • 학습 효율 ↑, 메모리 효율 ↑

(2) 목적

• 모델이 자연스러운 다음 검색어를 구분하게 됨
• perplexity 개선
• 자동완성 품질 상승

5. Query Session Based Sampling (사용자 의도 단위 샘플링)

• 단순히 “세션을 묶어서 함께 샘플링”이 아니라, _사용자 의도 전환(Intent shift)_을 기준으로 세그먼트 분리 후 샘플링하는 방식

(1) 세션 분리 기준

• 시간 기반: 30분 inactivity
• intent 기반: 검색어 embedding cosine similarity가 threshold 이하일 때 split
• action 기반: 클릭/스크롤 등 사용자 행동

(2) 이유

• 자동완성은 “사용자가 다음에 무엇을 검색할까?” 를 예측하는 task이기 때문에 세션 기반 데이터는 strong supervision signal을 줌

[치킨] → [치킨 배달] → [배달 시간]

6. Deduplication Sampling (중복 제어 + Noise Reduction)

• 단순 중복 제거가 아니라 아래 단계로 구성됨

(1) Exact deduplication

• 동일한 쿼리는 user-level / global-level로 중복 제거

(2) Fuzzy deduplication

• 오타나 경미한 철자 차이가 있는 쿼리를 묶어서 처리
  • 예: “아이폰배터리” / “아이폰 베터리” / “iphone battery”
• Levenshtein distance 기반 또는 embedding distance 기반으로 병합

(3) Spam/automation detection

• 의도적으로 반복되는 자동화 트래픽 제거
• 안티 스팸 모듈과 연동
• 이 단계에서 품질이 확연히 좋아짐

실제 자동 완성 모델 학습 파이프라인에서의 샘플링 흐름

• 전체 쿼리 로그 → 깨끗하게 정제(Cleaning) → 샘플링 → 모델 학습

(원본 쿼리 로그: 5억~20억 건)
   ↓
1) Cleaning
   - 스팸/자동화 필터링
   - 인코딩/오타 normalization
   - fuzzy deduplication
   ↓
2) Frequency-based Subsampling
   - Zipf 상위 쿼리 다운샘플링
   - 각 bucket별 target distribution 설정
   ↓
3) Temporal Weighted Sampling
   - exponential decay 적용
   - 최근 트렌드 weight 강화
   ↓
4) Negative Sampling (In-batch + Hard negative mining)
   - 자연스러운/비자연스러운 continuation 데이터 구성
   ↓
5) Session-based Sampling
   - intent shift 기준으로 세션 segmentation
   - session-aware pair 생성
   ↓
[최종 학습 데이터 ≈ 1~5백만 건 수준의 고품질 샘플]
   ↓
Transformer Decoder / BERT Decoder-Only Autocomplete Model 학습

• 검색어 자동 완성: 웹사이트 검색창에 단어 입력 시 입력 중인 글자에 맞는 검색어가 자동으로 완성되어 표시되는 기능
• autocomplete, typeahead, search-as-you-type, incremental search
• 가장 많이 이용된 검색어 k개를 자동완성하여 출력하는 시스템 설계

1단계. 문제 이해 및 설계 범위 확정

1.질문을 통한 요구사항 확인

• 입력 단어는 자동완성될 검색어의 첫 부분으로 한정
• 5 개의 자동 완성 검색어 표시
• 자동완성 검색어 5개를 고르는 기준: 질의 빈도에 따라 정해지는 검색어 인기 순위를 기준
• 맞춤법 검사나 자동수정기능은 지원 X
• 질의는 영어. 여유가 있는 경우 다국어 지원 고려
• 모든 질의는 여어 소문자로 이루어지며, 대문자나 특수 문자는 처리하지 않음

2. 요구사항

2-1. 빠른 응답 속도

• 사용자가 검색어를 입력함에따라 자동 완성 검색어도 빠르게 표시되어야 함
• 페이스북 검색어 자동 완성 시스템에 관한 문서: 시스템 응답 속도는 100ms 이내여야 함

2-2. 연관성

• 자동완성되어 출력되는 검색어는 사용자가 입력한 단어와 연관된 것이어야 함

  2-3. 정렬

• 시스템 계산 결과는 인기도 등의 순위 모델(ranking model)에 의해 정렬되어 있어야 함

2-4. 규모 확장성

• 시스템은 많은 트래픽을 감당할 수 있도록 확장 가능해야 함

2-5. 고가용성

• 시스템은 계속 사용 가능해야 함

2. 개략적 규모 추정

• 일간 능동 사용자(DAU): 천만 명 가정
• 사용자당 일간 검색 수행 횟수: 10건
• 질의 데이터: 평균적으로 20바이트의 데이터 입력 가정
  • 문자 인코딩 방법으로는 아스키 사용 가정(1문자=1바이트)
  • 질의문은 평균적으로 4개 단어로 이루어진다고 가정, 각 단어는 평균적으로 다섯 글자로 구성된다고 가정
  • 질의당 평균 4 단어 * 5글자 = 20바이트

2단계. 개략적 설계안 제시 및 동의 구하기

1. 개략적인 시스템 분류

1-1. 데이터 수집 서비스(data gathering service)

• 사용자가 입력한 질의를 실시간으로 수집하는 시스템

1-2. 질의 서비스(query service)

• 주어진 질의에 다섯 개의 인기 검색어를 정렬해 내놓는 서비스

3단계. 상세 설계

1. 트라이(trie) 자료 구조

1-1. 트라이

• 탐색 트리의 일종으로
• 이진 탐색 트리와 달리 트리의 어떤 노드도 그 노드 자체와 연관된 키는 저장하지 않음
• 대신 노드가 트리에서 차지하는 위치가 연관된 키를 정의

트라이 자료 구조의 핵심 아이디어

(root)
 └─ t
      └─ r
      │    └─ e   ← tre
      │
      └─ o         ← to

• 트리 형태의 자료구조
• 루트 노드는 빈 문자열을 나타냄
• 각 노드는 글자(character) 하나를 저장, 최대 26개의 자식 노드를 가질 수 있음

트라이로 검색어 자동 완성 구현

• 가장 많이 사용된 질의어 K 찾기
  1. 해당 접두어를 표현하는 노드를 찾는다. 시간 복잡도는 O(p)
  2. 하위 트리를 탐색하여 모든 유효 노드를 찾는다.
  3. 유효한 검색 문자열을 구성하는 노드가 유효 노드. 시간 복잡도는 O(c)
  4. 유효 노드들을 정렬하여 가장 인기 있는 검색어 k개를 찾는다. 시간 복잡도는 O(clog c)
  5. 알고리즘의 시간 복잡도
     = 각 단계에 소요된 시간
     = O(p) + O(c) + O(clog c)

최적화 방안

• 접두어의 최대 길이 제한(O(p) 에서 p 값 감소)
• 각 노드에 인기 검색어를 캐시
  • 각 노드에 k 개의 인기 검색어 저장 시, 전체 트라이 검색 방지
  • 각 단계의 시간 복잡도가 O(1)로 변경 > 최고 인기 검색어 k개를 찾는 전체 알고리즘의 복잡도도 O(1)로 변경

2. 데이터 수집 서비스

2-1. 종전 방법의 문제점: 사용자 타이핑 시 실시간 데이터 수정

• 실시간 트라이 갱신 시 질의 서비스의 속도가 심각하게 느려질 것
• 인기 검색어는 그다지 자주 바뀌지 않기 때문에 트라이를 자주 갱신할 필요가 없음

flowchart LR
A[데이터 분석 서비스 로그]--> B[로그 취합 서버] -->C[취합된 데이터] 
C--> D[작업 서버] --매주 갱신--> E[트라이 데이터 베이스] --매주 DB 상태 스냅샷-->F[트라이 케시]

2-2. 새로운 방식

1) 데이터 분석 서비스 로그

2) 로그 취합 서버

• 데이터 취합 실시간성의 중요성에 따른 분류
  • 실시간 앱: 데이터 취합 주기를 짧게 가져갈 필요가 있을 수 있음
  • 대부분: 일주일에 한번 정도 로그 취합

3) 취합된 데이터

• time 필드: 해당 주의 시작 날짜

• frequency 필드: 해당 질의가 해당 주에 사용된 횟수의 합

  query	time	frequency
  tree	2025-11-03	12000
  tree	2025-11-10	15000
  tree	2025-11-17	9000
  toy	2025-11-03	8500
  toy	2025-11-17	6256

4) 작업 서버

• 주기적으로 비동기적 작업을 실행하는 서버 집합
• 트라이 자료구조를 만들고 트라이 DB에 저장하는 역할 담당

5) 트라이 캐시

• 분산 캐시 시스템으로 트라이 데이터를 메모리에 유지하여 읽기 연산 성능을 높이는 구실
• 매주 트라이 DB의 스냅샷을 떠서 갱신

6) 트라이 DB

• 지속성 저장소
• 트라이 DB의 형태
  1. 문서 저장소(document store): 주기적으로 트라이를 직렬화하여 DB에 저장
  2. 키-값 저장소: 해시 테이블 형태로 변환

3. 질의 서비스

3-1. 비효율성을 개선한 설계안

flowchart LR
A[사용자 단말] --> B[로드 밸런서] -->C[API 서버] --> D[트라이캐시] -->E[트라이 DB]

1. query가 로드밸런서로 전송됨
2. 로드밸런서는 query를 API 서버로 전송
3. API 서버는 트라이 캐시에서 데이터를 가져와 해당 요청에 대한 자동 ㅗ안성 검색어 제안 응답 구성
4. 데이터가 트라이 캐시에 없는 경우 데이터를 DB에서 가져와 캐시에 채움

3-2. 질의 서비스 최적화 방안

AJAX 요청

브라우저 캐싱

• 대부분의 앱에서 자동 완성 검색어 제안 결과는 짧은 시간 안에 자주 바뀌지 않음
• 따라서 제안된 검색어들을 브라우저 캐시에 넣어두어 후속 질의 결과는 캐시에서 바로 가져갈 수 있게 함

  데이터 샘플링

• N개 요청 가운데 1개만 로깅

4. 트라이 연산

4-1. 트라이 생성

• 데이터 분석 서비스의 로그나, DB로부터 취합된 데이터를 이용하여, 작업 서버가 담당

4-2. 트라이 갱신 방법

• 매주 한 번 갱신. 새로운 트라이를 만든 후 기존 트라이를 대체
• 트라이의 각 노드를 개별적으로 갱신
  • 일반적으로 성능이 좋지 않지만, 트라이를 작을 때는 고려해볼만 함

4-3. 검색어 삭제

• 트라이 캐시 앞에 필터 계층(filter layer)을 두고 부적절한 질의어가 반환되지 않도록 함

5. 규모 확장이 가능한 저장소

• 첫 글자를 기준으로 샤딩
  • 서버를 26대 이상으로 늘리려면 계층적 샤딩 적용
  • 데이터의 균등 분배가 불가능함
• 과거 질의 데이터의 패턴을 분석하여 샤딩
  • 검색어 대응 샤드 관리자(shard map manager): 어떤 검색어가 어느 저장소 서버에 저장되는 지에 대한 정보 관리

4단계. 마무리

다국어 지원이 가능하도록 시스템 확장

• 트라이에 유니코드 데이터 저장

국가별로 인기 검색어 순위가 다른 경우

• 국가별로 다른 트라이 사용
• 트라이를 CDN에 저장하여 응답 속도를 높일 수 있음

실시간 검색어 자동완성 시스템 구축 시 고려할 점

• 샤딩을 통한 작업 대상 데이터 양 줄이기
• 순위 모델을 변경하여 최근 검색어에 높은 가중치 주기
• 데이터가 스트림 형태로 올 수 있다는 점을 고려(스트림 프로세싱에 필요한 시스템)
  • 아파치 하둡 맵리듀스
  • 아파치 스파크 스트리밍
  • 아파치 스톰
  • 아파치 카프카 등

스프링은 일관된 방법으로 프록시를 만들 수 있게 도와주는 추상 레이어를 제공한다 생성된 프록시는 스프링 빈으로 등록되어야 하며, 스프링은 프록시 객체를 생성해주는 기술을 추상화한 팩토리빈 ProxyFactoryBean을 제공해준다

1. 프록시에서 사용할 부가 기능

• MethodInterceptor 인터페이스를 구현해서 만든다
• ``MethodInterceptor의invoke()는ProxyFactoryBean`으로부터 타깃 객체에 대한 정보를 함께 제공받기 떄문에, 타깃 객체에 상관없이 독립적으로 생성되어질 수 있다
• MethodInterceptor 객체는 타깃이 다른 여러 프록시에서 함께 사용할 수 있고, 싱글톤 빈으로 등록 가능하다

2. 어드바이스: 타깃 객체에 종속되지 않는 순수한 부가 기능을 담은 객체

• MethodInvocation의 동작
  • MethodInvocation은 일종의 콜백 객체로, proceed()를 실행하면 타깃 객체의 메소드를 내부적으로 실행해주는 기능을 가지고 있다.
  • MethodInvocation 구현 클래스는 일종의 공유 가능한 템플릿처럼 동작한다.
  • 앞서 말한 MethodInvocation의 동작 때문에MethodInterceptor는 부가 기능을 제공하는 데만 집중할 수 있다.
• 여러 개의 부가 기능 제공
  • ProxyFactoryBean에 MethodInterceptor 설정 시, addAdvice()를 사용해서 여러 MethodInterceptor를 동시에 추가할 수 있다.
  • 즉, ProxyFactoryBean 하나로 여러 부가 기능을 제공하는 프록시를 생성할 수 있다.
• 참고: MethodInterceptor는 Advice 인터페이스를 상속하고 있는 서브 페이스

3. 포인트컷: 부가기능 적용 대상 메소드 선정 방법

4. 프록시 동작

1. 프록시가 클라이언트로부터 요청을 받는다.
2. 포인트컷에 부가 기능을 부여할 메서드인지를 확인해달라고 요청한다.
3. MethodInterceptor 타입의 어드바이스를 호출한다.

5. 사용된 디자인 패턴

전략 패턴 구조

• 프록시로부터 어드바이스와 포인트컷을 독립시키고 DI를 사용하게 한 덕분에,
  1. 여러 프록시가 공유해서 사용할 수 있고,
  2. 구체적인 부가 기능 방식이나 메서드 선정 알고리즘이 바뀌면 구현 클래스만 변경해서 설정에 넣어주면 된다

템플릿/콜백 구조

• 재사용 가능한 기능을 만들어두고 변경되는 부분(콜백 객체와 메서드 호출정보)만 외부에서 주입해서 작업 흐름(부가기능 부여) 중에 사용하는 구조
  • 어드바이스: 일종의 템플릿
  • 타깃을 호출하는 기능을 가지고 있는 MethodInvocation 객체: 콜백

6. 어드바이저: 어드바이스와 포인트 컷을 묶은 조합

7. ProxyFactoryBean 적용

• MethodInterceptor라는 Advice 서브 인터페이스를 구현한 TransactionAdvice 작성
• MethodInvocation 타입의 콜백을 이용해서 번거로운 타깃 메서드 호출 작업을 대부분 제거
• 타깃 메서드가 던지는 예외 또한 InvocationTargetException으로 래핑되지 않고 그대로 캐치해서 처리

  public class TransactionAdvice implements MethodInterceptors{    // 스프링의 인터페이스 구현
  

// 중략

// 타깃을 호출하는 기능을 가진 콜백 객체(MehotdInvocation 타입의 객체)를 프록시로부터 받음 public Object invoke(MehotdInvocation invocation)throws Throwable{

// 중략 try{ Object ret = invocation.proceed(); // 콜백을 호출해서 타깃 메서드 실행 가능 } catch (RuntimeException e){ // 예외가 래핑되지 않고 타깃에서 보낸 그대로 전달된다

// 생략

## 6.5 스프링AOP
### 1. 자동 프록시 생성기
- 스프링은 컨테이너로서 제공하는 기능 중 많은 부분을 확장할 수 있도록 확장 포인트를 제공해준다.
- `DefaultAdvisorAutoProxyCreator`는 어드바이저를 이용한 자동 프록시 생성기로, 스프링은 빈 후처리기가 빈으로 등록되어 있으면 빈 객체가 생성될 때마다 빈 후처리기에 보내서 후처리 작업을 요청한다.

#### 빈 후처리기를 이용한 자동 프록시 생성 방법
1. `DefaultAdvisorAutoProxyCreator` 빈 후처리기가 등록되어 있으면, 스프링은 빈 객체 생성마다 후 처리기에 빈을 보낸다.
2. `DefaultAdvisorAutoProxyCreator`는 포인트컷을 이용해 전달받은 빈이 프록시 적용 대상인지를 확인한다.
3. 프록시 적용 대상일 경우,
    1) 내장되 프록시 생성기에게 현재 빈에 대한 프록시를 생성하게 한다.
    2) 만들어진 프록시에 어드바이저를 연결해준다.
    3) 프록시가 생성되면 원래 컨테이너가 전달해준 빈 객체 대신 프록시 객체를 컨테이너에게 돌려준다.
4. 컨테이너는 최종적으로 빈 후처리기가 돌려준 객체를 빈으로 등록하고 사용한다.


### 2. 포인트컷의 두 가지 기능
- 포인트컷은 `ClassFilter`와 `MethodMatcher` 두 가지를 돌려주는 메서드를 가지고 있다
- 만약 포인트컷 선정 기능을 모두 적용한다면 아래와 같은 순서로 동작하게 된다.
    1. 프록시를 적용할 클래스인지 판단
    2. 적용 대상 클래스 인 경우, 어드바이스를 적용할 메소드인지를 확인

- `ProxyFactoryBean`에서는 굳이 클래스 레벨의 필터는 필요 없었지만, `DefaultAdvisorAutoProxyCreator`는 클래스와 메서드 선정 알고리즘을 모두 갖고 있는 포인트컷과 어드바이스가 결합되어 있는 어드바이저가 필요하다.


#### 클래스 필터가 포함된 포인트컷
```java
public class NameMatchClassMethodPointcut extends NameMatchMethodPointcut{
    public void setMappedClassName(String mappedClassName){
        this.setClassFilger(new SimpleClassFilter(mappedClassName));
        // 모든 클래스를 다 허용하던 디폴트 클래스 필터를 
        // 프로퍼티로 받은 클래스 이름을 이용해서 필터를 만들어 덮어씌움

        // 생략

포인트컷 표현식

• 포인트컷 표현식: 스프링이 제공하는 간단하고 효과적인 포인트컷의 클래스/메서드 선정 알고리즘 작성 방법
• 스프링이 사용하는 포인트컷 표현식은AspectJ 프레임 워크의 일부 문법을 확장한 표현식으로, AspectJExpressionPointcut 클래스를 사용해서 적용 가능하다.

AspectJ 포인트컷 표현식

• 포인트컷 지시자를 이용해서 작성하며, 가장 대표적으로 사용되는 지시자는 execution()

execution([접근제한자 패턴] 타입패턴 [타입패턴.]이름패턴 (타입패턴 | "..", ...)[throws 예외패턴])

포인트컷 표현식 문법

• AspectJ 포인트컷 표현식은 포인트컷 지시자를 이용해 작서 l

1. URL 단축기의 동작

1-1. 단축 URL 제공 기능

• https://www.example.com/q=chatsystem&c=loggedin&v=3&l=long이라고 입력이 주어진 경우
• 서비스에서 https://www.tinyurl.com/y7ke-ocwj와 같은 단축 URL을 결과로 제공해야 함

  1-2. URL 리디렉션 기능

• 해당 단축 URL을 통해 원래 URL로 갈 수도 있어야 함

2. 트래픽 규모

• 매일 1억 개의 단축 URL 생성 가능

  3. 단축 URL의 길이는?

• 짧을 수록 좋음

  4. 단축 URL 포함 문제에 대한 제한

• 숫자(0-9)와 영문자(a-z, A-Z)만 사용 가능

5. 단축URL을 삭제하거나 갱신하는 기능

• 시스템 단순화를 위해 삭제나 갱신 기능은 없다고 가정

6. 높은 가용성과 규모 확장성, 장애 감내가 요구됨

2단계. 개략적 설계얀 제시 및 동의 구하기

1. API 엔드포인트

• URL 단축기는 기본적으로 두 개의 엔드포인트를 필요로 함
  • URL 단축용 엔드포인트
  • URL 리디렉션용 엔드포인트

2. URL 리디렉션

2-1. 리디렉션 응답 비교

• 서버부하를 줄이는 것이 중요하다면 301
• 트래픽 분석이 중요할 때는 302

2-2. 301 vs 302

2-3. URL 리디렉션 구현

원래 URL = hashTable.get(단축 URL)
301 또는 302 응답 Location 헤더에 원래 URL을 넣은 후 전송

3. URL 단축

• 단축 URL이 www.tinyurl.com/{hashValue}와 같은 형태일 때,
• 결국 중요한 것은 긴 URL을 해시 값으로 대응시킬 해시 함수를 찾는 일

3-1. 해시 함수가 만족해야 하는 요구사항

• 입력으로 주어지는 URL이 다른 값이면 해시 값도 달라야 함
• 계산된 해시값은 원래 입력으로 주어졌던 긴 URL로 복원될 수 있어야 함

3단계. 상세 설계

1. 데이터 모델

• <단축 URL, 원래 URL>의 순서쌍을 관계형 DB에 저장
• 

2. 해시 함수

• hashValue는 [0-9, a-z, A-Z]의 문자들로 구성됨(10+26+26=62개)
• hashValue의 길이를 정하기 위해서는 62^n>=3650억인 n의 최솟값을 찾아야 함
• n이 7일 때 62^7=3.5조 개의 URL 생성 가능하므로 hashValue의 길이는 7로 결정

2-1. 해시 후 충돌 해소 기법

• 긴 URL을 줄이기 위해서 원래 URL을 7글자 문자열로 줄이는 해시함수가 필요함

1) 해시 함수

• 비암호학적 해시 함수: MurmurHash, CRC32, FNV-1a 등 (빠르고 단순)
• 암호학적 해시 함수: SHA-1, SHA-256, MD5 등 (보안적 목적 시)

2) 해시 재계산 방식(Rehashing with Salt)

• URL을 해시한 후 이미 존재하는(=충돌한) 단축 코드라면, 미리 정한 문자열(또는 숫자)을 붙여 다시 해시
• 해시 공간을 바꿔서 서로 다른 해시 결과를 강제로 생성하는 방식

• hash("https://example.com/a") → "A7xPqL2"
  이미 존재함 → 충돌 발생!
  hash("https://example.com/a" + "1") → "bK0RzTf"
  새 키 확보 

3) Bloom Filter

• 확률적 집합 존재 여부(“이 값이 이미 등록되었는가?”) 를 빠르게 판별하기 위한 비트 배열 기반 데이터 구조
• 충돌 이전에 “이 값이 이미 존재할 가능성이 있나?”를 빠르게 추정하는 확률적 필터
  • 여러 개의 서로 다른 해시 함수를 사용 (k개)
  • 입력값을 각각 해시 → 비트 배열의 인덱스로 사용 → 비트들을 1로 설정
  • 새 값이 들어올 때 → 동일한 해시로 검사 → 해당 비트가 모두 1이면 “이미 존재 가능성이 있음”

2-2. base-62 변환

• hashValue에 사용할 수 있는 문자 수가 62개이기 때문에 base62 변환

• 문자 매핑 가능

  • 값	문자	값	문자	값	문자
    0–9	'0'–'9'	10–35	'A'–'Z'	36–61	'a'–'z'

• base-62 변환 원리

2-3. 해시 후 충돌 해소 전략 vs base 62 변환

3. URL 단축 및 리디렉션

1. 사용자가 단축 URL 클릭
2. 로드 밸런서가 해당 클릭으로 발생한 요청 웹 서버에 전달
3. 단축 URL이 이미 캐시에 있는 경우에는 원래 URL을 바로 꺼내서 클라이언트에 전달
   3-1. 캐시 미스의 경우 DB에서 꺼내서 전달. DB에도 없다면 사용자가 잘못된 단축 URL을 입력한 것
   3-2. DB에서 꺼낸 URL을 캐시에 넣은 사용자에게 반환

4단계. 추가 고려 사항

1. 처리율 제한 장치(rate limiter)

2. 웹 서버 규모 확장

3. DB 규모 확장

4. 데이터 분석 솔루션(analytics)

5. 가용성, 데이터 일관성, 안정성

"대규모 시스템 설계" 책 스터디 중 트위터의 Snowflake 관련 내용을 보완하기 위해 서칭하다가 찾게 된 내용입니다 트위터 기술 블로그 내용 중 "대규모 시스템 설계"와 관련있고, 제가 관심있는 부분을 정리하였습니다 (참고: 2010년 6월 1일 작성)

제 포스팅을 읽는 다른 분들에게도 도움이 되는 내용이기를 바랍니다.

1. 트위터의 Snowflake 방식

1-1. 트위터의 데이터 저장소

• MySQL 기반
• 단일 소규모 DB 인스턴스 → 이후 단일 대규모 DB 인스턴스로 확장 → 대규모 DB 클러스터로 분산
• 시스템 다수를 Cassandra나 MySQL 샤딩으로 교체
• 참고: Cassandra는 내장 전역 유일키 생성기가 없어 별도 솔루션이 필요

1-2. 분산 유일키 생성에 대한 트위터의 요구사항

• 고가용성, 초당 수만 건 생성, 로컬 O(1)에 가까운 지연 → 비조정(uncoordinated) 방식 지향
• 대체로 시간 정렬(K-sorted) 지원
• 64 bit
  • 트위터는 이미 트윗 ID 저장용 비트 수를 늘리는 고통스러운 과정을 겪은 바 있음
  • 비트 확장 이슈 재발 방지(광범위한 코드 영향 최소화)

2. 고려했던 선택지

• MySQL 기반 티켓 서버(플리커 방식)
  • 별도의 재동기화 루틴을 구축하지 않고서는 필요한 순서 보장을 제공하지 못함
• 다양한 UUID 방식
  • 발견한 모든 방식은 128비트가 필요했음
• Zookeeper 순차 노드
  • 트위터는 로컬 계산을 통한 낮은 지연·높은 가용성을 원했기 때문에, 전역 순서를 위해 조정이 필요한 ZK 순차 노드는 배제

3. 해결책(Snowflake)

• ID = ⟨시간⟩ ⊕ ⟨데이터센터⟩ ⊕ ⟨워커⟩ ⊕ ⟨시퀀스⟩의 조합 채택
• 시퀀스 번호: 워커(프로세스) 단위로 할당, 동일 ms 내 0..4095 증가(스레드 간 동기화로 공유)
• 워커 번호: 시작 시 Zookeeper를 통해 선택됨(구성 파일을 통해 재정의 가능)

4. Twitter Snowflake의 구현 포인트

4-1. 비트 구성

• 각 필드는 충돌 공간을 분할하는 네임스페이스
• 시간 41bits, DC 5bits, 워커 5bits, 시퀀스 12bits → 설계적으로 충돌 배제

    시간(41b) | DC(5b) | 워커(5b) | 시퀀스(12b)
  ID = ⟨시간⟩ ⊕ ⟨데이터센터⟩ ⊕ ⟨워커⟩ ⊕  ⟨시퀀스⟩

  1) 시간

• timestampLeftShift = 12+5+5 = 22 → 나머지 상위 비트는 시간
• twepoch = 1288834974657L 기준(2010-11-04 01:42:54.657 UTC)
• 수명: 41비트(ms) ≈ 약 69.7년 → 위 twepoch 기준 ~2080년대 초까지 사용 가능

2) 데이터 센터

• datacenterIdBits = 5 → 데이터센터 ID 0~31

3) 워커

• workerIdBits = 5 → 워커 ID 0~31

4) 시퀀스

• sequenceBits = 12 → 같은 ms 내에서 0~4095 순번

4-2. 코드 스니펫

private[this] val sequenceBits = 12L
private[this] val workerIdBits = 5L
private[this] val datacenterIdBits = 5L
val twepoch = 1288834974657L 

// ...중략

((timestamp - twepoch) << timestampLeftShift) |
  (datacenterId << datacenterIdShift) |
  (workerId << workerIdShift) |
  sequence

//...

5. 운영 시 주의

• 시계 역행(Clock Skew): 감지 시 예외로 생성 차단(중복 방지 우선). 엄격한 NTP 운영 필수

• 버스트 처리: 동일 ms에 4096개 초과 시 다음 ms까지 대기 → tail latency 증가 가능 → 워커 확장, 요청 평탄화(배치·리밋) 고려

• 전역 단조증가 아님: 다중 워커·DC 간엔 전역 순서 보장 X → 정렬/인덱스에 시간 보조키 병행 권장

• ZK 의존 영역 최소화: 워커ID 임차만 조정. 세션 만료/네트워크 분할 시 중복 워커ID 방지(펜싱 토큰 등) 설계

6. 용어 정리

6-1. K-sorted(대체로 시간 정렬)

• 상위 비트가 시간이라 대체로 시간순 정렬되지만, 서로 다른 워커/동일 ms에서는 전역 단조증가가 절대적으론 보장되지 않음

6-2.조정방식과 비조정 방식

1) 비조정(uncoordinated) 방식

• ID 생성 시 별도의 합의/락 없이 각 노드가 독립적으로 생성
• 가용성·지연에 유리 (Snowflake의 핵심 철학)

2) 조정(coordinated) 방식

• 중앙 조정(예: DB 시퀀스, ZK 순차 노드)으로 순서 보장
• 전역 순서엔 유리하나 지연·가용성 손해

6-3.모노토닉 시계(monotonic clock)

• 시스템 시간이 뒤로 가지 않는다는 가정
• 위배되면 충돌 위험 존재 → Snowflake는 예외로 중단

6-4.시계 스큐(clock skew)

• 노드 간 시간 차이
• NTP 튜닝·알람이 필수

6-5.O(1) 생성

• 네트워크 왕복/합의 없이 로컬 비트 연산만으로 즉시 생성 → 매우 낮은 지연

7. 레퍼런스

• https://blog.x.com/engineering/en_us/a/2010/announcing-snowflake
• https://twitter.github.io/twitter-server/
• https://github.com/twitter-archive/snowflake/releases/tag/snowflake-2010

"대규모 시스템 설계" 책 스터디 중 티켓서버 관련 내용을 보완하기 위해 서칭하다가 찾게 된 내용입니다 플리커의 기술 블로그 내용 중 "대규모 시스템 설계"와 관련있고, 제가 관심있는 부분을 정리하였습니다(참고: 2010년 2월 8일 작성)

제 포스팅을 읽는 다른 분들에게도 도움이 되는 내용이기를 바랍니다.

1. 플리커의 티켓서버

1-1. 플리커의 데이터 저장 방식

• 플리커는 샤딩 방식으로 데이터 저장소를 확장하고 있음
  • 하나의 거대한 DB 대신 여러 DB에 데이터를 분산저장함으로써 부하 분산
• DB 간 데이터 마이그레이션이 필요한 경우 존재

1-2. MySQL 샤드

• 마스터-마스터 복제 쌍으로 구성되어 있음
• 샤드 간 이동과 마스터-마스터 복제 모두에서 충돌이 없도록 전역적으로 고유한 키가 보장되어야 함

1-3. GUID를 사용할 수도 있지 않을까?

• 전역적으로 유일한 키가 필요하다면 GUID를 고려해도 될 것 같은데 쓰지 않는 이유?
• GUID는 크기가 크고, MySQL에서 인덱스 성능이 좋지 않음

1) 플리커의 MySQL 성능 유지 방법

• 쿼리 대상이 되는 모든 항목에 인덱스 생성
• 인덱스만으로 쿼리 수행
• GUID는 인덱스 팽창 문제 때문에 이러한 전략과 상충함

2) 티켓 서버의 유용성

• 티켓 서버는 순차성(sequentiality) 제공
• 리포팅과 디버깅을 좀 더 직관적으로 만들어주고
• 캐싱 트릭(ID 순서를 이용한 캐시 전략)이 가능함

1-4. 안전 해시를 사용할 수도 있지 않을까?

• 아마존의 Dynamo 같은 시스템은 안전 해시를 통해 GUID/샤딩 문제 처리함
  • 이는 쓰기 비용이 낮은(Write-cheap) 환경(예:LSM-tree)에 적합함
• MySQL은 빠른 랜덤 읽기(fast random reads)에 최적화 되어 있음
• Flickr는 MySQL의 빠른 랜덤 읽기 특성을 살리기 위해 순차 ID를 유지하는 선택을 한 것

2. 중앙 집중 Auto-Increments

2-1. 한계

• 단일 DB에서 ID만 발급받는 방식은 단순함
• 하지만 초당 60장+ 업로드와 댓글/즐겨찾기/그룹/태그 등 모든 엔터티가 ID를 필요로 해 중앙 테이블이 급격히 비대해짐
• 그래서 Flickr는 티켓 서버라는 가벼운 시퀀스 전용 테이블을 운용

2-2. 플리커 방식의 중앙 집중 Auto-Increments

• 단일 DB에 새 행 삽입 시, 해당 테이블의 자동 증가 ID를 모든 DB의 기본키로 사용
• MySQL의 REPLACE INTO를 통해 기존 행 삭제 후 새 행 INSERT
  • DB의 단일 행을 원자적으로 업데이트하고, 자동 증가된 새 기본키를 획득
  • 참고: 일반적으로는 INSERT … ON DUPLICATE KEY UPDATE가 더 권장됨
• 플리커의 티켓 서버는 전용 DB 서버로 단일 DB를 보유하고 있음
• 해당 DB에는 32비트 ID용 Tickets32 테이블과 64비트 ID용 Tickets64 테이블 등이 존재

1) 테이블 구조

CREATE TABLE `Tickets64` (
  `id` bigint(20) unsigned NOT NULL auto_increment,
  `stub` char(1) NOT NULL default '',
  PRIMARY KEY  (`id`),
  UNIQUE KEY `stub` (`stub`)
) ENGINE=InnoDB;

2) 조회

• Tickets64 테이블에서 조회 수행 시 다음과 같이 단일 행이 반환됨

+-------------------+------+
| id                | stub |
+-------------------+------+
| 72157623227190423 |    a |
+-------------------+------+

3) 전역 유니크 키 발급

• stub는 유니크 제약이 걸린 더미 컬럼으로, 테이블에는 보통 'a' 한 값만 유지

  REPLACE INTO Tickets64 (stub) VALUES ('a');  -- PK/UNIQUE 충돌 시 기존 행 삭제 후 새 행 INSERT
  SELECT LAST_INSERT_ID(); -- 반드시 같은 커넥션에서 호출
  

---
# 3. SPOFs
- 티켓서버 방식에는 티켓서버 그 자체가 단일 장애지점이 될 수 있다는 문제가 있음
- 이 문제를 해결하기 위해 플리커에서는 ID 공간을 짝수/홀수로 나눈 두 개의 티켓 서버 운영
  - 라운드 로빈 방식을 통해 두 서버 간 로드밸런싱과 다운타임 처리
  - 참고: 양쪽 카운트가 조금 달라도 기능적으로 무방함 (실제 플리커도 홀수가 더 많다고 함)

``` text
TicketServer1:
auto-increment-increment = 2
auto-increment-offset = 1

TicketServer2:
auto-increment-increment = 2
auto-increment-offset = 2

4. 여러 시퀀스 분리 운용

4-1. 개별 시퀀스 테이블 운용

• OfflineTasks: 발급량이 많아 다른 개체들의 카운트를 불필요하게 끌어올리지 않으려 분리
• Groups/Accounts: 발급량이 적어 따로 분리
• Photos: 과거 auto-increment와 동기화해 총 업로드 수의 직관적 파악이 가능하도록 설계

5. 작동하는 가장 단순한 것

• 플리커의 티켓서버 방식은 2006년 1월 13일(금)부터 운영
• 특별히 우아한 방식은 아니지만, 작동하는 가장 단순한 것 설계 원칙을 보여주는 훌륭한 사례

6. 레퍼런스

• https://code.flickr.net/2010/02/08/ticket-servers-distributed-unique-primary-keys-on-the-cheap/

1단계. 문제 이해 및 설계 범위 확정

2단계. 개략적 설계안 제시및 동의 구하기

• 분산 시스템에서 유일성이 보장되는 ID 생성 기법은 다양함
• 선택지
  • 다중 마스터복제(multi-master replication)
  • UUID(Universally Unique Identifier)
  • 티켓 서버(ticket server)
  • 트위터 스노플레이크(twitter snowflake) 접근법

2-1. 다중 마스터 복제

• DB의 auto_increment 기능을 활용하는 방법
• 단, 1씩 증가가 아닌 K(분산 DB 수)씩 증가

2-2. UUID(v4)

특징

• 컴퓨터 시스템에 저장되는 정보를 유일하게 식별하기 위한 128비트 수

2-3. 티켓 서버

• 플리커는 분산 기본키를 만들기 위해 티켓 서버 기술 활용
• auto_increment 기능을 갖춘 DB 서버(티켓 서버)를 중앙 집중형으로 하나만 사용하는 방식

2-4. 트위터 스노우플레이크 접근법

• 64비트 정수를 여러 절(타임스탬프 | 노드ID | 시퀀스)로 비트 분할해 시간 정렬과 완전 분산을 동시에 달성하는 방식

생성

• sign bit: 1비트 할당
• timestamp: 기준 epoch 이후 경과 ms(또는 ns)
• 노드 ID(머신/프로세스)
  • 데이터 센터 ID: 5비트 할당. 2^5 = 32개 데이터 센터 지원 가능
  • 서버 ID: 5비트 할당. 데이터 센터당 32개 서버 사용 가능
• 일련번호
  • 각 서버에서는 ID 생성 시 일련 번호 1씩 증가
  • 1ms 경과할 때마다 초기화됨(즉, 같은 ms 내 증가하는 시퀀스 비트)

[ 1bit 예약 | 41bit 타임스탬프 | 10bit 노드ID | 12bit 시퀀스 ]

3단계. 상세 설게

노드 ID

• 데이터 센터 ID와 서버 ID는 시스템이 시작할 때 결정되며, 일반적으로 운영중에는 변경되지 않음
• 변경 시 ID 충돌이 발생할 수 있음

4단계. 추가 논의 사항

시계 동기화(clock synchronization)

• 하나의 서버에서 여러 코어가 실행될 경우 ID 생성 서버들이 전부 같은 시계를 사용하지 않을 수도 있음
• 해결 방법 중 하나: NTP(Network Time Protocol)

각 절의 길이 최적화

• 동시성이 낮고 수명이 긴 앱이라면 일련번호의 길이를 줄이고 타임스탬프 절의 길이를 늘이는 것을 고려 가능

고가용성

5. 참고 내용

5-1. UUID v4 (난수형)

정의

• 128비트 UUID
• 상수 비트(버전/variant)를 제외한 122비트를 암호학적으로 충분한 난수로 채우는 식별자

보장/성질

• 완전 분산: 중앙 없이 생성
• 정렬성 없음: 삽입 위치가 랜덤 → 인덱스 단편화 유발 가능
• 충돌 확률: 현실적으로 극히 낮음(122비트 공간)
• 개인정보 노출 없음: 시간/노드 정보 미포함

권장 유스케이스

• “그냥 충돌 없이 잘 돌아가는 전역 고유키”가 필요하고 DB 인덱스 비용을 감수할 수 있을 때
• 마이크로서비스/이벤트ID/추적ID 등 중앙 조율이 싫을 때

5-2. UUID 버전

• v7 과 v4 비교
  • v7 장점: 타임스탬프를 상위비트에 두어 삽입 정렬성↑, 범위쿼리·시계열 조회에 유리. 인덱스 단편화↓, 캐시 친화적
  • v4 장점: 구현·호환성 측면에서 가장 널리 쓰이고 라이브러리 풍부.
• DB 성능/정렬성이 중요하면 v7, 단순 분산 유일 키면 v4도 충분

6. 용어

• 정렬성(orderability): 시간이 흐를수록 값이 대체로 증가
• 충돌 확률: 서로 다른 두 생성 결과가 동일 키가 되는 확률(이상적으로 0에 가깝다)
• 완전 분산성: 중앙 조율 없이 각 노드가 독립적으로 생성 가능

분산 키 - 값 저장소가 가져야 하는 기능과 기능 구현에 이용되는 기술들

1. 키 값 저장소란?

1-1. 이론적 정의

• 데이터를 키(Key)와 값(Value) 쌍으로 관리하는 가장 단순한 형태의 DB 모델
• 내부적으로 해시 테이블 유사 구조 사용
• 스키마리스(Schema-less)
• 값에는 문자열·JSON·Blob 등 다양한 데이터 저장 가능

1-2. 기본 연산

• PUT(key, value), GET(key), DELETE(key) 등 최소한의 조작 인터페이스

1-3. 성능 특성

• O(1)에 가까운 조회/쓰기 성능 제공 (메모리 기반 접근, 해시 인덱스 활용)
  • 기본적으로 해시 테이블이나 LSM-Tree 구조를 활용하여 매우 빠른 접근 성능을 보장
• 분산 환경에서 수평 확장(Scale-Out) 가능
  • Dynamo는 "highly available key-value store"로 설계되었으며, Consistent Hashing을 기반으로 새로운 노드를 추가하거나 제거할 때 전체 데이터를 재분배하지 않고도 수평 확장 가능하도록 설계됨

1-4. 예시

• Redis: In-memory key-value DB, 다양한 데이터 타입 지원
• Memcached: 캐싱 중심 단순 Key-Value Store
• DynamoDB: AWS 관리형 Key-Value + Document DB (밀리초 단위 성능, 자동 샤딩)
• Cosmos DB: Azure의 글로벌 분산 Key-Value DB API 지원

2. 단일 서버 키-값 저장소 설계

• 단일 서버 수준에서는 키-값 저장소를 해시 테이블 기반의 빠른 조회·쓰기를 중심으로 설계하면 충분

  2-1. 단일 서버 수준에서 다루는 사항들

• 데이터 모델

  • 단순한 Key → Value 매핑
  • 키는 유일성을 보장해야 하며, 값은 문자열·JSON·바이너리 등 어떤 형태든 저장 가능→ 스키마 유연성(Schema-less)

• 저장 구조

  • 메모리 기반 해시 테이블(dictionary)을 사용해 평균 O(1) 조회 성능 제공
  • 필요 시 디스크에 주기적 스냅샷(RDB)이나 Append-Only File(AOF)로 내구성 보장

• 만료/퇴출 정책

  • TTL(Time-To-Live)로 키의 생존 시간을 제한
  • 메모리 부족 시 LRU/LFU/Random 같은 eviction 정책으로 데이터 제거

• 동시성/원자성

  • 단일 스레드 이벤트 루프 또는 락 분할(shard) 기반 멀티스레딩

• 단일 서버에서는 빠른 접근(O(1))·TTL/eviction·내구성 옵션까지 갖추면 실무적으로 충분

3. 분산 서버 키-값 저장소 설계

3-1. 분산 시스템 설계 시 알아둬야 하는 개념들

1) CAP 정리

• Eric Brewer (2000) 제안, 이후 Gilbert & Lynch(2002)에 의해 정리된 이론
• 분산 시스템에서는 Consistency(일관성), Availability(가용성), Partition Tolerance(분할 내성) 세 가지 속성을 동시에 모두 만족할 수 없다는 이론

1-1) 핵심 포인트

• 네트워크 분할 가능성을 완전히 배제할 수 없기 때문에 P(Partition Tolerance)는 분산 시스템에서는 사실상 필수
• 따라서 실제 선택은 AP vs CP의 문제
• 즉, 네트워크 파티션이 발생했을 때, 시스템은 C(일관성)과 A(가용성) 중 하나를 희생해야 함

1-2) CAP 정리에 따른 키-값 저장소 분류

3-2. 시스템 컴포넌트(feat. Dynamo, Cassandra, BigTable)

1) 데이터 파티션

1-1) 데이터 파티셔닝에서 고려할 점

• 데이터의 고른 분산
• 노드 추가/삭제 시 데이터의 이동 최소화

1-2) 안정 해시를 사용한 파티셔닝의 장점

• 규모 확장 자동화(automatic scaling)
• 다양성(heterogeneity): 각 서버의 용량에 맞게 가상노드 수 조정 가능

2) 데이터 다중화

• 높은 가용성과 안정성 확보를 위해 데이터를 N개 서버에 비동기적으로 다중화

3) 데이터 일관성

3-1) 일관성과 관련된 주요 프로토콜

• 참고: Tunable Consistency란?

  • 정의: 분산 데이터베이스에서 읽기(Read)와 쓰기(Write) 연산 시 필요한 복제본(Replica)의 수를 조정하여, 일관성과 가용성 사이의 균형을 사용자가 선택할 수 있는 모델

  • 핵심 공식:

    R + W > N

    • N: 전체 복제본 수
    • R: 읽기에 필요한 복제본 수
    • W: 쓰기에 필요한 복제본 수

  • 특징:

    • 유연성: 애플리케이션의 요구에 따라 “일관성 우선(CP)” 또는 “가용성 우선(AP)”으로 운영 가능.
    • 대표 사례: Cassandra, Amazon DynamoDB → 클라이언트가 Consistency Level을 지정 가능 (ONE, QUORUM, ALL 등).

3-2) 일관성모델

3-3) 비일관성 해소 기법

예방 기법

• 비일관성 발생 자체를 막음 (합의, 쿼럼, 동기 복제)
  • 장점: 데이터 무결성 보장
  • 단점: 지연(latency), 성능 비용

사후 해결 기법

• 일관성 깨짐을 허용하고, 나중에 맞춤(Repair, Vector Clocks, CRDT, Anti-Entropy)
  • 장점: 확장성과 가용성에 유리
  • 단점: 충돌 처리 복잡, 사용자 체감 일관성 저하

벡터 클락 (Vector Clock)

• 개념

  • 버저닝의 확장 기법
  • 단순 타임스탬프(하나의 시간값) 대신, 각 노드별 버전 정보를 벡터 형태로 관리
  • 즉, 데이터 변경 이력이 다차원 벡터로 기록되어, 어떤 노드에서 어떤 시점에 변경이 발생했는지 알 수 있음

• 동작 방식

  1. 각 노드가 자신의 카운터를 유지 (예: Node A=3, Node B=5)
  2. 데이터 변경 시 해당 노드의 카운터를 증가
  3. 변경 데이터를 다른 노드에 전송할 때 벡터 클락도 함께 전송
  4. 수신한 노드는 자신이 가진 벡터와 비교하여 충돌 여부를 판정

• 충돌 판정

  • 완전히 포함: (A:2, B:1) vs (A:3, B:1) → 후자가 최신.
  • 교차: (A:3, B:1) vs (A:2, B:2) → 어느 쪽이 최신인지 판단 불가 → 충돌 발생.

• 단점

  • 벡터 길이가 노드 수에 비례해 커짐 (확장성 문제)
  • 충돌을 탐지는 하지만, 최종 해결(Resolution) 은 애플리케이션 로직이 필요

4) 장애 처리

4-1) 장애 감지(failure detection) 기법

• 가십 프로토콜 - 분산형 장애 감지 솔루션
  • 각 노드는 멤버십 목록 유지 (멤버 ID + 박동 카운터(heartbeat counter) 쌍)
  • 각 노드는 주기적으로 자신의 박동 카운터를 증가 시킴
  • 무작위로 선정된 다른 노드들에게 자신의 멤버십 목록(박동 카운터 포함)을 전송
  • 수신한 노드는 더 큰 값의 박동 카운터가 있으면 자신의 멤버십 목록을 갱신
  • 특정 멤버의 박동 카운터가 일정 시간 동안 갱신되지 않으면 장애(offline) 로 판정

4-2) 장애 해소(failure resolution)

일시적 장애 처리

• 단서 후 임시 위탁 기법(hinted handoff)
  • 장애 노드가 쓰기를 받을 수 없을 때, 다른 노드가 대신 데이터를 저장
  • 장애 노드가 복구하면, 해당 데이터를 위탁 노드에서 넘겨받아 동기화
  • Dynamo, Cassandra에서 활용 → 일시적 네트워크 불안정에 효과적

영구 장애 처리

• 반-엔트로피(anti-entropy) 프로토콜
  • 장애 노드가 장시간 복구되지 않으면 다른 노드 간 사본 비교 및 동기화 필요
  • 단순 전체 복사 대신, Merkle Tree 같은 자료구조로 차이를 효율적으로 비교
  • Gossip 기반 동기화와 함께 사용 가능 → Eventually Consistency 달성

5) 시스템 아키텍처 다이어그램(Cassandra 참고)

5-1) 쓰기경로

1. 클라이언트 → 노드: 쓰기 요청
2. Commit Log: 먼저 디스크에 Append → 장애 시 복구 가능
3. Memtable: 메모리상에 데이터 기록 (쓰기 성능 향상)
4. Flush: Memtable이 가득 차면 SSTable로 디스크에 영구 저장

5-2) 읽기 경로

1. 클라이언트 → 노드: 읽기 요청
2. Memtable 조회: 메모리에서 최신 데이터 확인
3. Bloom Filter: 해당 키가 SSTable에 있는지 빠르게 확인
4. Partition Index: SSTable 내 위치 확인
5. SSTable 조회 후 병합: 여러 SSTable에서 데이터 가져와 병합
6. 응답 반환: 최종 결과를 클라이언트에게 전달

4. 레퍼런스

• https://docs.aws.amazon.com/whitepapers/latest/availability-and-beyond-improving-resilience/availability-and-beyond-improving-resilience.html
• https://ardalis.com/cap-pacelc-and-microservices/
• https://blog.bytebytego.com/p/cap-pacelc-acid-base-essential-concepts
• https://docs.datastax.com/en/cassandra-oss/3.x/cassandra/dml/dmlHowDataWritten.html

수평적 규모 확장성을 달성하기 위해서는 요청 또는 데이터를 서버에 균등하게 나누는 것이 중요하다
안정해시는 이를 달성하기 위해 보편적으로 사용하는 기술이다

1. 수평적 규모 확장이란?

• 단일 서버 성능을 올리는 수직적 확장(Scale-up)과 달리, 서버를 여러 대로 나누어 부하를 분산하는 것
• 균등하고 일관성 있는 데이터의 분산이 중요

2. 설계 관점에서의 서버 풀

2-1. 고정 서버 풀

• 서버 수가 늘거나 줄지 않는 전제
• 단순 해시(hash(key) % N)로도 충분
• 균등 분포만 잘 맞추면 문제 없음

2-2. 변동 서버 풀

• 현실 세계에서는 서버가 고정되지 않음:
  • 오토스케일링: 트래픽 스파이크 대응 위해 서버 증설/축소
  • 장애 대응: 서버가 죽으면 다른 서버로 재분배 필요
• 이때 단순 모듈러 해시는 풀 사이즈가 바뀌면 전체 키 매핑이 바뀌는 문제 발생 → 재배치 비용이 매우 큼

3. 데이터 분산 방식

3-1. 단순 해시(Uniform / Modulo Hashing)

• hash(key) % N (N = 서버 개수)로 분산
• 키를 해시함수로 충분히 무작위로 섞은 후, 탐색이나 검색 없이 즉시 도달하는 인덱싱 모델

    long x = XxHash64.hash(keyBytes, seed); // 1. 해시 알고리즘 실행(섞기)
    int  i = Math.floorMod(x, N);           // 2. 범위 축소(인덱스 뽑기)
    Server s = servers[i];                  //    해당 인덱스의 서버 선택

• 장점: 단순, 빠름, 균등 분배 가능
• Naive 해시(hash(key) % N) 방식의 가장 큰 약점:
  • 서버 수 N이 바뀌면 전체 키 매핑이 바뀜.
  • 대규모 키 재배치발생 → 캐시 미스, 데이터 불일치 문제
• 예: 서버 4대에서 5대로 확장 → 80% 이상의 키가 다른 서버로 이동

3-2. 안정 해시(Consistent Hashing)

• 키와 서버를 동일한 해시 공간 (원형 링, hash ring)에 매핑

• 각 키는 시계 방향으로 가장 가까운 서버에 할당

• 서버 추가/삭제 시 일부 키만 재배치 → 확장성, 장애 대응에 유리

• Redis Cluster, Cassandra, DynamoDB 같은 분산 시스템에서 사용

• 이미지 참고: https://medium.com/@sylvain.tiset/consistent-hashing-a-hash-ring-to-rule-them-all-ab1b3154e795

4. 실무에서 고려할 점

4-1. 해시 함수 선택

• 단순한 mod N 대신 어떤 해시 함수를 쓰느냐에 따라 분포 균등도가 달라짐
• MD5, SHA-1 같은 암호학적 해시 vs MurmurHash, xxHash 같은 비암호학적 고속 해시
• 분산 시스템에서는 충돌 최소화 + 속도 둘 다 중요

4-2. 가상 노드(Virtual Node, vnode)

• 안정 해시만 쓰면 서버 개수가 적을 때 분포 불균형 발생
• 각 서버를 여러 개의 가상 노드로 링에 배치하면 데이터 분포가 더 균등해짐

4-3. 서버 가중치(Weighted Consistent Hashing)

• 모든 서버가 같은 스펙은 아님 → CPU, 메모리, 디스크, 네트워크 성능 차이 존재
• 서버별 처리 능력에 따라 가중치 부여
• 가상 노드 개수 ∝ 서버 성능 으로 균형 잡음

4-4. 데이터 이동 비용 (Resharding Overhead)

• 서버 추가/삭제 시에도 일부 키는 이동해야 함
• 데이터 이동 과정에서 캐시 미스 폭증, 백엔드(DB) 부하 급증 가능
• 이를 줄이기 위해:
  • 백그라운드 점진적 마이그레이션
  • 더블 라이트(Double-write) 전략
  • 버전 기반 라우팅

4-5. 안정 해시와 CAP 정리

• 분산 환경에서 노드 장애 → 데이터 재배치 → 일관성(Consistency) 문제 발생
• Dynamo, Cassandra는 Eventual Consistency + 안정 해시 모델을 채택
• RDBMS 스타일의 Strong Consistency를 원하면 안정 해시 적용 범위에 제약 생김

1) Eventual Consistency란?

• 분산 시스템에서 모든 복제본(replica)이 즉시는 아니지만, 충분한 시간이 지나면 결국 동일한 상태로 수렴하는 일관성 모델
• CAP 이론에서 Availability(가용성)과 Partition Tolerance(분할 내성)을 우선할 때 주로 채택
• 강한 일관성(Strong Consistency)과 달리, 읽는 순간마다 최신 데이터를 보장하지 않는다

2) 동작 원리

• 쓰기 요청이 들어오면 모든 노드에 동시에 적용되지 않고, 먼저 도착한 일부 노드에서 처리됨
• 나머지 노드들은 비동기적 복제 / 동기화 프로세스를 통해 나중에 같은 데이터로 맞춰짐
• 결국 어느 시점에는 모든 복제본이 같은 값을 가지게 됨

  3) C.A.P

• Consistency (일관성) → 모든 노드가 같은 시점에 동일한 데이터를 보여준다
• Availability (가용성) → 모든 요청에 대해 항상 응답을 돌려줄 수 있다 (성공/실패 여부 무관)
• Partition Tolerance (분할 내성) → 네트워크가 분리(Partition)돼도 시스템은 계속 동작할 수 있다

4-6. 안정 해시 대안 기법

1) Rendezvous Hashing (HRW, Highest Random Weight)

• Consistent Hashing보다 간단하면서도 비슷한 재배치 성질
• 구글 GFS, Ceph, 일부 CDN에서 사용
  • 장점: 균등 분포, 구현 단순, Consistent Hashing보다 데이터 이동량이 더 적을 수 있음

2) Jump Consistent Hashing

• 구글이 제안, O(1) 시간 복잡도, 균등 분포 뛰어남
• Kafka, FoundationDB 같은 대규모 분산 시스템에서 채택

5. 운영 단계에서 해시와 안정 해시의 문제들

5-1. 데이터 분포 균등성 (Uniformity)

• 해시는 이상적으로 키를 균등하게 분배해야 함
• 하지만 실제 운영에서는 Hotspot Key / Celebrity Problem이 발생:
  • 예: 특정 사용자 ID(연예인 계정), 특정 해시 범위에만 트래픽 집중
• 안정 해시를 쓰더라도, 키 분포 자체가 편향되면 샤드 불균형은 피할 수 없음

해결 전략

• Sharding Key 설계: 고카디널리티(high cardinality) 키 선택
• Hash Salting: 키에 무작위성을 추가해 편향 완화
• Virtual Nodes (가상 노드): 한 물리 노드가 여러 해시 구간 담당 → 균등화

5-2. 노드 추가/삭제 시 데이터 재배치 비용

• 단순 해싱(Mod N) 방식:
  • 서버 수가 바뀌면, 전체 키의 대부분이 다른 서버로 이동 → 재배치 비용 큼
• 안정 해시:
  • 노드 추가/삭제 시, 해당 구간 일부 키만 이동 → 비용 최소화
• 그러나 재배치 자체는 여전히 비용:
  • TB 단위 데이터를 옮기는 데 수시간~수일
  • 그동안 읽기/쓰기 지연 발생

해결 전략

• Rebalancing Window: 트래픽이 낮은 시간대에 점진적 재분배
• Double Write: 재분배 기간 동안 두 노드에 동시에 기록해 일관성 유지
• Lazy Migration: 요청 시점에 필요한 키만 새로운 노드로 점진적으로 옮김

5-3. 데이터 일관성 (Consistency)

• 분산 해시 환경에서는, 노드 이동/장애 시 데이터 복제가 중요
• 안정 해시의 기본 구조는 N개의 인접 노드에 복제(replica) → Dynamo, Cassandra.
• 문제:
  • 네트워크 분할(Partition) → 일부 노드만 최신 데이터 보유
  • 복제본 간 충돌(conflict) 발생

해결 전략

• Quorum 기반 읽기/쓰기: W+R > N 보장 (예: 3개의 복제 중 2개 이상 성공해야 ack)
• Conflict Resolution: Last Write Wins, Vector Clock, CRDT 등
• Eventual Consistency 허용 여부 결정: 애플리케이션 성격 따라 선택

5-4. 장애 복구와 트래픽 우회

• 노드가 죽으면, 해당 구간 키 요청이 모두 장애로 이어짐

• 안정 해시는 바로 인접 노드로 우회 가능하지만, 실제 운영은 더 복잡:

  • 캐시/DB 미스율 폭발
  • 특정 노드로 트래픽 집중(2차 장애)

  해결 전략

• Replica 활용: 읽기는 다른 복제본에서 즉시 처리

• Auto-Rebalancing 제어: 장애 시 자동 리밸런싱을 막고, 임시 우회 후 복구 단계에서 이동

• Rate Limiting + Circuit Breaker: Failover 중 과부하 방지

5-5. 관측성과 모니터링

• 운영 시 가장 큰 문제 중 하나는 샤드 불균형을 조기에 탐지하지 못하는 것
• 해시 분포 문제는 지표로 드러남:
  • 샤드별 QPS, Latency, Storage Usage, Cache Hit Rate
• 안정 해시라고 해서 자동으로 "균등"이 보장되는 건 아님 → 반드시 모니터링 필요

핵심 지표

• 키 분포 균등도(Entropy)
• 샤드별 Hotspot 비율
• 재배치 중 지연 시간 증가율

5-6. 운영 환경에서의 설계 Trade-off

1) 서버 풀(Server Pool)의 고정 vs 변동

• 고정 풀: 서버 수가 잘 변하지 않으면, 단순 해싱(Mod N)도 가능 → 운영 단순
• 변동 풀: 클라우드 오토스케일링, 다중 데이터센터 환경이라면 → 안정 해시 필수

2) 데이터 분포

• 분포가 완전히 랜덤이라면 이상적 → 하지만 실제 키는 특정 패턴(사용자 ID, 지역, 시간대)에 따라 편향
• 해시 함수 선택, 키 설계가 중요

3) 안정 해시와 변형 기법

• Virtual Nodes: 균등화 보완
• Jump Hashing: O(1) 매핑, 대규모 클러스터 효율적
• Rendezvous Hashing: 데이터 이동량 최소화

1. 처리율 제한 장치

1-1. 의미

• 클라이언트 또는 서비스가 보내는 트래픽의 처리율을 제어하기 위한 장치
• 특정 기간 내에 전송되는 클라이언트의 요청 횟수 제한
  • 예시
    • 사용자는 초당 2회 이상의 새 글을 올릴 수 없음
    • 같은 IP 주소로는 하루에 10개 이상의 계정 생성 불가
    • 같은 디바이스로는 주당 5회 이상 리워드 요청 불가

1-2. API에 처리율 제한 장치를 두면 좋은점

• 악의적 공격에 의한 자원 고갈 방지 가능
  • DoS 공격뿐만 아니라, 무차별 대입 공격(Brute-force attack), 크리덴셜 스터핑(Credential stuffing) 등
  • 비용이 저렴하면서도 시스템에 치명적인 공격을 효과적으로 방어
  • 특정 IP나 계정의 비정상적인 요청 패턴을 초기에 차단 → 시스템 전체를 보호
• 비용 관리: 예측 가능한 인프라 운영
  • 인프라 자원의 상한선을 설정 → 예측 가능한 비용 내에서 서비스 운영 가능
  • 우선순위가 높은 핵심 API에 더 많은 리소스를 할당 → 전략적 자원 분배 가능
• 서버 과부하 방지
  • 봇 트래픽/잘못된 사용 패턴을 걸러내어 안정성 확보
  • 선량한 사용자들이 안정적으로 서비스를 이용할 수 있도록 트래픽을 제어 → 서비스의 전반적인 품질과 신뢰도를 높임

2. 프레임 워크

[1단계] 문제 이해 및 설계 범위 확정

[1-1] 면접관과의 소통을 통한 구현 기능 확인

[1-2]요구사항

• 설정된 처리율을 초과하는 요청은 정확하게 제한
• 낮은 응답 시간
• 가능한 한 적은 메모리 사용
• 분산형 처리율 제한(distributed rate limiting)
  • 하나의 처리율 제한 장치를 여러 서버나 프로세스에서 공유할 수 있어야 함
• 예외 처리
  • 요청이 제한되었을 때는 그 사실을 사용자에게 분명하게 보여주어야 함
• 높은 결함 감내성(fault tolerance)
  • 제한 장치에 장애가 생기더라도 전체 시스템에 영향을 주어서는 안됨

[2단계] 개략적 설계안 제시 및 동의 구하기

[2-1]처리율 제한 장치 배치 전략

(1) 클라이언트 측: X

• 요청 위변조 가능성 큼 → 신뢰 불가
• 모든 클라이언트 구현 통제 불가

(2) 서버 측

• 마이크로서비스 환경에서는 API Gateway가 압도적으로 유리
• 레거시 모놀리식에서는 미들웨어가 현실적 선택

[2-2]처리율 제한 알고리즘

• 토큰 버킷(token bucket)
• 누출 버킷(leaky bucket)
• 고정 윈도 카운터(fixed window counter)
• 이동 윈도 로그(sliding window log)
• 이동 윈도 카운터(sliding window counter)

[2-3]개략적인 아키텍처

• 카운터 단위: 사용자 / IP 주소 / API 엔드포인트
• 보관 장소: DB는 느림 → 메모리 캐시(Redis)가 적합
  • INCR와 EXPIRE로 원자적 증가 및 TTL 관리
  • Lua 스크립트 활용 시 읽기-쓰기-만료를 한 번에 처리 → 경쟁 조건 방지
  • TTL 만료 후 자동 삭제 → 메모리 관리 용이

[3단계] 상세 설계

[3-1]처리율 제한 규칙 (Rate Limiting Rules)

• 제한 단위: 사용자 ID, IP 주소, API Key, 엔드포인트, 디바이스 등
• 시간 윈도우: 초당, 분당, 시간당, 하루 단위 등
• 엔드포인트별 차등 제한:
  • 핵심 API → 높은 한도
  • 비용 큰 API → 낮은 한도
• 가중치 기반 제한:
  • 예: 단순 조회 = 1 요청, 복잡한 리포트 생성 = 10 요청

[3-2]한도 초과 트래픽 처리 (Over-limit Traffic Handling)

• HTTP 상태 코드 429 (Too Many Requests) 반환
• 헤더 노출:
  • X-RateLimit-Limit (총 한도)
  • X-RateLimit-Remaining (남은 요청 수)
  • X-RateLimit-Reset (초기화 시각)
  • Retry-After (재시도까지 대기 시간)
• Graceful Fallback:
  • 일부 기능 제한 (쓰기 차단, 읽기만 허용)
  • 캐시/대체 데이터 반환
• 큐잉 옵션 (Soft limit): 초과 요청을 버리지 않고 대기열에 넣어 순차 처리

[3-3]분산 환경에서의 처리율 제한 구현

(1) 경쟁 조건 (Race Condition)

• 여러 인스턴스가 동시에 같은 키 갱신 시 발생 가능
• 해결책
  • Redis INCR + EXPIRE 조합 (원자적 연산)
  • 복잡한 로직 → Lua 스크립트로 원자성 보장
  • 락

(2) 동기화

• Sticky Session: 동일 사용자가 항상 같은 서버로 → 단순하지만 확장성 제한
• 중앙 집중 저장소 (Redis, DynamoDB 등): 모든 인스턴스가 공유 → 분산 환경에 적합
• 최종 일관성(Eventual Consistency) 모델 허용 여부를 서비스 특성에 맞게 결정

(3) 성능 최적화

• 에지 서버에서 제한 적용 → 사용자와 가까운 곳에서 차단
• 로컬 캐시 버퍼링: 초단위 카운트는 로컬에서 관리, 일정 주기마다 Redis와 동기화

[3-4]모니터링 방안

• 모니터링을 통해 알고리즘의 효과성과 처리율 제한 규칙의 효과성 확인 가능

(1) 모니터링 지표

• 요청 처리율 (RPS)
• 거부율 (429 응답 비율)
• 응답 시간 (레이트 리미터 처리 지연 포함)
• 활성 키 수 (현재 추적 중인 유저/IP/토큰 개수)
• 시스템 리소스 (Redis CPU, 메모리, 연결 상태)
• 에러율 (Redis 장애, 타임아웃 등)

(2) 대시보드 예시

• API별 요청량/거부율 시각화
• 슬라이딩 윈도우별 평균 처리율 표시
• Redis 노드 상태/레플리카 동기화 상태

(3) 알림/자동화

• SLA 기준 초과 시 알람 발송
• 장애 발생 시 자동 롤백 / 오토스케일링 트리거

[4단계] 마무리

[4-1] 추가적으로 언급할 부분

(1) 정책 유형

• 경성 또는 연성 처리율 제한
  • 경성(Hard): 절대적인 임계치 제한
  • 연성(Soft): 초과 요청은 큐에 대기 또는 일부 기능만 제한
    • 예: 읽기는 되지만 쓰기는 차단

(2) 보안/안정성

• 계층형 방어 (Defense in Depth)

  • L4 (네트워크): iptables/firewall
  • L7 (게이트웨이): 전역 처리율 제한
  • 서비스: 비즈니스 로직별 제어
  • 리소스: DB connection pool, thread pool

• 동적 임계값 조정

  • 트래픽 상황에 따라 한도를 자동 상향/하향 조정 → 예측 불가한 스파이크 완화

(3) 사용자 경험 최적화

• 응답 헤더 제공 (X-RateLimit-Limit, X-RateLimit-Remaining, X-RateLimit-Reset)

• 제한 시 429와 함께 안내 메시지, Retry-After 제공

• 클라이언트가 자체적으로 요청을 조절할 수 있도록 지원

• HTTP/1.1 429 Too Many Requests
  X-RateLimit-Limit: 1000
  X-RateLimit-Remaining: 0  
  X-RateLimit-Reset: 1640995200
  Retry-After: 60
  
  {
    "error": "rate_limit_exceeded",
    "message": "API rate limit exceeded",
    "retry_after_seconds": 60
  }

(4) 클라이언트 설계 패턴

• 클라이언트 측 캐시 활용 → API 호출 횟수 감소
• 백오프(특히 지수 백오프)로 재시도
• 임계치 이해 및 graceful fallback 구현

3. 참고

3-1. 지수 백오프 (Exponential Backoff)

(1) 정의

• 네트워크 요청이 실패했을 때, 재시도 간격을 지수적으로 증가시키며 재시도하는 전략.
• 예: 1초 → 2초 → 4초 → 8초 … 처럼 대기 시간이 점점 길어짐.

(2) 목적

• 트래픽 폭주 방지: 많은 클라이언트가 동시에 무한 재시도를 하면 서버가 더 빨리 다운됨 → 백오프는 재시도를 분산시켜 서버 회복 시간을 벌어줌
• 시스템 안정성 확보: 재시도 간격을 늘려 네트워크나 서버의 일시적 부하 완화
• 비용 절감: 불필요한 실패 요청을 줄여 서버 리소스와 네트워크 비용 절약

(3) 실무적 특징

• 보통 지수 증가 + 랜덤 지터(jitter)를 함께 사용
  • 단순 지수 증가만 하면 클라이언트들이 동시에 재시도하는 “스파이크(동기화 폭주)” 발생 가능
  • → 지터를 넣어 2초 ~ 3초, 4초 ~ 6초 범위 안에서 랜덤 대기 → 동기화 회피
• 많이 쓰이는 곳: AWS SDK, Google Cloud API, TCP 네트워크 재전송 로직

3-2. Graceful Fallback

(1) 정의

• 시스템이 장애나 제한 상황에 직면했을 때, 완전히 실패하지 않고 축소된 기능이나 대체 경로를 제공하는 전략
• 즉, “최소한의 경험”을 보장하는 방식

(2) 목적

• 사용자 경험 보호: 서비스 전체가 죽는 대신, 일부 기능만 제한적으로 제공
• 안정성 강화: 특정 리소스(DB, API)가 장애나 Rate Limit에 걸려도 서비스의 핵심 기능은 계속 동작
• 신뢰 확보: “완전 불가” 대신 “부분적 가능”을 제공 → 서비스에 대한 신뢰감 유지

(3) 실무적 특징

• 예시
  • 트위터: API Rate Limit 초과 시, 최근 트윗 캐시를 보여주고 새 트윗은 잠시 불가
  • 전자상거래: 추천 서비스 장애 시, 기본 베스트셀러 목록 제공
  • 동영상 스트리밍: 서버 부하 시, 저화질 영상으로 자동 전환
• Graceful Fallback은 단순한 에러 메시지(“서버 다운”)가 아니라, 대체 데이터/기능을 제공하는 점이 핵심

1. 시스템 설계 면접의 의미

• 시스템 설계 면접은 두 명의 동료가 모호한 문제를 풀기 위해 협력하여 그 해결책을 찾아내는 과정에 대한 시뮬레이션

• 면접은

  • 설계 기술을 시연하는 자리
  • 설계 과정에서 내린 결정들에 대한 방어 능력을 보이는 자리
  • 면접관의 피드백을 건설적인 방식으로 처리할 자질이 있음을 보이는 자리

• 면접관이 면접자에게 평가하고자 하는 부분

  • 지원자의 설계 능력의 기술적 측면
  • 협력
  • 압박
  • 문제 해결 능력
  • 좋은 질문을 던질 능력
  • 부정적 신호
    • 타협적 결정 도외시, 과도한 엔지니어링, 완고함, 편협함 등

2. 효과적인 면접을 위한 4단계 접근법

1단계. 문제 이해 및 설계 범위 확정: 요구사항을 이해하고 모호함을 없애는 것

(1) 엔지니어가 가져야 할 가장 중요한 기술

• 올바른 질문을 하는 것 / 적절한 가정을 하는 것 / 시스템 구축에 필요한 정보를 모으는 것
• 예시
  • 구체적으로 어떤 기능들을 만들어야 하나?
  • 제품 사용자 수는 얼마나 되나?
  • 회사의 규모는 얼마나 빨리 커지리라 예상하나?(석 달, 여섯 달, 일년 뒤의 규모는 얼마나 되리라 예상하는가?)
  • 회사가 주로 사용하는 기술 스택은 무엇인가?
  • 설계를 단순화하기 위해 활용할 수 있는 기존 서비스로는 어떤 것들이 있는가?

(2) 예제 - 뉴스 피드 시스템 설계

• 구체적으로 어떤 기능들을 만들어야 하나?

  • 모바일 앱과 웹 앱 가운데 어느 쪽을 지원? 아니면 둘 다?
  • 가장 중요한 기능?
  • 뉴스 피드의 정렬 기준은? 피드에 올라갈 포스트마다 다른 가중치가 부여되어야 하는 지?
  • 피드의 형식은 텍스트? 이미지나 비디오도 포함 가능?

• 제품 사용자 수는 얼마나 되나?

  • 한 사용자는 최대 몇 명의 사용자와 친구를 맺을 수 있는가?
  • 사이트로 오는 트래픽 규모는 어느 정도 되는가?

2.단계. 개략적인 설계안 제시 및 동의 구하기

(1) 개략적 설계안 제시하고 면접관 의견 청취

• 설계안에 대한 최초 청사진 제시 및 의견 구하기
  • 면접관을 팀원인 것처럼 대하기
• 화이트 보드나 종이에 핵심 컴포넌트를 포함하는 다이어그램 그리기
  • 클라이언트(모바일/웹), API, 웹 서버, 데이터 저장소, 캐시, CDN, 메세지 큐 등 포함
• 최초 설계안이 시스템 규모에 관계된 제약 사항들을 만족하는 지 개략적으로 계산
  • 계산 과정은 소리내어 설명
  • 개략적 추적이 필요한 지는 면접관에게 미리 물어보기
• 시스템의 구체적 사용 사례 살펴 보기
  • 개략적 설계안을 잡아 나가는데 도움이 됨
  • 미처 고려하지 못한 에지 케이스 발견에도 도움 됨
• API 엔드포인트나 데이터베이스 스키마도 보여야 하는가?
  • 질문에 따라 다르다. 면접관의 의견을 구하라

(2) 예제

설계의 흐름

개략적으로 봤을 때 이 설계는 두 가지 플로우로 나눠 생각해볼 수 있다

• 피드 발행(feed publishing)
  • 사용자가 포스트를 올리면 관련된 데이터가 캐시/DB에 기록되고, 해당 사용자의 친구 뉴스 피드에 뜨게 됨
• 피드 생성(feed building)
  • 어떤 사용자의 뉴스 피드는 해당 사용자 친구들의 포스트를 시간 역순으로 정렬하여 만듦

설계 흐름도

• 피드 발행

• 피드 생성

3단계. 상세 설계: 설계 대상 컴포넌트 사이의 우선순위 선정

(1) 상세 설계 시작 전 달성한 상태

• 시스템에서 전반적으로 달성해야 할 목표와 기능 범위 확인
• 전체 설계의 개략적 청사진 마련
• 해당 청사진에 대한 면접관의 의견 청취
• 상세 설계에서 집중해야 할 영역들 확인

(2) 설계 대상 컴포넌트 사이의 우선 순위 정하기

• 시스템 성능 특성에 대한 질문의 경우, 질문 내용은 시스템 병목 구간이나 자원 요구량 추정치에 초점이 맞춰져 있을 것
• 대부분의 면접관은 특정 시스템 컴포넌트들의 세부 사항을 깊이 있게 설명하는 것을 보고 싶어 함
  • 예시
    • URL 단축기 설계: 해시 함수의 설계
    • 채팅 시스템: 지연시간을 줄이는 설계, 사용자의 온/오프라인 상태 표시에 관한 설계
• 시간 관리: 사소한 세부사항이 아니라 규모 확장 가능한 시스템을 설계할 능력이 있다는 것을 입증할만한 사항에 시간을 쓰기

(3) 예제

• 뉴스 피드 설계에서 우선순위가 높은 컴포넌트 선정

  • 피드 발행(feed publishing)
  • 뉴스 피드 가져오기(news feed retrieval)

• 피드 발행

• 뉴스 피드 가져오기

4단계. 마무리

(1) 지침 활용

• 시스템 병목 구간 혹은 좀 더 개선 가능한 지점 파악
  • 개선할 점은 언제나 있음
  • 비판적 사고 능력을 보이고, 마지막으로 좋은 인상을 남길 기회
• 만든 설계를 다시 한번 요약하면 면접관의 기억을 환기시켜줌
  • 특히 여러 해결책을 제시한 경우 중요함
• 오류 발생 시 발생이 예상되는 일
  • 서버 오류, 네트워크 장애
• 운영 이슈
  • 메트릭은 수집 방법, 모니터링 방법, 로깅 방법, 배포 방법 등
• 미래에 닥칠 규모 확장 요구에 대한 대처
• 필요하지만 다루지 못했떤 세부적 개선 사항들 제안

(2) 면접장에서 해야 할것

• 질문을 통한 확인
• 문제의 요구사항 이해
• 면접관이 내 사고의 흐름을 이해할 수 있도록 면접관과 소통
• 가능하다면 여러 해법을 함꼐 제시
• 개략적 설계에 면접관이 동의하고 난 후, 가장 중요한 컴포넌트부터 각 컴포넌트의 세부사항 설명 시작
• 면접 관의 아이디어를 이끌어 내며 마치 면접관과 팀원인 것처럼 협력

(4) 하지 말아야 할 것

• 요구 사항이나 가정들이 분명하지 않은 상태에서 설계 제시
• 처음부터 특정 컴포넌트의 세부사항을 너무 깊이 설명하는 것
  • 개략적 설계를 마친 뒤 세부사항으로 나아갈 것
• 진행 중에 막혔다면 힌트를 요청할 것
• 면접관의 의견을 일찍, 그리고 자주 구할 것

3. 시간배분

3-1. 면접 시간이 45분이라면?

(1) 단계별 시간 배분

(2) 단계별 시간 배분 비율(45분 기준, 평균 값)

1. 개략적인 규모 추정(back-of-the-envelope estimation)

• 보편적으로 통용되는 성능 수치상에서 사고실험(thought experiments)을 행하여 추정치를 계산하는 행위
• 어떤 설계가 요구사항에 부합할 것인지 보기 위한 것

2. 규모 확장성을 표현하는 데 필요한 수치들

2-1. 데이터 볼륨 단위

2-2. 지연 시간(Latency)

• 제프 딘(Jeff Dean), 통상적인 컴퓨터에 구현된 연산들의 응답 지연 값

(1) 메모리 & CPU (ns 단위)

(2) 스토리지 (ms 단위)

(3) 네트워크 (ms 단위)

(4) 대역폭 (Bandwidth)

2-3. 가용성 관련 수치들

(1) 고가용성(High Availability, HA)

• 시스템이 오랜 시간 동안 지속적으로 중단 없이 운영될 수 있는 능력을 지칭하는 용어

• 퍼센트로 표현

• 대부분의 서비스는 99~100%사이의 값을 가지며, 단 한번도 중단된 적이 없었을 경우 100%

• 일반적인 가용성(Availability) 공식 $$ \text{가용성} = \frac{\text{총 시간} - \text{장애 시간}}{\text{총 시간}} $$

• SLA(Service Level Agreement)

  • 서비스 사업자가 보장하는 가용성 수준(uptime)을 계약서에 명시한 것

  • 아마존, 구글 등의 사업자는 99% 이상의 SLA 제공

  • 가용시간은 관습적으로 숫자 9를 사용해 표시하며, 9가 많을수록 좋음

(2) 가용성과 다운타임 허용치

3. 수치의 의미

3-1. 응답 지연 시간 관련

• 메모리는 디스크에 비해 빠름
• 디스크 탐색은 가능한 회피하는 것이 좋음
• 단순한 압축 알고리즘은 빠름
• 데이터를 인터넷으로 전송하기 전에 가능하면 압축할 것
• 데이터 센터는 보통 여러 지역에 분산되어 있고, 센터들 간에 데이터를 주고받는 데는 오랜 시간이 걸림

3-2. 가용성 관련

• 1 nine (90%): 하루 중 2시간 이상 멈춰도 허용 → 사실상 실무 서비스 불가능
• 3 nines (99.9%): 흔히 SaaS나 클라우드 기본 SLA → 연간 9시간 이내 장애 허용
• 5 nines (99.999%)*: “Carrier Grade” → 연간 5분 이내 장애만 허용 (통신사, 금융)
• 9의 개수가 하나 늘 때마다 허용 장애시간이 10배씩 줄어듦

4. 예제: 트위터 QPS와 저장소 요구량 추정

4-1. 가정

• 월간 능동 사용자는 3억명
• 50% 사용자가 트위터를 매일 사용
• 평균적으로 각 사용자는 매일 2건의 트윗 업로드
• 미디어를 포함하는 트윗은 10% 정도
• 데이터는 5년간 보관됨

4-2. 문제

• QPS 추정치
• 미디어 저장을 위한 저장소 요구량

4-3. 풀이

• QPS 추정치
  1. 일간 능동 사용자(DAU) 계산
     • 3억 * 50% = 1.5억
  2. QPS 계산
     • 1.5억 * 2 트윗 / 24 /3600초 = 약 3,500
  3. 최대 QPS(peek QPS) 계산
     • 2 * QPS = 약 7,000
• 저장소 요구량
  1. 평균 트윗 크기
     • 트윗 id: 64바이트
     • 텍스트: 140 바이트
     • 미디어: 1MB
  2. 미디어 저장소 요구량
     • 1.5억 * 2트윗 * 10% * 1MB = 30TB/일
  3. 5년간 미디어를 보관하기 위한 저장소 요구량
     • 30TB/일 * 365일 * 5년 = 약 55PB

5. 면접 팁

• 근사치를 활용한 계산: 계산 결과의 정확함 < 적절한 근사치 활용을 통한 시간 절약
• 가정들은 나중에 살펴볼 수 있도록 작성해두기
• 단위를 붙이는 습관을 들여 모호함 방지
• 자주 출제되는 문제 유형
  • QPS 추정
  • 최대 QPS 저장소 요구량 추정
  • 캐시 요구량 추정
  • 서버 수 추정

10-1. 수직적 확장(Scale-Up)

(1) DB 스케일업 개념

• 단일 DB 인스턴스의 하드웨어 성능을 키우는 방식
• 더 빠른 CPU, 더 많은 RAM, 더 빠른 스토리지(예: NVMe), 고사양 인스턴스로 교체

(2) DB 스케일업 장점

• 설계·구현 단순, 애플리케이션 코드 수정 최소화
• 강한 일관성(ACID) 유지, 조인·트랜잭션 친화적
• 기존 RDB 기능 그대로 활용 가능

(3) DB 스케일업 단점

• 하드웨어 한계 존재 (성능/용량의 물리적 상한선 존재)
• 고사양 인스턴스로 갈수록 비용 급증
• 단일 장애 지점(SPOF) → 장애 시 서비스 전체 중단

(4) DB 스케일업 전략 구현 시 고려할 점

• 병목 자원 정확히 진단 (CPU, 메모리, 디스크 I/O, 락 경합)
• 무중단 업그레이드 시나리오(리플리카 승격, 스토리지 분리) 마련
• 읽기 전용 레플리카, 캐시 병행 사용해 수명 연장

(5) DB 스케일업 전략 도입 시 고려할 점

• 데이터·트래픽 성장 곡선이 단일 인스턴스 범위 내에서 감당 가능한지
• 다운타임 허용도와 예산
• 팀이 단순성을 선호하고, 트랜잭션·조인이 많은 워크로드인지

10-2. 수평적 확장(Sharding / Scale-Out)

(1) DB 샤딩 개념

• 데이터를 파티션(샤드) 으로 나누어 여러 DB 노드에 분산 저장/처리
• 각 샤드는 전체 데이터의 일부만 보유(수평 분할)
• 라우팅 키(샤딩 키)에 따라 쿼리를 특정 샤드로 전달

(2) DB 샤딩 장점

• 수평 확장성: 노드 추가로 용량·처리량이 거의 선형적으로 증가
• 쓰기 처리량 개선: 여러 샤드 병렬 처리
• 장애 격리: 특정 샤드 장애 시 전체 장애로 확산되지 않음

(3) DB 샤딩 단점

• 복잡성 증가: 샤딩 키 설계, 라우팅 계층, 운영 관리 모두 난이도↑
• 조인·트랜잭션 제약: 크로스샤드 조인 어려움 → 애플리케이션/비정규화로 보완
• 운영 부담: 백업/복구, 모니터링도 샤드 단위로 관리

(4) DB 샤딩 약점

• Resharding: 샤드 추가·분할·병합 시 데이터 재분배 → 온라인 마이그레이션 난이도 ↑
• Celebrity Problem: 특정 샤딩 키(예: 인기 연예인 ID)에 트래픽 집중 → 특정 샤드 과부하
• Hotspot Key: 특정 범위/키에만 쓰기 집중 → 불균형 발생
• 샤드 소진: 균등 분할했으나 특정 샤드가 먼저 용량 한계 → 리밸런싱 필요(안정 해시(Consistent Hashing)기법 활용해 리밸런싱 비용 최소화)
• 조인 문제: 크로스샤드 조인 시 성능 저하 → 비정규화/중복 데이터로 대체

(5) DB 샤딩 전략 구현 시 고려할 점

• 샤딩 키 설계: 고카디널리티, 균등 분포, 액세스 패턴 친화적
  • Celebrity/Hotspot 방지: 해시 샤딩, 샤딩 키 솔팅 활용
• Resharding 계획: 온라인 재분배, 더블라이트(이중 쓰기), 안정 해시 적용
• 크로스샤드 트랜잭션 회피: 필요 시 2PC(이중 커밋), 사가(Saga) 패턴
• 데이터 모델링: 조인 최소화 → 비정규화, CQRS/Event Sourcing 병행
• 관측: 샤드별 모니터링(QPS, 지연, 히트율, 용량), 핫 샤드 탐지

(6) DB 샤딩 전략 도입 시 고려할 점

• 데이터·트래픽 성장 곡선 (단일 노드 한계 도달 시점)
• 팀의 운영 역량 (샤딩 운영 복잡성 감당 가능 여부)
• 일관성 요구 수준 (Strong vs Eventual Consistency)
• 비용 모델 (고성능 단일 인스턴스 vs 다수 중소형 노드)
• 지리적 분산 요구 (멀티 리전/글로벌 서비스라면 샤딩 적합)

시스템 규모 확장을 위한 기법들

시스템의 규모를 확장하는 것은 지속적이고 반복적(iterative)인 과정이다

수백만 사용자 이상을 지원하려면 새로운 전략을 도입해야 하고 지속적으로 시스템을 가다듬어야 할 것이다

- 웹 계층: 무상태

- 모든 계층에 다중화 도입

- 가능한 한 한 많은 데이터 캐싱

- 여러 데이터 센터 지원

- 정적 콘텐츠은 CDN을 통해 서비스

- 데이터 계층은 샤딩을 통해 규모 확장

- 각 계층은 독립적 서비스로 분할

- 시스템의 지속적인 모니터링 및 자동화 도구 활용

6-1. 상태 의존적 웹 아키텍처

6-2. 무상태 웹 아키텍처

참고 - 배포방식

6-3. 최종 설계

7. 데이터 센터

7-1. 데이터 센터 (DC; Data Center)

(1) 정의

• 서버, 스토리지, 네트워크 장비, 전력/냉각 인프라를 집약해 대규모 IT 서비스를 운영하는 시설

(2) 역할

• 대규모 서비스의 안정성·확장성·보안 확보
• 클라우드(IaaS/PaaS/SaaS) 기반 물리적 토대

(3) 특징

• 이중화(전력, 네트워크, 스토리지 등)
• 보안성(물리/네트워크/운영)
• 확장성(랙 단위/리전 단위 확장)

(4) 실제 예시

• 구글 클라우드 리전 (미국·유럽·아시아) → YouTube, Gmail 서비스 기반
• AWS 서울 리전(ap-northeast-2) → 쿠팡, 네이버 일부 서비스 운영
• 네이버 데이터 센터 ‘각’ (춘천) → 친환경 냉각 활용
• 카카오 데이터 센터 ‘안산’ → 카카오톡, 카카오뱅크 인프라 운영

7-2. 지리적 라우팅 (Geo Routing / Geo DNS Routing)

(1) Geo Routing 정의

• 사용자의 지리적 위치(IP, DNS 질의 위치)에 따라 가장 가까운 데이터 센터 또는 CDN PoP로 트래픽을 분산시키는 기법.

(2) Geo Routing 방식

• GeoDNS: DNS 레벨에서 질의 위치 기반으로 IP 응답
• Anycast: 동일 IP를 여러 지역에서 광고 → 라우팅 프로토콜(BGP)이 가장 가까운 경로 선택

(3) Geo Routing 목적

• 지연(latency) 최소화
• 지역별 트래픽 부하 분산
• 특정 리전 장애 시 자동 우회 (Failover)

(4) 실제 예시

• Cloudflare Anycast 네트워크 → 전 세계 어디서든 동일 IP로 접속 시 가까운 POP 응답
• AWS Route 53 → 서울 사용자 요청은 서울 리전, 미국 사용자는 버지니아 리전으로 라우팅

7-3. 다중 데이터 센터 아키텍처 (Multi-Data Center Architecture)

(1) Active-Passive

• 하나의 센터만 Active, 다른 하나는 대기 상태
• 장애 시 Failover
• 예시: 금융권 DR 센터(재해복구 전용 데이터 센터)

(2) Active-Active

• 여러 데이터 센터가 동시에 트래픽 처리
• 지리적 라우팅으로 사용자 근처 센터에 연결
• 예시: Netflix → AWS 다중 리전에서 동시에 스트리밍 서비스 제공

(3) Hybrid

• 읽기 요청은 지역별 센터에서 처리, 쓰기 요청은 특정 리전으로 집중
• 예시: 글로벌 전자상거래 서비스(상품 조회는 현지 리전, 결제는 중앙 리전)

7-3. 고려사항 & 기술적 난제

(1) 트래픽 우회 (Traffic Routing & Failover)

고려할 점

• 사용자를 어떤 데이터센터(리전)으로 라우팅할 것인가?

  장애 발생 시, 다른 센터로 신속하게 우회(Failover) 가능한가?

  정상 복구(Failback) 시 데이터 일관성을 어떻게 맞출 것인가?

기술적 난제

• DNS 기반 라우팅: TTL 캐싱으로 인해 우회 반영 지연

  GeoDNS: 단순히 지리적 위치만 고려 → 실제 부하/장애 반영 한계

  Anycast: 가장 가까운 경로 선택은 가능하나, 세밀한 트래픽 제어 불가

  실시간 헬스체크 + 글로벌 로드밸런서 필요 → 구현 복잡

(2) 데이터 동기화 (Data Synchronization)

고려할 점

• 여러 데이터센터에 걸친 DB·캐시·세션을 어떻게 동기화할 것인가?

  강한 일관성을 보장할지, 최종 일관성을 허용할지?

  충돌(conflict) 발생 시 해결 방법은 무엇으로 할지?

기술적 난제

• 관계형 DB: 글로벌 트랜잭션 동기화 시 지연(latency) 증가, 성능 저하
• NoSQL / 분산 DB: 최종 일관성(Eventual Consistency) 허용 시 충돌 발생 가능
• 세션/캐시: 리전 분리 시 단순하지만, 글로벌 공유는 복잡도↑
• Conflict Resolution 필요 → Last Writer Wins, CRDT, Vector Clock 등

(3) 테스트 & 배포 (Testing & Deployment)

고려할 점

• 새 버전 배포 시, 모든 리전에 동시에 적용해야 할까?
• 일부 리전에만 배포해 안전성을 검증할 수 있을까? (카나리 방식)
• 다중 리전 배포 실패 시 롤백 전략은 무엇인가?

기술적 난제

• 배포 동기화: 모든 리전에 동일 버전·설정을 유지하는 것 자체가 어려움
• 카나리 배포: 특정 리전(일부 사용자 그룹)에만 새 버전 적용 → 글로벌 환경에서 트래픽 분리 어려움
• 블루-그린: 리전 단위 환경 전환은 가능하나, 비용·운영 부담 큼
• 데이터 스키마 변경: 순차 적용 과정에서 리전 간 불일치 발생 가능

8. 메세지 큐

8-1. 개념

• 메세지의 무손실(durability)을 보장하는, 프로세스나 서비스 간의 비동기 통신(Asynchronous Communication)을 지원하는 소프트웨어 컴포넌트
• 생산자(Producer)가 메시지를 큐에 넣고, 소비자(Consumer)가 이를 꺼내 처리하는 구조

8-2. 역할

8-3. 작동 방식 (흐름)

1. 생산자(Producer)
   • 처리할 작업/데이터를 메시지 형태로 큐에 전송(Publish/Send)
2. 메세지 큐 (Broker)
   • 메시지를 안전하게 저장
   • 메시지 전달 보장 방식 적용 (At-most-once, At-least-once, Exactly-once)
   • 메시지를 Consumer에게 전달
3. 소비자(Consumer)
   • 큐에서 메시지를 가져와 처리(Subscribe/Consume)
   • 처리 완료 후 ACK(확인 응답)를 보내면 큐에서 메시지 삭제

9. 로그, 메트릭 그리고 자동화

9-1. 사업 규모 확장 시 투자해야 할 도구들

9-2. 메세지 큐, 로그, 메트릭, 자동화 등을 반영하여 수정한 최종 설계

• 모든 컴포넌트가 하나의 서버에서 실행되는 간단한 시스템 설계
• 웹, 앱, DB, 캐시 등이 전부 서버 한 대에서 실행됨

1-1. 사용자 요청이 처리되는 과정

2. DB

2-1. DB 분류와 선택 기준

(1) 관계형 DB와 비관계형 DB 비교

(2) 비관계형 DB(No SQL)

No SQL의 분류

• 키-값 저장소(key-value store)
• 그래프 저장소(graph store)
• 칼럼 저장소(column store)
• 문서 저장소(document store)

No SQL이 바람직한 경우

• 아주 낮은 응답 지연 시간이 요구됨
• 다루는 데이터가 관계형 데이터가 아닌 비정형 데이터인 경우
• 데이터를 직렬화(serialize)/역직렬화(deserialize) 할 수 있기만 하면 됨
• 대량의 데이터를 저장하는 경우

3. 규모 확장의 방향(수직적/수평적)

3-1. 수직적 규모 확장(스케일 업) VS 수평적 규모 확장(스케일 아웃)

스케일 업의 단점

• 규모 확장에 한계 존재
• 장애에 대한 자동 복구(failover) 방안이나 다중화(redundancy) 방안 제시 X
  • 즉, 서버에 장애 발생 시 웹/앱은 완전히 중단됨

3-2. 로드 밸런서

• 부하 분산 집합(load balancing set)에 속한 웹 서버들에게 트래픽 부하를 고르게 분산하는 역할

(1) 사용자 요청이 처리되는 과정

1. 사용자는 로드밸런서의 공개 IP 주소로 접속
2. 서버 간 통신에는 사설 IP 주소가 이용됨

(2) 웹 계층의 가용성 향상

• 서버 1 다운 시, 모든 트래픽은 서버 2로 전송
• 웹 사이트로 유입되는 트개픽 증가 시 웹 서버 계층에 더 많은 서버만 추가하면 로드 밸런서가 자동으로 트래픽 분산 시작

3-3. 데이터 다중화

• 보통 서버 사이에 주(master)-부(slave) 관계를 설정하고 데이터 원본은 주 서버, 사본은 부 서버에 저장하는 방식(Master-Slave 패턴)
  • 쓰기 연산은 마스터에서만 지원
  • 부 DB는 마스터로부터 사본을 전달받으며, 읽기 연산만 지원
• 대부분의 앱에서는 읽기 연산 비중 > 쓰기 연산 비중 → 부 DB 수 > 주 DB 수

(1) 데이터 다중화의 이점

(2) 데이터 다중화 아키텍처 패턴

• Master–Slave: 단일 쓰기 지점, 읽기 분산 (구현 단순, 장애 시 Failover 필요)
• Multi-Master: 모든 리전 쓰기 가능 (충돌 해결 필요, 고난도)
• Hybrid: 읽기는 로컬, 쓰기는 중앙 집중 (지연 최소화, 복잡도 증가)

(3) 데이터 복제 방식

• 동기(Sync): 모든 리전에 쓰기 반영 후 확정 → 일관성↑, 지연↑
• 비동기(Async): 로컬만 확정, 다른 리전은 나중에 반영 → 성능↑, 최종 일관성
• 반동기(Semi-sync/Quorum): 일부 리전만 확인 후 확정 → 절충안

3-4. 최종 설계

1. 사용자는 DNS로부터 로드밸런서의 공개 IP를 응답 받음
2. 사용자는 IP 주소를 사용해 로드밸런서 접속
3. HTTP 요청이 서버 1 또는 서버 1로 전달됨
4. 웹 서버는 사용자 데이터를 부 DB 서버로부터 읽음
5. 웹 서버는 데이터 변경 연산은 주 DB로 전달

4. 캐시(응답시간 개선)

4-1. 캐시의 정의

• 자주 접근되거나 비용이 큰 데이터를 더 빠른 저장소에 일시적으로 보관해 두어 성능을 높이고 원본 자원(DB, API 등)의 부하를 줄이는 계층

4-2. 캐시의 목적

• 성능 개선
• DB 부하 감소
• 비용 절감
• 확장성 확보

4-3. 캐시의 핵심 속성

(1) 임시 저장소 (Temporary Storage)

• 캐시는 데이터의 사본을 보관할 뿐, 원본 저장소(DB, 파일, API)가 따로 존재
• 따라서 캐시 데이터는 언제든 무효화(invalidate)되거나 손실될 수 있음

(2) 빠른 접근 (Low Latency)

• 목표: 원본보다 빠른 접근
• 예: 메모리(RAM)에 데이터를 두어 디스크 I/O를 피함, 가까운 지역(에지)에 두어 네트워크 왕복을 줄임

(3) 투명성 (Transparency)

• 이상적으로는 애플리케이션이 캐시 유무를 의식하지 않고도 동작할 수 있어야 함
• 다만 Cache-Aside 패턴처럼 앱에서 직접 제어하는 경우도 많음

(4) 일관성 문제 (Consistency Trade-off)

• 캐시가 원본 DB와 항상 동일하다고 보장되지는 않음
• TTL(Time-to-Live), 무효화 정책, 쓰기 전략(Write-through, Write-back 등)을 통해 균형을 맞추어야 함

4-4. 캐시 전략

4-5. 읽기 주도형 캐시전략(read-through caching strategy)

4-6. 캐시 사용 시 고려할 점

(1) 캐싱 적합성

• 캐시하기 적합한 데이터

  • 자주 조회되는 데이터(Hot Data) → 반복 접근으로 히트율↑
  • 조회 비용이 큰 데이터 → DB I/O, CPU 사용량 절감 효과 큼 (예: 복잡한 조인, 대규모 집계, 외부 API 호출 결과)

  캐싱이 부적합한 데이터

  • 항상 최신 상태가 보장되어야 하는 데이터 (예: 은행 잔액, 실시간 재고) → 캐시 지연으로 인한 불일치 허용 불가
  • 영구적으로 보관해야 하는 데이터 → 캐시는 본질적으로 임시 저장소이므로 적합하지 않음

(2) 만료/무효화 정책

• TTL(Time-To-Live) 설정
  • 짧은 TTL: 데이터 신선도 보장 ↑, 하지만 캐시 미스율↑ → DB 부하 증가
  • 긴 TTL: 히트율↑, DB 부하 ↓, 하지만 오래된(stale) 데이터 제공 가능성↑
  • 핵심: 데이터 신선도 vs 효율성의 트레이드오프

(3) 일관성 유지

• 일관성 모델

  • 최종 일관성(Eventual Consistency): 대부분 서비스에서 허용 가능
  • 강한 일관성(Strong Consistency): 일부 요청은 반드시 DB에서 조회 필요

  불일치 가능성

  • DB와 캐시 갱신이 단일 트랜잭션에 묶이지 않으면 불일치 발생 가능
  • 해결책:
    • TTL 기반 자연 갱신
    • 쓰기 시 무효화
    • 이벤트 기반 캐시 업데이트

(4) 장애 내성

• SPOF(Single Point Of Failure)
  • 캐시 서버가 단일 노드라면 장애 시 전체 서비스 영향
  • 분산 배치(멀티 노드, 멀티 AZ/리전) 필요
• 캐시 장애 시 대응 전략
  • 캐시 장애 → 모든 요청이 DB로 몰릴 때, DB가 감당 가능한지 고려
  • Graceful Degradation: 캐시를 건너뛰고 DB fallback
  • TTL 무시, 일시적 stale 데이터 허용 등으로 완충 가능

(5) 메모리 할당 용량

• Underprovision (메모리 부족)

  • 캐시 항목이 자주 퇴출(eviction)됨
  • 캐시 히트율 저하 → 캐시 효과 상실

  Overprovision (메모리 과다 할당)

  • 데이터 오래 유지 가능 → 히트율↑, 트래픽 급증 대응 가능
  • 단점: 비용/자원 낭비
  • 일부 이론적 관점에서는 캐시의 “완충(buffer)” 역할을 중시하여 의도적 오버프로비저닝 권장

  용량 산정

  • (평균 객체 크기 × 예상 동시 보존 수) + 여유분
  • 실제 필요량보다 20~50% 여유를 두는 방식도 존재

(6) 퇴출 정책(Eviction Policy)

• LRU (Least Recently Used): 가장 오래 참조되지 않은 항목 제거 → 일반적, 균형적
• LFU (Least Frequently Used): 참조 횟수 기반 제거 → 반복적 Hot Data에 최적
• TTL 우선: 만료 시간이 지난 데이터부터 제거 → 최신성 보장에 유리
• Random: 임의 항목 제거 → 단순 구현, 하지만 효율성 낮음

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

5-1. CDN의 정의

• 지리적으로 분산된 여러 노드(에지 서버, PoP: Point of Presence)에 원본 콘텐츠의 사본을 저장하고,
• 사용자가 요청할 때 가장 가까운 노드에서 콘텐츠를 전달하는 분산 네트워크 인프라

5-2. CDN의 목적

• 지연(latency) 감소: 사용자와 가까운 에지 서버에서 응답해 네트워크 왕복 시간 단축
• 원본 서버 부하 감소: 반복 요청을 CDN이 대신 처리 → DB/애플리케이션/스토리지 보호
• 트래픽 분산: 대규모 트래픽(예: 이벤트, 스트리밍)을 전 세계 노드로 분산
• 가용성 및 안정성 향상: 일부 노드 장애 시 다른 노드로 우회 가능
• 보안 강화: TLS, 인증, DDoS 방어, WAF와 통합해 전송 계층 보안 확보

참고: 에지 서버(Edge Server)

• 위치: 사용자와 물리적으로 가까운 네트워크 경계(Edge)에 위치한 서버
• 역할: 원본 서버(Origin)에서 제공하는 콘텐츠 사본을 저장(캐시)하고, 사용자 요청 시 가장 가까운 위치에서 응답
• 특징:
  • 전 세계에 분산된 CDN PoP(Point of Presence) 안에 배치됨
  • 정적 리소스(이미지, JS, CSS, 동영상 등)를 캐시하여 응답 속도를 단축
  • 일부 CDN은 동적 콘텐츠 처리, TLS 종료, 보안 기능(WAF, DDoS 방어)도 수행

5-3. CDN의 작동 원리

(1) 사용자 요청

• 사용자가 cdn.example.com/image.png 요청

(2) 에지 서버 확인

• 요청한 콘텐츠가 캐시에 있으면 즉시 반환 (캐시 히트)
• 없으면 원본 서버(Origin)에서 가져와 캐시에 저장한 뒤 반환 (캐시 미스)

(3) 이후 요청

• 동일 지역의 다른 사용자도 같은 CDN 노드에서 캐시된 콘텐츠를 받음
• TTL/정책에 따라 캐시가 만료되면 다시 원본 서버에서 갱신

5-4. CDN 사용 시 고려할 점

• 캐시 가능 여부: 정적/동적 콘텐츠 중 어떤 것을 캐싱할지
• TTL 및 무효화 정책: 콘텐츠 신선도와 성능 균형
• 지리적 분포: 사용자 위치와 CDN PoP 분포 일치 여부
• 비용: CDN 트래픽/요청량 기반 과금 구조 확인
• 장애/Failover: 특정 노드나 CDN 전체 장애 시 대체 경로 확보 가능성

📘 클린 아키텍처 북스터디 정리입니다

📚 도서: 로버트 C. 마틴 《Clean Architecture》
🧑‍💻 목적: 올바른 설계에 대한 감각과 습관을 익히기 위해
🗓️ 진행 기간: 2025년 7월 ~ 매주 2장

✅ 핵심 요약 (Key Takeaways)

이 장의 핵심 문장은?

시스템 아키텍처는 일련의 소프트웨어 컴포넌트와 그 컴포넌트들을 분리하는 경계에 의해 정의된다."

저자가 전달하고자 하는 메세지 요약

좋은 아키텍처는 경계를 제대로 인식하고, 설계하고, 횡단 시 의존성 전파를 방지함으로써
시스템을 유연하고 유지보수하기 쉬운 구조로 만든다.

💡 내용 정리

1. 서론

• 시스템 아키텍처는 일련의 소프트웨어 컴포넌트와 그 컴포넌트들을 분리하는 경계에 의해 정의된다

소프트웨어 경계

• 소프트웨어 시스템 내부의 서로 다른 책임과 관심사를 물리적 또는 논리적으로 분리하는 구조적 장치
• 경계를 어떻게 나누느냐에 따라 빌드 전략/배포 방식/버전 관리/언어 수준의 유연성과 제약이 결정된다

2. 경계 횡단하기

• 경계를 넘어서는 호출(예: Controller → Service)은 피할 수 없다.
• 이때 의존성 방향이 올바르게 설정되어 있어야 경계가 무너지지 않는다.
• 경계는 변경이 전파되는 것을 막는 방화벽을 구축하고 관리하는 역할을 해야 한다

3. 단일체와 소스 수준 분리 모드

단일체(Monolith)

• 애플리케이션의 모든 컴포넌트가 하나의 배포 단위로 묶여 있는 형태
• 단일체 구조에서는 컴포넌트 간 경계는 파일이나 패키지 수준(소스 코드 수준)에서만 존재
• 컴파일도, 배포도 한 번에 이루어지기 때문에 의존성 구조가 잘못되어도 빌드 시점에 드러나지 않는다
• 의존성 제어가 어렵다는 문제 존재

소스 수준 분리 (Source-level separation)

• 논리적 분리만 존재하고, 물리적인 분리는 없는 수준
• 구조적으로만 나뉘어 있을 뿐, 실질적인 독립성과 격리는 부족
• 예: Java 프로젝트 내에서 controller, service, repository 패키지로 나눴지만, 하나의 jar로 컴파일

단일체에서 다형성과 경계 관리

동적 다형성 (Dynamic Polymorphism)

• 동일한 인터페이스를 구현한 여러 객체 중 하나를 런타임에 선택하여 사용하는 OOP 원리
• 고수준 컴포넌트가 구체 구현이 아닌 인터페이스에 의존하도록 구성 → 내부 컴포넌트 간에도 경계를 인식하고 설계할 수 있음
• 이 원리를 활용하면 단일체 안에서도 의존성을 인터페이스로 추상화하여 결합도를 낮출 수 있다

단일체에서의 다형성 활용

• 단일체 내부에서도 컴포넌트 간 결합이 무분별해지면 경계가 무너지기 쉽다
• 동적 다형성을 사용하면 다음과 같은 효과가 있다
  • DIP(의존성 역전 원칙) 구현
  • 전략 패턴 등 확장성 있는 코드 작성
  • 제어 흐름과 의존성 방향 분리 가능

핵심 원칙

• 의존성은 항상 고수준 컴포넌트를 향해야 한다
• 데이터 구조의 정의 또한 호출하는 쪽에 있어야 한다 (즉, "안쪽"에 있어야 한다)

4. 동적 링크 라이브러리와 배포 수준 분리 모드

동적 링크 라이브러리

• .dll, .so, .jar 등 런타임에 연결되는 컴포넌트
• 각 모듈은 별도로 빌드·배포되며, 실행 시점에 동적으로 연결됨

배포 수준 분리 (Deployment-level separation)

• 각 모듈이 독립적으로 배포 가능
• 서로 다른 팀이 각각의 컴포넌트를 유지/배포 가능
  • 예: UserService.dll과 OrderService.dll이 독립적으로 배포됨
• 배포 과정에서만 차이가 날 뿐, 배포 수준의 컴포넌트는 단일체와 동일
• 배포 단위는 나뉘어 있지만, 컴포넌트 간 통신은 여전히 함수 호출 → 경계를 너무 자주 횡단하면 단일체처럼 결합될 위험이 있음

5. 실행 단위에 따른 경계

스레드

• 스레드는 경계가 아니라 실행 계획의 도구
• 여러 스레드가 하나의 경계를 공유할 수도 있고, 하나의 컴포넌트가 여러 경계를 스레드로 운영할 수도 있다

로컬 프로세스

• OS 레벨에서 분리된 실행 단위 (예: Billing.exe, ReportGenerator.exe)
• 각 로컬 프로세스는 정적으로 링크된 단일체이거나 동적으로 링크된 여러개의 컴포넌트로 구성될 수 있다
• 로컬 프로세스 간 분리 전략은 단일 바이너리 컴포넌트의 경우와 동일하다
• 아키텍처 관점의 목표: 저수준 프로세스가 고수준 프로세스의 플러그인이 되도록 만드는 것
• 서로 다른 실행 파일이므로 통신 시 고비용(IPC, 데이터 직렬화 등)
  • OS 호출, 데이터 마샬링 및 언어 마샬링, 프로세스 간 문맥 교환 등
• 프로세스 간 경계는 분명하지만, 통신 빈도는 최소화해야 한다

• 서비스

• 가장 강력한 형태의 물리적 경계
• HTTP/gRPC 등 네트워크 기반으로 통신 비용이 높고, 실패 가능성도 존재한다
• 서비스 수준에서는 응답 지연을 고려할 수 있는 고수준에서 통신 해야 한다

6. 결론

경계 수준별 비교 요약

• 독립성 및 통신 비용

• 주요 특징

• 단일체를 제외한 대다수의 시스템은 한 가지 이상의 경계 전략을 사용한다
• 대체로 한 시스템 안에서도 통신이 빈번한 로컬 경계와 지연을 중요하게 고려해야 하는 경계가 혼합되어 있다.

용어 정리

플러그인 아키텍처

정의

• 고수준 정책(핵심 로직)이 저수준 세부사항(DB, 외부 API, 프레임워크 등)을 몰라도 동작할 수 있는 구조
  • 핵심 로직(정책)은 중심에 있고, DB, 외부 API, 프레임워크 등은 외곽에 위치
  • 인터페이스를 통해 구현체와 분리
  • 각 구현체는 고수준 로직의 플러그인이 되는 구조

📘 클린 아키텍처 북스터디 정리입니다

📚 도서: 로버트 C. 마틴 《Clean Architecture》
🧑‍💻 목적: 올바른 설계에 대한 감각과 습관을 익히기 위해
🗓️ 진행 기간: 2025년 7월 ~ 매주 2장

✅ 핵심 요약 (Key Takeaways)

이 장의 핵심 문장은?

좋은 시스템 아키텍처란 이러한 결정(업무 요구사항과 무관한 결정)이 부수적이며, 결정을 연기할 수 있는 아키텍처다

저자가 전달하고자 하는 메세지 요약

• 시스템을 컴포넌트 단위로 분할하여 업무 규칙과 세부사항으로 분리
• 업무 규칙과 세부사항 간 경계를 생성하고, 세부 사항에서 업무 규칙쪽으로 화살표가 향하도록 함

💡 내용 정리

1. 서론

• 소프트웨어 아키텍처는 선(경계)을 긋는 기술

경계의 역할

• 소프트웨어 요소를 서로 분리하고, 경계 한편에 있는 요소가 반대편에 있는 요소를 알지 못하도록 막음

결합(coupling)

• 너무 일찍 내려진 결정에 따른 결합은 인적자원의 효율을 떨어트림

좋은 아키텍처

• 이른 결정: 시스템의 업무 요구사항(유스케이스)와 무관한 결정
• 예시: 프레임워크, DB, 웹 서버, 유틸리티 라이브러리, 의존성 주입에 대한 결정 등
• 이러한 결정이 부수적이며, 결정을 연기할 수 있는 아키텍처

2. 경계를 긋는 방법

• 관련이 있는 것과 없는 것 사이에 선을 그거야 함

업무 규칙과 데이터베이스

• DB는 업무 규칙이 간접적으로 사용할 수 있는 도구
• 업무 규칙은 스키마, 쿼리 언어, 또는 DB와 관련된 나머지 세부 사항에 대해 어떤 것도 알아서는 안됨
• 업무 규칙이 알아야 할 것은 데이터를 가져오고 저장할 때 사용할 수 있는 함수 집합이 있다는 사실
• 이 함수 집합을 통해서 DB를 인터페이스 뒤로 숨길 수 있음

경계선

• 경계선은 DB Interface와 DB Access 사이에 그어짐
• DB Access에서 출발하는 화살표는 DB Access 클래스로부터 바깥쪽으로 향함(DB Access가 존재한다는 사실을 아는 클래스는 없다는 의미)

화살표 방향의 의미

• 화살표의 방향을 보면 DB에서 BusinessRules로 향하고 있음
• 이를 통해 DB는 BusinessRules에 대해 알고 있지만 BusinessRules는 DB에 대해 알지 못한다는 것을 알 수 있음
• 즉, 두 컴포넌트 사이에 이러한 경계선을 긋고 화살표의 방향이 BusinessRules를 향하도록 만들었으므로, BusinessRules에서는 어떤 종류의 DB도 사용할 수 있음
• DB 컴포넌트는 다양한 구현체로 교체될 수 있으며, BusinessRules는 이에 대해 조금도 개의치 않음

업무 규칙과 GUI

• 예시: 비디오 게임
• 비디오 게임의 사용자 경험은 인터페이스에 의해 좌우됨
• 인터페이스의 뒷단에는 인터페이스를 조작하는 모델(데이터 구조와 함수로 구성된 정교한 집합)이 존재
• 모델에게 중요한 것은 인터페이스가 아닌 업무 규칙

경계선과 화살표의 방향과 의미

• GUI와 BusinessRules가 경계선에 의해 분할됨
• GUI가 BusinessRules를 신경쓰는 것을 알 수 있음

3. 플러그인 아키텍처

• 업무 규칙과 무관한 컴포넌트 추가는 시스템에서 서드파티 플러그인을 사용할 수 있도록한 패턴과 동일
• 사용자 인터페이스는 플러그인 형태로 고려되었기 때문에 수 많은 사용자 인터페이스를 플러그인 형태로 연결 가능
• DB도 마찬가지로 플러그인으로 다루기로 결정했기 때문에 다양한 임의의 DB 기술로 대체 가능

4. 플러그인과 단일책임 원칙

• 경계는 변경의 축(axis of change)이 있는 지점에 그어짐
• 업무 규칙과 다른 시점에, 다른 속도로 변경되는 컴포넌트와 업무 규칙 사이에는 반드시 경계가 필요함
• 시스템을 플러그인 아키텍처로 배치하면 변경이 전파될 수 없는 방화벽 생성 가능

5. 결론

소프트웨어 아키텍처에 경계선 긋기

1. 시스템을 컴포넌트 단위로 분할
2. 컴포넌트 사이의 화살표가 특정 방향, 즉 핵심 업무를 향하도록 이들 컴포넌트의 소스를 배치

컴포넌트 분류

• 핵심 업무 규칙
• 플러그인: 핵심 업무와는 직접적인 관련이 없지만 필수 기능 포함

소프트웨어 경계의 의미?

• 의존성 역전 원칙과 안정된 추상화 원칙 응용
• 의존성 화살표는 저수준 세부사항에서 고수준의 추상화를 향하도록 배치됨

용어 정리

플러그인 아키텍처

플러그인 아키텍처의 정의

• 시스템의 핵심은 고수준 정책(비즈니스 규칙)으로 구성되고, 저수준 구현(세부사항)은 나중에 ‘꽂는(plug-in)’ 방식으로 설계하는 아키텍처 패턴
• 즉, 시스템의 주요 동작은 추상화된 인터페이스에 의존하고, 구체적인 구현은 외부에서 독립적으로 연결될 수 있도록 만든 구조

예시

[ Core Application ]
     ↑       ↑
  [ DB 구현 ] [ UI 구현 ]
  [ Mail 구현 ] [ Logger 구현 ]

• 핵심 정책(Core)은 인터페이스만 알고 있음
• DB, 웹서버, UI, 파일시스템 같은 외부 구현은 플러그인처럼 꽂힘
• DIP(Dependency Inversion Principle)를 통해 의존성 방향을 추상 쪽으로 역전

플러그인 아키텍처 적용 사례

클린 아키텍처에서의 구조화

                 [ Entities ]
                     ↑
           [ Use Cases / Interactors ]
                     ↑
         [ Interface Adapters (Controller, Gateway) ]
                     ↑
[ Frameworks & Drivers (DB, Web, UI, External APIs) ]

• 안쪽 계층은 바깥쪽 계층을 몰라도 됨
• 바깥쪽 계층은 안쪽 계층의 인터페이스에 맞춰서 구현
• 바깥 계층은 안쪽을 의존하지 않고 “플러그인”처럼 연결됨

📘 클린 아키텍처 북스터디 정리입니다

📚 도서: 로버트 C. 마틴 《Clean Architecture》
🧑‍💻 목적: 올바른 설계에 대한 감각과 습관을 익히기 위해
🗓️ 진행 기간: 2025년 7월 ~ 매주 2장

✅ 핵심 요약 (Key Takeaways)

이 장의 핵심 문장은?

좋은 아키텍처는 선택사항을 열어 둠으로써, 향후 시스템에 변경이 필요할 때 어떤 방향으로든 쉽게 변경할 수 있도록 한다

저자가 전달하고자 하는 메세지 요약

• 좋은 아키텍처는 4개의 관심사(유스케이스, 운영, 개발, 배포)를 지원해야 함
• 각각의 관심사 간 균형을 맞추고 각 관심사 모두를 만족시키면 좋겠지만 현실상 어려움
• 따라서 아키텍처는 선택사항을 열어두어 향후 변경이 필요할 때 쉽게 변경할 수 있도록 해야 함

💡 내용 정리

서론

좋은 아키텍처는 다음을 지원해야 함

• 시스템의 유스케이스
• 시스템의 운영
• 시스템의 개발
• 시스템의 배포

1. 좋은 아키텍처가 지원해야 하는 관심사들

유스케이스

• 시스템의 아키텍처는 시스템의 의도를 지원해야 함
• 아키텍처는 반드시 유스케이스를 지원해야 함
• 좋은 아키텍처는 행위를 명확히하고 외부로 드러내는 것을 통해 시스템이 지닌 의도를 아키텍처 수준에서 알아볼 수 있게 만듦

운영

• 좋은 아키텍처는 시스템의 운영을 지원해야 하고 이러한 지원은 시스템에 따라 다양한 의미를 가짐
• 따라서 아키텍처에서 각 컴포넌트를 적절히 격리하여 유지하고 컴포넌트 간 통신 방식을 특정 형태로 제한하지 않아야 함
• 그러면 시간이 지나 운영에 필요한 요구사항이 바뀌더라도 기술 스펙트럼을 전환하는 일이 쉬움

개발

• 콘웨이의 법칙: "시스템을 설계하는 조직이라면 어디든지 그 조직의 의사소통 구조와 동일한 구조의 설계를 만들어 낼 것이다"
• 아키텍처는 잘 격리되어 독립적으로 개발 가능한 컴포넌트 단위로 시스템을 분할할 수 있어야 함

배포

• 목표: 시스템 빌드 후 즉각적인 배포(immediate deployment)

2. 관심사들 간의 균형

• 좋은 아키텍처는 컴포넌트 구조와 관련된 관심사들 간 균형을 맞추고, 각 관심사 모두를 만족시킴
• 하지만 현실에서는 이러한 균형을 잡기가 어려움
• 좋은 아키텍처는 선택 사항을 열어둠으로써, 향후 시스템에 변경이 필요할 때 어떤 방향으로든 쉽게 변경할 수 있도록 함

3. 계층 결합 분리

• 시스템을 서로 결합되지 않은 수평적인 계층으로 분리 > 여러 요소를 서로 독립적으로 변경, 유스케이스를 가시적이고 분명하게 유지
• 예시: UI / 앱에 특화된 업무 규칙 / 앱과는 독립적인 업무 규칙, DB 등

4. 유스 케이스 결합 분리

• 시스템을 수평적 계층으로 분할하면서, 동시에 계층을 가로지르는 수직적인 유스케이스로 분할 가능
• 시스템에서 서로 다른 이유로 변경되는 요소들의 결합을 분리하면 기존 요소에 지장을 주지 않고도 새로운 유스케이스를 계속해서 추가 가능
• 유스케이스를 뒷받침하는 UI와 DB를 서로 묶어서 각 유스케이스가 UI와 DB의 서로 다른 관점 사용하는 것도 가능
• 예시: 주문 입력 시스템의 주문 추가 유스케이스 / 주문 삭제 유스케이스

5. 결합 분리 모드

결합 분리 시 운영 관점에서의 의미?

• 유스케이스를 수행하는 작업(결합 분리)들은 운영에 도움이 됨
• 하지만 운영 측면에서의 이점을 살리기 위해서는 결합 분리 시 적절한 모드를 선택해야 함
• 운영 측면의 이점을 위해 컴포넌트를 서비스 수준까지 분리해야하는 경우도 있음

개발 독립성

배포 독립성

6. 중복

• 중복 발생 시 진짜 중복인지 가짜 또는 우발적 중복인 지 확인해야 함

  진짜 중복

• 처리:인스턴스 변경 시, 동일한 변경을 그 인스턴스의 모든 복사본에 반드시 적용

  거짓된 또는 우발적 중복

• 두 코드 영역이 각자의 경로로 발전한다면(서로 다른 속도와 다른 이유로 변경) 진짜 중복이 아님
• 해당 코드를 통합하지 않도록 유의해야 함

7. 결합 분리 수준

• 좋은 아키텍처는 결합 분리 모드를 선택사항으로 남겨두어서 배포 규모에 따라 가장 적합한 모드를 선택해 사용할 수 있게 만들어줌

1) 소스 코드 수준

• 소스 코드 모듈 사이의 의존성 제어
• 흔히 모노리틱 구조라고 부름

2)바이너리 코드 수준

• jar 파일, DLL, 공유 라이브러리와 같이 배포 가능한 단위들 사이의 의존성 제어
• 결합이 분리된 컴포넌트가 jar 파일, Gem 파일, DLL과 같이 독립적으로 배포할 수 있는 단위로 분할되어 있음

3) 실행 단위(서비스) 수준

• 의존하는 수준을 데이터 구조 단위까지 낮출 수 있고, 순전히 네트워크 패킷을 통해서만 통신하도록 할 수 있음
• 이를 통해 모든 실행 가능한 단위는 소스와 바이너리 변경에 대해 서로 완전히 독립적이게 됨
• 예시: 서비스 또는 마이크로 서비스

용어 정리

관점 지향 프로그래밍(Aspect-Oriented programming; AOP)

• 횡단 관심사를 분리하여 모듈화를 높이는 프로그래밍 패러다임
• 코드 자체를 수정하지 않고, 기존 코드에 추가하는 방식으로 구현
• 횡단 관심사의 주요 예: 예외 처리, 로깅, 프랜잭션 등