dus_snp.log

[대규모 시스템 설계 스터디] 13장 정리

Thu, 20 Aug 2026 07:37:22 GMT

검색어 자동완성 시스템

1. 요구사항 확인

설계에 앞서 다음 사항을 먼저 확인해야 함.

사용자 입력이 검색어의 첫 부분에 한정되는가, 중간 부분도 대응하는가
몇 개의 자동완성 검색어를 보여줄 것인가
자동완성 검색어를 고르는 기준은 무엇인가
맞춤법 검사와 자동 수정 기능을 제공하는가
어떤 언어를 지원하는가
대문자나 특수문자는 어떻게 처리하는가
얼마나 많은 사용자를 지원해야 하는가(DAU)

비기능 요구사항

빠른 응답 속도
- 페이스북의 검색어 자동완성 시스템 문서에 따르면 응답 속도가 100밀리초 이상이면 사용자가 불편을 느낌
연관성
- 출력되는 검색어는 사용자가 입력한 단어와 연관되어야 함
정렬
- 계산 결과는 인기도 등의 순위 모델에 따라 정렬되어 있어야 함
규모 확장성
- 많은 트래픽을 감당할 수 있도록 확장 가능해야 함
고가용성
- 시스템 일부에 장애가 발생하거나 느려지거나 예상치 못한 네트워크 문제가 생겨도 계속 사용 가능해야 함

2. 개략적 규모 추정

현재 데이터가 없으므로 몇 가지 가정을 세우고 시작함.

일간 능동 사용자(DAU): 1000만 명
한 사용자가 하루에 검색하는 횟수: 평균 10회
질의당 평균 입력 데이터 크기: 20바이트
- ASCII 문자 하나는 1바이트
- 질의문은 평균 4개 단어, 단어당 평균 5글자로 가정
신규 검색어 비율: 전체의 20%

백엔드 요청 수

검색어를 입력할 때 글자 하나마다 요청이 발생함.

"dinner" 입력
→ search?q=d
→ search?q=di
→ search?q=din
→ search?q=dinn
→ search?q=dinne
→ search?q=dinner

따라서 검색 1회당 평균 20건의 요청이 백엔드로 전달됨.

QPS

QPS
= 1000만 × 10회 × 20건 ÷ 86,400초
≈ 24,000

최대 QPS
= 24,000 × 2
= 48,000

신규 데이터 크기

하루 질의 데이터
= 1000만 × 10회 × 20바이트
= 2GB

신규 데이터
= 2GB × 20%
= 0.4GB / 일

3. 개략적인 설계안

시스템은 크게 두 부분으로 나눌 수 있음.

데이터 수집 서비스
- 사용자가 입력한 질의를 실시간으로 수집하는 시스템
- 데이터가 많은 애플리케이션에서 실시간 수집은 바람직하지 않지만, 설계의 출발점으로 일단 둠
질의 서비스
- 주어진 질의에 대해 인기 검색어 k개를 정렬해 내놓는 서비스

빈도 테이블

질의문과 사용 빈도를 저장하는 빈도 테이블이 있다고 가정함.

데이터 수집 서비스는 사용자가 입력한 질의문을 저장하면서 사용 빈도를 늘림.

질의 서비스는 빈도가 높은 순으로 상위 k개의 검색어를 SQL 질의문으로 계산하여 보여줌.

사용하는 질의문은 다음과 같음.

SELECT * FROM frequency_table
WHERE query LIKE 'prefix%'
ORDER BY frequency DESC
LIMIT k

데이터가 적을 때는 괜찮은 설계안이지만, 데이터가 많아지면 DB가 병목이 됨.

따라서 상세 설계안으로 넘어감.

4. 트라이 자료구조

관계형 DB로 가장 인기 있는 k개의 질의문을 골라내는 방식은 효율적이지 않음.

따라서 트라이 자료구조를 사용하여 응답 시간을 줄임.

트라이(trie)라는 이름은 retrieval의 가운데 부분에서 따온 것임.

구조

트리 형태의 자료구조임
루트 노드는 빈 문자열을 나타냄
각 노드는 글자 하나를 저장함
각 노드는 하나의 단어 또는 접두어 문자열을 나타냄

자식 노드의 개수는 지원하는 문자 집합에 따라 달라짐.

영문 소문자만 지원한다면 노드마다 최대 26개의 자식을 가질 수 있고, 한글이나 유니코드 전반을 지원한다면 훨씬 커짐.

따라서 요구사항에서 지원 언어를 먼저 확인해야 함.

빈도 테이블의 정보를 트라이 노드에 저장하면 다음과 같음.

5. 탐색 알고리즘과 시간 복잡도

기호는 다음과 같이 정의함.

p: 접두어의 길이
n: 트라이 안에 있는 노드 개수
c: 주어진 노드의 자식 노드 개수

단계별 복잡도

해당 접두어를 표현하는 노드를 찾음 → O(p)
그 노드부터 하위 트리를 탐색하여 모든 유효 노드를 찾음 → O(c)
- 유효 노드는 유효한 검색 문자열을 구성하는 노드를 말함
유효 노드를 정렬하여 가장 인기 있는 검색어 k개를 찾음 → O(c log c)

전체 시간 복잡도는 다음과 같음.

O(p) + O(c) + O(c log c)
= O(p + c log c)

최적화

최악의 경우 전체 트라이를 모두 검색해야 하는 상황이 생길 수 있음.

이를 해결하는 방법은 두 가지임.

접두어의 최대 길이 제한
- 사용자가 검색창에 긴 질의를 입력하는 일은 드묾
- p를 상수로 만들 수 있으므로 1단계가 O(1)이 됨
각 노드에 인기 검색어 캐시
- 노드마다 상위 k개를 미리 저장해 둠
- 2단계와 3단계를 건너뛸 수 있음

저장 공간이 많이 필요해지지만, 빠른 응답 속도가 더 중요하므로 이 기법들을 사용함.

두 기법을 함께 적용하면 접두어를 찾아 인기 검색어를 얻는 과정의 전체 시간 복잡도가 O(1)이 됨.

접두어 길이 제한 → O(p)를 상수로
노드별 top k 캐시 → 탐색과 정렬 제거
= O(1)

여기서 O(1)은 접두어 길이가 상수로 제한된다는 전제 위에서 성립함.

6. 데이터 수집 서비스 상세 설계

앞선 설계안에서는 실시간으로 데이터를 갱신했으나, 매일 수천만 건의 질의가 발생하는 대형 서비스에서는 적합하지 않음.

트라이가 한 번 만들어지면 인기 검색어는 자주 바뀌지 않으므로 자주 갱신할 필요가 없음.

트라이를 만드는 데 쓰이는 데이터는 보통 데이터 분석 서비스나 로깅 서비스로부터 옴.

각 컴포넌트의 역할

데이터 분석 로그
- 입력된 질의에 관한 원본 데이터를 보관
로그 취합 서버
- 로그를 취합함
- 취합의 실시간성은 서비스 성격에 따라 중요도가 다르므로 확인이 필요함
작업 서버
- 주기적으로 비동기 작업을 실행하는 서버 집합
- 트라이 자료구조를 만들고 트라이 DB에 저장하는 역할
트라이 캐시
- 트라이 DB의 스냅샷을 주기적으로 떠서 연산 성능을 높임
트라이 DB
- 영속성 저장장치로는 두 가지 선택지가 있음.
  - 문서 저장소
    - 주기적으로 트라이를 직렬화하여 저장
  - 키-값 저장소
    - 트라이에 보관된 모든 접두어를 해시 테이블의 키로 변환
    - 각 노드에 보관된 데이터를 해시 테이블의 값으로 변환

접두어 "din" → 키
["dinner", "dinosaur", ...] → 값

7. 질의 서비스 상세 설계

질의 서비스는 다음 과정으로 이루어짐.

검색 질의가 로드밸런서로 전송됨
로드밸런서가 API 서버 중 하나로 질의를 보냄
API 서버가 트라이 캐시에서 데이터를 가져옴
캐시 미스가 나면 DB에서 가져와 캐시를 채운 뒤 응답을 구성함

최적화 기법

AJAX 요청
- 페이지 전체를 새로 고치지 않고 필요한 데이터만 비동기로 주고받음
- 글자마다 요청이 발생하는 자동완성의 특성상 필수적임
브라우저 캐싱
- 자동완성 결과는 짧은 시간 안에 자주 바뀌지 않음
- 응답을 브라우저에 캐시해 두면 같은 접두어를 다시 입력할 때 서버 요청 자체가 발생하지 않음
데이터 샘플링
- 모든 질의를 기록하지 않고 일부만 골라 기록함
- 인기 검색어의 순위는 표본만으로도 충분히 파악할 수 있으므로 로그 양과 처리 비용을 크게 줄일 수 있음

8. 트라이 연산

트라이 생성

작업 서버가 담당하며, 데이터 분석 서비스의 로그나 데이터베이스로부터 취합된 데이터를 이용함.

트라이 갱신

두 가지 방법이 있음.

주기마다 전체 갱신
- 새로운 트라이를 만들어 기존 트라이를 대체함
각 노드를 개별적으로 갱신
- 트라이가 작을 때 고려할 만한 방법임

검색어 삭제

혐오 조장, 폭력성, 성적 불쾌감, 위험 단어 등은 연산 결과에서 제거해야 함.

캐시 앞에 필터 계층을 두고 부적절한 질의어를 걸러내는 방법이 좋음.

트라이 캐시
→ 필터 계층
→ API 서버

필터 계층을 두면 필터 규칙에 따라 검색 결과를 자유롭게 변경할 수 있기 때문임.

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

트라이가 한 서버에 담기지 않을 만큼 커지면 샤딩이 필요함.

단순한 분할의 한계

첫 글자를 기준으로 나누는 방식은 데이터가 균등하게 분배되지 않음.

a로 시작하는 검색어 → 매우 많음
x, z로 시작하는 검색어 → 매우 적음

검색어 대응 샤드 관리자

과거 질의 데이터의 분포를 분석하여, 각 샤드가 비슷한 양의 데이터를 담도록 구간을 나눔.

분포 분석 결과 s로 시작하는 검색어가 많다면
→ s 하나만으로 한 샤드를 구성

u, v, w, x, y, z는 각각 적다면
→ 묶어서 한 샤드로 구성

이 매핑 정보, 즉 어떤 검색어가 어느 저장소 서버에 저장되는지를 관리하는 것이 검색어 대응 샤드 관리자임.

10. 최종 정리

검색어 자동완성 시스템의 전체 흐름은 다음과 같음.

수집
→ 데이터 분석 로그
→ 로그 취합 서버
→ 작업 서버
→ 트라이 DB
→ 트라이 캐시

질의
→ 로드밸런서
→ API 서버
→ 트라이 캐시(미스 시 DB)
→ 응답

핵심은 다음과 같음.

100밀리초 이내 응답이 목표이므로 RDB 질의로는 부족하고 트라이가 필요함
접두어 길이 제한과 노드별 top k 캐시를 함께 써야 O(1)에 가까워짐
인기 검색어는 자주 바뀌지 않으므로 실시간 갱신 대신 주기적 배치로 처리함
부적절한 검색어는 필터 계층에서 걸러야 규칙 변경이 자유로움
샤딩은 첫 글자가 아니라 실제 질의 분포를 기준으로 나눠야 균등해짐

[대규모 시스템 설계 스터디] 12장 정리

Mon, 17 Aug 2026 13:35:03 GMT

채팅 시스템 설계

1. 요구사항 확인

설계에 앞서 다음 사항을 먼저 확인해야 함.

어떤 앱을 설계해야 하는가
- 1:1 채팅 앱
- 그룹 채팅 앱
처리해야 하는 트래픽 규모는 어느 정도인가(DAU)
그룹 채팅의 참여 인원 제한은 몇 명인가
어떤 기능이 필요한가
- 접속 상태 표시
- 첨부파일 지원 여부
- 채팅방 유형
메시지 길이 제한은 어떻게 되는가
종단 간 암호화를 지원하는가
채팅 이력을 얼마나 보관하는가
어떤 통신 프로토콜을 사용할 것인가

2. 채팅 서비스의 역할

클라이언트끼리 직접 통신하는 것이 아니라, 위의 기능을 모두 지원하는 채팅 서비스를 거쳐 통신함.

채팅 서비스는 다음 기능을 제공해야 함.

클라이언트로부터 메시지 수신
메시지 수신자 결정 및 전달
수신자가 접속 상태가 아닌 경우 접속할 때까지 메시지 보관

메시지 송신

송신 클라이언트에서 채팅 서비스로 메시지를 보낼 때는 HTTP 프로토콜을 사용함.

이때 keep-alive 헤더를 사용하는 것이 효율적임.

클라이언트와 서버 사이의 연결을 끊지 않고 유지할 수 있음
TCP 접속 과정에서 발생하는 핸드셰이크 횟수를 줄일 수 있음

메시지 수신

채팅 서비스가 수신 클라이언트에게 메시지를 보낼 때는 일반 HTTP를 사용할 수 없음.

HTTP는 클라이언트가 서버에 요청하는 방식이지, 서버가 클라이언트에게 먼저 보내는 방식이 아니기 때문임.

이를 해결하기 위한 기법으로 폴링, 롱 폴링, 웹소켓이 있음.

폴링, 롱 폴링
→ HTTP 프로토콜 위에서 동작

웹소켓
→ HTTP로 연결을 시작한 뒤 다른 프로토콜로 전환

3. 폴링 · 롱 폴링 · 웹소켓

폴링

클라이언트가 주기적으로 서버에 새 메시지가 있는지 물어보는 방법임.

폴링을 자주 할수록 비용이 올라감
메시지가 없는 경우 서버 자원이 불필요하게 낭비됨

롱 폴링

폴링을 변형한 방법으로, 새 메시지가 반환되거나 타임아웃될 때까지 연결을 유지함.

클라이언트는 새 메시지를 받으면 기존 연결을 종료하고 새 요청을 보내어 모든 절차를 다시 시작함.

단점:

HTTP 서버는 보통 무상태이므로, 라운드로빈 방식으로 로드밸런싱하면 송신 클라이언트와 수신 클라이언트가 서로 다른 채팅 서버에 접속할 수 있음
- 이 경우 송신 클라이언트가 메시지를 보내도 롱 폴링이 끝나지 않음
서버 입장에서 클라이언트가 연결을 해제했는지 알아낼 좋은 방법이 없음
메시지를 많이 받지 않는 클라이언트도 타임아웃마다 주기적으로 접속하므로 여전히 비효율적임

웹소켓

서버가 클라이언트에게 비동기 메시지를 보낼 때 가장 널리 사용하는 기술임.

연결이 한 번 맺어지면 항구적으로 유지됨
80번(HTTP), 443번(HTTPS) 포트를 그대로 사용하므로 방화벽이 있는 환경에서도 잘 동작함
- 스킴은 ws://, wss://를 사용함

세 방식 비교

폴링
→ 요청 → 없음 → 대기 → 요청 → 없음 ...
→ 빈 응답이 대부분, 자원 낭비

롱 폴링
→ 요청 → (메시지 올 때까지 대기) → 응답 → 재요청
→ 빈 응답은 줄지만 재연결 반복

웹소켓
→ 연결 1회 → 양방향 송수신 지속
→ 서버가 먼저 보낼 수 있음

4. 웹소켓의 한계

웹소켓이 모든 상황에서 우월한 것은 아니며, 다음과 같은 비용이 따름.

서버가 상태를 갖게 됨
- 연결이 특정 서버에 묶이므로 무상태 서버처럼 자유롭게 분산할 수 없음
- 세션 고정이나 서비스 탐색 같은 별도 장치가 필요함
유휴 연결도 자원을 소모함
- 연결 하나마다 메모리와 소켓이 점유됨
- 메시지를 전혀 주고받지 않는 사용자도 비용을 발생시킴
재배포와 장애에 취약함
- 서버를 재시작하면 그 서버에 붙어 있던 모든 연결이 끊김
- 끊긴 클라이언트가 동시에 재연결을 시도하면 부하가 몰림
HTTP의 이점을 잃음
- 캐싱, 상태 코드, 표준 미들웨어 같은 기존 인프라를 그대로 쓸 수 없음
- 일부 프록시나 방화벽은 프로토콜 전환을 차단하므로 롱 폴링 폴백이 필요함
신뢰성을 직접 구현해야 함
- 연결이 끊긴 사이 유실된 메시지의 재전송, 순서 보장, 수신 확인을 애플리케이션이 처리해야 함

HTTP
→ 무상태 / 확장 쉬움 / 서버가 먼저 못 보냄

웹소켓
→ 상태 유지 / 확장 복잡 / 실시간 양방향

즉 실시간 양방향 통신이 필요한 구간에만 웹소켓을 쓰고, 나머지는 일반 HTTP로 처리하는 것이 적절함.

5. 개략적인 설계안

채팅 시스템은 크게 세 부분으로 나눌 수 있음.

무상태 서비스

로그인, 회원가입, 사용자 프로파일 표시 등을 처리하는 전통적인 요청/응답 서비스임.

많은 웹사이트와 앱이 보편적으로 제공하는 기능에 해당함.

상태 유지 서비스

각 클라이언트가 채팅 서버와 독립적인 네트워크 연결을 유지해야 하므로 필요함.

서버가 살아 있는 한 다른 서버로 연결을 변경하지 않음.

제3자 서비스 연동

앱이 실행 중이지 않더라도 알림을 받아야 하므로 푸시 알림 서비스와의 통합이 중요함.

컴포넌트별 역할

채팅 서버
- 클라이언트 간 메시지 중계
- 실시간 송수신을 위해 웹소켓 연결을 유지
접속상태 서버
- 사용자의 접속 여부 관리
API 서버
- 로그인, 회원가입, 프로파일 변경 등 나머지 전부 처리
알림 서버
- 푸시 알림 전송
키-값 저장소
- 채팅 이력 보관

6. 저장소 선택

RDB와 NoSQL 중 무엇을 쓸지 결정하려면 데이터의 유형과 읽기/쓰기 연산 패턴을 함께 고려해야 함.

채팅 시스템이 다루는 데이터

일반적인 데이터

사용자 프로파일, 설정, 친구 목록 등이 해당함.

안정성 보장을 위해 RDB에 보관
가용성과 규모 확장성을 위해 다중화와 샤딩을 사용

채팅 이력

빈번하게 사용되는 것은 최근에 주고받은 메시지
검색, 특정 사용자가 언급된 메시지 조회, 특정 메시지로 점프 등 무작위 접근을 지원하는 기능도 필요
1:1 채팅의 경우 읽기와 쓰기 비율은 대략 1:1 정도라고 함

키-값 저장소를 선택하는 이유

수평적 규모 확장이 쉬움
데이터 접근 지연 시간이 낮음
RDB는 롱테일에 해당하는 부분을 잘 처리하지 못하는 경향이 있음
실제로 페이스북 메신저와 디스코드가 키-값 저장소를 채택하고 있음

롱테일

원래는 통계 그래프의 모양을 가리키는 용어임.

머리(head)
- 소수의 항목이 압도적으로 많은 양을 차지
꼬리(tail)
- 개별 항목의 양은 적지만 항목 수 자체가 많아 합치면 무시할 수 없는 비중을 차지

채팅 시스템에서는 채팅방 하나에 쌓이는 메시지 개수의 분포를 가리킴.

대부분의 1:1 대화, 소규모 채팅방
→ 메시지 수십~수백 개

극소수의 대규모 그룹, 활성 커뮤니티
→ 메시지 수백만 개

RDB가 롱테일을 잘 다루지 못하는 이유

인덱스가 커질수록 무작위 접근 비용이 증가함
- 메시지 전체가 하나의 테이블에 쌓이면서 인덱스 규모가 계속 커짐
- 최근 메시지가 아닌 오래된 메시지를 조회할수록 캐시에 없는 페이지를 읽어야 하므로 디스크 랜덤 I/O가 늘어남
- 꼬리 쪽 데이터가 전체의 대부분을 차지하므로 이 비용이 무시할 수 없는 수준이 됨
핫스팟 문제
- 메시지가 몰린 소수의 채팅방은 읽기와 쓰기 요청도 함께 몰림
- chat_id 같은 키로 샤딩하면 이 소수의 채팅방 때문에 특정 샤드에만 부하가 집중됨
- 나머지 샤드는 한가한 상태로 남아 불균형이 발생함

7. 데이터 모델

1:1 채팅을 위한 메시지 테이블

메시지 ID를 기본 키로 사용하면서 메시지 순서를 정하는 역할도 맡김.

작성 일시는 서로 다른 메시지가 동시에 생성될 수 있어 순서를 정할 수 없는 경우가 있기 때문임.

그룹 채팅을 위한 메시지 테이블

채널 ID와 메시지 ID를 기본 키로 사용함.

채널은 채팅 그룹과 같은 뜻이며, 메시지 ID는 파티션 키로도 사용함.

메시지 ID

메시지 ID가 만족해야 할 조건은 다음과 같음.

고유한 값이어야 함
정렬 가능해야 함
시간 순서와 일치해야 함

auto_increment를 쓰면 간단히 해결될 것 같지만, NoSQL에서는 보통 해당 기능을 제공하지 않음.

따라서 다음 방법을 사용함.

스노플레이크 같은 전역적 순서 번호 생성기
지역적 순서 번호 생성기
- ID의 유일성을 같은 그룹 안에서만 보증하면 충분하다는 뜻

8. 서비스 탐색

클라이언트에게 가장 적합한 채팅 서버를 추천하는 역할임.

기준으로는 클라이언트의 위치, 서버의 용량 등을 사용함.

오픈소스 솔루션으로는 아파치 주키퍼가 널리 쓰임.

9. 메시지 전달 흐름

1:1 채팅 메시지 처리 흐름

여러 단말 사이의 메시지 동기화

한 사용자가 여러 단말을 사용하는 경우, 각 단말은 저마다 독립적인 웹소켓 연결을 유지함.

따라서 어떤 단말에서 접속하더라도 동일한 메시지를 빠짐없이 받아야 함.

이를 위해 각 단말은 자신이 마지막으로 확인한 메시지의 ID를 보관함.

단말이 보관하는 값
→ cur_max_message_id

새 메시지 판별 조건
→ 수신자가 나이고
→ message_id > cur_max_message_id

message_id가 시간 순서와 일치하는 값이므로, 이 조건만으로 각 단말이 놓친 메시지를 판별할 수 있음.

단말 A: cur_max_message_id = 1005
단말 B: cur_max_message_id = 1002

→ 단말 B는 1003~1005를 추가로 내려받아 동기화

즉 서버가 단말별 상태를 일일이 관리하지 않아도, 단말이 보관한 값 하나로 동기화가 성립함.

소규모 그룹 채팅에서의 메시지 흐름

그룹 채팅에서는 메시지를 그룹 구성원 각각의 메시지 동기화 큐에 사본으로 넣음.

사용자 A가 메시지 전송
→ A를 제외한 구성원 각각의 큐에 사본 저장
→ 각 사용자는 자기 큐만 확인

이 방식의 장점은 다음과 같음.

수신자는 자기 큐 하나만 보면 되므로 메시지 동기화 흐름이 1:1 채팅과 동일해짐
여러 사용자로부터 온 메시지를 한 곳에서 순서대로 확인할 수 있음
그룹 규모가 작으면 사본을 여러 벌 저장하는 비용이 크지 않음

수신자 관점
→ 큐 1개
→ 발신자가 누구든 동일하게 처리

다만 사본의 개수가 그룹 크기에 비례하므로, 인원이 매우 많은 그룹에는 적합하지 않음.

이 경우에는 사본을 만들지 않고 채널 단위로 메시지를 보관한 뒤 읽는 시점에 조회하는 방식을 사용함.

10. 접속 상태 표시

접속

사용자가 로그인하여 웹소켓 연결이 맺어지면, 접속상태 서버는 해당 사용자의 상태와 last_active_at 타임스탬프를 키-값 저장소에 보관함.

이 절차가 끝나면 접속 중으로 표시됨.

접속 장애

클라이언트가 보내는 Heartbeat Event를 사용하여 접속 상태를 판단함.

매우 짧은 시간 동안 발생한 접속 장애를 모두 반영해 상태를 변경하면 지나칠 뿐 아니라 UX에도 좋지 않기 때문임.

상태 정보의 전송

발행-구독 모델을 사용하여 접속 상태 변경을 알림.

다만 이 방법은 소규모 그룹에서만 효과적이고, 대규모 그룹에서는 비용과 시간이 많이 듦.

따라서 대규모 그룹에서는 다음과 같은 방법을 사용함.

사용자가 채팅에 입장하는 순간에만 상태 정보를 읽어가게 함
접속 상태를 수동으로 갱신하도록 유도함

11. 최종 정리

채팅 시스템의 전체 구조는 다음과 같음.

로그인, 회원가입, 프로파일
→ API 서버(무상태)

메시지 송수신
→ 채팅 서버(웹소켓, 상태 유지)
→ 메시지 동기화 큐
→ 키-값 저장소

접속 상태
→ 접속상태 서버 + 발행-구독

앱 미실행 시
→ 알림 서버 → 푸시 알림

핵심은 다음과 같음.

서버가 먼저 보내야 하는 구간에만 웹소켓을 쓰고 나머지는 HTTP로 처리할 것
웹소켓은 상태를 갖는 대신 확장이 어려워지므로 서비스 탐색 같은 장치가 필요함
채팅 이력은 롱테일 분포를 가지므로 키-값 저장소가 유리함
message_id는 고유하면서 시간 순서와 일치해야 하며, 이 값 하나로 다중 단말 동기화가 가능함
그룹 채팅은 규모에 따라 사본 저장과 채널 단위 보관 중에서 선택해야 함

[대규모 시스템 설계 스터디] 11장 정리

Thu, 13 Aug 2026 07:44:10 GMT

뉴스 피드 시스템 설계

뉴스 피드는 홈페이지 중앙에 지속적으로 업데이트되는 스토리들의 목록임.

페이스북 도움말 페이지의 정의에 따르면 다음과 같은 항목이 포함됨.

사용자 상태 정보 업데이트
사진, 비디오, 링크
앱 활동
팔로우하는 사람, 페이지, 그룹으로부터 발생한 좋아요

1. 요구사항 확인

설계에 앞서 다음 사항을 먼저 확인해야 함.

어떤 클라이언트를 지원할 것인가
- 앱
- 웹
어떤 기능이 필요한가
- 스토리 업로드
- 친구의 스토리 조회
스토리를 어떤 순서로 표시할 것인가
- 최신순
- 토픽 점수순
- 그 외 기준
한 사용자가 가질 수 있는 최대 친구 수는 몇인가
트래픽 규모는 어느 정도인가
피드에 어떤 형식의 콘텐츠가 들어가는가
- 텍스트
- 이미지
- 비디오

2. 뉴스 피드 API

클라이언트가 서버와 통신하기 위해 사용하는 수단임.

HTTP 프로토콜 기반이며 상태 정보 업데이트, 뉴스 피드 조회, 친구 추가 등의 작업을 수행하는 데 사용함.

피드 발행 API

새 스토리를 포스팅하기 위한 API임.

POST /v1/me/feed

인자:

body
- 포스팅 내용
Authorization 헤더
- API 호출 인증에 사용

피드 읽기 API

뉴스 피드를 가져오는 API임.

GET /v1/me/feed

인자:

Authorization 헤더
- API 호출 인증에 사용

3. 개략적인 설계안

뉴스 피드 시스템은 크게 두 부분으로 나눌 수 있음.

피드 발행
- 사용자가 스토리를 포스팅하면 캐시와 DB에 기록
- 새 포스팅은 친구의 뉴스 피드에도 전송
뉴스 피드 생성
- 모든 친구의 포스팅을 시간 흐름 역순으로 모아서 구성

이 설계에서는 정렬 기준을 시간 역순으로 가정함.

다만 실제 서비스에서는 사용자의 참여 가능성을 예측하는 랭킹 모델을 사용해 노출 순서를 결정하는 경우가 일반적임.

피드 발행 시스템

뉴스 피드 생성 시스템

4. 피드 발행 흐름 상세 설계

웹 서버

클라이언트와의 통신뿐 아니라 인증이나 처리율 제한 등의 기능도 수행함.

올바른 인증 토큰을 Authorization 헤더에 넣어 API를 호출한 사용자만 포스팅할 수 있어야 함
특정 기간 동안 한 사용자가 올릴 수 있는 포스팅 수를 제한하여 스팸과 유해 콘텐츠 유입을 방지함

포스팅 전송(팬아웃) 서비스

팬아웃은 어떤 사용자의 새 포스팅을 그와 친구 관계에 있는 모든 사용자에게 전달하는 과정임.

크게 두 가지 모델로 나뉨.

쓰기 시점 팬아웃 = push 모델
읽기 시점 팬아웃 = pull 모델

5. 팬아웃 모델: push와 pull

push 모델

새로운 포스팅을 기록하는 시점에 뉴스 피드를 갱신함.

포스팅이 완료되면 바로 친구들의 뉴스 피드 캐시에 해당 포스팅을 기록함.

포스팅 작성
→ 친구 목록 조회
→ 친구 각각의 피드 캐시에 기록
→ (사용자가 접속하면 캐시를 그대로 읽음)

장점:

뉴스 피드가 실시간으로 갱신되어 친구에게 즉시 전달됨
포스팅 시점에 이미 피드가 갱신되어 있으므로 읽기 시간이 짧음

단점:

친구가 많은 사용자의 경우 피드 갱신에 많은 시간이 소요됨
서비스를 자주 이용하지 않는 사용자의 피드까지 갱신하므로 컴퓨팅 자원이 낭비됨

pull 모델

피드를 읽어야 하는 시점에 뉴스 피드를 갱신함.

즉 요청 기반 모델이며, 사용자가 홈이나 타임라인을 로딩하는 시점에 새 포스팅을 가져옴.

포스팅 작성
→ 작성자 쪽에만 기록

사용자 접속
→ 친구 목록 조회
→ 각 친구의 최근 포스팅 조회
→ 병합 후 렌더링

장점:

비활성 사용자나 서비스를 자주 이용하지 않는 사용자에게 유리함
- 로그인 전까지 어떤 컴퓨팅 자원도 소모하지 않음
데이터를 친구 각각에게 밀어 넣는 작업이 없으므로 쓰기 부하가 집중되지 않음

단점:

뉴스 피드를 읽는 데 많은 시간이 소요됨

두 모델 비교

push
→ 쓰기 비쌈 / 읽기 쌈
→ 실시간성 좋음
→ 친구 많은 사용자에게 취약

pull
→ 쓰기 쌈 / 읽기 비쌈
→ 자원 낭비 없음
→ 접속 시 지연 발생

6. 쓰기 증폭과 핫 키

팔로워가 매우 많은 사용자를 처리할 때 발생하는 문제는 사실 두 가지이며, 서로 다른 문제임.

쓰기 증폭(팬아웃 폭발)

포스팅 하나를 처리하기 위해 팔로워 수만큼의 쓰기 작업이 한꺼번에 발생하는 문제임.

포스팅 1건
→ 팔로워 1,000만 명
→ 피드 캐시 쓰기 1,000만 회

push 모델에서 발생하며, 쓰기 지연과 자원 소모의 원인이 됨.

핫 키

캐시나 샤딩 환경에서 특정 키 하나에 요청이 몰려 그 키를 담당하는 노드만 과부하되는 문제임.

셀럽 계정 데이터 = 단일 키
→ 특정 샤드로만 요청 집중
→ 해당 노드만 과부하

셀럽 계정은 두 문제를 동시에 일으키지만, 원인과 해법은 서로 다름.

안정 해시는 핫 키의 해법이 아님

안정 해시(consistent hashing)는 노드가 추가되거나 제거될 때 재배치를 최소화하고 데이터를 고르게 분산하는 기법임.

그러나 요청이 몰리는 대상이 키 하나라면 어느 노드에 배치되든 그 노드에 부하가 집중되므로, 안정 해시만으로는 핫 키를 해결할 수 없음.

안정 해시
→ 샤드 단위 분산은 균등해짐
→ 단일 핫 키 부하는 그대로

실제로 페이스북의 TAO 역시 샤드를 캐시 서버에 매핑할 때 안정 해시를 사용하지만, 핫 키는 별도로 처리함.

인기 샤드를 여러 서버가 함께 서빙하는 샤드 복제
접근 빈도가 임계값을 넘는 항목에 대한 클라이언트 측 캐싱

즉 안정 해시는 일반적인 부하 분산 기법으로 두고, 셀럽 문제의 해법은 아래의 하이브리드 팬아웃으로 보는 것이 적절함.

7. 하이브리드 팬아웃

실제 뉴스 피드 시스템은 push와 pull을 함께 사용함.

두 모델의 단점을 버리고 장점만 취하기 위한 방식임.

일반 사용자
→ push
→ 포스팅 시점에 친구 피드에 기록

팔로워 수 임계값 초과 사용자(셀럽)
→ pull
→ 팔로워가 피드를 읽는 시점에 조회 후 병합

팔로워 수를 기준으로 분기하므로, 쓰기 증폭을 일으키는 소수 계정만 pull로 빠지고 나머지는 push의 빠른 읽기 성능을 그대로 유지할 수 있음.

팬아웃 서비스 동작 과정

그래프 DB에서 친구 ID 목록 조회
사용자 정보 캐시에서 친구 정보를 조회한 뒤 설정(mute, 친한 친구 등)에 따라 걸러내기
친구 목록과 새 스토리의 포스팅 ID를 메시지 큐에 넣음
작업 서버가 <포스팅ID, 사용자ID> 형태의 데이터를 뉴스 피드 캐시에 넣음

그래프 데이터베이스

친구 관계 조회는 "특정 사용자에서 출발해 연결된 노드를 따라가는" 탐색 연산이므로, 관계 자체를 1급 개념으로 다루는 그래프 DB가 적합함.

책이 참고 자료로 제시한 페이스북의 TAO 논문을 기준으로 보면 소셜 그래프는 두 가지 요소로 모델링됨.

객체(Object)
- 타입을 가진 노드
- 사용자, 게시물, 댓글, 장소 등
연관(Association)
- 타입을 가진 방향성 엣지
- 친구 관계, 작성 관계, 좋아요 등

Object: (id) → (타입, 데이터)
Assoc : (id1, 엣지타입, id2) → (시간, 데이터)

질의는 항상 특정 객체와 엣지 타입에서 시작함.

(사용자 A, FRIEND) → [친구 목록]
(게시물 X, COMMENT) → [댓글 목록]

이런 구조 덕분에 다음과 같은 특성을 가짐.

인접 노드 탐색이 단일 조회로 처리됨
엣지 목록이 시간 역순으로 정렬되어 최신 항목 조회에 유리함
읽기가 압도적으로 많은 워크로드에 맞춰 캐시 계층이 그래프 구조를 이해한 상태로 동작함

영구 저장은 MySQL을 사용하되 그 앞에 그래프를 인지하는 캐시 계층을 두는 구조이며, 강한 일관성보다 가용성과 읽기 효율을 우선함.

8. 피드 읽기 흐름 상세 설계

사용자가 요청 전송
로드밸런서가 웹 서버 중 하나에 요청 전달
웹 서버가 뉴스 피드 서비스 호출
뉴스 피드 서비스가 뉴스 피드 캐시에서 포스팅 ID 목록 조회
사용자 이름, 사진, 포스팅 콘텐츠 등을 사용자 캐시와 포스팅 캐시에서 가져와 뉴스 피드 생성
생성된 뉴스 피드를 JSON 형태로 클라이언트에 전달하고 클라이언트가 렌더링

이때 이미지나 비디오 같은 미디어 콘텐츠는 피드 응답에 직접 담지 않고 CDN에서 가져옴.

피드 응답(JSON)
→ 텍스트, 메타데이터, 미디어 URL

미디어 파일
→ CDN
→ 클라이언트

용량이 큰 파일을 CDN으로 분리하면 응답 크기가 줄고 지연도 개선됨.

9. 캐시 구조

캐시는 다음과 같이 계층별로 나눔.

뉴스 피드
- 뉴스 피드 ID 보관
콘텐츠
- 포스팅 데이터 보관
- 인기 콘텐츠는 따로 보관
소셜 그래프
- 사용자 간 관계 정보 보관
행동
- 포스팅에 대한 사용자의 행위(좋아요, 댓글 등)
횟수
- 좋아요 수, 댓글 수, 팔로잉/팔로워 수 등

뉴스 피드 캐시의 크기 제한

뉴스 피드 캐시에 모든 포스팅을 담지 않고 최근 N개만 보관함.

사용자당 피드 캐시
→ 최근 N개 ID만 유지
→ 그 이후는 DB에서 조회

대부분의 사용자는 피드 상단 일부만 확인하므로, 전체를 캐싱하는 것은 메모리 낭비임.

또한 ID만 보관하고 콘텐츠 본문은 별도 캐시에서 가져오므로 사용자 수가 늘어나도 메모리 사용량이 완만하게 증가함.

10. 최종 정리

뉴스 피드 시스템의 전체 흐름은 다음과 같음.

포스팅
→ 웹 서버(인증, 처리율 제한)
→ 팬아웃 서비스
→ 메시지 큐
→ 작업 서버
→ 뉴스 피드 캐시

조회
→ 웹 서버
→ 뉴스 피드 서비스
→ 피드 캐시에서 ID 조회
→ 콘텐츠/사용자 캐시에서 상세 조회
→ 미디어는 CDN
→ 클라이언트 렌더링

핵심은 단순히 포스팅을 모아서 보여주는 것이 아니라 다음 사항을 함께 고려하는 것임.

쓰기 부하와 읽기 부하 중 무엇을 감수할 것인가(push와 pull)
팔로워가 많은 계정의 쓰기 증폭을 어떻게 분리할 것인가
핫 키를 부하 분산 기법과 구분해 별도로 처리할 것
친구 관계 탐색에 적합한 저장소를 선택할 것
캐시를 계층별로 나누고 보관 범위를 제한할 것
미디어를 CDN으로 분리할 것

[대규모 시스템 설계 스터디] 10장 정리

Thu, 13 Aug 2026 04:24:37 GMT

알림 시스템 설계

알림 시스템은 사용자에게 중요한 정보나 이벤트를 전달하는 시스템

대표적인 알림 방식은 다음과 같음.

모바일 푸시 알림
SMS 메시지
이메일

알림 시스템은 보통 정해진 시간 안에 빠르게 전달되는 것이 중요하지만, 일부 지연이 발생했다고 시스템 전체가 실패한 것으로 보지는 않기 때문에 연성 실시간(Soft Real-Time) 시스템에 가까움.

반대로 경성 실시간(Hard Real-Time) 시스템은 정해진 deadline을 반드시 지켜야 하며 이를 넘기는 것이 시스템 실패로 이어질 수 있음.

1. 요구사항 확인

알림 시스템을 설계하기 전에 다음 사항을 먼저 확인해야 함.

어떤 종류의 알림을 지원할 것인가
- 푸시
- SMS
- 이메일
어떤 종류의 단말을 지원할 것인가
- iOS
- Android
- 웹 등
알림을 생성하는 주체는 누구인가
사용자가 특정 알림을 거부하거나 opt-out 할 수 있어야 하는가
하루에 몇 건의 알림을 처리해야 하는가
어느 정도의 알림 지연까지 허용할 것인가

2. 알림 유형별 전송 방식

iOS 푸시 알림

iOS에 푸시 알림을 보내기 위해서는 크게 다음 세 요소가 필요함.

알림 제공자(Notification Provider)

알림 요청을 생성하여 APNs로 전달하는 서버임.

알림을 생성하기 위해 다음과 같은 정보가 필요함.

Device Token
- 특정 기기에서 실행되는 특정 앱으로 푸시 알림을 전달하기 위해 APNs가 발급하는 식별 정보
- 앱은 발급받은 Device Token을 알림 서버에 전달
Payload
- 알림 내용을 담고 있는 JSON 데이터

APNs

Apple Push Notification service

Apple이 제공하는 푸시 알림 서비스로, 알림 서버에서 받은 요청을 실제 iOS 단말로 전달함.

알림 서버
→ APNs
→ iOS 앱

Android 푸시 알림

Android에서는 일반적으로 FCM(Firebase Cloud Messaging)을 사용함.

개략적인 구조는 iOS와 유사함.

알림 서버
→ FCM
→ Android 앱

다만 APNs와 FCM은 사용하는 API와 인증 방식 등 세부 구현에는 차이가 있음.

SMS

SMS는 통신사와 직접 연동하기보다 제3자 서비스를 사용하는 경우가 많음.

대표적인 서비스:

Twilio
Vonage(구 Nexmo)

알림 서버
→ SMS 제공 사업자
→ 이동통신망
→ 사용자 휴대전화

이메일

이메일 역시 제3자 이메일 서비스를 사용할 수 있음.

대표적인 서비스:

SendGrid
Mailchimp

이러한 서비스는 대량 이메일 전송뿐 아니라 전송 성공률이나 클릭률 등의 데이터 분석 기능도 제공할 수 있음.

3. 사용자 연락처 및 단말 정보 저장

알림을 보내기 위해 다음과 같은 정보가 필요함.

이메일 주소
전화번호
Device Token

이메일 주소와 전화번호 등의 기본 정보는 user 테이블에 저장하고, Device Token은 별도의 device 테이블에 저장함.

이렇게 분리하는 이유는 한 사용자가 여러 단말을 사용할 수 있기 때문임.

User A
 ├─ Device 1
 ├─ Device 2
 └─ Device 3

즉 관계는 다음과 같음.

User : Device
= 1 : N

필요한 경우 한 사용자가 등록한 모든 단말로 알림을 전송할 수 있음.

4. 개략적인 시스템 설계

알림 시스템의 주요 컴포넌트는 다음과 같음.

Service 1 ~ N

알림을 발생시키는 서비스임.

예:

마이크로서비스
크론잡
배치 시스템
분산 시스템의 다른 컴포넌트

예를 들어:

주문 서비스 → 주문 완료 알림
결제 서비스 → 결제 완료 알림
배송 서비스 → 배송 시작 알림

즉 알림 시스템은 서로 다른 서비스들이 생성하는 알림을 공통으로 처리하는 인프라 역할을 함.

알림 서버

알림 시스템의 핵심 컴포넌트임.

주요 역할:

서비스들이 사용할 알림 API 제공
사용자 정보 조회
Device Token 조회
사용자 알림 설정 확인
알림 템플릿 적용
제3자 서비스에 전달할 Payload 생성
알림 이벤트를 메시지 큐에 저장

알림 서버를 한 대만 두면 다음 문제가 발생할 수 있음.

SPOF
처리량 한계
성능 병목
수평적 확장 어려움

따라서 알림 서버를 여러 대로 구성하고 DB와 캐시도 별도 컴포넌트로 분리함.

캐시

자주 조회되는 다음 정보를 저장함.

사용자 정보
Device 정보
알림 설정
알림 템플릿

DB 접근을 줄이고 응답 시간을 단축할 수 있음.

데이터베이스

다음과 같은 데이터를 영구 저장함.

사용자 정보
Device Token
사용자 알림 설정
알림 정보
알림 로그
전송 상태

메시지 큐

시스템 컴포넌트 사이의 강한 결합을 줄이는 역할을 함.

알림 서버
→ Message Queue
→ Worker

대량의 알림이 한꺼번에 발생할 경우 알림을 임시로 저장하는 버퍼 역할도 담당함.

작업 서버(Worker)

메시지 큐에서 알림 이벤트를 가져와 실제 제3자 서비스로 전달함.

Push Queue
→ Push Worker
→ APNs / FCM

SMS Queue
→ SMS Worker
→ SMS Provider

Email Queue
→ Email Worker
→ Email Provider

제3자 서비스

실제로 사용자에게 알림을 전달함.

예:

APNs
FCM
Twilio
SendGrid

제3자 서비스와 통합할 때는 새로운 서비스 사업자를 쉽게 추가하거나 기존 사업자를 제거할 수 있도록 설계하는 것이 중요함.

특정 국가나 시장에서는 특정 서비스 제공자를 사용할 수 없을 수도 있으므로 대체 사업자를 지원할 수 있어야 함.

5. 알림 API와 전송 과정

이메일 알림 API 예제

POST /api/v1/email/send

요청 예:

알림 전송 과정

서비스가 알림 API 호출
알림 서버가 캐시 또는 DB에서 사용자 정보, Device Token, 알림 설정 등의 메타데이터 조회
알림 서버가 전송할 알림 이벤트 생성
알림 종류에 맞는 메시지 큐에 이벤트 저장
Worker가 메시지 큐에서 이벤트 조회
Worker가 APNs, FCM, SMS, 이메일 등의 제3자 서비스로 전달
제3자 서비스가 사용자 단말로 알림 전달

서비스
→ 알림 서버
→ 메시지 큐
→ Worker
→ 외부 알림 서비스
→ 사용자

6. 안정성과 중복 처리

데이터 손실 방지

책의 설계 요구사항에서는 다음과 같이 가정함.

알림은 지연되거나 순서가 달라질 수는 있지만 시스템 내부에서 소실되어서는 안 됨.

이를 위해 알림 데이터를 지속적으로 저장하고 전송 실패 시 재시도해야 함.

한 가지 방법은 알림 로그 DB를 유지하는 것임.

알림 이벤트 생성
→ 로그 또는 지속 가능한 큐에 저장
→ 전송 시도
→ 결과 저장

전송에 실패하면 저장된 데이터를 이용해 다시 시도할 수 있음.

알림 중복 전송 방지

분산 시스템에서는 재시도로 인해 동일 이벤트가 여러 번 처리될 수 있음.

따라서 각 이벤트에 고유한 event_id를 부여할 수 있음.

event_id = 8237471

Worker가 이벤트를 받으면:

event_id 확인
       ↓
이미 처리했는가?
 ├─ YES → 폐기
 └─ NO  → 알림 전송

이를 통해 중복 발송 빈도를 줄일 수 있음.

7. 알림 시스템의 부가 기능

알림 템플릿

매번 알림 문구를 새로 작성하는 대신 미리 형식을 정의해둘 수 있음.

예:

[배송 알림]

{사용자명}님의 상품이 배송을 시작했습니다.
송장번호: {송장번호}

장점:

형식의 일관성 유지
오류 감소
작성 시간 단축
다국어 지원 용이
추적 링크와 스타일 일괄 적용 가능

알림 설정

사용자가 너무 많은 알림을 받으면 알림 기능 자체를 꺼버릴 수 있음.

따라서 사용자가 종류별로 알림을 조정할 수 있어야 함.

마케팅 알림   OFF
배송 알림     ON
결제 알림     ON
이벤트 알림   OFF

알림을 보내기 전에 사용자 설정을 확인해야 함.

전송률 제한

한 사용자에게 지나치게 많은 알림을 보내지 않도록 제한함.

예:

마케팅 Push
→ 사용자당 하루 최대 3건

이를 통해:

알림 피로 감소
스팸 방지
외부 서비스 비용 절감

등의 효과를 얻을 수 있음.

재시도 메커니즘

전송 실패 시 알림을 재시도 전용 큐로 이동시킴.

전송 실패
→ Retry Queue
→ 재시도

계속 실패할 경우 오류를 기록하고 운영자나 개발자에게 알림을 보낼 수 있음.

재시도 횟수와 재시도 간격도 제한해야 함.

푸시 알림 보안

인증되지 않은 클라이언트가 임의로 알림을 보낼 수 없어야 함.

APNs와 FCM은 각각 별도의 인증 방식을 사용함.

APNs
- APNs Signing Key를 이용한 JWT Provider Token
- 인증서 방식도 사용 가능
FCM
- 서비스 계정 기반 OAuth 2.0 Access Token 사용

즉 단순한 appKey + appSecret으로 일반화하기보다 플랫폼별 인증 체계를 사용한다고 보는 것이 적절함.

8. 모니터링과 이벤트 추적

큐 모니터링

알림 시스템에서 중요한 지표 중 하나는 메시지 큐에 쌓인 알림의 수임.

Queue Size ↑

큐가 계속 증가한다면:

알림 생성 속도
>
Worker 처리 속도

일 가능성이 있음.

이 경우 다음을 확인해야 함.

Worker 수가 충분한가
외부 서비스가 느려졌는가
오류율이 증가했는가
큐 처리 속도가 떨어졌는가

필요하면 Worker를 증설할 수 있음.

이벤트 추적

다음 지표를 수집하면 알림의 효과를 분석할 수 있음.

전달 성공률
확인율
클릭률
앱 실행 전환율
구매 전환율

예:

Push 발송
→ 알림 확인
→ 클릭
→ 앱 실행
→ 구매

이벤트 추적 데이터는 사용자 행동과 알림 품질을 개선하는 데 활용할 수 있음.

9. 분산 시스템에서 Exactly-once가 어려운 이유

책에서는 이 부분의 참고 자료로 다음 글을 제시함.

Tyler Treat, You Cannot Have Exactly-Once Delivery

핵심 내용은 네트워크로 분리된 두 컴포넌트 사이에서 메시지가 정확히 한 번 전달됐다는 사실을 완벽하게 확인하기 어렵다는 것임.

예를 들어 서버 A가 서버 B에게 메시지를 보냈는데 ACK를 받지 못했다고 가정함.

가능한 경우:

1. 메시지가 네트워크에서 유실됨
2. B가 메시지를 받았지만 처리 전에 장애 발생
3. B가 메시지를 처리 중이지만 매우 느림
4. B가 처리를 완료함
5. B가 ACK를 보냈지만 ACK가 유실됨

A는 ACK를 받지 못했다는 사실만으로 B가 메시지를 처리했는지 알 수 없음.

블로그에서는 이러한 분산 시스템의 불확실성을 설명하기 위해 Two Generals Problem, Byzantine Generals Problem, FLP 결과 등을 함께 언급함.

FLP는 exactly-once delivery 자체에 대한 직접적인 증명이라기보다는 비동기 분산 시스템에서 장애와 합의가 갖는 근본적인 한계를 설명하는 이론적 배경으로 볼 수 있음.

At-most-once

최대 한 번 전달하는 방식.

블로그의 단순한 예에서는 메시지를 받은 뒤 처리 전에 ACK를 보냄.

메시지 수신
→ ACK
→ 처리

ACK 이후 처리 중 장애가 발생하면 Sender는 이미 성공했다고 생각하므로 재전송하지 않음.

따라서:

At-most-once
→ 중복 가능성 낮음
→ 메시지 유실 가능

알림 서비스라면 사용자가 받아야 할 알림이 사라질 수 있음.

At-least-once

최소 한 번 이상 전달하는 방식.

메시지를 처리한 뒤 ACK를 보냄.

메시지 수신
→ 처리
→ ACK

하지만 처리는 완료됐는데 ACK가 유실되면 Sender는 실패로 판단하고 다시 메시지를 보냄.

처리 완료
→ ACK 유실
→ 재전송
→ 동일 메시지 다시 처리

따라서:

At-least-once
→ 메시지 유실 가능성을 줄임
→ 중복 처리 가능

알림 서비스라면 동일한 알림이 두 번 전달될 수 있음.

Exactly-once와 실무적인 해결 방법

이상적인 목표는:

메시지 유실 없음
+
중복 없음
=
Exactly-once

이지만 네트워크에서 메시지나 ACK가 유실될 수 있으므로 네트워크 수준에서 exactly-once delivery를 완벽하게 보장하기 어려움.

따라서 실무에서는 중복 가능성을 받아들이고 애플리케이션 계층에서 이를 흡수함.

대표적인 방법은 두 가지임.

멱등성(Idempotency)

같은 연산을 여러 번 수행해도 최종 결과가 같도록 설계함.

상태 = 활성화

를 여러 번 수행해도 최종 상태는 동일함.

중복 제거(Deduplication)

각 메시지에 고유한 Event ID를 부여하고 처리 이력을 확인함.

event_id = abc123

처음 들어온 경우:

처리 이력 없음
→ 처리
→ 완료 기록

같은 이벤트가 다시 들어온 경우:

이미 처리됨
→ 폐기

알림 발송은 같은 함수를 두 번 실행하면 실제 알림도 두 번 나갈 수 있으므로 자연스럽게 멱등한 연산이 아님.

따라서 알림 시스템에서는 Event ID 기반 중복 제거가 특히 중요함.

전체 흐름은 다음과 같음.

At-least-once
       ↓
중복 가능
       ↓
Event ID
       ↓
Deduplication 또는 Idempotency
       ↓
중복으로 인한 부작용 방지

즉 분산 알림 시스템에서는 중복 전달 자체를 완전히 없애려 하기보다, 재전송을 허용하고 Event ID와 중복 제거 또는 멱등 처리를 이용해 중복으로 인한 문제를 흡수하는 방식이 현실적임.

10. 최종 설계 정리

최종적인 알림 시스템 구조는 다음과 같음.

추가적으로 다음 기능을 포함함.

Notification Log
Retry Queue
Rate Limiter
알림 Template
User Preference
Deduplication
Monitoring
Event Tracking

핵심은 단순히 알림을 보내는 것에 그치지 않고 다음 사항을 함께 고려하는 것임.

알림의 유실 방지
중복 발송 억제
대량 요청 처리
외부 서비스 장애 대응
사용자별 알림 설정
전송률 제한
시스템 모니터링
알림 효과 분석

[대규모 시스템 설계 스터디] 9장 정리

Sat, 08 Aug 2026 10:05:55 GMT

웹 크롤러 설계

1. 웹 크롤러란

웹 크롤러는 웹에 새로 올라오거나 갱신된 콘텐츠를 찾아내고 수집하는 시스템임.

수집 대상은 다음과 같이 다양할 수 있음.

웹 페이지
이미지
비디오
PDF
기타 웹 문서

대표적인 활용 사례는 다음과 같음.

검색 엔진 인덱싱

크롤러는 웹 페이지를 발견하고 수집하여 검색 엔진의 인덱싱 시스템에 전달함
대표적인 예로 Google Search에서 사용하는 웹 크롤러인 Googlebot이 있음

웹 아카이빙

웹에 존재하는 정보를 장기간 보관하기 위해 수집하는 작업
많은 국립도서관과 기관에서 웹사이트를 주기적으로 수집하여 보존함
예시
- 미국 의회도서관
- EU 웹 아카이브

웹 마이닝

웹에서 대량의 데이터를 수집한 뒤 유용한 정보를 추출하는 작업
예를 들어 금융 기업이 기업의 연차 보고서나 주주총회 자료를 수집해 기업의 사업 방향을 분석할 수 있음

웹 모니터링

웹에서 특정 정보나 콘텐츠가 새롭게 등장하는지 지속적으로 감시하는 용도
저작권 또는 상표권 침해 사례를 탐지하는 데 활용 가능
예를 들어 웹에서 불법 복제 콘텐츠를 탐지하는 시스템에 crawler를 사용할 수 있음

2. 웹 크롤러 설계 시 고려 사항

웹 크롤러의 복잡도는 수집해야 하는 데이터의 규모에 따라 크게 달라짐.

따라서 설계를 시작하기 전에 다음 내용을 명확하게 해야 함.

얼마나 많은 페이지를 수집해야 하는가
어떤 종류의 콘텐츠를 수집해야 하는가
얼마나 자주 다시 방문해야 하는가
수집한 데이터를 얼마나 오래 저장해야 하는가
특정 사이트에 얼마나 자주 요청할 수 있는가

대규모 웹 크롤러가 만족해야 할 주요 속성은 다음과 같음.

규모 확장성

웹은 매우 크므로 한 서버만으로 모든 페이지를 수집하기 어려움
여러 서버와 여러 작업 스레드를 사용하여 병렬로 처리할 필요가 있음

안정성

웹에는 다음과 같은 비정상적인 상황이 존재할 수 있음.

잘못 작성된 웹 페이지
응답하지 않는 서버
매우 느린 서버
악성 콘텐츠
무한히 생성되는 URL

따라서 특정 페이지의 문제가 전체 크롤러 시스템 장애로 이어지지 않도록 해야 함.

예절

특정 웹사이트에 짧은 시간 동안 지나치게 많은 요청을 보내서는 안 됨
대상 사이트의 robots.txt 정책과 요청 속도 제한을 고려해야 함

확장성

새로운 콘텐츠 형식을 쉽게 추가할 수 있어야 함
이미지, PDF, 동영상 등 새로운 콘텐츠를 지원할 때 전체 시스템을 다시 설계하지 않아도 되는 구조가 바람직함

3. 기본 크롤링 알고리즘

웹 크롤러의 기본적인 동작 방식은 다음과 같음.

시작 URL 집합을 입력받음
해당 URL이 가리키는 웹 페이지를 다운로드
다운로드한 페이지에서 새로운 URL 추출
새롭게 발견한 URL을 다운로드할 URL 목록에 추가
위 과정을 반복

개념적으로는 다음과 같음.

시작 URL
→ 페이지 다운로드
→ URL 추출
→ 새로운 URL 저장
→ 다시 다운로드
→ 반복

하지만 실제 웹은 매우 크기 때문에 단순히 이 알고리즘만 반복하는 것으로는 대규모 크롤러를 구현하기 어려움.

4. 요구사항

다음 규모를 처리하는 웹 크롤러를 설계한다고 가정함.

페이지 다운로드 수

매달 10억 개의 웹 페이지 다운로드

평균 QPS:

10억 ÷ 30일 ÷ 24시간 ÷ 3,600초
≈ 386페이지/초
≈ 약 400 QPS

Peak QPS를 평균의 2배로 가정:

400 × 2
= 약 800 QPS

저장 용량

웹 페이지 평균 크기를 500KB라고 가정함.

10억 페이지 × 500KB
≈ 500TB/월

5년 동안 데이터를 보관한다고 가정하면:

500TB × 12개월 × 5년
= 30PB

따라서 약 30PB 규모의 저장 공간이 필요함.

5. 개략적인 시스템 구성

대규모 웹 크롤러는 다음과 같은 주요 컴포넌트로 구성할 수 있음.

시작 URL 집합
미수집 URL 저장소
HTML 다운로더
DNS 변환기
콘텐츠 파서
중복 콘텐츠 탐지
콘텐츠 저장소
URL 추출기
URL 필터
방문 URL 관리
URL 저장소

6. 시작 URL 집합

시작 URL은 웹 크롤러가 크롤링을 시작하는 출발점임.

전체 웹을 크롤링하려면 가능한 많은 페이지로 연결될 수 있는 URL을 선택하는 것이 중요함.

예를 들어 다음과 같은 기준으로 시작 URL을 구성할 수 있음.

국가별 주요 웹사이트
카테고리별 주요 웹사이트
인기 웹사이트
기존에 알고 있는 도메인 목록

시작 URL을 선택하는 절대적인 정답은 없으며 크롤러의 목적에 따라 달라짐.

7. 미수집 URL 저장소

미수집 URL 저장소는 아직 다운로드하지 않은 URL을 관리하는 컴포넌트임.

이를 일반적으로 URL Frontier라고 부름.

기본적인 BFS 구조에서는 FIFO 큐처럼 볼 수 있음.

URL 발견
→ URL Frontier 저장
→ 순서대로 다운로드

하지만 실제 대규모 크롤러에서는 단순 FIFO 큐 하나만 사용하지 않음.

다음 기능이 추가로 필요하기 때문임.

URL 우선순위
웹사이트별 요청 속도 제한
재수집 시점 관리
크롤러 예절 유지

따라서 실제 URL Frontier는 여러 개의 큐와 스케줄링 로직으로 구성됨.

8. HTML 다운로더

HTML 다운로더는 인터넷에서 실제 웹 페이지를 다운로드하는 컴포넌트임.

다운로드할 URL은 URL Frontier에서 전달받음.

URL Frontier
→ HTML Downloader
→ 웹 서버에 HTTP 요청
→ 웹 페이지 다운로드

9. 도메인 이름 변환기

웹 페이지를 다운로드하려면 URL의 도메인 이름을 IP 주소로 변환해야 함.

예:

www.example.com
→ DNS
→ 93.184.216.34

HTML 다운로더는 DNS 시스템을 사용하여 대상 서버의 IP 주소를 알아냄.

10. 콘텐츠 파서

웹 페이지를 다운로드한 후에는 페이지를 파싱하고 검증해야 함.

웹에는 다음과 같은 비정상적인 콘텐츠가 존재할 수 있음.

잘못된 HTML
지나치게 큰 문서
악성 콘텐츠
파싱할 수 없는 데이터

다운로드와 파싱은 작업 특성이 다르므로 별도 컴포넌트로 분리하면 다음 장점이 있음.

다운로드와 파싱을 독립적으로 확장 가능
파서 장애가 다운로더 전체에 영향을 주는 것을 줄일 수 있음
네트워크 중심 작업과 CPU 중심 작업 분리 가능

11. 중복 콘텐츠 탐지

웹에는 동일하거나 매우 유사한 콘텐츠가 여러 URL에 존재하는 경우가 많음.

연구에 따라 상당한 비율의 웹 페이지가 중복 콘텐츠일 수 있음.

동일한 콘텐츠를 반복해서 저장하면 다음 문제가 발생함.

저장 공간 낭비
네트워크 사용량 증가
인덱싱 비용 증가

이를 방지하기 위해 페이지 콘텐츠의 해시값이나 체크섬을 사용할 수 있음.

웹 페이지 콘텐츠
→ Hash
→ 콘텐츠 해시값

이미 같은 해시값이 존재한다면 중복 콘텐츠로 판단할 수 있음.

12. 콘텐츠 저장소

다운로드한 HTML 문서를 장기간 보관하는 저장소임.

저장소 기술을 선택할 때는 다음 요소를 고려해야 함.

데이터 크기
데이터 형식
접근 빈도
데이터 보관 기간

대규모 시스템에서는 디스크와 메모리를 함께 활용할 수 있음.

자주 접근하는 데이터 → 메모리 또는 캐시
대량의 원본 데이터 → 디스크 또는 객체 저장소

13. URL 추출기

다운로드한 HTML 페이지를 분석하여 새로운 링크를 추출하는 역할을 함.

예를 들어 다음 HTML이 있다고 가정함.

뉴스

현재 페이지가 다음과 같다면:

https://example.com

상대 경로 /news/1을 절대 경로로 변환함.

https://example.com/news/1

14. URL 필터

URL 필터는 크롤링할 필요가 없는 URL을 제거하는 역할을 함.

예를 들어 다음 URL을 제외할 수 있음.

특정 콘텐츠 타입
특정 파일 확장자
접속 시 오류가 발생하는 URL
접근 제외 목록에 포함된 URL
크롤러 목적과 관계없는 URL

특정 콘텐츠 타입이나 파일 확장자를 제외하는 이유는 크롤러의 목적과 관계없는 파일에 시간, 네트워크, 저장 공간을 낭비하지 않기 위해서임.

예를 들어 일반적인 HTML 중심 크롤러라면 다음 파일은 제외할 수 있음.

.jpg
.mp4
.zip
.exe

이미지나 동영상은 파일 크기가 크고 HTML 링크 분석 대상이 아닐 수 있음.

또한 HTML 파서는 이미지나 실행 파일을 직접 분석할 수 없음.

다만 크롤러의 목적이 이미지 검색이나 동영상 검색이라면 이러한 콘텐츠도 수집 대상으로 포함할 수 있음.

15. 이미 방문한 URL 관리

새 URL을 발견할 때마다 이미 발견하거나 방문한 URL인지 확인해야 함.

새로운 URL 발견
→ 이미 본 URL인지 확인
→ 처음 보는 URL이면 URL Frontier에 추가
→ 이미 처리한 URL이면 제외

중복 URL을 제거하지 않으면 다음 문제가 발생할 수 있음.

동일 페이지 반복 다운로드
대상 서버 부하 증가
네트워크 자원 낭비
크롤러가 순환 링크에 의해 무한 반복할 가능성

방문 여부를 추적하기 위한 자료구조로 다음을 사용할 수 있음.

해시 테이블
블룸 필터

16. URL 저장소

이미 방문하거나 발견한 URL을 저장하는 시스템임.

대규모 검색 엔진 크롤러에서는 URL 수가 수억~수십억 개 이상이 될 수 있으므로 모든 URL을 메모리에만 저장하기 어려움.

따라서 지속적인 저장소와 메모리를 함께 사용하는 방식을 고려할 수 있음.

17. DFS와 BFS

웹은 그래프로 표현할 수 있음.

웹 페이지 = 노드
하이퍼링크 = 간선

따라서 웹 크롤링은 웹 그래프의 간선을 따라 이동하면서 노드를 방문하는 과정으로 볼 수 있음.

대표적인 그래프 탐색 방법은 다음과 같음.

DFS

DFS는 특정 경로를 계속 깊게 탐색함.

웹은 사실상 깊이를 예측하기 어려울 정도로 거대한 그래프이므로 특정 사이트나 경로만 지나치게 깊게 탐색할 수 있음.

따라서 일반적인 웹 크롤러에는 적합하지 않음.

BFS

BFS는 가까운 페이지부터 넓게 탐색함.

FIFO 큐를 사용하여 구현할 수 있으므로 웹 크롤러에서 기본적인 접근 방식으로 많이 사용됨.

하지만 단순 BFS에도 문제가 있음.

18. 단순 BFS의 문제점

문제 1. 특정 서버에 요청 집중

한 페이지에서 추출한 많은 URL이 같은 호스트를 가리킬 수 있음.

예:

example.com
 ├─ /news/1
 ├─ /news/2
 ├─ /news/3
 ├─ /news/4
 └─ /news/5

이 URL들을 병렬로 동시에 다운로드하면:

example.com
← 다수의 HTTP 요청

특정 웹 서버에 요청이 집중되어 과부하를 발생시킬 수 있음.

이런 크롤러는 예의 없는 크롤러로 간주될 수 있음.

문제 2. URL 우선순위가 없음

일반적인 BFS는 모든 URL을 동일한 우선순위로 처리함.

하지만 실제 웹 페이지의 중요도는 서로 다름.

예를 들어 다음 요소를 고려할 수 있음.

PageRank
사용자 트래픽
페이지 갱신 빈도
사이트 신뢰도
콘텐츠 중요도

따라서 중요한 페이지를 우선적으로 크롤링할 수 있는 시스템이 필요함.

19. 예의 바른 크롤러

예의 바른 크롤러는 동일 웹사이트에 대해서 한 번에 한 페이지만 요청하는 원칙을 지켜야 함.

같은 웹사이트의 페이지를 다운로드하는 작업은 시간차를 두고 수행하도록 구성할 수 있음.

이를 위해 웹사이트의 호스트명과 다운로드 작업을 수행하는 작업 스레드 사이의 관계를 유지함.

각 작업 스레드는 별도의 FIFO 큐에서 URL을 가져와 처리함.

주요 컴포넌트는 다음과 같음.

큐 라우터

동일한 호스트에 속하는 URL이 항상 같은 큐로 전달되도록 함

예:

example.com/a ─┐
example.com/b ─┼→ Queue 1
example.com/c ─┘

매핑 테이블

호스트 이름과 큐의 관계를 저장함.

example.com → Queue 1
google.com  → Queue 2

FIFO 큐

같은 호스트의 URL을 저장
큐 내부에서는 순차적으로 URL 처리

큐 선택기

여러 큐를 순회
처리할 URL을 선택
해당 URL을 담당 작업 스레드에 전달

작업 스레드

전달받은 URL 다운로드
동일 호스트에 대한 요청은 순차적으로 처리
요청 사이에 일정한 시간 간격을 둘 수 있음

20. URL 우선순위

웹에 존재하는 모든 페이지가 동일한 중요도를 가지는 것은 아님.

크롤러는 가치가 높은 페이지를 먼저 수집하는 것이 효율적임.

URL의 우선순위를 결정할 때 다음 요소를 사용할 수 있음.

PageRank
사용자 트래픽
페이지 갱신 빈도
사이트 신뢰도

우선순위 처리는 다음 컴포넌트로 구성할 수 있음.

순위 결정 장치

URL을 입력받음
URL의 우선순위를 계산

우선순위 큐

우선순위별로 URL을 별도의 큐에 저장함.

높은 우선순위 Queue
중간 우선순위 Queue
낮은 우선순위 Queue

큐 선택기

높은 우선순위 큐에서 URL을 더 자주 선택
낮은 우선순위 URL도 완전히 굶지 않도록 확률적으로 선택 가능

21. 전면 큐와 후면 큐

URL Frontier는 크게 다음 두 역할로 나눌 수 있음.

전면 큐

URL의 우선순위 관리
어떤 페이지를 먼저 크롤링할 것인지 결정

후면 큐

크롤링 예절 관리
동일 호스트에 대한 요청 속도 제한
호스트별 URL 큐 관리

정리하면:

새로운 URL
→ 전면 큐
→ 우선순위 결정
→ 후면 큐
→ 호스트별 속도 제어
→ Downloader

22. 신선도

웹 페이지는 지속적으로 변경됨.

새로운 페이지 생성
기존 페이지 수정
페이지 삭제

따라서 한 번 다운로드한 페이지도 일정 시간이 지나면 다시 수집할 필요가 있음.

하지만 모든 URL을 동일한 주기로 다시 크롤링하면 막대한 자원이 필요함.

따라서 다음 정보를 이용하여 재수집 주기를 결정할 수 있음.

과거 페이지 변경 빈도
페이지 중요도
마지막 변경 시각
사이트 특성

자주 변경되는 중요한 페이지는 자주 방문하고, 거의 변경되지 않는 페이지는 더 긴 주기로 방문하도록 최적화할 수 있음.

23. URL Frontier 저장 구조

검색 엔진 수준의 크롤러는 처리해야 하는 URL 수가 매우 많음.

모든 URL을 메모리에 저장하면:

메모리 비용 증가
장애 발생 시 상태 손실 가능
규모 확장 어려움

반대로 모든 데이터를 디스크에서 직접 처리하면 디스크 I/O가 병목이 될 수 있음.

따라서 메모리와 디스크를 함께 사용하는 하이브리드 방식이 적절함.

대부분의 URL
→ 디스크

곧 처리할 URL
→ 메모리 버퍼

메모리 버퍼의 데이터는 주기적으로 지속 저장장치에 기록함.

24. robots.txt

robots.txt는 로봇 제외 프로토콜이라고도 하며, 웹사이트 운영자가 crawler와 소통하기 위한 표준적인 방법임.

사이트 운영자는 crawler별로 특정 URL 경로에 대한 접근 허용 또는 제외 규칙을 정의할 수 있음.

예:

User-agent: *
Disallow: /admin/
Allow: /

크롤러는 사이트를 수집하기 전에 해당 사이트의 robots.txt를 확인하고 자신의 User-Agent에 적용되는 규칙을 확인해야 함.

다만 robots.txt는 보안 시스템이 아님.

즉 사이트에 대한 실제 접근 자체를 기술적으로 막는 것이 아니라 crawler에게 정책을 전달하는 규칙임.

25. Amazon robots.txt에서 본 crawler별 정책 차이

2026년 8월 amazon.com/robots.txt를 확인했을 때 crawler의 User-Agent에 따라 서로 다른 접근 정책이 적용되어 있는 것을 확인할 수 있었음.

일반적인 검색 crawler에는 특정 경로만 제외하는 방식으로 설정되어 있는 반면, 일부 AI 서비스 관련 crawler는 더 강한 제한이 적용되어 있을 수 있음.

이 차이가 왜 발생하는지 궁금하여 일반 crawler와 AI 서비스 crawler의 차이를 조사해 봄.

26. 일반 crawler와 AI crawler

crawler는 기술적으로 모두 웹 페이지를 자동으로 요청하고 수집하는 프로그램이라는 점에서는 비슷함.

차이는 주로 수집 목적과 운영 주체에서 발생함.

일반적인 crawler

목적에 따라 다음 용도로 사용될 수 있음.

검색 엔진 색인
데이터 수집
사이트 분석
웹 아카이빙
가격 비교

대표적으로 Googlebot은 검색 엔진 색인을 위해 Google이 운영하는 crawler임.

AI 서비스 관련 crawler

AI 서비스 사업자가 운영하는 crawler 역시 목적에 따라 여러 종류로 구분될 수 있음.

예:

모델 학습 또는 개선용 데이터 수집
AI 검색을 위한 웹 페이지 수집
최신 정보 기반 답변 생성을 위한 콘텐츠 접근

따라서 모든 AI crawler가 반드시 모델 학습만을 목적으로 하는 것은 아님.

검색 엔진 crawler와 AI crawler의 가장 큰 차이는 crawler의 기본 동작 구조보다는 수집된 데이터를 어디에 사용하는지에 있음.

27. robots.txt는 실제 접근 차단 기능인가

robots.txt는 강제적인 접근 통제 시스템이 아님.

robots.txt
→ "이 경로는 크롤링하지 말아 달라"는 정책 전달

정상적인 crawler는 이러한 규칙을 준수함.

하지만 악의적인 crawler가 robots.txt를 무시하는 것도 기술적으로 가능함.

실제로 접근을 막으려면 별도의 보안 기술을 사용해야 함.

예:

WAF
IP 차단
인증
Rate Limiting
CAPTCHA

즉:

robots.txt
= crawler 행동 규칙

WAF / 인증 / IP 차단
= 실제 접근 제어

28. 일반 사용자가 AI crawler를 사용할 수 있는가

GPTBot이나 Googlebot처럼 특정 서비스 사업자가 공식적으로 운영하는 crawler는 일반 사용자가 직접 실행하거나 제어할 수 있는 서비스가 아님.

해당 crawler는 서비스 사업자가 자체 인프라에서 운영함.

예를 들어:

Googlebot
→ Google이 직접 운영

GPTBot
→ OpenAI가 직접 운영

따라서 사용자가 명령을 내려 Googlebot이나 GPTBot 자체를 직접 실행시키는 것은 불가능함.

다만 일반 사용자가 직접 웹 crawler를 개발하는 것은 가능함.

예:

직접 만든 crawler
→ 웹 페이지 수집
→ AI 모델에 전달
→ 분석 또는 요약

즉 AI와 crawler를 결합한 시스템 자체는 직접 만들 수 있지만, 특정 기업이 운영하는 공식 crawler를 사용하는 것은 별개의 문제임.

29. HTML 다운로더 성능 최적화

분산 크롤링

크롤링 성능을 높이기 위해 다운로드 작업을 여러 서버에 분산할 수 있음.

Crawler Server 1
Crawler Server 2
Crawler Server 3
...

각 서버는 여러 작업 스레드를 사용하여 동시에 페이지를 다운로드할 수 있음.

DNS 조회 결과 캐싱

DNS 조회는 네트워크 통신이 필요한 작업이므로 반복적으로 수행하면 오버헤드가 발생함.

따라서 다음 정보를 캐시에 저장할 수 있음.

도메인 이름 → IP 주소

예:

example.com → 93.184.216.34

동일한 도메인을 다시 방문할 때 DNS 서버에 매번 요청하지 않고 캐시된 결과를 사용할 수 있음.

캐시된 DNS 정보는 TTL이나 별도의 갱신 정책에 따라 주기적으로 갱신해야 함.

지역성

크롤링 서버를 대상 웹 서버와 지리적으로 가까운 지역에 배치하면 네트워크 지연 시간을 줄일 수 있음.

지역성은 다음 컴포넌트에 활용 가능함.

크롤링 서버
캐시
메시지 큐
저장소

짧은 타임아웃

일부 웹 서버는 다음과 같은 문제가 있을 수 있음.

응답이 매우 느림
연결은 되었지만 데이터를 보내지 않음
아예 응답하지 않음

이러한 서버를 무한정 기다리면 작업 스레드가 계속 점유됨.

따라서 최대 대기 시간을 설정해야 함.

응답 시간 > Timeout
→ 요청 중단
→ 실패 처리

30. 안정성

성능뿐 아니라 장애 상황에서도 시스템이 계속 동작하도록 설계해야 함.

안정 해시

다운로더 서버에 URL을 분산할 때 안정 해시를 사용할 수 있음.

장점:

서버 추가 시 일부 URL만 재배치
서버 제거 시 일부 URL만 다른 서버로 이동
서버 변경에 따른 전체 데이터 재배치 감소

크롤링 상태 저장

장애 발생 후 처음부터 모든 작업을 다시 시작하지 않도록 다음 정보를 지속 저장장치에 기록함.

이미 방문한 URL
URL Frontier 상태
수집 완료 여부
수집된 콘텐츠

이를 통해 장애 발생 이후 이전 상태에서 작업을 재개할 수 있음.

예외 처리

대규모 시스템에서는 오류를 완전히 없애기 어려움.

따라서 일부 요청 실패가 전체 시스템 중단으로 이어지지 않도록 해야 함.

예:

재시도
실패 큐
오류 로그
특정 URL 격리

데이터 검증

다운로드한 데이터가 정상적인지 확인해야 함.

예:

문서 크기 제한
콘텐츠 타입 확인
HTML 유효성 확인
악성 파일 여부 검사

31. 확장성

웹에는 HTML 외에도 다양한 콘텐츠가 존재함.

이미지
PDF
동영상
문서 파일

새로운 콘텐츠 형식을 지원할 때마다 전체 크롤러를 수정하는 구조는 유지보수가 어려움.

따라서 콘텐츠 유형별 처리기를 독립적인 모듈로 구현하는 것이 좋음.

Downloader
   ↓
Content Type
   ├─ HTML Parser
   ├─ Image Processor
   ├─ PDF Parser
   └─ Video Processor

32. 유해하거나 불필요한 콘텐츠 처리

중복 콘텐츠

웹 페이지의 해시값이나 체크섬을 이용하여 중복 콘텐츠 탐지 가능.

Content
→ Hash
→ 기존 Hash와 비교

Spider Trap

Spider Trap은 크롤러가 끝없이 URL을 따라가도록 만드는 웹 구조임.

예:

/page?id=1
/page?id=2
/page?id=3
...

또는 URL이 계속 길어지는 구조:

/a
/a/a
/a/a/a
/a/a/a/a
...

대응 방법:

URL 최대 길이 제한
페이지 깊이 제한
비정상적으로 많은 URL을 생성하는 사이트 탐지
반복 패턴 탐지
문제가 지속되는 사이트를 차단 목록에 추가

URL 길이 제한만으로 모든 Spider Trap을 막을 수 있는 것은 아님.

데이터 노이즈

웹 페이지에는 실제 콘텐츠 분석에 도움이 되지 않는 정보도 많음.

예:

광고
JavaScript 코드
추적 코드
스팸 URL
반복 메뉴
불필요한 UI 요소

이러한 데이터를 제거하면 저장 공간과 후속 처리 비용을 줄일 수 있음.

33. 전체 크롤링 흐름 정리

시작 URL
    ↓
URL Frontier
    ↓
우선순위 및 호스트별 스케줄링
    ↓
DNS 조회
    ↓
HTML Downloader
    ↓
Content Parser
    ↓
중복 콘텐츠 확인
    ↓
Content Storage
    ↓
URL Extractor
    ↓
URL Filter
    ↓
이미 방문한 URL인지 확인
    ↓
새 URL이면 URL Frontier에 추가
    ↓
반복

URL Frontier 내부에서는 다음 두 가지가 핵심임.

전면 큐
→ 어떤 URL을 먼저 크롤링할 것인지 결정

후면 큐
→ 특정 웹사이트에 요청이 몰리지 않도록 제어

대규모 웹 크롤러에서는 단순히 많은 페이지를 빠르게 다운로드하는 것뿐 아니라 우선순위, 신선도, 중복 제거, 크롤링 예절, 장애 복구를 함께 고려하는 것이 중요함.

[대규모 시스템 설계 스터디] 8장 정리

Thu, 06 Aug 2026 04:42:55 GMT

URL 단축기 설계

1. URL 단축 시스템의 기본 기능

URL 단축
- 주어진 긴 URL을 훨씬 짧은 URL로 변환
URL 리디렉션
- 단축 URL로 HTTP 요청이 들어오면 원래 URL로 안내
비기능 요구사항
- 높은 가용성
- 높은 규모 확장성
- 장애 감내

2. 요구사항

2.1 쓰기 연산

매일 1억 개의 단축 URL 생성

초당 평균 쓰기 연산:

1억 ÷ 24 ÷ 3,600
≈ 1,160회/초

2.2 읽기 연산

읽기와 쓰기의 비율을 10:1로 가정
초당 평균 읽기 연산:

1,160 × 10
= 11,600회/초

2.3 저장할 레코드 수

10년간 운영한다고 가정

1억 × 365 × 10
= 3,650억 개

10년 동안 약 3,650억 개의 레코드 보관 필요

2.4 저장 용량

단축 전 URL의 평균 길이를 100바이트로 가정

3,650억 × 100바이트
= 36.5TB

10년 동안 필요한 저장 용량은 약 36.5TB

3. API 엔드포인트

클라이언트는 서버가 제공하는 API 엔드포인트를 통해 URL 단축 시스템과 통신함.

이번 설계는 REST 스타일로 구성함.

3.1 URL 단축 엔드포인트

새로운 단축 URL을 생성하기 위한 엔드포인트
클라이언트는 단축할 URL을 요청에 담아 POST 방식으로 전송

POST /api/v1/data/shorten

3.2 URL 리디렉션 엔드포인트

단축 URL 요청을 원래 URL로 리디렉션하기 위한 엔드포인트

GET /api/v1/shortUrl

4. URL 리디렉션 응답 절차

클라이언트가 단축 URL 서버에 요청 전송
단축 URL 서버가 단축 URL에 대응하는 원래 URL 조회
원래 URL을 HTTP 응답의 Location 헤더에 포함
클라이언트가 Location 헤더에 지정된 원래 URL로 이동
원래 URL 서버 방문

5. HTTP 301과 302의 차이

두 상태 코드는 모두 리디렉션에 사용되지만 의미와 활용 방식에 차이가 있음.

5.1 301 Moved Permanently

해당 URL의 요청 처리 위치가 Location 헤더의 URL로 영구적으로 변경되었음을 의미
브라우저나 중간 캐시에 리디렉션 정보가 저장될 가능성이 높음
이후 같은 단축 URL을 요청할 때 단축 URL 서버를 거치지 않고 원래 URL로 직접 이동할 수 있음
단축 URL 서버의 부하를 줄이는 데 유리

5.2 302 Found

요청이 현재는 Location 헤더에 지정된 다른 URL에서 임시로 처리됨을 의미
일반적으로 301보다 장기적으로 캐시될 가능성이 낮음
요청할 때마다 단축 URL 서버를 거쳐 원래 URL로 이동할 가능성이 높음
단, 명시적인 캐시 정책에 따라 캐시될 수도 있음

5.3 선택 기준

301이 적합한 경우

리디렉션 대상이 영구적으로 유지됨
단축 URL 서버의 부하를 줄이는 것이 중요함
모든 클릭 요청을 직접 추적할 필요가 적음

302가 적합한 경우

클릭 수와 접속 위치 등의 트래픽 분석이 중요함
단축 URL의 목적지가 나중에 변경될 수 있음
요청이 단축 URL 서버를 거치도록 유지할 필요가 있음

6. URL 리디렉션 구현

URL 리디렉션을 구현하는 가장 직관적인 방법은 해시 테이블을 사용하는 것임.

해시 테이블에는 다음과 같은 쌍을 저장함.

<단축 URL, 원래 URL>

원래 URL 조회:

원래 URL = hashTable.get(단축 URL)

조회한 원래 URL을 HTTP 301 또는 302 응답의 Location 헤더에 넣어 전송함.

7. 단축 코드 생성 시 고려할 점

긴 URL을 단축 코드로 변환할 때는 단축 코드가 가능한 한 고르게 분포하도록 해야 함.

다만 고정 길이의 단축 코드를 사용하면 서로 다른 긴 URL이 같은 단축 코드로 변환되는 충돌 가능성을 완전히 없앨 수 없음.

예를 들어 7자리 단축 코드를 사용하면 출력 가능한 코드 수는 유한함.

62⁷ = 약 3.52조 개

따라서 다음 조건이 필요함.

단축 코드가 고르게 분포하도록 생성
충돌 발생 여부 확인
충돌 발생 시 새로운 코드 생성
동일한 코드가 중복 저장되지 않도록 데이터베이스 제약 설정

또한 단축 코드에서 원래 URL을 직접 복원하는 방식이 아님.

단축 코드
→ 데이터베이스 또는 캐시 조회
→ 원래 URL 반환

원래 URL은 별도 저장소에 반드시 보관해야 함.

구체적인 설계안

8. 데이터 모델

모든 <단축 URL, 원래 URL> 쌍을 메모리의 해시 테이블에 저장하기에는 메모리 용량이 제한적이고 비용도 큼.

따라서 전체 데이터는 관계형 데이터베이스에 영구 저장함.

8.1 데이터베이스 조회 성능

관계형 데이터베이스는 메모리 해시 테이블보다 느리지만, 단축 코드에 인덱스를 설정하면 전체 테이블을 탐색하지 않고 빠르게 조회 가능함.

예시:

SELECT long_url
FROM urls
WHERE short_code = ?;

8.2 캐시 활용

데이터베이스만 사용하는 것이 아니라 Redis 등의 캐시를 함께 사용함.

조회 흐름:

단축 URL 요청
→ 캐시 조회
→ 캐시 적중: 원래 URL 반환
→ 캐시 미스: 데이터베이스 조회
→ 조회 결과를 캐시에 저장
→ 원래 URL로 리디렉션

데이터베이스
- 전체 URL 데이터의 영구 저장 담당
캐시
- 자주 조회되는 URL의 빠른 응답 담당

9. 단축 코드 문자 구성

편의상 단축 URL의 고유 코드 부분을 hashValue라고 부름.

hashValue는 다음 문자로 구성함.

숫자: 0~9
소문자: a~z
대문자: A~Z

사용 가능한 전체 문자 수:

10 + 26 + 26
= 62개

10. 단축 코드 길이 계산

10년 동안 약 3,650억 개의 URL을 생성할 예정이므로 다음 조건을 만족하는 최소 n을 구해야 함.

62ⁿ ≥ 3,650억

계산 결과:

62⁶ = 56,800,235,584
약 568억

62⁷ = 3,521,614,606,208
약 3.52조

따라서 필요한 최소 길이는 7자리임.

11. 단축 코드 생성 방식

단축 코드를 생성하는 방식은 다음 두 가지로 나눌 수 있음.

해시 후 충돌 해소
유일 ID의 Base62 변환

Base62는 해시 함수가 아니라 숫자를 62진수 문자열로 표현하는 인코딩 방식임.

12. 해시 후 충돌 해소

12.1 기본 과정

긴 URL에 해시 함수 적용
생성된 해시값에서 필요한 길이만큼 문자 선택
현재 설계에서는 앞의 7글자를 단축 코드로 사용
데이터베이스에서 해당 코드의 존재 여부 확인
충돌하지 않으면 저장
충돌하면 새로운 값을 만들어 다시 해싱

예시:

hash(longURL)
→ 충돌 발생

hash(longURL + "1")
→ 다시 확인

hash(longURL + "2")
→ 다시 확인

즉, 충돌이 발생하면 원래 URL에 사전에 정한 문자열이나 salt를 추가한 뒤 다시 해싱함.

단축 코드 자체에 문자열을 계속 덧붙이는 방식은 7자리 고정 길이 요구와 맞지 않으므로 사용하지 않음.

12.2 장점

별도의 순차적 ID 생성기가 없어도 단축 코드 생성 가능
동일한 입력에 대해 일정한 결과를 만들도록 구현 가능

12.3 단점

충돌 가능성 존재
생성한 코드가 이미 사용 중인지 확인해야 함
충돌이 반복되면 데이터베이스 질의와 재시도 증가
같은 URL을 중복 생성할지 재사용할지에 대한 정책 필요

13. 충돌 검사를 위한 데이터베이스와 블룸 필터

해시 후 충돌 해소 방식에서는 생성한 단축 코드가 이미 존재하는지 확인해야 함.

기본 흐름:

단축 코드 생성
→ 데이터베이스 존재 여부 확인
→ 충돌 시 코드 재생성
→ 다시 데이터베이스 확인

여러 서버가 동시에 같은 단축 코드를 생성할 가능성에 대비해 데이터베이스에 유일 제약을 설정할 수 있음.

UNIQUE(short_code)

13.1 블룸 필터 활용

블룸 필터는 데이터베이스를 완전히 대체하는 것이 아니라 불필요한 데이터베이스 조회를 줄이는 보조 자료구조임.

블룸 필터의 판단 결과:

없음
→ 확실히 존재하지 않음

있음
→ 존재할 수도 있음

처리 흐름:

새 단축 코드 생성
→ 블룸 필터 확인

블룸 필터가 없다고 판단한 경우

해당 코드는 확실히 존재하지 않음
바로 데이터베이스 저장 시도 가능

블룸 필터가 있을 수 있다고 판단한 경우

거짓 양성 가능성 존재
데이터베이스에서 실제 존재 여부 확인 필요

따라서 블룸 필터를 사용하면 확실히 존재하지 않는 코드에 대한 데이터베이스 조회를 줄일 수 있음.

14. Base62 변환

Base62는 유일한 숫자 ID를 62개의 문자로 구성된 짧은 문자열로 변환하는 방식임.

사용 문자:

0-9
a-z
A-Z

14.1 동작 과정

유일한 숫자 ID 생성
→ 숫자 ID를 Base62로 변환
→ 단축 코드 생성

예를 들어 숫자 ID가 125라면 이를 Base62 문자열로 변환하여 짧은 코드로 표현 가능함.

14.2 Base62를 사용하는 이유

한 자리에서 62개의 값을 표현 가능
10진수보다 같은 숫자를 더 짧은 문자열로 표현 가능
URL에 사용하기 적합한 영문자와 숫자로 구성
숫자 ID가 유일하면 Base62 결과도 유일함
해시 충돌이 발생하지 않음

14.3 단점

순차적인 숫자 ID를 사용하면 단축 코드도 어느 정도 예측 가능
전체 URL 생성량이나 생성 순서가 외부에 노출될 가능성 존재
전역적으로 유일한 ID 생성기가 필요함

15. 두 방식 비교

구분	해시 후 충돌 해소	유일 ID의 Base62 변환
입력값	긴 URL	유일 숫자 ID
충돌 가능성	있음	ID가 유일하면 없음
충돌 검사	필요	불필요
DB 조회	충돌 확인을 위해 필요	URL 저장 및 조회에 사용
별도 ID 생성기	불필요	필요
코드 예측 가능성	상대적으로 낮음	순차 ID 사용 시 높음
구현 복잡도	충돌 처리 필요	ID 생성기 관리 필요

16. Base62 방식의 처리 흐름

클라이언트가 긴 URL을 전달
ID 생성기가 전역적으로 유일한 숫자 ID 생성
숫자 ID를 Base62 문자열로 변환
Base62 결과를 단축 코드로 사용
데이터베이스에 새로운 레코드 저장
생성된 단축 URL을 클라이언트에게 반환

기본 레코드:

ID | shortURL | longURL

ID는 전역적으로 유일해야 함.

17. 데이터 저장 방식

Base62는 숫자 ID와 단축 코드 사이의 가역적인 변환임.

따라서 두 가지 데이터 모델을 사용할 수 있음.

17.1 단축 코드를 직접 저장하는 방식

ID | short_code | long_url | created_at

조회 과정:

short_code
→ 데이터베이스 조회
→ long_url 반환

17.2 단축 코드를 숫자 ID로 복원하는 방식

ID | long_url | created_at

조회 과정:

short_code
→ Base62 디코딩
→ numeric ID
→ 데이터베이스 조회
→ long_url 반환

이 방식은 short_code를 별도 컬럼으로 저장하지 않아도 됨.

18. ID 생성기

Base62 방식에서는 입력으로 사용할 숫자 ID가 전역적으로 유일해야 함.

선택 가능한 방식:

단일 쓰기 데이터베이스

auto_increment
데이터베이스 sequence

여러 데이터베이스 샤드 또는 데이터센터

Snowflake
ID 구간 할당
별도의 분산 ID 생성기

현재 요구사항은 평균 초당 약 1,160개의 쓰기 요청임.

사용하는 데이터베이스와 하드웨어가 해당 쓰기 부하를 감당할 수 있다면 단일 데이터베이스의 auto_increment나 sequence로도 구현 가능함.

여러 데이터베이스에서 독립적으로 ID를 발급해야 한다면 Snowflake 등의 분산 ID 생성 방식을 고려해야 함.

19. 전체 처리 흐름

19.1 URL 생성

클라이언트
→ 긴 URL 전송
→ 유일 ID 생성
→ Base62 변환
→ DB에 ID와 원래 URL 저장
→ 단축 URL 반환

19.2 URL 리디렉션

클라이언트가 단축 URL 요청
→ 캐시에서 원래 URL 조회
→ 캐시 적중 시 즉시 리디렉션
→ 캐시 미스 시 DB 조회
→ 조회 결과 캐시 저장
→ 301 또는 302 응답 반환

20. 정리

데이터 저장

모든 URL 매핑 정보를 메모리에 저장하기에는 비용과 용량 한계 존재
전체 데이터는 데이터베이스에 영구 저장
자주 조회되는 URL은 캐시에 저장

단축 코드 길이

사용 가능한 문자는 총 62개
약 3,650억 개의 URL을 저장하기 위한 최소 코드 길이는 7자리

해시 후 충돌 해소

긴 URL을 해싱하여 단축 코드 생성
충돌 발생 시 salt 등을 추가하여 다시 해싱
데이터베이스 또는 블룸 필터를 이용해 충돌 확인

블룸 필터

데이터베이스를 대체하지 않음
확실히 존재하지 않는 코드를 빠르게 판별
불필요한 데이터베이스 조회 감소

Base62 변환

유일한 숫자 ID를 짧은 문자열로 변환
숫자 ID가 유일하면 충돌 없음
전역적으로 유일한 ID 생성기가 필요함

최종 설계

데이터베이스로 전체 URL 매핑 영구 저장
Redis 등의 캐시로 읽기 성능 향상
유일 ID를 생성한 뒤 Base62로 변환하여 단축 코드 생성
단축 코드 요청 시 캐시와 데이터베이스를 통해 원래 URL 조회
서비스 목적에 따라 301 또는 302 리디렉션 사용

[대규모 시스템 설계 스터디] 7장 정리

Thu, 30 Jul 2026 07:10:02 GMT

분산 시스템을 위한 유일 ID 생성기

1. 유일 ID 생성기가 필요한 이유

관계형 데이터베이스의 기본 키에 auto_increment 속성을 설정하면 간단하게 유일 ID 생성 가능
그러나 대규모 분산 환경에서는 단일 데이터베이스가 병목 또는 단일 장애 지점이 될 수 있음
여러 데이터베이스 서버를 사용하면 처리량을 늘릴 수 있지만 다음 문제 발생 가능
- ID 충돌 방지를 위한 서버 간 조정 필요
- ID 생성 순서 보장 어려움
- 네트워크 통신으로 인한 지연 시간 증가
- 서버 추가 및 제거 시 운영 복잡도 증가

시스템 설계 면접의 첫 단계는 질문을 통해 모호한 요구사항을 제거하고 설계 범위를 확정하는 것임.

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

이번 장에서 주어진 요구사항은 다음과 같음.

ID는 유일해야 함
ID는 숫자로만 구성되어야 함
ID는 64비트로 표현할 수 있어야 함
ID는 발급 날짜에 따라 정렬 가능해야 함
초당 10,000개의 ID를 생성할 수 있어야 함

3. 개략적인 설계안

분산 시스템에서 유일성이 보장되는 ID를 생성하는 방법은 다음과 같음.

다중 마스터 복제
UUID
티켓 서버
Twitter Snowflake 방식

4. 다중 마스터 복제

4.1 기본 원리

여러 데이터베이스 서버의 auto_increment 기능 활용
각 서버의 시작값을 다르게 설정
ID 증가폭 k를 전체 데이터베이스 서버 수로 설정

데이터베이스 서버가 3대인 경우:

서버 A: 1, 4, 7, 10 ...
서버 B: 2, 5, 8, 11 ...
서버 C: 3, 6, 9, 12 ...

각 서버의 시작값은 각각 1, 2, 3
각 서버의 ID 증가폭은 3
서로 다른 서버가 같은 ID를 생성하는 문제 방지

4.2 장점

데이터베이스 서버 수를 늘려 ID 생성 처리량 증가 가능
단일 데이터베이스의 처리량 한계 일부 완화
기존 데이터베이스의 auto_increment 기능 활용 가능

4.3 단점

여러 데이터센터에 걸쳐 규모를 확장하기 어려움
ID의 유일성은 보장할 수 있지만 생성 시간에 따라 값이 증가하는 것은 보장하기 어려움
서버 수가 변경되면 증가폭과 시작값 규칙을 다시 조정해야 함
서버를 추가하거나 제거하는 과정의 운영 복잡도가 높음

5. UUID

5.1 기본 개념

컴퓨터 시스템의 정보를 유일하게 식별하기 위한 128비트 식별자
여러 서버가 서로 조율하지 않고 독립적으로 생성 가능
중복 UUID가 생성될 확률이 0은 아니지만 현실적으로 무시할 수 있을 정도로 낮음

5.2 장점

생성 방식이 비교적 단순함
서버 사이의 조율이 필요 없음
중앙 ID 생성 서버가 필요 없음
서버를 추가하더라도 별도의 ID 범위 할당이 필요 없음
수평적 규모 확장이 쉬움

5.3 단점

128비트로 구성되어 64비트 요구사항을 만족하지 못함
일반적으로 많이 사용하는 무작위 기반 UUIDv4는 생성 시간순 정렬이 어려움
일반적인 문자열 표현에 16진수 문자와 하이픈이 포함됨

예시:

550e8400-e29b-41d4-a716-446655440000

UUID 자체는 128비트 값임
문자열로 표현할 때 a~f와 하이픈이 포함되므로 숫자로만 구성되어야 한다는 요구사항을 만족하지 못함

6. 티켓 서버

6.1 기본 원리

auto_increment 기능을 갖춘 데이터베이스 서버를 중앙 ID 생성 서버로 사용
다른 서비스는 ID가 필요할 때 티켓 서버에 요청
티켓 서버가 순차적으로 증가하는 유일 ID 발급

6.2 장점

유일성이 보장되는 숫자 ID를 쉽게 생성 가능
구현이 비교적 단순함
생성된 ID가 순차적으로 증가함
중소 규모 애플리케이션에 적합

6.3 단점

모든 ID 생성 요청이 하나의 티켓 서버에 집중
티켓 서버 장애 시 ID를 생성할 수 없는 단일 장애 지점 발생
티켓 서버의 처리 능력이 전체 시스템의 ID 생성 한도 결정

6.4 다중 티켓 서버 구성

단일 장애 지점을 피하기 위해 여러 티켓 서버를 둘 수 있음
여러 티켓 서버가 서로 다른 ID를 발급하도록 조정 필요
서버 간 상태 동기화와 충돌 방지 문제 발생
구조가 복잡해지면서 티켓 서버 방식의 단순성 감소

7. Twitter Snowflake 방식

7.1 기본 개념

하나의 64비트 ID를 여러 영역으로 분할
생성 시각과 ID 생성 서버 정보를 하나의 정수에 포함
각 서버가 다른 서버와 매번 통신하지 않고 독립적으로 ID 생성 가능
ID의 상위 영역에 타임스탬프를 배치하여 대체로 생성 시각 순으로 정렬 가능

7.2 64비트 구조

7.3 사인 비트

1비트 사용
현재 구조에서는 별도의 값을 저장하지 않고 0으로 유지
추후 ID 체계를 확장하거나 용도를 변경할 때 활용 가능

7.4 타임스탬프

41비트 사용
시스템이 정한 기원 시각 이후 몇 밀리초가 경과했는지 저장

타임스탬프 값 = 현재 시각 - 자체 epoch

밀리초 단위의 41비트로 약 69.7년 표현 가능
Unix epoch가 아닌 서비스 시작 시점과 가까운 자체 epoch 설정 가능
자체 epoch를 사용하면 제한된 비트 범위를 서비스 운영 기간에 효율적으로 사용 가능

7.5 데이터센터 ID

5비트 사용
최대 32개의 데이터센터 식별 가능

2⁵ = 32

서로 다른 데이터센터에서 생성한 ID를 구분하는 데 사용

7.6 서버 ID

5비트 사용
하나의 데이터센터에서 최대 32개의 ID 생성 서버 식별 가능

2⁵ = 32

데이터센터 ID와 서버 ID의 조합으로 최대 1,024개의 생성 서버 구분 가능

32 × 32 = 1,024

7.7 일련번호

12비트 사용
같은 서버가 같은 밀리초 안에서 여러 ID를 생성할 때 중복 방지
동일한 밀리초 안에서 ID를 생성할 때마다 1씩 증가
밀리초가 변경되면 0으로 초기화

같은 밀리초에서 생성되는 ID:

첫 번째 ID: 일련번호 0
두 번째 ID: 일련번호 1
세 번째 ID: 일련번호 2
...

12비트로 한 서버가 1밀리초에 최대 4,096개의 ID 생성 가능

2¹² = 4,096

같은 밀리초 안에서 4,096개를 모두 사용하면 다음 밀리초가 될 때까지 대기 필요

7.8 이론적 처리량

한 서버가 1밀리초에 최대 4,096개의 ID를 생성할 수 있으므로 이론적인 초당 처리량은 다음과 같음.

4,096 × 1,000
= 초당 4,096,000개

요구사항인 초당 10,000개의 ID 생성 가능
실제 처리량은 언어, 구현 방식, 락, 하드웨어 등의 영향을 받음

8. 상세 설계

8.1 정적 값

다음 값은 ID 생성기가 시작될 때 결정됨.

데이터센터 ID
서버 ID
자체 epoch
일반적으로 운영 중에는 변경하지 않음
동시에 동작하는 생성기는 서로 다른 데이터센터 ID와 서버 ID 조합을 가져야 함
서로 다른 생성기가 같은 식별자 조합을 사용하면 ID 충돌 가능

ID 충돌 조건:

동일한 데이터센터 ID
동일한 서버 ID
동일한 타임스탬프
동일한 일련번호

운영 중 서버 ID를 재할당할 때는 기존 생성기와 중복되지 않도록 관리 필요.

8.2 동적 값

다음 값은 ID 생성기가 동작하는 동안 계속 변경됨.

타임스탬프
일련번호
타임스탬프는 현재 시각에 따라 증가
일련번호는 같은 밀리초 안에서 ID를 생성할 때마다 증가
밀리초가 변경되면 일련번호 초기화

9. 타임스탬프 영역의 수명

41비트 타임스탬프로 약 69.7년 표현 가능
기원 시각으로부터 약 69.7년이 지나면 타임스탬프 영역 소진
소진되기 전에 새로운 ID 형식이나 별도의 버전 체계로 마이그레이션 필요
동일한 ID 공간에서 epoch만 단순히 변경하면 과거 ID와 충돌할 수 있음
새로운 형식임을 구분할 별도의 버전 또는 네임스페이스 필요

10. 동시성 문제

10.1 여러 스레드 또는 코어에서의 실행

하나의 ID 생성기가 여러 스레드나 CPU 코어에서 동시에 실행될 수 있음
여러 실행 흐름이 같은 일련번호를 동시에 읽고 증가시키면 중복 ID 발생 가능

예시:

스레드 A: 현재 일련번호 10 확인
스레드 B: 현재 일련번호 10 확인

스레드 A: 일련번호 11로 ID 생성
스레드 B: 일련번호 11로 ID 생성

동일한 타임스탬프와 서버 정보에서 같은 일련번호를 사용하면 ID 충돌 발생

10.2 해결 방법

락을 사용해 한 번에 하나의 스레드만 일련번호 수정
원자적 연산을 이용해 일련번호 증가
단일 스레드 ID 생성기 사용
생성 요청을 큐에 넣고 순차적으로 처리

11. 시계 동기화 문제

11.1 여러 서버의 시계 오차

물리적으로 독립된 여러 서버는 시스템 시각이 완전히 같지 않을 수 있음
서버 간 시계 차이가 크면 나중에 생성된 ID가 더 작은 타임스탬프를 가질 수 있음
실제 생성 순서와 ID 정렬 순서가 달라질 수 있음

11.2 NTP 활용

NTP를 이용해 여러 서버의 시스템 시계를 동기화 가능
서버 간 시계 오차를 줄여 타임스탬프 차이 완화 가능

12. 비트 길이 최적화

서비스 특성에 따라 각 영역의 비트 수 변경 가능.

12.1 동시성이 낮고 운영 기간이 긴 서비스

짧은 시간에 생성하는 ID 수가 적음
일련번호 비트 수 축소 가능
줄인 비트를 타임스탬프 영역에 추가
ID 체계의 사용 가능 기간 증가

12.2 생성 서버가 적은 서비스

데이터센터 ID 또는 서버 ID 비트 수 축소 가능
타임스탬프나 일련번호 영역 확대 가능

12.3 동시성이 높은 서비스

일련번호 비트 수 확대 가능
한 밀리초에 더 많은 ID 생성 가능
대신 타임스탬프 또는 서버 식별 영역 축소 필요

비트 분할은 다음 요소를 기준으로 결정해야 함.

예상 서비스 운영 기간
데이터센터 수
ID 생성 서버 수
밀리초당 최대 ID 생성량

13. 고가용성

ID 생성기는 여러 서비스에서 공통으로 사용하는 핵심 컴포넌트
ID 생성기가 중단되면 데이터 생성, 주문, 게시물 등록 등의 기능도 중단될 수 있음
높은 가용성 제공 필요

13.1 고려 사항

여러 ID 생성 서버 운영
생성 서버마다 고유한 데이터센터 ID와 서버 ID 할당
생성 서버 장애 자동 감지
장애 서버의 트래픽을 정상 서버로 전환
서버 식별자 중복 할당 방지
모니터링과 경고 체계 구성
생성 실패 및 지연 시간 측정

14. 방식 비교

방식	ID 길이	시간순 정렬	서버 간 조율	규모 확장	주요 단점
다중 마스터 복제	설정에 따라 다름	완전 보장 어려움	설정 조정 필요	보통	서버 수 변경이 어려움
UUID	128비트	UUIDv4는 어려움	불필요	쉬움	64비트·숫자 요구사항 불충족
티켓 서버	설정에 따라 다름	가능	중앙 서버 필요	제한적	단일 장애 지점
Snowflake	64비트	대체로 가능	생성 시 불필요	쉬움	시계와 서버 ID 관리 필요

15. 정리

다중 마스터 복제

각 데이터베이스 서버가 서로 다른 시작값과 공통 증가폭 사용
ID 생성 처리량 증가 가능
서버 수 변경과 다중 데이터센터 확장에 불리함

UUID

서버 간 조율 없이 독립적으로 생성 가능
규모 확장이 쉬움
128비트이며 UUIDv4는 시간순 정렬이 어려움
숫자로만 구성된 64비트 ID 요구사항에 부적합

티켓 서버

중앙 데이터베이스의 auto_increment 기능 활용
구현이 단순하고 순차적 ID 생성 가능
단일 장애 지점과 중앙 병목 발생 가능

Twitter Snowflake

타임스탬프, 데이터센터 ID, 서버 ID, 일련번호를 64비트에 조합
서버 간 통신 없이 유일 ID 생성 가능
대체로 시간순 정렬 가능
한 서버에서 매우 높은 처리량 지원
시계 동기화, 동시성, 서버 식별자 중복 관리 필요

16. 내가 생각한 우리 시스템에 적합한 유일 ID 생성기는

우리 시스템에는 Snowflake보다 관계형 데이터베이스의 auto_increment 또는 sequence 방식이 적합하다고 판단함.

우리 시스템은 여러 데이터센터와 독립된 데이터베이스에 걸쳐 운영되는 대규모 서비스가 아니라 일회성 애플리케이션임. 처리해야 하는 ID 생성량도 Snowflake가 제공하는 초당 수백만 개 수준의 처리량을 요구하지 않음.

Snowflake를 사용하면 다음 요소를 추가로 관리해야 함.

데이터센터 ID와 서버 ID 할당
생성 서버 간 식별자 중복 방지
일련번호 동시성 제어
서버 간 시계 동기화
시계 역행 처리
별도의 ID 생성기 배포와 장애 대응

이러한 기능은 여러 서버가 중앙 데이터베이스와 통신하지 않고 독립적으로 ID를 생성해야 할 때 유용함. 하지만 우리 시스템에서는 얻을 수 있는 이점보다 구현 및 운영 복잡도가 더 클 것으로 판단됨.

관계형 데이터베이스의 auto_increment 또는 sequence를 사용하면 다음 장점이 있음.

별도의 ID 생성 시스템이 필요하지 않음
숫자로 구성된 유일 ID 생성 가능
ID가 순차적으로 증가함
여러 애플리케이션 서버가 동시에 요청해도 데이터베이스가 유일성 보장
구현과 운영이 단순함

우리 시스템에서 중요한 요구사항은 높은 가용성임. 그러나 이를 위해 ID 생성기만 별도로 분산시키기보다는 데이터를 저장하는 데이터베이스 자체를 고가용성으로 구성하는 것이 더 적절함.

예를 들어 주 데이터베이스와 대기 데이터베이스를 구성하고, 주 데이터베이스 장애 시 대기 데이터베이스로 자동 전환하도록 설계할 수 있음. 데이터베이스가 중단되면 ID를 별도로 생성하더라도 실제 데이터를 저장할 수 없으므로, ID 생성기와 데이터베이스의 가용성을 분리하여 해결할 필요성이 낮음.

따라서 우리 시스템에서는 다음 방식을 선택함.

유일 ID 생성: BIGINT auto_increment 또는 데이터베이스 sequence 사용
애플리케이션 가용성: 여러 애플리케이션 서버와 로드밸런서 구성
데이터베이스 가용성: 주 데이터베이스와 대기 데이터베이스 및 자동 장애 조치 구성

Snowflake는 향후 시스템이 여러 데이터센터나 독립된 데이터베이스로 확장되고, 각 서버가 중앙 조정 없이 대량의 ID를 생성해야 할 때 다시 검토하는 것이 적절함.

[대규모 시스템 설계 스터디] 6장 정리

Thu, 30 Jul 2026 06:02:25 GMT

키-값 저장소

1. 키-값 저장소란

고유한 키를 이용해 값을 저장하고 조회하는 비관계형 데이터 저장소
키는 저장된 값을 식별하는 역할 수행
키는 일반 문자열이나 해시값 등의 형태로 구성 가능
저장소는 일반적으로 값의 내부 구조를 직접 해석하지 않음
제품이 허용하는 크기와 형식 안에서 문자열, 객체, 바이너리 데이터 등 다양한 값 저장 가능

기본 API

`put(key, value)`

키와 값의 쌍을 저장소에 저장
동일한 키가 이미 존재하면 기존 값을 새로운 값으로 갱신할 수 있음

`get(key)`

입력한 키에 대응하는 값 조회
해당 키가 없으면 값이 존재하지 않음을 반환

2. 대표적인 키-값 저장소

2.1 Amazon Dynamo

Amazon이 내부 서비스의 높은 가용성을 위해 설계한 분산 키-값 저장소
2007년 논문을 통해 설계 원리 공개
외부 고객에게 직접 제공되는 AWS 서비스가 아니라 Amazon 내부 시스템의 설계 사례
일부 서버와 네트워크에 장애가 발생해도 쓰기 요청을 가능한 한 계속 처리하는 것을 중요하게 설계
강한 일관성보다 높은 가용성과 최종 일관성을 우선
다음과 같은 분산 시스템 기법 활용
- 안정 해시
- 데이터 복제
- 정족수(읽기나 쓰기를 성공으로 인정하기 위해 필요한 최소 서버 수)
- 벡터 시계
- 가십 프로토콜
- 단서 후 임시 위탁
- 머클 트리

Amazon Dynamo는 Amazon의 핵심 서비스에 항상 사용 가능한 저장 기능을 제공하기 위해 설계된 고가용성 키-값 저장소임.

2.2 Redis

메모리를 중심으로 동작하는 고성능 데이터 저장소
문자열뿐 아니라 다양한 자료구조 제공
- 리스트
- 집합
- 정렬 집합
- 해시
캐시 외에도 다음 용도로 활용 가능
- 세션 저장
- 순위표
- 분산 락
- 메시지 전달
- 실시간 카운터
설정에 따라 메모리의 데이터를 디스크에 저장하여 장애 후 복구 가능

2.3 Memcached

메모리에 데이터를 저장하는 단순한 분산 캐시 시스템
키를 이용한 값의 저장과 조회 기능에 집중
Redis보다 제공 기능과 자료구조가 단순함
기본적으로 데이터 영속성을 제공하지 않음
서버가 재시작되거나 캐시 항목이 제거되면 데이터가 사라질 수 있음

2.4 Amazon Dynamo와 DynamoDB의 차이

Amazon Dynamo
- Amazon 내부 서비스의 높은 가용성을 위해 개발된 분산 키-값 저장소
- 2007년 논문을 통해 설계 원리 공개
- 일반 사용자가 직접 사용할 수 있는 AWS 서비스는 아님
- 안정 해시, 벡터 시계, 가십 프로토콜, 단서 후 임시 위탁, 머클 트리 등의 기법 활용
- 강한 일관성보다 높은 가용성과 최종 일관성을 우선한 설계
Amazon DynamoDB
- AWS가 고객에게 제공하는 완전관리형 서버리스 NoSQL 데이터베이스
- 사용자가 AWS 콘솔, CLI, SDK 및 API를 통해 직접 사용 가능
- 서버 구성, 확장, 장애 대응 등의 인프라 운영을 AWS가 담당
- Dynamo의 설계 원칙에서 영향을 받았지만 Dynamo와 동일한 시스템은 아님
- 강력한 일관된 읽기, 트랜잭션, 보조 인덱스, 백업 등 상용 데이터베이스 기능 제공

즉, Amazon Dynamo는 분산 키-값 저장소의 설계 사례이고, DynamoDB는 해당 설계 철학의 영향을 받아 만들어진 실제 AWS 데이터베이스 서비스임.

3. 설계 목표

이번 장에서 설계하는 분산 키-값 저장소의 요구사항은 다음과 같음.

데이터 크기

개별 키-값 쌍의 크기는 10KB 이하
시스템 전체로는 대규모 데이터 저장 가능

높은 가용성

일부 서버에 장애가 발생하더라도 가능한 한 빠르게 응답
장애 노드 때문에 전체 시스템이 중단되지 않도록 설계

높은 규모 확장성

데이터와 요청량이 증가하면 서버 추가 가능
서버 추가와 제거 과정 자동화
서버 수 변경 시 데이터 이동량 최소화

조정 가능한 일관성

서비스 요구사항에 따라 읽기·쓰기 일관성 수준 조정 가능
강한 일관성과 높은 가용성 사이에서 적절한 절충 필요

짧은 응답 지연 시간

읽기와 쓰기 요청을 빠르게 처리
디스크 접근과 네트워크 통신 비용 최소화

4. 단일 서버 키-값 저장소

4.1 기본 구조

모든 키-값 쌍을 한 서버의 메모리 해시 테이블에 저장
키를 해싱하여 값의 위치를 빠르게 탐색
단순한 구조로 빠른 읽기와 쓰기 가능

4.2 개선 방법

데이터 압축을 통한 메모리 사용량 감소
자주 사용하는 데이터만 메모리에 저장
자주 사용하지 않는 데이터는 디스크에 저장

4.3 한계

메모리 기반 해시 테이블 자체는 빠름
그러나 한 서버의 메모리 용량과 처리 능력에는 한계 존재
데이터와 요청량이 증가하면 단일 서버만으로 처리하기 어려움
서버 장애 시 전체 저장소가 중단되는 단일 장애 지점 발생
대규모 시스템에서는 여러 서버에 데이터를 분산하는 구조 필요

분산 키-값 저장소

5. CAP 정리

CAP는 다음 세 가지 속성에 관한 분산 시스템의 제약을 설명함.

일관성
가용성
파티션 감내

5.1 일관성

어떤 노드에 접속하더라도 동일한 데이터를 보게 되는 성질
완료된 최신 쓰기가 이후 읽기에 반영되어야 함
복제본마다 서로 다른 값을 반환하지 않도록 보장

5.2 가용성

일부 노드에 장애가 발생하더라도 요청에 응답하는 성질
모든 정상적인 요청이 성공 또는 실패 여부를 포함한 응답을 받을 수 있어야 함

5.3 파티션 감내

노드 사이의 네트워크 통신이 끊겨도 시스템이 계속 동작하는 성질
파티션은 일부 노드 그룹끼리 통신할 수 없는 네트워크 장애를 의미

5.4 CAP 정리의 의미

단순히 세 가지 중 항상 두 가지만 고르는 문제는 아님
네트워크가 정상일 때는 일관성과 가용성을 모두 제공할 수 있음
네트워크 파티션이 발생하면 일관성과 가용성을 동시에 완전하게 보장하기 어려움
현실적인 분산 시스템에서는 네트워크 장애를 피할 수 없으므로 파티션 감내 필요
파티션 발생 시 일관성과 가용성 가운데 어떤 속성을 우선할지 결정 필요

5.5 CAP 예시

서버 A와 서버 B가 동일한 데이터의 사본을 가지고 있다고 가정함.

서버 A와 서버 B 사이의 네트워크 단절
클라이언트가 서버 A의 데이터 변경
서버 A가 변경 내용을 서버 B에 전달하지 못함

일관성을 우선하는 경우

서버 B는 자신이 가진 값이 최신인지 확인 불가
오래된 값을 반환하지 않기 위해 읽기 또는 쓰기 요청 거부
일관성을 유지하는 대신 가용성 일부 포기

가용성을 우선하는 경우

서버 B가 자신이 가진 값을 계속 반환
사용자는 응답을 받을 수 있음
서버 A의 최신 값과 다른 값을 받을 가능성 존재
가용성을 유지하는 대신 일시적으로 일관성 포기

시스템 컴포넌트

6. 데이터 파티션

6.1 파티션이 필요한 이유

대규모 데이터 전체를 한 서버에 저장하기 어려움
전체 데이터를 여러 개의 작은 파티션으로 나누어 여러 서버에 분산
서버별 저장 공간과 처리 부하를 고르게 분배할 필요

6.2 파티션 설계 시 고려 사항

데이터를 여러 서버에 고르게 분산할 수 있어야 함
서버가 추가되거나 제거될 때 데이터 이동량을 최소화해야 함
서버별 성능 차이를 데이터 분산에 반영할 수 있어야 함

6.3 안정 해시 활용

서버와 키를 동일한 해시 링 위에 배치
키의 위치에서 시계 방향으로 처음 만나는 서버가 해당 키 담당
서버가 추가되거나 제거되어도 영향받는 일부 키만 이동
전체 키를 다시 배치하는 문제 방지

안정 해시의 이점

자동적인 규모 확장에 유리
서버 추가·제거 시 데이터 이동 최소화
성능이 좋은 서버에 더 많은 가상 노드를 배치하여 서버 성능 차이 반영 가능

7. 데이터 복제

7.1 복제가 필요한 이유

하나의 서버에만 데이터를 저장하면 서버 장애 시 데이터 접근 불가
높은 가용성과 데이터 안정성을 위해 여러 서버에 동일한 데이터 사본 저장

7.2 복제 계수

N: 동일한 데이터를 저장할 복제본의 개수
예를 들어 N=3이면 하나의 데이터를 서로 다른 세 서버에 저장

7.3 복제 서버 선택

키의 위치에서 시계 방향으로 탐색
처음 만나는 서로 다른 물리 서버 N개에 데이터 저장
가상 노드를 사용하는 경우 동일한 물리 서버를 중복 선택하지 않도록 주의

7.4 복제 방식

쓰기 요청이 들어오면 여러 복제본에 데이터 전달
클라이언트는 그중 W개의 서버가 성공을 응답하면 쓰기 성공으로 판단 가능
즉시 응답하지 못한 나머지 복제본은 이후 비동기적으로 동기화 가능

8. 정족수와 데이터 일관성

복제된 데이터는 여러 서버에 저장되므로 읽기와 쓰기 과정에서 적절한 동기화 필요.

8.1 정족수 인자

N

데이터 사본의 전체 개수

W

쓰기 성공에 필요한 서버 응답 수
최소 W개의 복제본이 쓰기 성공을 응답해야 클라이언트에게 성공 반환

R

읽기 성공에 필요한 서버 응답 수
최소 R개의 복제본으로부터 데이터를 읽어 결과 결정

8.2 정족수 설정 예시

`R=1, W=N`

모든 복제본에 쓰기 완료 후 성공 처리
읽기는 하나의 복제본만 확인
읽기 속도에 유리
쓰기 지연 시간과 장애 민감도 증가 가능

`W=1, R=N`

하나의 복제본만 쓰기 성공해도 성공 처리
읽을 때 모든 복제본 확인
쓰기 속도와 가용성에 유리
읽기 비용 증가

`R+W>N`

읽기 정족수와 쓰기 정족수가 최소 한 복제본에서 겹침
최근 쓰기에 참여한 복제본이 읽기 대상에 포함될 가능성 확보
적절한 버전 비교와 충돌 처리 기능을 함께 사용하면 일관성 확보에 유리

`R+W≤N`

읽기 대상과 쓰기 대상이 전혀 겹치지 않을 수 있음
최신 쓰기를 보지 못하고 오래된 값을 반환할 가능성 증가

8.3 정족수 조건의 한계

R+W>N이라는 조건만으로 모든 시스템에서 강한 일관성이 자동 보장되는 것은 아님
다음 요소도 함께 고려해야 함
- 복제본 선택 방식
- 버전 비교
- 동시 쓰기 처리
- 장애 시 대체 노드를 사용하는 느슨한 정족수
- 읽기 복구
- 쓰기 순서 보장

Amazon Dynamo는 높은 가용성을 우선하므로 정족수, 버전 관리 및 비동기 복구를 사용하면서도 최종 일관성 모델을 채택함.

9. 일관성 모델

9.1 강한 일관성

읽기 요청에 완료된 최신 쓰기 결과 반환
클라이언트가 오래된 데이터를 보지 않도록 보장
읽기와 쓰기의 순서를 조정해야 함
합의, 리더 또는 정족수 등의 동기화 과정 필요
네트워크 장애 시 요청을 거부할 수 있어 가용성 저하 가능
추가 동기화 때문에 응답 지연 시간이 증가할 수 있음

9.2 약한 일관성

읽기 요청이 가장 최근에 갱신된 결과를 반환하지 못할 수 있음
복제본 동기화가 끝나기 전에 오래된 값 조회 가능
강한 일관성보다 높은 가용성과 낮은 응답 지연 시간 제공 가능

9.3 최종 일관성

약한 일관성의 한 형태
새로운 갱신이 더 이상 발생하지 않으면 모든 복제본이 결국 같은 값으로 수렴
짧은 시간 동안 서로 다른 복제본이 다른 값을 가질 수 있음
높은 가용성과 낮은 지연 시간이 중요한 시스템에 적합
Amazon Dynamo가 채택한 일관성 모델

9.4 우리가 만들 시스템에서는..?

선착순 경품 지급
혹은 정확히 100번째 요청 판별

이러한 기능에는 단순히 최신 값을 읽는 것뿐 아니라 다음 기능도 필요함.

강한 일관성
원자적 카운터 연산
트랜잭션 또는 동시성 제어

10. 데이터 버저닝

10.1 버저닝이 필요한 이유

최종 일관성 시스템에서는 여러 복제본이 일시적으로 서로 다른 값 보유 가능
네트워크가 단절된 상태에서 서로 다른 서버가 동일한 키를 동시에 변경할 수 있음
어느 값이 최신인지 또는 두 값이 충돌했는지 판별 필요

10.2 데이터 버전 생성

데이터가 변경될 때마다 새로운 버전 생성
이미 생성된 버전의 데이터는 변경하지 않음
여러 버전 사이의 선후 관계 비교 가능

11. 벡터 시계

11.1 벡터 시계란

각 데이터 버전에 [서버, 버전 번호]의 순서쌍을 연결하는 방식
서버마다 자신이 수행한 변경 횟수를 별도로 관리
각 버전이 어떤 서버의 변경을 얼마나 포함하는지 표현

11.2 버전 비교 방법

두 버전 X와 Y를 비교할 때 다음 조건을 확인함.

X의 모든 서버 카운터가 Y보다 작거나 같음
최소 하나의 서버 카운터는 Y가 더 큼

위 조건을 만족하면 Y가 X의 모든 변경을 포함하므로 Y를 X보다 나중 버전으로 판단.

11.3 선후 관계가 있는 예시

X = [(A, 1), (B, 0)]
Y = [(A, 2), (B, 1)]

Y의 A 카운터가 X보다 큼
Y의 B 카운터도 X보다 큼
Y가 X의 모든 변경을 포함
Y를 X의 후속 버전으로 판단

11.4 충돌한 버전 예시

X = [(A, 2), (B, 0)]
Y = [(A, 1), (B, 1)]

X는 A 서버의 변경을 더 많이 포함
Y는 B 서버의 변경을 더 많이 포함
어느 버전도 상대방의 모든 변경을 포함하지 않음
두 버전은 서로 병렬적으로 생성된 충돌 관계

11.5 벡터 시계의 역할

버전 사이의 선후 관계 판별
동시 변경으로 발생한 충돌 탐지
충돌을 발견할 수 있지만 어떤 버전을 선택할지는 자동으로 결정하지 않음

11.6 충돌 해결 방법

사용자 또는 애플리케이션이 하나의 버전 선택
여러 버전의 내용을 병합
집합처럼 합칠 수 있는 데이터는 합집합 사용
업무 규칙을 이용한 서버 측 병합
마지막 쓰기 우선 방식 적용 가능

11.7 단점

Dynamo에서는 여러 버전의 충돌 해결 책임이 애플리케이션으로 전달될 수 있음
애플리케이션 또는 클라이언트 구현 복잡도 증가
서버가 많아질수록 [서버, 버전] 순서쌍 증가 가능
벡터 시계의 크기가 지속적으로 커질 수 있어 오래된 항목 정리 필요

장애 처리

12. 장애 감지

12.1 장애 판단의 어려움

분산 시스템에서는 서버 장애와 일시적인 네트워크 지연을 즉시 구분하기 어려움
한 노드의 보고만으로 바로 장애를 확정하면 정상 서버를 장애로 잘못 판단할 수 있음
여러 노드의 관찰이나 반복된 타임아웃을 바탕으로 장애 여부 판단 가능

12.2 전체 노드 간 상태 교환

모든 노드가 서로 상태를 직접 전달하는 방식
노드 수가 적을 때 구조가 단순함
노드 수가 많아지면 통신 연결과 메시지 수가 크게 증가
대규모 분산 시스템에는 비효율적일 수 있음

13. 가십 프로토콜

13.1 멤버십 목록

각 노드는 클러스터에 참여하는 노드의 상태를 기록하는 멤버십 목록 유지.

멤버십 목록에는 다음 정보 포함 가능.

노드 또는 멤버 ID
박동 카운터
마지막 갱신 시간

13.2 동작 과정

각 노드가 주기적으로 자신의 박동 카운터 증가
무작위로 다른 노드 선택
책의 설계에서는 선택된 노드와 멤버십 목록 교환
상대방이 가진 정보와 자신의 정보 비교
더 큰 박동 카운터나 더 최근의 정보를 기준으로 목록 갱신
특정 노드의 박동 카운터가 일정 시간 동안 갱신되지 않으면 장애 의심

13.3 장점

모든 노드가 모든 노드에 직접 메시지를 보낼 필요 없음
일부 노드와 주기적으로 정보를 교환하면서 상태가 전체 클러스터로 확산
노드 수가 증가해도 비교적 효율적으로 멤버십 정보 전달 가능

14. 일시적인 장애 처리

14.1 느슨한 정족수

원래 데이터를 담당하는 서버가 일시적으로 응답하지 않는 상황
정상 상태인 다른 서버를 임시 복제본으로 선택
원래 복제 서버의 복구를 기다리지 않고 쓰기 요청 처리
높은 쓰기 가용성 유지

14.2 단서 후 임시 위탁

다른 서버가 장애 서버를 대신해 데이터를 임시 저장하는 방식
임시 저장된 데이터에 원래 담당 서버 정보를 함께 기록
이 정보를 단서라고 부름

14.3 단서에 포함되는 정보

해당 데이터의 원래 담당 서버
전달할 키와 값
데이터 버전
타임스탬프 또는 만료 정보

14.4 단서를 남기는 이유

임시 저장 서버가 해당 데이터가 자신의 정식 데이터인지 구분 가능
장애가 복구된 뒤 어느 서버로 데이터를 전달해야 하는지 확인 가능
원래 서버에 전달한 후 임시 사본 정리 가능

14.5 복구 과정

원래 담당 서버의 장애 발생
다른 정상 서버가 쓰기를 임시 저장
데이터와 함께 원래 담당 서버에 관한 단서 기록
원래 서버가 복구되었는지 주기적으로 확인
복구되면 임시 저장 데이터를 원래 서버로 전달
전달 완료 후 임시 데이터와 단서 제거

Amazon Dynamo는 일시적 장애 상황에서 높은 가용성을 유지하기 위해 느슨한 정족수와 단서 후 임시 위탁을 사용함.

15. 영구적인 장애 처리

15.1 반-엔트로피 프로토콜

장기간의 장애나 전달 실패로 서로 달라진 복제본을 동기화하는 과정
각 복제본이 가진 데이터 비교
오래되거나 누락된 데이터를 찾아 최신 상태로 갱신
모든 데이터를 매번 직접 비교하면 네트워크와 디스크 비용이 매우 큼

15.2 머클 트리 활용

복제본 사이의 차이를 효율적으로 찾기 위해 머클 트리 사용
전체 데이터를 작은 범위로 분할
각 데이터 범위의 해시값 계산
하위 노드의 해시값을 결합하여 상위 노드 해시값 계산
최종적으로 루트 해시값 생성

15.3 머클 트리 비교 과정

두 서버의 루트 해시값 비교
루트 해시값이 같으면 비교 대상 데이터가 동일한 것으로 판단
루트 해시값이 다르면 자식 노드의 해시값 비교
서로 다른 해시값을 가진 하위 구간으로 이동
실제 데이터가 다른 범위 탐색
차이가 있는 데이터 구간만 전송하여 동기화

15.4 장점

전체 데이터를 서버 간에 전송할 필요 없음
서로 다른 데이터 범위만 탐색 가능
네트워크 사용량 감소
대규모 데이터 집합의 비교 비용 감소

Amazon Dynamo는 복제본 사이의 불일치를 효율적으로 탐지하기 위한 반-엔트로피 과정에 머클 트리를 활용함.

아키텍처

16. 전체 구조

16.1 클라이언트

키-값 저장소의 get 및 put API 호출
특정 저장 노드의 위치를 직접 알 필요 없음

16.2 중재 노드

클라이언트 요청을 처음 받은 노드
클라이언트의 프록시 또는 코디네이터 역할 수행
키에 대한 담당 복제 서버 확인
읽기와 쓰기 요청 전달
필요한 정족수 응답 수집
충돌한 버전이 있으면 클라이언트 또는 애플리케이션에 전달 가능

16.3 저장 노드

안정 해시의 해시 링 위에 분포
자신이 담당하는 파티션의 데이터 저장
다른 노드의 데이터를 복제본으로 저장 가능

16.4 완전 분산 구조

노드를 자동으로 추가하거나 제거 가능
데이터를 여러 노드에 복제
모든 노드가 동일하거나 유사한 책임 수행
저장소 내부의 단일 장애 지점을 최소화
특정 중앙 서버 하나에 전체 기능이 의존하지 않도록 구성

16.5 각 노드가 수행할 수 있는 기능

클라이언트 요청 수신
중재 노드 역할
키의 담당 서버 탐색
데이터 읽기와 쓰기
복제본 저장
장애 감지
가십 프로토콜 참여
일시적 장애 데이터 임시 저장
복제본 동기화

데이터 저장 경로

17. 쓰기 경로

17.1 처리 과정

쓰기 요청 수신
커밋 로그에 요청 순차 기록
데이터를 메모리의 MemTable에 기록
MemTable이 설정된 임계 크기에 도달
MemTable의 데이터를 디스크의 SSTable로 플러시

17.2 커밋 로그

쓰기 내용을 디스크에 순차적으로 기록하는 로그
서버가 장애로 재시작되어도 아직 SSTable에 기록되지 않은 데이터 복구 가능
임의 위치를 수정하는 것보다 순차 쓰기를 사용해 디스크 쓰기 효율 향상 가능

17.3 MemTable

최근 쓰기 데이터를 임시로 보관하는 메모리 내 자료구조
일반적인 읽기 캐시가 아니라 디스크 기록 전 쓰기 버퍼 역할
키를 기준으로 정렬된 구조로 유지 가능
메모리 임계치에 도달하면 SSTable로 변환하여 디스크에 저장

17.4 SSTable

키를 기준으로 정렬된 키-값 쌍을 저장하는 불변 디스크 파일
한 번 생성된 이후 파일 내부 내용을 직접 수정하지 않음
새로운 쓰기나 수정 사항은 새로운 MemTable과 SSTable에 기록
여러 SSTable에 흩어진 오래된 데이터를 합치고 제거하는 컴팩션 과정 필요

Cassandra의 공식 저장 엔진 문서에서도 MemTable은 쓰기를 버퍼링하는 메모리 구조이며, 디스크로 플러시되면 불변 SSTable이 된다고 설명함.

18. 읽기 경로

18.1 기본 처리 과정

읽기 요청 수신
요청한 키가 MemTable 또는 메모리 캐시에 있는지 확인
메모리에 최신 값이 있으면 반환
메모리에 없으면 디스크의 SSTable 검색
블룸 필터로 키가 확실히 없는 SSTable 제외
키가 있을 가능성이 있는 SSTable의 인덱스와 데이터 확인
여러 버전이 발견되면 버전 또는 타임스탬프 비교
최신 값 반환

18.2 여러 SSTable을 확인하는 이유

SSTable은 생성된 이후 수정되지 않음
동일한 키의 서로 다른 버전이 여러 SSTable에 존재할 수 있음
최신 값을 찾기 위해 여러 SSTable을 검사해야 할 수 있음
모든 SSTable을 직접 읽으면 디스크 접근 비용 증가
불필요한 SSTable 접근을 줄이기 위해 블룸 필터 활용

19. 블룸 필터

19.1 블룸 필터란

특정 값이 집합에 존재하는지 빠르게 검사하는 확률적 자료구조
비트 배열과 여러 개의 해시 함수 사용
실제 키 전체를 저장하지 않고 해시 결과만 비트 형태로 표현
적은 메모리로 많은 키의 존재 가능성 검사 가능

Redis 공식 문서도 블룸 필터를 적은 고정 메모리로 원소의 집합 포함 여부를 검사하는 확률적 자료구조로 설명함.

19.2 데이터 추가

초기 비트 배열:

[0, 0, 0, 0, 0, 0, 0, 0]

apple을 추가한다고 가정함.

hash1(apple) → 1번
hash2(apple) → 4번
hash3(apple) → 6번

해당 위치의 비트를 1로 설정:

[0, 1, 0, 0, 1, 0, 1, 0]

19.3 데이터 조회

apple을 조회할 때 동일한 해시 함수 적용:

hash1(apple) → 1번
hash2(apple) → 4번
hash3(apple) → 6번

모든 비트가 1인 경우

1번, 4번, 6번이 모두 1
→ 해당 키가 있을 가능성이 있음

실제로 키가 존재할 수 있음
다른 키들이 우연히 같은 비트들을 1로 설정했을 수도 있음
실제 SSTable 조회 필요

하나라도 0인 경우

1번, 4번, 6번 중 하나라도 0
→ 해당 키는 확실히 없음

해당 키를 삽입했다면 모든 위치가 1이어야 함
하나라도 0이면 해당 SSTable을 검색할 필요 없음

19.4 블룸 필터의 특성

거짓 양성 가능

블룸 필터가 있다고 판단했지만 실제 데이터에는 없을 수 있음
해시 충돌로 다른 키들이 동일한 비트를 1로 만들 수 있기 때문
블룸 필터의 양성 결과 이후 실제 데이터 확인 필요

거짓 음성 없음

일반적인 블룸 필터는 없다고 판단한 데이터가 실제로 존재하는 상황이 발생하지 않음
하나의 비트라도 0이면 해당 키는 확실히 없음

블룸 필터는 거짓 양성이 발생할 수 있지만 일반적인 구현에서는 거짓 음성이 발생하지 않음.

19.5 SSTable에서의 역할

블룸 필터가 키의 정확한 저장 위치를 알려주는 것은 아님
각 SSTable에 특정 키가 존재할 가능성만 판단
키가 확실히 없는 SSTable을 검색 대상에서 제외
있을 가능성이 있는 SSTable만 실제로 조회
불필요한 디스크 접근 감소
읽기 응답 시간 개선

20. 전체 정리

데이터 분산

안정 해시로 키와 서버를 해시 링에 배치
서버 추가와 제거 시 이동하는 데이터 최소화
가상 노드로 서버별 부하와 데이터 분포 균등화

데이터 복제

동일한 데이터를 서로 다른 N개의 물리 서버에 저장
일부 서버 장애 시에도 다른 복제본을 통해 데이터 접근 가능

데이터 일관성

R, W, N 값을 조정하여 읽기·쓰기 성능과 일관성 수준 조절
R+W>N은 읽기와 쓰기 정족수의 교집합을 만드는 조건
이 조건만으로 강한 일관성이 자동 보장되지는 않음
Amazon Dynamo는 높은 가용성과 최종 일관성을 우선

충돌 처리

벡터 시계로 버전 사이의 선후 관계와 동시 변경 탐지
충돌한 데이터는 애플리케이션 또는 서버의 정책으로 병합

장애 감지와 복구

가십 프로토콜로 노드 상태 정보 전파
일시적 장애에는 느슨한 정족수와 단서 후 임시 위탁 사용
장기적인 데이터 불일치는 반-엔트로피와 머클 트리로 복구

데이터 저장

쓰기 요청을 커밋 로그와 MemTable에 기록
MemTable이 가득 차면 불변 SSTable로 디스크에 저장
여러 SSTable은 컴팩션으로 병합 및 정리

데이터 읽기

메모리에서 먼저 최신 데이터 확인
블룸 필터로 키가 확실히 없는 SSTable 제외
가능한 SSTable만 조회하여 디스크 접근 최소화

[대규모 시스템 설계 스터디] 5장 정리

Thu, 23 Jul 2026 07:49:31 GMT

안정 해시

1. 안정 해시가 필요한 이유

1.1 데이터의 균등 분산

수평적 규모 확장을 위해 요청 또는 데이터를 여러 서버에 균등하게 분산할 필요가 있음
특정 서버에 부하가 집중되면 해당 서버의 처리량과 저장 공간이 먼저 소진될 수 있음

1.2 나머지 연산을 이용한 해시 방식

일반적인 데이터 분산 방식

서버 인덱스 = hash(key) % 서버 개수

키의 해시값을 서버 개수로 나눈 나머지를 이용해 담당 서버 결정
서버 목록이 고정되어 있는 경우 비교적 간단하게 사용 가능

1.3 서버 수 변경 시 발생하는 문제

서버가 추가되거나 삭제되면 나머지 연산에 사용되는 서버 개수 변경
기존 키의 해시값이 같더라도 나머지 계산 결과 변경
많은 키가 기존과 다른 서버에 배치됨

캐시 시스템에서 발생할 수 있는 문제

기존 서버에서 캐시 데이터를 찾지 못하는 대규모 캐시 미스 발생
데이터베이스 요청량 급증
서버와 데이터베이스 부하 증가
심한 경우 전체 서비스 장애 발생 가능

2. 안정 해시의 개념

서버 추가 또는 제거 시 키의 재배치를 최소화하기 위한 해시 기법
전체 키를 다시 배치하지 않고 서버 변경의 영향을 받는 일부 키만 재배치
분산 캐시, 분산 데이터 저장소, 부하 분산 등에 활용 가능
일반적으로 해시 공간을 링 형태로 구성하여 설명하고 구현함

3. 해시 링

3.1 해시 공간

해시 함수가 생성할 수 있는 모든 해시값의 범위
서버와 키에 동일한 해시 함수를 적용하여 같은 해시 공간에 배치
예를 들어 SHA-1을 사용할 경우 해시값의 범위

0 ~ 2¹⁶⁰-1

안정 해시는 SHA-1만 사용하는 방식이 아님
구현에 따라 다른 해시 함수 사용 가능

3.2 해시 링 구성

해시 공간의 시작점과 끝점을 연결하여 원형 구조로 표현
원형으로 연결된 해시 공간을 해시 링이라고 함
최대 해시값 다음에는 다시 해시값 0으로 이어짐

4. 서버와 키의 배치

4.1 서버 배치

각 서버의 식별자에 해시 함수 적용
계산된 해시값에 따라 서버를 해시 링 위에 배치

4.2 키 배치

각 키에도 서버와 동일한 해시 함수 적용
계산된 해시값에 따라 키를 해시 링 위에 배치

4.3 담당 서버 결정

키의 위치에서 링을 시계 방향으로 탐색
처음 만나는 서버를 해당 키의 담당 서버로 결정
링의 끝을 지나면 처음 위치부터 탐색 계속

5. 안정 해시 알고리즘의 기본 절차

서버와 키에 균등 분포 해시 함수 적용
계산된 해시값을 기준으로 서버와 키를 해시 링에 배치
각 키의 위치에서 시계 방향으로 링 탐색
처음 만나는 서버에 해당 키 저장

6. 서버 추가

새로운 서버의 식별자를 해싱하여 해시 링에 배치
기존 키 대부분은 이전 서버에 그대로 유지
새 서버가 담당하게 된 범위의 키만 재배치

6.1 재배치 범위

새 서버의 반시계 방향에 있는 직전 서버와 새 서버 사이의 키들이 재배치 대상
해당 키들은 기존에 새 서버의 시계 방향에 있던 서버가 담당
새 서버 추가 후 해당 키들이 새 서버로 이동

6.2 서버 추가의 효과

전체 키를 다시 배치할 필요 없음
새 서버가 담당하는 일부 구간의 키만 이동
나머지 연산 방식보다 데이터 이동량 감소
캐시 시스템에서 대규모 캐시 미스 발생 가능성 감소

7. 서버 제거

제거된 서버가 담당하던 키들만 재배치
제거된 서버의 시계 방향에 있는 다음 서버가 해당 키들을 담당
기존의 다른 서버가 담당하던 키는 그대로 유지

7.1 서버 제거의 효과

제거된 서버와 관련된 키만 재배치
전체 키의 재배치 방지
서버 장애 또는 규모 축소 상황에서 데이터 이동량 감소

8. 파티션

8.1 파티션의 개념

해시 링에서 각 서버가 담당하는 해시값의 구간
각 서버는 반시계 방향에 있는 직전 서버부터 자신의 위치까지의 해시 구간 담당
해당 구간에 위치한 키들이 해당 서버에 저장됨

8.2 기본 안정 해시의 한계

서버가 해시 링에 균등하게 배치된다는 보장 없음
서버 사이의 거리가 서로 다르게 형성될 수 있음
서버별로 담당하는 파티션 크기가 달라질 수 있음

9. 키 분포의 불균형

파티션 크기가 다르면 서버별로 담당하는 키의 수에도 차이 발생
일부 서버에 키와 요청이 집중될 가능성 존재
서버가 추가되거나 삭제될 때 파티션 크기의 불균형이 커질 수 있음
기본적인 안정 해시만으로는 키의 균등 분포를 보장하기 어려움

10. 가상 노드

10.1 가상 노드의 개념

기본 안정 해시의 파티션 및 키 분포 불균형을 완화하기 위한 기법
하나의 물리 서버를 해시 링 위의 여러 위치에 배치하는 방식
하나의 물리 서버가 여러 개의 가상 노드를 가질 수 있음
각각의 가상 노드는 서로 다른 해시값을 가지지만 모두 동일한 물리 서버를 가리킴
일부 자료에서는 가상 노드를 복제 노드 또는 replica라고 표현하기도 함
여기서 복제는 동일한 데이터를 여러 서버에 저장하는 데이터 복제와는 다른 개념임

10.2 가상 노드의 동작

물리 서버마다 여러 개의 가상 노드 식별자 생성
각 가상 노드 식별자에 해시 함수 적용
계산된 해시값에 따라 해시 링의 여러 위치에 가상 노드 배치
키의 위치에서 시계 방향으로 가장 먼저 만나는 가상 노드 탐색
실제 데이터는 해당 가상 노드가 가리키는 물리 서버에 저장

11. 가상 노드의 장점

11.1 키의 균등 분산

하나의 서버가 해시 링의 여러 구간 담당
물리 서버 하나가 하나의 큰 파티션만 담당하는 문제 완화
가상 노드 수가 충분히 많을수록 서버별 담당 범위가 고르게 분산될 가능성 증가
서버별 키 개수와 요청 부하의 편차 감소

11.2 서버 변경 시 재배치 부하 분산

서버 추가 또는 제거 시 해시 링의 여러 구간에서 키 재배치 발생
특정 서버 하나에 데이터 이동이 집중되는 문제 완화
여러 물리 서버에 재배치 부하 분산 가능

11.3 서버 성능 차이 반영

성능이 높은 서버에 더 많은 가상 노드 할당 가능
성능이 낮은 서버에는 적은 수의 가상 노드 할당 가능
서버의 CPU, 메모리, 저장 공간 등의 성능 차이를 데이터 분산에 반영 가능

12. 정리

나머지 연산 방식

구현이 간단함
서버 수가 변경되면 많은 키의 담당 서버 변경
대규모 캐시 미스와 데이터 재배치 발생 가능

기본 안정 해시

서버 추가 또는 제거 시 일부 키만 재배치
데이터 이동량과 캐시 미스 감소
서버별 파티션과 키 분포가 불균등해질 수 있음

가상 노드를 적용한 안정 해시

하나의 물리 서버를 해시 링의 여러 위치에 배치
키 분포와 재배치 부하를 더욱 균등하게 분산
서버 성능에 따라 가상 노드 수 조절 가능

[대규모 시스템 설계 스터디] 4장 정리

Thu, 23 Jul 2026 06:10:35 GMT

처리율 제한 장치

1. 처리율 제한 장치란

클라이언트 또는 서비스가 보내는 트래픽의 처리율을 제어하는 장치
일정 시간 동안 허용되는 요청 수를 제한하는 방식
웹 서버, API 게이트웨이, 로드밸런서, 방화벽 등에 프로그램 로직으로 구현 가능

2. 처리율 제한 장치의 장점

2.1 DoS 공격으로 인한 자원 고갈 방지

과도한 요청으로부터 서버 자원 보호
CPU, 메모리, 네트워크, 데이터베이스 연결 등의 고갈 방지
악의적인 요청뿐 아니라 비정상적인 클라이언트 동작에도 대응 가능

2.2 비용 절감

불필요한 서버 확장 방지
유료 외부 API 호출 횟수 제한
처리 가능한 요청만 백엔드 서비스로 전달

2.3 서버 과부하 방지

서버가 처리할 수 있는 수준으로 요청량 조절
급격한 트래픽 증가로 인한 장애 방지
서비스 안정성 및 응답 시간 유지

3. 처리율 제한 방식

처리율 제한은 요청 속도를 제어하는 주체에 따라 클라이언트 측 제한과 서버 측 제한으로 구분 가능

3.1 클라이언트 측 제한

요청을 보내는 클라이언트가 자체적으로 요청 속도를 조절하는 방식
대표적인 방법
- 디바운싱
- 스로틀링
- 재시도 간격 조절
서버 부담 감소 가능
불필요한 네트워크 요청 감소 가능
클라이언트 프로그램의 수정 또는 우회 가능
보안 목적의 처리율 제한 수단으로는 신뢰하기 어려움

3.2 서버 측 제한

서버가 들어오는 요청을 직접 검사하고 제한하는 방식
다음과 같은 기준으로 제한 가능
- IP 주소
- 사용자 계정
- API 키
- 특정 API 경로
- 일정 시간 동안의 요청 횟수
클라이언트가 임의로 우회하기 어려움
실제 서비스 보호를 위해 필요한 방식

3.3 클라이언트 측 제한과 서버 측 제한의 병행

실제 서비스에서는 두 방식을 함께 적용 가능
클라이언트 측 제한
- 불필요한 요청 발생 억제
- 사용자 경험 및 네트워크 효율 개선
서버 측 제한
- 클라이언트의 우회 또는 비정상 동작으로부터 시스템 보호
- 최종적인 처리율 제한 정책 강제

4. 시스템 요구사항

4.1 기능 요구사항

서버 측 API를 위한 처리율 제한 장치 설계
다양한 형태의 제어 규칙 지원
요청 제한 시 클라이언트에게 제한 사실 전달
서비스별 처리율 제한 정책 설정 지원

4.2 비기능 요구사항

대규모 요청 처리 가능
가능한 한 적은 메모리 사용
분산 환경에서 동작
높은 가용성 확보
처리율 제한 기능으로 인한 응답 지연 최소화

4.3 배포 방식

처리율 제한 장치를 독립된 서비스로 구현 가능
애플리케이션 서버 또는 API 게이트웨이에 종속된 기능으로 구현 가능
시스템 환경, 운영 규모, 성능 요구사항에 따라 적절한 방식 선택 필요

독립된 서비스로 구현하는 경우

여러 서비스의 처리율 제한 정책을 중앙에서 관리 가능
처리율 제한 로직을 각 애플리케이션과 분리 가능
여러 서비스에서 공통 기능으로 재사용 가능
처리율 제한 기능만 독립적으로 확장하거나 배포 가능

애플리케이션 또는 API 게이트웨이에 포함하는 경우

별도의 네트워크 호출이 필요하지 않아 지연 시간 감소 가능
시스템 구성과 운영 복잡도 감소
애플리케이션 또는 게이트웨이의 기존 인증·라우팅 정보 활용 가능
소규모 시스템이나 서비스별 정책이 다른 환경에 적용하기 쉬움

선택 시 고려 사항

독립된 서비스는 중앙 관리와 재사용에 유리하지만 추가적인 네트워크 지연과 장애 지점 발생 가능
종속된 방식은 구현이 단순하지만 서비스마다 로직이 중복될 가능성 존재
독립 여부와 관계없이 처리율 제한 장치 장애에 대한 정책 필요
- 장애 발생 시 요청을 허용하는 fail-open
- 장애 발생 시 요청을 차단하는 fail-closed

5. API 게이트웨이와 처리율 제한

5.1 API 게이트웨이의 역할

클라이언트와 백엔드 서비스 사이에서 API 요청을 중계하는 컴포넌트
여러 서비스에 공통으로 필요한 기능 처리
- 요청 라우팅
- 처리율 제한
- 사용자 인증 및 인가
- SSL/TLS 종단
- API 키 검증
- 로깅 및 모니터링
처리율 제한은 API 게이트웨이가 제공할 수 있는 기능 중 하나임

5.2 완전 관리형 API 게이트웨이

클라우드 사업자가 API 게이트웨이를 완전 관리형 서비스로 제공하는 경우가 많음
서버 설치와 운영 부담 감소
처리율 제한, 인증, 모니터링 등의 기능을 설정 방식으로 적용 가능
사용하는 제품에 따라 지원 기능과 처리율 제한 알고리즘에 차이 발생 가능

5.3 MSA에서의 활용

MSA에서는 처리율 제한 장치를 API 게이트웨이에 구현하는 경우가 많음
클라이언트 요청이 각 마이크로서비스에 도달하기 전에 공통 정책 적용 가능
각 마이크로서비스에 처리율 제한 로직을 중복 구현하는 문제 감소
서비스 전체의 처리율 제한 정책을 중앙에서 관리 가능

5.4 처리율 제한 장치의 위치를 결정할 때 고려할 사항

처리율 제한 장치를 어디에 배치할지는 서비스 상황과 목표에 따라 결정
모든 시스템에 적용되는 단일한 정답은 없음

구현 환경

현재 사용하는 프로그래밍 언어와 프레임워크가 서버 측 처리율 제한 구현에 적합한지 확인
높은 요청량에서도 충분한 성능을 제공할 수 있는지 확인

알고리즘 선택권

직접 구현할 경우 필요한 알고리즘을 자유롭게 선택 가능
외부 API 게이트웨이를 사용할 경우 제공되는 알고리즘과 설정 방식에 제약 발생 가능

기존 아키텍처

MSA에 API 게이트웨이가 이미 포함된 경우 게이트웨이에 처리율 제한 기능 추가 가능
공통 정책의 중앙 관리 가능

개발 및 운영 인력

직접 구현하고 운영할 인력이 부족한 경우 상용 API 게이트웨이 활용 가능
개발 비용과 운영 복잡도 감소 가능

6. 처리율 제한 알고리즘

토큰 버킷
누출 버킷
고정 윈도 카운터
이동 윈도 로그
이동 윈도 카운터

7. 토큰 버킷 알고리즘

7.1 기본 개념

지정된 용량을 갖는 버킷 사용
버킷 내부에 요청 처리 권한을 의미하는 토큰 저장
사전에 설정된 공급률에 따라 토큰 추가
버킷이 가득 찬 경우 추가 토큰 폐기

7.2 동작 원리

요청 도착
버킷에 토큰이 있는지 확인
토큰이 있으면 토큰 하나 소비
요청을 시스템에 전달
토큰이 없으면 요청 거부 또는 폐기

7.3 주요 인자

버킷 크기

버킷에 저장할 수 있는 토큰의 최대 개수
순간적으로 허용할 수 있는 최대 요청량과 관련됨

토큰 공급률

일정 시간 마다 버킷에 추가되는 토큰 수
장기적으로 허용되는 평균 요청 처리율과 관련됨

7.4 버킷 구성

제한 정책에 따라 별도의 버킷 구성 가능
버킷을 구분할 수 있는 기준
- 사용자
- IP 주소
- API 키
- API 엔드포인트
- 서비스
사용자 ID + API 경로처럼 여러 기준을 조합하여 버킷을 구분할 수도 있음

7.5 장점

구현이 비교적 간단함
메모리 사용량이 적음
일정 범위의 순간적인 트래픽 증가 허용 가능
평균 처리율을 유지하면서 버스트 트래픽 처리 가능

7.6 단점

버킷 크기와 토큰 공급률의 적절한 설정이 어려움
잘못된 인자 설정 시 정상 요청이 과도하게 거부될 수 있음

8. 누출 버킷 알고리즘

8.1 기본 개념

요청을 큐에 저장한 후 일정한 속도로 처리
일반적으로 FIFO 큐로 구현
출력 처리율이 일정하게 유지됨

8.2 동작 원리

요청 도착
큐에 빈자리가 있는지 확인
빈자리가 있으면 요청을 큐에 추가
큐가 가득 찬 경우 새로운 요청 폐기
일정한 주기마다 큐에서 요청을 꺼내 처리

8.3 주요 인자

버킷 크기

요청을 저장하는 큐의 최대 크기

처리율

일정 시간 동안 큐에서 처리하는 요청 수
일반적으로 초 단위로 설정

8.4 토큰 버킷과의 차이

토큰 버킷
- 토큰이 남아 있으면 순간적인 요청 증가 허용
누출 버킷
- 요청을 일정한 속도로 꺼내 처리
- 출력 처리율이 상대적으로 일정함

8.5 장점

큐 크기가 제한되어 있어 메모리 사용량 예측 가능
일정한 출력 처리율 제공
안정적인 요청 처리 속도가 필요한 시스템에 적합

8.6 단점

단시간에 트래픽이 몰리면 큐에 오래된 요청 누적
큐가 가득 차면 새로운 요청 폐기
큐 크기와 처리율 설정이 어려움
큐 대기로 인해 응답 지연 증가 가능

9. 고정 윈도 카운터 알고리즘

9.1 기본 개념

시간을 일정한 크기의 고정 구간으로 분할
각 구간마다 요청 수를 기록하는 카운터 사용

9.2 동작 원리

요청 도착
현재 윈도의 카운터를 1 증가
카운터가 설정된 한도 이하이면 요청 허용
한도를 초과하면 새로운 윈도가 시작될 때까지 요청 거부
새로운 윈도가 시작되면 카운터 초기화

9.3 장점

구현이 간단함
이해하기 쉬움
카운터 하나만 저장하면 되므로 메모리 효율이 높음
일정한 시간 단위로 요청량을 관리하는 정책에 적합

9.4 단점

윈도 경계에서 처리율 한도를 초과할 수 있음
이전 윈도 마지막 시점과 다음 윈도 시작 시점에 요청이 집중될 경우 문제 발생
실제 연속 시간 기준으로는 설정한 한도보다 많은 요청 허용 가능

10. 이동 윈도 로그 알고리즘

10.1 기본 개념

각 요청의 타임스탬프를 개별적으로 기록
Redis 정렬 집합과 같은 자료구조 활용 가능

10.2 동작 원리

새로운 요청 도착
현재 윈도의 시작 시점보다 오래된 타임스탬프 제거
새로운 요청의 타임스탬프를 로그에 추가
로그에 저장된 요청 수 확인
요청 수가 허용치 이하이면 요청 전달
허용치를 초과하면 요청 거부

10.3 장점

고정 윈도 카운터의 경계 문제 해결
현재 시점을 기준으로 정확한 시간 범위 계산 가능
어느 시점에서 윈도를 계산해도 요청 수가 설정 한도를 넘지 않도록 제어 가능

10.4 단점

각 요청의 타임스탬프를 저장해야 함
요청량이 많을수록 메모리 사용량 증가
거부된 요청의 타임스탬프까지 저장하는 구현에서는 추가 메모리 사용 발생

11. 이동 윈도 카운터 알고리즘

11.1 기본 개념

고정 윈도 카운터와 이동 윈도 로그의 특징을 결합한 방식
현재 윈도와 직전 윈도의 카운터를 이용하여 현재 시간 범위의 요청 수 추정

11.2 동작 원리

예를 들어 시간을 1분 단위의 고정 구간으로 분할
이전 1분 구간과 현재 1분 구간의 요청 수 저장
이전 구간의 요청을 모두 포함하지 않음
현재 시점과 가까운 부분만 시간 비율에 따라 반영
직전 윈도의 요청이 윈도 전체에 균등하게 분포한다고 가정

11.3 계산 예시

처리율 제한: 분당 100개
현재 시각: 현재 윈도가 시작된 후 20초 경과
직전 윈도 요청 수: 90개
현재 윈도 요청 수: 30개
직전 윈도에서 현재 이동 윈도와 겹치는 비율: 40초 ÷ 60초
추정 요청 수

90 × (40 ÷ 60) + 30 = 90개

11.4 장점

이전 시간대의 평균 처리율에 따라 현재 윈도의 상태 계산
짧은 시간에 몰리는 트래픽에 효과적으로 대응
요청별 타임스탬프를 모두 저장할 필요 없음
이동 윈도 로그보다 메모리 사용량이 적음
고정 윈도의 경계 문제 완화

11.5 단점

직전 윈도의 요청이 균등하게 분포했다고 가정
실제 요청 분포와 계산된 추정치 사이에 오차 발생 가능
실험 결과에서는 이러한 오차가 심각한 문제로 나타나지 않음

12. 처리율 제한 데이터 저장소

12.1 데이터베이스 사용의 한계

처리율 제한 여부를 확인하기 위한 카운터 필요
모든 요청마다 카운터 조회 및 갱신 필요
디스크 기반 데이터베이스 사용 시 지연 시간 증가 가능
높은 요청량에서 데이터베이스 부하 증가 가능

12.2 인메모리 캐시 활용

일반적으로 Redis와 같은 인메모리 저장소 활용
빠른 읽기 및 쓰기 가능
만료 시간 설정 가능
카운터와 타임스탬프 자료구조 지원
여러 처리율 제한 장치가 데이터를 공유하기 쉬움

13. 처리율 제한 규칙 관리

13.1 제한 규칙의 구성

각 서비스의 요구사항에 따라 규칙 설정
규칙에 포함될 수 있는 항목
- 제한 대상
- 요청 허용량
- 시간 윈도 크기
- API 경로
- 사용자 등급
- 초과 요청 처리 방식

13.2 규칙 저장

규칙을 설정 파일 형태로 디스크에 저장 가능
처리율 제한 장치가 설정 파일을 주기적으로 읽어 규칙 갱신 가능

14. 한도 초과 요청 처리

14.1 HTTP 상태 코드

처리율 제한을 초과한 요청에 HTTP 429 Too Many Requests 응답 반환
클라이언트에게 요청 한도 초과 사실 전달

14.2 응답 헤더

클라이언트가 처리율 제한 상태를 확인할 수 있도록 응답 헤더 제공 가능
전달 가능한 정보
- 윈도당 허용되는 전체 요청 수
- 현재 윈도에 남아 있는 요청 수
- 다음 요청을 시도할 수 있는 시점
- 재시도까지 기다려야 하는 시간

14.3 초과 요청의 보관

제한된 요청을 즉시 폐기하지 않고 메시지 큐에 저장 가능
나중에 비동기 방식으로 처리 가능
모든 API 요청에 적용되는 방식은 아님
주문, 작업 실행 등 비동기 처리가 가능한 요청에 적합

15. 분산 환경에서의 처리율 제한

15.1 주요 문제

여러 처리율 제한 장치가 동시에 같은 카운터를 갱신하는 문제 발생
대표적인 문제
- 경쟁 조건
- 서버 간 상태 동기화

16. 경쟁 조건

16.1 경쟁 조건의 발생 과정

현재 카운터 값 조회
한도 초과 여부 확인
카운터 값 증가

여러 요청이 위 과정을 동시에 수행할 경우 동일한 카운터 값을 읽을 수 있음
실제 요청 수보다 카운터가 적게 증가하는 문제 발생 가능
허용 한도를 초과한 요청이 통과할 수 있음

16.2 락 사용

공유 데이터에 락을 적용하여 한 번에 하나의 요청만 수정하도록 제한 가능
경쟁 조건 방지 가능
높은 동시성 환경에서는 대기 시간과 성능 저하 발생 가능

16.3 Lua 스크립트와 Redis 정렬 집합

앞서 설명한 설계에서는 경쟁 조건의 해결책으로 Lua 스크립트와 Redis의 정렬 집합 활용 가능

Lua 스크립트

조회, 비교, 증가 작업을 하나의 Lua 스크립트에 포함
여러 Redis 명령을 하나의 작업처럼 실행
Redis 서버 내부에서 실행
조회·판단·갱신 과정의 원자적 실행 가능

Lua 언어

작고 가벼운 프로그래밍 언어
다른 프로그램 내부에 삽입하여 사용하기 적합
Redis 내부에서 데이터 처리 로직을 실행할 때 활용 가능

Redis 정렬 집합

각 데이터에 점수를 붙여 점수 순서대로 자동 정렬하는 자료구조
처리율 제한에서는 요청 시간을 점수로 저장
특정 시간 범위에 포함되는 요청만 조회 가능
최근 요청 수를 정확하게 계산하는 데 활용 가능

17. 서버 간 상태 동기화

17.1 문제 상황

처리율 제한 장치 서버를 여러 대 운영할 경우 서버마다 서로 다른 카운터를 가질 수 있음
같은 클라이언트의 요청이 여러 서버로 분산되면 전체 요청량을 정확하게 계산하기 어려움

17.2 고정 세션 활용

같은 클라이언트의 요청을 항상 같은 처리율 제한 장치로 전달
서버별 로컬 카운터 사용 가능

한계

특정 서버에 요청이 집중될 수 있음
서버 장애 시 상태 이전이 어려움
확장성과 유연성이 낮음
처리율 제한만을 위해 고정 세션을 사용하는 것은 권장하기 어려움

17.3 중앙 집중형 데이터 저장소 활용

Redis와 같은 중앙 집중형 데이터 저장소 사용
여러 처리율 제한 장치가 동일한 카운터 공유
요청이 어느 서버에 도착하더라도 같은 제한 상태 확인 가능
분산 환경에서 비교적 일관된 처리율 제한 제공 가능

18. 성능 및 분산 환경 고려 사항

18.1 여러 데이터센터 지원

사용자와 가까운 데이터센터에서 요청 처리
네트워크 지연 시간 감소
지역별 처리율 제한 장치 배치 가능
특정 데이터센터에 요청이 집중되는 문제 완화 가능

18.2 최종 일관성 모델 활용

데이터센터 사이의 처리율 제한 상태를 비동기적으로 동기화
모든 데이터센터의 상태를 즉시 동일하게 맞추지 않아도 됨
데이터 동기화로 인한 지연 시간과 통신 비용 감소 가능
데이터센터 사이의 상태가 일시적으로 다를 수 있음
동기화가 완료되기 전까지 전체 처리율 한도를 순간적으로 초과할 가능성 존재
정확한 전역 제한보다 낮은 지연 시간과 높은 가용성이 중요한 환경에 적합

19. 모니터링

19.1 모니터링 목적

처리율 제한 장치가 효과적으로 동작하는지 확인
설정한 알고리즘이 예상대로 동작하는지 확인
처리율 제한 규칙이 지나치게 엄격하거나 느슨하지 않은지 확인

19.2 주요 모니터링 항목

전체 요청 수
허용된 요청 수
거부된 요청 수
HTTP 429 응답 비율
사용자 또는 API별 제한 발생 횟수
처리율 제한 검사 지연 시간
Redis 조회 및 갱신 지연 시간
규칙별 한도 사용률

19.3 모니터링 결과의 활용

지나치게 많은 정상 요청이 거부되는 경우 제한 규칙 완화
서버 과부하가 계속 발생하는 경우 제한 강화
예상하지 못한 트래픽 패턴 발견
알고리즘 또는 주요 인자 조정

20. 경성 처리율 제한과 연성 처리율 제한

20.1 경성 처리율 제한

설정된 처리율 한도를 초과하는 요청을 허용하지 않는 방식
한도에 도달하면 이후 요청을 즉시 거부
엄격한 자원 보호가 필요한 경우에 적합
순간적인 트래픽 증가를 허용하기 어려움

20.2 연성 처리율 제한

설정된 한도를 일시적으로 초과하는 요청을 일정 범위까지 허용하는 방식
짧은 시간 동안 발생한 버스트 트래픽 수용 가능
사용자 요청을 유연하게 처리할 수 있음
허용 범위를 지나치게 크게 설정하면 서버 과부하 발생 가능

[대규모 시스템 설계 스터디] 3장 정리

Thu, 09 Jul 2026 07:50:03 GMT

시스템 설계 면접 공략법

시스템 설계 면접은 다음을 보여주는 자리다.

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

즉, 설계 능력의 기술적 측면 외에도 다음과 같은 자질을 함께 평가할 수 있다.

협력에 적합한 사람인지
압박이 심한 상황도 잘 헤쳐 나갈 자질이 있는지
모호한 문제를 건설적으로 해결할 능력이 있는지
좋은 질문을 던질 능력이 있는지

4단계 접근법

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

엔지니어가 가져야 할 중요한 기술 중 하나는 올바른 질문을 하는 것, 적절한 가정을 하는 것, 그리고 시스템 구축에 필요한 정보를 모으는 것이다.

⚠️ 이 단계에서 가장 중요한 것은 요구사항을 이해하고 모호함을 없애는 것이다.

문제를 받자마자 곧바로 답부터 내놓으려 하지 말고, 무엇을 만들어야 하는지부터 명확히 하는 것이 핵심이다.

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

설계안에 대한 최초 청사진을 제시하고 의견을 구하여, 면접관을 팀원처럼 대한다.

핵심 컴포넌트를 포함하는 다이어그램을 그린다.
설계안이 관계된 제약사항들을 만족하는지 개략적으로 계산한다.
이런 개략적인 추정이 필요한지는 면접관에게 미리 물어보는 것이 좋다.

3단계. 상세 설계

앞선 단계를 마쳤다면 전반적으로 달성해야 할 목표와 기능 범위를 확인하여, 전체 설계의 개략적인 청사진과 상세 설계에 집중해야 할 영역을 파악했을 것이다.

이 단계에서 할 일은 설계 대상 컴포넌트 사이의 우선순위를 정하는 것이다.
사소한 세부사항 설명에 시간을 낭비하지 말 것.

한정된 면접 시간 안에서 중요한 컴포넌트에 깊이를 더하는 것이, 모든 부분을 얕게 훑는 것보다 낫다.

4단계. 마무리

완벽한 시스템은 없다.

개선할 지점을 찾으라는 주문을 받으면, 비판적 사고 능력을 보일 수 있는 기회이니 개선할 점을 적극적으로 찾는다.
만든 설계를 다시 요약해 주는 것도 도움이 된다. 특히 여러 해결책을 제시한 경우엔 더욱 그렇다.
오류가 발생하면 무슨 일이 생기는지, 운영 이슈, 규모 확장 요구 대처, 세부적 개선 사항 제안 등을 이 단계에서 다루면 좋다.

정리

단계	핵심
1. 문제 이해 및 범위 확정	요구사항을 이해하고 모호함을 없앤다
2. 개략적 설계안 제시	청사진을 그리고 면접관과 합의한다
3. 상세 설계	중요한 컴포넌트에 우선순위를 두고 깊이 판다
4. 마무리	개선점을 찾고 설계를 요약한다

시스템 설계 면접은 정답을 맞히는 시험이 아니라, 문제를 풀어 나가는 과정과 소통 능력을 보여주는 자리라는 점을 기억해야한다.

[대규모 시스템 설계 스터디] 2장 정리

Thu, 09 Jul 2026 07:26:07 GMT

개략적인 규모 추정이란?

개략적인 규모 추정은 보편적으로 통용되는 성능 수치를 바탕으로 사고 실험을 행하여 추정치를 계산하는 행위다. 어떤 설계가 요구사항에 부합할 것인지 가늠해 보기 위한 것이다.

2의 제곱수

데이터 크기를 다룰 때는 2의 제곱수 단위를 알아두는 것이 좋다.

응답 지연(Latency) 값

책에 나온 수치들을 분석한 결과는 다음과 같다.

메모리는 빠르지만 디스크는 아직 느리다.
디스크 탐색(seek)은 가능한 한 피해야 한다.
단순한 압축 알고리즘은 빠르다. 데이터를 인터넷으로 전송하기 전에는 가능하면 압축할 것.
데이터 센터는 보통 여러 지역에 분산되어 있고, 센터들 간에 데이터를 주고받는 데 시간이 걸린다.

가용성 (Availability)

고가용성

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

고가용성은 %로 표현한다.
100%는 시스템이 단 한 번도 중단된 적이 없었음을 의미한다.

SLA (Service Level Agreement)

서비스 사업자와 고객 사이에 맺어진 합의다.

이 합의 안에 사업자가 제공하는 서비스의 가용 시간이 공식적으로 기술되어 있다.
관습적으로 숫자 9를 사용해 표시하며, 9가 많을 수록 좋다.

자주 출제되는 추정 문제

많이 출제되는 개략적 규모 추정 문제는 다음을 추정하는 것이다.

QPS
최대 QPS (Peak QPS)
저장소 요구량
캐시 요구량
서버 수

💡 추정할 때는 단위를 붙이는 습관이 중요하다.

궁금한 점

Q. 트위터 QPS와 저장소 요구량 추정에서 최대 QPS(Peak QPS)는 계산된 QPS에 2를 곱하는 것이 관습인지, 근거가 있는 것인지?

A. 관습적인 어림값이다.

트래픽은 하루 종일 일정하지 않고, 사용자가 몰리는 시간대(점심·저녁 등)와 새벽처럼 거의 없는 시간대가 존재한다. 평균값만으로 서버 용량을 정하면 피크 시간대를 감당하지 못하므로, 여유를 두기 위해 평균에 배수를 곱해 최대치를 가늠한다.

여기서 "×2"는 개략 추정이나 면접에서 편의상 쓰는 관습적 수치일 뿐, 근거가 있는 공식은 아니다.

이벤트성 트래픽(티켓팅, 수강신청, 세일)은 평균의 수십~수백 배까지 튀기도 한다.
트래픽이 고른 서비스는 1.5배 정도로도 충분할 수 있다.
실무에서는 실제 트래픽 로그로 peak/average 비율을 측정해서 배수를 정한다.

즉, "최대 QPS = 평균 QPS × 2"는 빠르게 감을 잡기 위한 rule of thumb이라고 이해하면 된다.

[대규모 시스템 설계 스터디] 1장 정리

Thu, 09 Jul 2026 07:08:17 GMT

들어가기에 앞서서

이번 방학 기간동안 대규모 시스템 설계 스터디를 진행한다.

교재는 가상 면접 사례로 배우는 대규모 시스템 설계 기초 를 사용했다.

기간은 7월 2일 ~ 9월 12일까지로 예상한다.

각 주마다 2번씩 진행되고, 스터디 과제는 벨로그 작성과 각 단원 문제풀이로 진행하며, 중간마다 시험문제를 출제하여 수준을 검토한다.

최종적으론 대규모 프로젝트를 진행하여 스터디를 마무리한다.

사용자 요청의 종류

사용자 요청에는 크게 웹 앱과 모바일 앱 두 가지 종류가 있다.

웹 앱은 비즈니스 로직과 데이터 저장 등을 처리하기 위해 서버 구현용 언어(자바, 파이썬 등)를 사용하고, 프레젠테이션 용으로는 클라이언트 구현용 언어(HTML, 자바스크립트 등)를 사용한다.

모바일 앱과 웹 서버 간 통신에는 HTTP 프로토콜을 이용한다. HTTP 프로토콜을 통해 반환되는 응답 데이터의 포맷으로는 보통 JSON이 쓰인다.

서버는 웹 계층과 데이터 계층으로 분리할 수 있으며, 각 계층을 독립적으로 확장해 나갈 수 있다.

데이터베이스

DB는 전통적인 관계형 DB와 비관계형 DB로 나뉜다.

관계형 DB (RDBMS)

관계형 데이터베이스 관리 시스템(RDBMS)이라고도 부른다.

대표적으로 MySQL, 오라클 DB, PostgreSQL 등이 있다.
자료를 테이블과 행, 열로 표현한다.
SQL을 사용하면 여러 테이블에 있는 데이터를 그 관계에 따라 조인하여 합칠 수 있다.

비관계형 DB (NoSQL)

대표적으로 CouchDB, Neo4j, Cassandra, HBase, Amazon DynamoDB 등이 있다.

키-값 저장소, 그래프 저장소, 칼럼 저장소, 문서 저장소 4가지로 나눌 수 있다.
일반적으로 조인 연산은 지원하지 않는다.

NoSQL이 적합한 경우는 다음과 같다.

아주 낮은 응답 지연시간이 요구될 때
다루는 데이터가 비정형이라 관계형 데이터가 아닐 때
데이터를 직렬화하거나 역직렬화할 수 있기만 하면 될 때
아주 많은 양의 데이터를 저장해야 할 때

스케일 업 vs 스케일 아웃

구분	설명
스케일 업 (수직적 규모 확장)	서버에 고사양 자원(더 좋은 CPU, 더 많은 RAM)을 추가하는 행위
스케일 아웃 (수평적 규모 확장)	더 많은 서버를 추가하여 성능을 개선하는 행위

스케일 업은 확장에 한계가 있으며, 장애에 대한 자동복구 방안이나 다중화 방안을 제시하지 못한다.

로드밸런서

부하분산 집합에 속한 웹 서버들에게 트래픽 부하를 고르게 분산하는 역할을 한다.

서버 간 통신에는 보안을 위해 사설 IP 주소를 이용한다.
웹 계층의 부하 분산 및 장애 대응이 가능해지고, 가용성이 향상된다.

OSI 계층 기준

OSI 기준으로 L4(NLB)와 L7(ALB) 로드밸런서가 있다.

L4: 전송 계층(TCP/UDP)에서 동작한다. IP와 포트 기반으로 트래픽을 분산하며, 패킷 내용을 보지 않아 빠르고 오버헤드가 적다.
L7: 애플리케이션 계층(HTTP/HTTPS)에서 동작한다. URL 경로, 헤더, 쿠키, 호스트명 등을 보고 라우팅한다. 세밀한 제어가 가능한 대신 상대적으로 무겁다.

구현 방식 기준

하드웨어 LB: 전용 장비를 사용한다. 고성능이지만 비싸고 확장성이 떨어진다.
소프트웨어 LB: 유연하고 저렴해서 클라우드 환경에 적합하다.

DB 다중화

보통 master-slave 관계를 설정하고, 원본은 주서버(master)에, 사본은 부서버(slave)에 저장한다.

쓰기 연산은 마스터에서만 지원하고, 슬레이브는 사본을 전달받아 읽기 연산만 지원한다.
DB에서는 읽기 연산이 쓰기 연산보다 비중이 크기 때문에, 통상 부데이터베이스 수가 더 많다.

이렇게 다중화를 하면 읽기 연산을 병렬 처리할 수 있어 성능이 향상되고, 안정성과 가용성이 높아진다.

💡 새로 알게 된 점 master가 꼭 하나일 필요는 없다. 쓰기 충돌 문제, PK 자동 증가값 충돌, 일관성 관리 복잡도 등의 문제가 있지만, master를 여러 개 둘 수도 있다.

캐시 (Cache)

값비싼 연산 결과나 자주 참조되는 데이터를 메모리 안에 두고, 뒤이은 요청이 보다 빨리 처리될 수 있도록 하는 저장소다.

데이터베이스보다 훨씬 빠르고, 데이터베이스의 부담을 덜어주는 장점이 있다.
정적 콘텐츠를 CDN으로 옮기면 응답시간을 개선할 수 있다.

읽기 주도형 캐시 전략: 찾는 데이터가 캐시에 없다면 데이터베이스 질의를 통해 데이터를 찾아 캐시에 저장한 뒤 클라이언트에 반환한다.

캐시 사용 시 고려할 부분

어떤 데이터를 둘지, 보관된 데이터는 어떻게 만료시킬지, 일관성 유지와 장애 대처는 어떻게 할지, 캐시 메모리의 크기를 얼마로 잡고 데이터 방출 정책을 무엇으로 할지 등 (자세한 내용은 책 참조)

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

정적 콘텐츠를 전송하는 데 쓰이는, 지리적으로 분산된 서버의 네트워크다.

이미지, 비디오, CSS, JavaScript 파일 등을 캐시하며, 동적 콘텐츠도 가능하다.
쉽게 말하면, 사용자에게 가장 가까운 CDN 서버로 안내하여 콘텐츠를 받게 하는 것이다.

CDN 사용 시 고려할 부분

비용, 적절한 만료 시한 설정, CDN 장애에 대한 대처 방안, 콘텐츠 무효화 방법 등 (자세한 내용은 책 참조)

무상태(Stateless) 웹 계층

웹 계층을 수평적으로 확장하기 위해서는 상태 정보를 제거해야 한다.

상태 정보를 가지면 특정 사용자의 요청이 그 상태 정보를 가진 특정 서버로만 가야 하기 때문에, 수평 확장을 방해한다.

같은 클라이언트의 요청을 같은 서버로 전송시키려면 로드밸런서의 고정 세션(sticky session) 기능을 사용하는데, 이는 로드밸런서에 부담을 주고 서버를 추가하고 제거하기도 까다로워진다.

따라서 상태 정보가 필요하면 지속성 저장소에 보관하고, 필요할 때 가져오게 하는 것이 좋다.

데이터 센터

단일 데이터 센터만 이용한다면, 해당 센터에 문제가 생길 시 서비스에 장애가 발생할 수 있다.

이를 방지하기 위해 두 개의 데이터 센터를 이용하고, 장애가 없는 상황에서는 사용자와 가까운 데이터 센터로 안내한다. 이 절차를 지리적 라우팅이라고 한다.

geoDNS: 사용자 위치에 따라 도메인 이름을 어떤 IP 주소로 변환할지 결정할 수 있도록 해 주는 DNS 서비스

다중 데이터 센터 아키텍처를 위해 고려할 점으로는 트래픽 우회, 데이터 동기화, 테스트와 배포 등이 있다. (자세한 내용은 책 참조)

메시지 큐

대규모 분산 시스템에서는 시스템의 컴포넌트들이 각기 독립적으로 확장될 필요가 있다. 이런 문제를 해결하기 위한 핵심 전략 중 하나가 메시지 큐다.

메시지 큐는 메시지 무손실을 보장하는 비동기 지원 컴포넌트다.

이 기능을 사용하면 서비스 또는 서버 간 결합이 느슨해져, 규모 확장성이 보장되어야 하는 안정적인 애플리케이션을 구성하기 좋다.
큐가 커지면 더 많은 작업 프로세스(소비자)를 추가해야 처리 시간을 줄일 수 있고, 큐가 항상 비어 있다면 작업 프로세스의 수를 줄일 수 있다.

로그, 메트릭, 자동화

로그: 시스템 오류와 문제들을 찾아내는 데 필수적이다. 서버 단위로 모니터링할 수도 있지만, 로그를 단일 서비스로 모아주는 도구를 활용하면 더 편리하게 검색하고 조회할 수 있다.
메트릭: 시스템의 현재 상태를 파악할 수 있는 지표다. 사업 현황에 관한 유용한 정보도 얻을 수 있다.
자동화: 지속적 통합(CI)을 도와주는 도구를 활용하면 코드를 자동으로 검증하여 문제를 쉽게 탐지할 수 있다. 이 외에도 빌드, 테스트, 배포 등을 자동화할 수 있다.

DB 규모 확장

시스템이 커지면서 저장할 데이터가 많아지면 데이터베이스의 규모도 확장할 필요가 있다.

앞서 말한 수직적, 수평적 방법이 있는데, 수직적으로 하는 경우도 있지만 결국 한계가 있고 장애 위험성과 비용 문제 등이 약점이다.

샤딩 (Sharding)

DB의 수평적 확장은 샤딩이라고도 부른다. 데이터베이스를 샤드(shard)라고 부르는 작은 단위로 분할하는 기술을 말한다.

모든 샤드는 같은 스키마를 쓰지만, 샤드에 보관되는 데이터 사이에는 중복이 없다.
이때 사용하는 것이 샤딩 키(파티션 키)로, 데이터가 어떻게 분산될지 정하는 하나 이상의 칼럼으로 구성된다.
데이터를 고르게 분할할 수 있도록 하는 것이 샤딩 키 선정에서 가장 중요하다.

샤딩 도입 시 고려할 점

데이터의 재샤딩, 유명인사 문제, 조인과 비정규화 등 (자세한 내용은 책 참조)

1장 마무리

시스템 규모 확장을 위해 살펴본 기법들을 정리하면 다음과 같다.

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

랩미팅 논문 발표 요약3

Mon, 17 Nov 2025 12:11:37 GMT

Resource-Aware Dynamic Scheduling for Tasks with Deadline Constraints on Edge Computing Systems

IEEE TRANSACTIONS ON CLOUD COMPUTING Wenbiao Cao, Xiaoyong Tang, Tan Deng, Ronghui Cao, and Keqin Li https://ieeexplore.ieee.org/abstract/document/11143954

연구 배경

AIoT 발전으로 MEC(Multi-access Edge Computing) 중요성 증대

AIoT와 IoT의 발전으로 데이터 소스와 가까운 위치에서 분산 연산 수요 및 지연 민감 서비스 급증

엣지 컴퓨팅은 코어 혼잡 완화 및 QoS 향상에 효과적 그러나, 엣지 환경은 다음과 같은 한계 존재

자원 이질성(Heterogeneity)
자원 경쟁(Resource competition)
마감시간 제약(Deadline Constraints)

핵심 과제 : 제한된 이질적 리소스와 동적 요구사항의 충돌

해당 논문의 Edge-Node에 대한 정의

Firstly, edge nodes have obvious heterogeneity in terms of resource type, performance, and architecture. Secondly, resource competition is widely present in edge networks.

Such as gateways(access points), local servers, small data centers, and even high-performance terminal devices are geographically distributed.

핵심 아이디어

RATGS(Resource-Aware Task Grouping Scheduling Strategy)

제한된 리소스로 최대한 많은 요청을 완료하는 것이 목표 데드라인 제약이 있는 태스크의 효과적인 스케줄링에 초점

Task Regrouping & Priority Response (Algorithm 1)
Resource-aware Greedy Scheduling (Algorithm 2)
Task Adjusting (DI/HRI/MRR, Algorithm 3)
Rescheduling (Algorithm 4)
핵심 목표

식(2) => 연산 능력 가용 검사 식(3) => 메모리 가용 검사 *현재 사용중인 {컴퓨팅 파워, 메모리} + 할당하려는 CU의 {컴퓨팅 파워, 메모리} <= 엣지 노드의 총 {컴퓨팅 파워, 메모리} 용량 *

Algorithm

Regrouping의 필요성

초기에는 태스크들이 도착 시간(Arrival Time) 기준으로 단순 저장되기 때문에, 서비스 유형과 자원 요구가 뒤섞여 스케줄링 효율이 저하 -> 태스크를 서비스 유형(Service Type) 및 긴급도(Urgency) 기준으로 Regrouping

Algorithm 1

태스크를 도착 시간에 따라 타이밍 그룹으로 분할
각 타이밍 그룹의 태스크를 서비스 타입별 컴퓨터 그룹(X_h)에 매핑
그 그룹의 기존 대기열의 각 태스크의 우선순위 및 평균 처리시간 계산
우선순위 값에 따라 새 대기열 생성
해당 서비스가 엣지에서 처리될 수 없으면 리모트 클라우드로 전송

Algorithm 2

즉시 가용 리소스가 있는 경우 (line 1~9)

가장 빠른 완료 시간을 가진 노드에 그리디 스케줄링 (line8~9)

리소스가 가득 찬 경우 (line 10~27)

각 슬롯 노드에 할당하여 EFT(Earliest Finish Time) 계산 (line 11~13)

데드라인 미충족 시 (line 14~27)

태스크 조정 호출 (line18~21)
실행가능한 솔루션이 없으면 리모트 클라우드로 스케줄링 (line22~25)

Algorithm 3

1. Direct Insertion(DI) (line 1~6) 새로운 태스크를 기존 실행 큐(PreScheme) 중간에 삽입하여 데드라인을 만족할 수 있는 위치를 찾음 특징 : 파편화된 리소스 활용하여 자원 낭비 감소 효과 : 데드라인 만족률 증가 2. Highest Reward Insertion(HRI) (line 7~15) 단순히 데드라인만 보는게 아닌 LTSS가 더 커지는 방향으로 태스크를 선택/재배치 특징 : Slack time을 활용하여 기다리면 더 가치있는 태스크를 살림 효과 : 전체 시스템 효용 극대화 3. Maximum Reward Replacement(MRR) (line 16~20) 가장 적은 재배치로 데드라인을 만족시키는 대안 탐색 특징 : 큰 구조 변경 없이 효율성 확보 효과 : 안정적이고 현실적인 조정 가능

Algorithm 4

Deadline 위반 태스크를 가장 빠른 EFT 노드로 재할당하여 CRD를 향상 시키는 것을 목표

가용 노드 집합 (AvaNodes) 생성 및 EFT 평가 (line 1~~6) EFT 최소 노드 선정 (line 7~~8) Deadline이내면 노드 갱신 및 우선순위 계산 (line 9~~13) 충족 불가 시 리모트 클라우드로 전송 (line 14~~17)

실험 환경

워크로드

실제 애플리케이션 이미지 처리, ALU 논리 연산, 부동소수점 연산, 얼굴 매칭 등 Python으로 작성된 여러 프로그램 사용

시뮬레이션 데이터셋 알리바바 클라우드 실제 트레이스 데이터 활용 밀도 데이터셋 : 8개 서브셋 (밀도 1~8), 각 약 10,000개 태스크 분포 데이터셋 : 3개 서브셋 (다양한 분포), 각 약 25,000개 태스크

각 태스크 디스패처는 서로 다른 종류의 애플리케이션을 실행 각 디스패처는 50~~100ms 간격으로 0~~1개의 태스크를 오프로딩

각 요청은 입력 메타데이터, 예상 마감시간 (Deadline), 긴급 여부(Expedited Flag)에 대한 정보 포함

서비스 인스턴스는 모두 pre-warmed 상태로 설정

평가지표

CRD(Completion Rate before Deadline) LTSS(Long-Term Satisfaction of System Service) ACT(Average Completion Time) Resource Utilization + RU Efficiency

비교 대상

Dedas : 노드의 스케줄을 순차적으로 순회하여 작업에 적합한 삽입 위치 탐색삽입 불가 시, 총 완료 시간을 비용 요소로 고려하여 최적의 스케줄을 얻기 위해 작업을 교체
RTH2S : 노드를 계층화하여 3단계 우선순위 큐와 EDF(Earliest Deadline First) 방식으로 스케줄링
LSPT (LeastLoad + SRPT) : 부하가 가장 낮은 노드에 태스크를 보내고, 남은 처리시간이 짧은 순으로 실행
LEDF (LeastLoad + EDF) : 부하 최소 + 가장 빠른 마감시간 순서로 태스크 할당
SF (Self + FCFS) : 태스크가 스스로 가장 빠른 완료시간을 예측하여 FCFS로 실행
실험 결과

테스트베드

태스크 도착 밀도

태스크 분포

태스크가어떤 분포로 도착하여도 RATGS가 CRD가 가장 높은 것을 확인 가능 태스크 도착 불확실성을 반영하기 위한 시뮬레이션

컴퓨터 유닛 수에 따른 데드라인 미스율

RATGS : 22 CU에서 99.9% 완료 (가장 빠름) 다른 전략 : 더 많은 CU 필요 LSPT/LEDF : CU증가해도 ~80% 완료 즉, RATGS는 자원이 부족한 상황일수록 성능 우위 확인 가능

컴퓨터 유닛 수에 따른 LTSS

컴퓨팅 유닛 수가 30에 도달하면 각 스케줄링 전략의 성능이 가장 좋아지는 경향이 있지만, 22 미만이면 RATGS의 성능이 LTSS 지표에서 모든 전략보다 우수

컴퓨터 유닛 수에 따른 ACT

컴퓨팅 유닛 수가 30을 초과하고 점진적으로 증가함에 따라 RATGS는 ACT에서 Dedas보다 약간 더 나은 성능을 보이기 시작 컴퓨팅 유닛 수가 증가함에 따라 최적의 스케줄링을 달성하기 위한 작업 조정 공간과 선택 사항이 더 넓어지기 때문

리소스 활용

RU(Resource Utilization) LSPT/LEDF: 평균 80% 이상 (최고) ->로드밸런싱 계열 RATGS: 고밀도 시 높음, 저밀도 시 낮음 RUE (RU Efficiency = CRD/RU) RATGS: 대조적 상황에서 최고 RUE 적은 리소스로 더 많은 태스크 완료 핵심발견 엣지 환경과 같은 자원이 제한된 환경에선 RUE가 더 중요한 지표 단순 활용보다 활용 효율성이 중요 RATGS는 제한된 리소스를 가장 효율적으로 활용

연구의 핵심 성과

이질적 자원 환경을 현실적으로 모델링
- 노드별 성능, 메모리, 대역폭 등을 구체적으로 고려
다항시간 복잡도의 휴리스틱 솔루션 제시
- NP-hard 문제를 O(n²) 내에서 근사적으로 해결
마감시간 제약과 자원 경쟁을 동시에 고려한 스케줄링 정식화
- LTSS와 CRD를 통합적으로 최적화
단순한 RU보다 RUE의 성능지표로서의 가치
- 자원이 한정된 환경에서 RUE가 성능지표로 더 적합한 것을 확인
  연구의 한계점 및 향후 연구
태스크 간 종속성 미고려
에너지 소비와 콜드 스타트로 인한 서비스 지연 무시

향후 연구

태스크 간 선후 관계를 반영한 스케줄링 모델
에너지 효율성 고려

랩미팅 논문 발표 요약2

Tue, 11 Nov 2025 10:17:52 GMT

A Price-and-Time-Slot-Negotiation Mechanism for Cloud Service Reservations IEEETRANSACTIONS ONSYSTEMS,MAN,ANDCYBERNETICS—PARTB:CYBERNETICS,VOL.42,NO.3,JUNE2012 Seokho Son and Kwang Mong Sim, _ Senior Member, IEEE_ https://ieeexplore.ieee.org/abstract/document/6108366

문제 제기 및 연구의 필요성

기존 모델의 한계와 PTN 지원의 부재

상업 클라우드 서비스 제공 업체들의 대표적인 세 가지 가격 모델은 온디맨드, 예약, 스팟 인스턴스로 나눌 수 있음 이 중 온디맨드와 예약 인스턴스는 고정된 가격을 지불해야하며 유동성이 적음. 스팟 인스턴스는 비용 절약이 가능하지만 서비스 시작, 종료 시점 계획이 어렵고 최대 입찰 가격 초과 시 경고 없이 인스턴스가 종료되는 큰 단점이 존재함

이로 인해 중단 없이 선호하는 시간대 예약을 위한 협상 메커니즘이 필요한데, 아직까지 서비스 가격과 시간대 협상을 자동화하는 메커니즘이 없음 따라서 연구를 통해 Price and Time slot Negotiation(PTN) 메커니즘을 개발함

연구 목표

시간대 선호도를 특성화하는 새로운 효용함수를 포함한 PTN 메커니즘 개발
소비자와 제공자의 협상 전략을 위한 절충 및 양보 알고리즘 설계
에이전트 기반 클라우드 테스트베드 구현
실험을 통한 PTN 메커니즘 평가
클라우드 리소스 가격 책정에 PTN 메커니즘 적용 사례 연구
핵심 아이디어

PTN(Prcie-Time-Slot Negotiation)
가격과 시간대를 동시에 고려하는 통합 협상 시스템
효용 함수 설계 a. 가격 효용 + 시간대 효용 = 총 효용 b. 개별 선호도를 정량적으로 표현
스마트 협상 전략 a. 절충 및 시간의존적 양보 알고리즘으로 효율성 증대 b. 버스트 모드로 선택권 확대
협상 프로토콜 a. Rubinstein's alternating offers protocol
핵심 해결책

협상 방식
기존 방식 한 번에 하나의 제안만 가능 상대방이 거절하면 다음 라운드까지 대기
VS
버스트 모드 한 번에 총 효용이 같은 제안을 동시에 제시 기존 방식보다 빠른 합의에 도달
효용함수
기존방식 사용자의 다양한 시간대 선호도 반영 불가 시간대를 단순히 마감 기한 내에 있는지 여부만 확인
vs
새로운 시간대 효용 함수 비선형 함수로 복잡한 시간 선호도 표현 가능 소비자 : 선호하는 여러 시간대 구간을 자유롭게 설정 가능 공급자 : 수요 예측, 리소스 활용도, 시간 순서를 종합 고려

효용 함수

가격 효용함수

소비자 가격 효용 함수 공급자 가격 효용 함수

시간대 효용 함수

소비자 시간대 효용 함수

공급자 시간대 효용 함수

총 효용 함수

실험 환경

에이전트 기반 클라우드 테스트베드

Java 및 JADE(Java Agent Development) 프레임워크를 사용하여 설계하고 구현

모든 에이전트는 JADE Directory Facilitator를 통해 구현된 클라우드 시장 등록소에 등록 등록소에 등록된 소비자 에이전트는 제공자 에이전트를 인식하고 상호 통신 가능 사용자는 GUI를 통해 서비스 이름, 가격, 시간대, 협상 전략 등 서비스에 대한 선호도를 지정하고 에이전트를 생성 가능

실험 결과

(a) λC =3.0, λP =3.0, τC =50,andτP =50. (b)λC =3.0,λP =3.0,τC = 200,andτP = 200. (c) λC =1/3, λP =1/3, τC =50, andτP =50. (d)λC =1/3, λP =1/3, τC = 200, andτP = 200. (e)λC =3.0, λP =1/3, τC =50, and τP =200. (f) λC =1/3, λP =3.0, τC =50, andτP = 200. (g)λC =3.0, λP =1/3, τC = 200,andτP =50. (h)λC =1/3, λP =3.0, τC =200,andτP =50.

λ : 협상 전략, τ : 협상 기한 λ < 1 -> 관대함(빠르게 양보) λ = 1 -> 선형(일정하게 양보) λ > 1 -> 보수적(느리게 양보)

협상 속도

동일한 협상 전략, 기한을 가진 에이전트 쌍의 경우 -> (a) - (d) 협상 에이전트가 더 빠른 양보 전략을 선택할 수록 협상 시간이 빠른 것을 확인

다른 협상 전략, 기한을 가진 에이전트 쌍의 경우 -> (e) - (h) 서로 다른 전략과 마감 기한을 가졌을 때도 Burst 모드에서 협상 속도가 높아지는 것을 볼 수 있음 (f), (g)에서는 한 에이전트가 보수적 전략과 긴 마감기한을 선택하면 협상 속도가 느려지는 것을 볼 수 있음 그럼에도 B50이 H1보다 28.1% ~ 57.3% 빠른 것을 확인

총 효용

협상 전략과 기한에 좌우되지 않음 협상 전략과 기한이 서로 같거나 다르거나 상관없이 일관되게 다른 기법들보다 총 효용이 높게 나오는 것을 볼 수 있음. 다만, CL이 0.9일 때는 사용 가능한 시간대가 적어지면서 평균 총 효용이 줄어드는 것을 확인할 수 있음

Burst Mode의 제안 개수

동시 제안의 수 증가와 결과 향상량

버스트 모드를 사용할 때, 동시 제안의 수가 증가함에 따라 더 빠른 협상 속도와 더 높은 효용이 나타났지만, 향상량은 동시 제안의 수가 증가함에 따라 감소함.

B10에서 B50으로 넘어갈 때, 협상 속도와 총 효용은 각각 5.6%와 1.5% 증가하였지만, B50에서 B100으로 넘어갈 때, 협상 속도와 총 효용이 각각 0.7%와 0.6% 증가하였음.

이는 버스트 모드가 너무 많은 제안을 동시에 한다고 성능이 크게 달라지지 않는다는 것을 시사함. 따라서 계산 복잡도와 성능 개선을 잘 확인하며 제안 개수를 설정해야 함.

연구의 기여도

최초의 클라우드 서비스 예약을 위한 PTN 메커니즘 설계 및 구현

Burst Mode 절충, 양보 알고리즘 설계

협상 속도와 총 효용 모두 향상
다중 이슈 협상에서 동시 다중 제안 가능
새로운 시간대 효용 함수 개발
다양한 시간대에 대한 서로 다른 선호도 특성화
기존 연구에서는 고려되지 않던 새로운 개념
연구의 한계점 및 향후 연구
협상 메커니즘에서 다룬 쟁점의 수가 제한적
계산 복잡도가 더 효율적인 알고리즘 필요
사용자 친화적 인터페이스 부족
동적인 환경 변화에 대한 미고려
향후연구
다른 협상 쟁점(QoS 등)을 고려하고 명시하는 것
버스트 모드의 동시 제안의 수를 적응적으로 제어하여 계산 복잡도를 줄이고 알고리즘 향상
높은 수준의 사용자 선호도를 시간대 효용 함수의 낮은 수준의 기술적 사양으로 변환하는 GUI

랩미팅 논문 발표 요약1

Tue, 11 Nov 2025 09:50:22 GMT

분산 데이터센터 환경의 클라우드에서 SLA 위반을 경감시키기 위한 가변 기법 정보과학회논문지: 컴퓨팅의 실제 및 레터 제 18 권 제 11 호(2012.11) 손석호, 정기훈, 전성찬 https://www.dbpia.co.kr/Journal/articleDetail?nodeId=NODE02033323

문제 제기 및 연구의 필요성

서비스 수준 협약을 위반할 가능성

기존 CSP는 고정된 SLA를 제시하지만, 시스템 자원이 부족해지면 SLA를 위반할 가능성이 높음 특히, 지역적으로 분산된 데이터 센터를 운영하는 클라우드 환경에서는 서비스 응답속도와 부하 분산 사이에 상관관계가 있는데, 고정된 SLA는 부하를 효율적으로 분산시키기 어렵게 만듦

이러한 문제를 해결하고자 분산 데이터센터 환경에서 SLA 위반을 줄이기 위한 가변 SLA기법을 제안하고 그 유효성을 평가하고자 이 논문이 작성됨

핵심 아이디어 및 해결책

핵심 아이디어

클라우드 서비스 공급자와 사용자 간의 자동화된 SLA 협상 메커니즘을 도입하여, 사용자의 요구사항과 시스템 자원 상황에 맞춰 서비스 품질을 미리 조율하는 것 이를 통해 고정 SLA로 인해 발생하는 문제들을 해결

해결책

다중 쟁점 협상 : 서비스 응답 속도와 가격을 주요 협상 쟁점으로 설정 공급자와 사용자는 이 두 가지 쟁점에 대한 만족도를 유틸리티 함수로 정의하고, 협상 에이전트가 최적의 합의점을 찾도록 함

가변 SLA 구현 : 협상을 통해 서비스 응답 속도와 가격을 유동적으로 결정하여, 사용자는 낮은 가격으로 느린 서비스를 받거나, 공급자는 부하 분산에 유리한 데이터센터에 작업을 할당할 수 있음

연구 결과 및 입증내용

결론 도출 과정

에이전트 기반의 클라우드 테스트베드를 구축하고, 가변 SLA 기법과 고정 SLA 기법의 성능을 비교하는 시뮬레이션을 수행함 1,000명, 5,000명, 10,000명의 사용자로 가정 후 테스트를 진행함

SLA위반 경감

가변 SLA를 적용했을 때, 고정 SLA를 사용했을 때 보다 위반 사용자의 수가 월등히 낮아진 것을 볼 수 있음

수익 증대

가변 SLA를 이용하면 클라우드 공급자에게 더 높은 수익을 제공하는 것을 그래프를 통해 확인할 수 있음

논문의 타당성 및 한계점

타당성

이 연구는 분산 데이터센터 환경의 문제점을 해결하기 위해 가변적인 SLA라는 새로운 접근법을 제시하고, 자동화된 협상 메커니즘을 적용하여 이를 구체적으로 구현함

실험을 통해 SLA 위반율 감소와 수익 증대라는 뚜렷한 결과를 확인할 수 있으므로, 논문의 주장은 매우 합당하다고 볼 수 있음

한계점

본 논문에서 언급된 직접적인 한계점이 없음

그러나 저자가 향후 연구로 SLA 협상 기법에 기반한 자원 및 과금 정책 스케줄러 디자인을 고안할 계획이라고 밝히며, 이는 SLA 협상 외에 실제 클라우드 시스템의 자원 관리 및 요금 청구 방식과 연계하는 포괄적인 연구가 필요하다고 볼 수 있음

컴퓨터 구조 Chapter 06

Mon, 01 Sep 2025 11:32:10 GMT

컴퓨터 저장 장치: RAM과 보조기억장치 (ft. 캐시 메모리)

1. RAM과 보조기억장치의 차이

컴퓨터의 저장 장치는 데이터가 전원이 꺼진 후에도 유지되는지 여부에 따라 휘발성과 비휘발성으로 나뉩니다.

RAM (Random Access Memory):
- 휘발성 장치로, 전원이 꺼지면 모든 내용이 사라집니다.
- CPU가 직접 접근하는 주기억장치이며, 현재 실행 중인 프로그램이나 데이터를 임시로 저장하는 '작업 공간' 역할을 합니다.
- RAM의 용량이 클수록 더 많은 프로그램을 동시에 처리할 수 있어 작업 속도가 빨라집니다.
보조기억장치:
- 비휘발성 장치로, 전원이 꺼져도 데이터가 보존됩니다.
- 하드 디스크(HDD), SSD, CD-ROM, USB 메모리 등이 대표적입니다.
- 프로그램과 데이터를 영구적으로 저장하는 역할을 합니다. CPU는 여기에 직접 접근하지 못하고, 실행에 필요한 데이터를 RAM으로 복사하여 사용합니다.

2. DRAM vs. SRAM: RAM의 두 얼굴

RAM은 크게 DRAM과 SRAM 두 종류로 나뉘며, 각각의 특성과 사용 목적이 다릅니다.

DRAM (Dynamic RAM):
- 저장된 데이터가 시간이 지나면 동적으로 사라지기 때문에, 주기적으로 데이터를 재활성화(재충전)해야 합니다.
- 저렴하고 집적도가 높아 대용량 메모리인 주기억장치(RAM)로 널리 쓰입니다.
SRAM (Static RAM):
- 전원이 공급되는 동안 데이터가 유지되어 재충전이 필요 없습니다.
- DRAM보다 속도가 빠르지만, 가격이 비싸고 소비 전력이 많으며 집적도가 낮습니다.
- 대용량보다는 빠른 속도가 중요한 캐시 메모리에 주로 사용됩니다.

구분	DRAM	SRAM
재충전	필요함	필요 없음
속도	느림	빠름
가격	저렴함	비쌈
집적도	높음	낮음
소비 전력	적음	높음
주요 용도	주기억장치(RAM)	캐시 메모리

3. 발전된 RAM: SDRAM과 DDR SDRAM

SDRAM (Synchronous Dynamic RAM):
- CPU의 클럭 신호와 동기화되어 작동하는 발전된 형태의 DRAM입니다.
- 클럭 타이밍에 맞춰 CPU와 데이터를 주고받아 비동기식 DRAM보다 훨씬 효율적입니다.
DDR SDRAM (Double Data Rate SDRAM):
- SDRAM의 발전형으로, 대역폭을 2배로 넓혀 한 클럭당 두 번씩 데이터를 주고받을 수 있게 되었습니다.
- DDR2, DDR3, DDR4 등으로 발전하며 전송 속도가 계속 향상됩니다.

4. 메모리 관리 기술: 논리 주소와 물리 주소

CPU는 프로그램을 실행할 때 실제 메모리 주소를 직접 다루기 어렵기 때문에 가상의 주소를 사용합니다.

물리 주소: 메모리 하드웨어가 실제로 사용하는 주소.
논리 주소: CPU와 실행 중인 프로그램이 사용하는 가상의 주소.

이를 변환하는 장치가 바로 메모리 관리 장치(MMU)입니다. MMU는 논리 주소에 베이스 레지스터 값을 더해 실제 물리 주소를 계산합니다.

메모리 보호 기법

베이스 레지스터: 현재 프로그램의 시작 물리 주소를 저장합니다.
한계 레지스터: 현재 프로그램의 논리 주소 최대 크기를 저장합니다.
작동 방식: CPU가 메모리에 접근할 때, 접근하려는 논리 주소가 한계 레지스터 값을 넘지 않는지 검사하여 다른 프로그램의 영역을 침범하지 않도록 보호합니다.

5. 저장 장치 계층 구조와 캐시 메모리

컴퓨터의 저장 장치는 속도와 용량에 따라 계층적으로 구성됩니다.

원칙: CPU에 가까운 장치일수록 빠르고, 멀어질수록 느립니다. 또한, 속도가 빠를수록 용량은 작고 가격은 비쌉니다.

캐시 메모리

CPU와 RAM의 속도 차이를 줄이기 위해 탄생한 매우 빠른 임시 저장 장치입니다. CPU가 필요할 것으로 예측되는 데이터를 미리 가져와 저장해 둡니다. 메모리로부터 데이터를 가져올 때는 참조 지역성의 원리를 따릅니다.

캐시 히트: 예측이 맞아 캐시에서 데이터를 찾았을 때.
캐시 미스: 예측이 틀려 RAM에서 데이터를 가져와야 할 때.
종류: CPU 코어에 가까운 순서대로 L1, L2, L3 캐시가 있습니다. L1이 가장 빠르고 용량이 작습니다.
참조 지역성의 원리: 캐시 메모리가 데이터를 가져오는 핵심 원칙입니다.
1. 시간 지역성: 최근에 사용된 데이터는 곧 다시 사용될 가능성이 높다.
2. 공간 지역성: 사용된 데이터 근처의 데이터가 곧 사용될 가능성이 높다.

컴퓨터 구조 Chapter 05

Sun, 17 Aug 2025 08:27:39 GMT

CPU의 핵심 작동 원리: 클럭, 멀티코어, 멀티스레드

1. 클럭 (Clock)

클럭은 컴퓨터 부품들이 일사불란하게 움직일 수 있도록 해주는 시간 단위입니다. 마치 지휘자의 박수처럼, CPU는 이 클럭 신호에 맞춰 명령어를 처리합니다.

클럭 속도 (Clock Speed): 1초에 발생하는 클럭의 횟수로, 헤르츠(Hz) 단위로 나타냅니다. 일반적으로 클럭 속도가 빠를수록 CPU의 성능이 높아집니다.
클럭 속도의 한계: 클럭 속도를 무작정 높이면 발열이 심해져 CPU 성능에 오히려 악영향을 줄 수 있습니다. 이 때문에 클럭 속도를 높이는 데에는 한계가 있습니다.

2. 멀티코어 (Multi-core)

클럭 속도의 한계를 극복하기 위해 등장한 방식 중 하나가 코어 수를 늘리는 것입니다.

코어 (Core): 실제로 명령어를 실행하는 CPU의 핵심 부품입니다.
멀티코어 CPU: 여러 개의 코어를 한 칩에 집적한 CPU를 말합니다. 여러 개의 일꾼이 동시에 작업하는 것처럼, 여러 코어가 동시에 명령어를 처리하여 전체 성능을 향상시킵니다.
- 예시: 2.4GHz 클럭의 단일 코어 CPU보다 1.9GHz 클럭의 멀티코어 CPU가 일반적으로 더 높은 성능을 보입니다.
주의사항: 코어 수가 많다고 해서 무조건 성능이 비례하여 증가하는 것은 아닙니다. 작업을 효율적으로 분배하는 기술이 중요하며, 작업량에 비해 코어 수가 지나치게 많으면 효율이 떨어질 수 있습니다.

3. 스레드 (Thread)

스레드는 CPU에서 명령어를 처리하는 단위로, 하드웨어 스레드와 소프트웨어 스레드로 구분해 이해하는 것이 좋습니다.

하드웨어 스레드

정의: 하나의 코어가 동시에 처리하는 명령어의 단위를 의미합니다.
멀티스레드 프로세서: 하나의 코어가 2개 이상의 명령어를 동시에 처리할 수 있는 기술입니다. 인텔의 하이퍼스레딩(Hyper-Threading) 기술이 대표적입니다.
- 원리: 코어 내에 여러 개의 레지스터를 두어 마치 여러 개의 코어가 있는 것처럼 동작하게 합니다. 그래서 하드웨어 스레드를 논리 프로세서라고 부르기도 합니다.

소프트웨어 스레드

정의: 하나의 프로그램에서 독립적으로 실행되는 작업의 단위입니다.
- 예시: 워드 프로그램에서 '입력 내용 보여주기', '맞춤법 검사', '자동 저장' 등의 기능을 각각의 스레드로 만들어 동시에 실행할 수 있습니다.

정리:

코어: 물리적으로 명령어를 실행하는 하드웨어 부품. (일꾼)
스레드: 명령어를 실행하는 논리적인 단위. (일꾼 한 명이 동시에 여러 개의 일을 할 수 있는 능력)
멀티코어: CPU에 물리적인 코어가 여러 개 있는 것.
멀티스레드: 하나의 코어가 여러 스레드를 동시에 처리할 수 있는 것.

CPU 성능 향상을 위한 명령어 병렬 처리 기법

CPU의 성능을 높이기 위해서는 클럭, 코어, 스레드 외에도 CPU가 쉬지 않고 일하게 만드는 명령어 병렬 처리 기술이 중요합니다.

1. 명령어 파이프라이닝 (Instruction Pipelining)

명령어 처리 과정을 여러 단계(인출, 해석, 실행, 결과 저장 등)로 나누고, 각 단계를 겹쳐서 동시에 처리하는 기법입니다. 마치 공장의 생산 라인처럼 여러 명령어를 연속적으로 처리하여 효율을 극대화합니다.

위험 요소:
- 데이터 위험: 명령어 간 데이터 의존성 때문에 발생하는 문제. (예: 앞선 명령어의 결과가 다음 명령어에 필요할 때)
- 제어 위험: 프로그램 분기(조건에 따라 실행 순서가 바뀌는 것)로 인해 미리 가져온 명령어들이 쓸모없게 되는 문제. 분기 예측 기술로 해결합니다.
- 구조적 위험: 여러 명령어가 동시에 같은 CPU 부품(ALU, 레지스터 등)을 사용하려고 할 때 발생하는 문제.

2. 슈퍼스칼라 (Superscalar)

대부분의 현대 CPU가 채택하고 있는 구조로, 여러 개의 파이프라인을 동시에 사용하는 기법입니다. 여러 명령어를 한꺼번에 처리할 수 있어 처리 속도가 이론적으로 파이프라인 개수에 비례하여 빨라집니다.

3. 비순차적 명령어 처리 (Out-of-order Execution, OoOE)

데이터 의존성이 없는 명령어들을 순서와 관계없이 먼저 실행하여, 파이프라인이 멈추는 것을 방지하고 전체적인 성능을 높이는 기법입니다.

명령어 집합 아키텍처 (Instruction Set Architecture, ISA)

ISA는 CPU가 이해할 수 있는 명령어들의 모음으로, CPU의 언어와 같습니다. 대표적으로 CISC와 RISC가 있습니다.

CISC (Complex Instruction Set Computer)

특징: 복잡하고 다양한 기능의 명령어 집합을 사용합니다.
장점: 하나의 명령어로 복잡한 연산을 수행할 수 있어 프로그램을 이루는 명령어 수가 적습니다.
단점: 명령어의 길이가 가변적이고 실행 시간이 일정하지 않아 파이프라이닝에 불리합니다.

RISC (Reduced Instruction Set Computer)

특징: 단순하고 적은 종류의 명령어를 사용합니다.
장점: 고정된 명령어 길이와 1클럭 내외의 실행 시간으로 파이프라이닝에 최적화되어 있습니다.
단점: CISC보다 많은 명령어를 사용해야 프로그램을 완성할 수 있습니다.

구분	CISC	RISC
명령어	복잡하고 다양함	단순하고 적음
명령어 길이	가변적	고정적
파이프라이닝	어려움	쉬움
프로그램 명령어 수	적음	많음
주소 지정 방식	다양함	적음
수행 시간	여러 클럭	1클럭 내외

컴퓨터 구조 Chapter 04

Thu, 17 Jul 2025 08:21:24 GMT

CPU와 작동 원리

ALU (산술 논리 연산 장치)

받아들이는 정보

피연산자와 제어 신호
- 레지스터를 통해 피연산자를 받아들이고, 제어장치로부터 수행할 연산을 알려주는 제어 신호를 받아들임
- 받아들인 피연산자와 제어 신호로 산술 연산, 논리 연산 등 다양한 연산을 수행

내보내는 정보

결과값과 플래그
- 결과값은 일시적으로 레지스터에 저장된 후 메모리에 저장 (프로그램의 실행 속도를 위해서)
- 플래그는 연산 결과에 대한 추가적인 상태 정보를 뜻하며, 플래그 레지스터에 저장됨

플래그 종류 및 의미

플래그 종류	의미
부호 플래그	연산한 결과의 부호를 나타냄
제로 플래그	연산 결과가 0인지 여부를 나타냄
캐리 플래그	연산 결과 올림수나 빌림수가 발생했는지를 나타냄
오버플로우 플래그	오버플로우가 발생했는지를 나타냄
인터럽트 플래그	인터럽트가 가능한지를 나타냄
슈퍼바이저 플래그	실행 중인 모드가 커널 모드인지 사용자 모드인지 나타냄

제어장치 (Control Unit)

받아들이는 정보

클럭 신호
- 컴퓨터의 모든 부품을 일사분란하게 움직일 수 있게 하는 시간 단위
- (모든 부품이 클럭 박자에 맞춰서 작동하지만, 한 박자마다 작동하는 건 아님)
명령어
- 명령어 레지스터로부터 해석할 명령어를 받아들이고, 해석한 뒤 제어신호를 발생시켜 수행할 내용을 알려줌
플래그
- 플래그 값을 참고하여 제어신호를 발생시켜 올바른 정보 전달 및 동작 수행 유도
제어 신호
- 제어 버스를 통해 외부로부터 전달된 제어 신호를 받아들이기도 함

내보내는 정보

외부에 전달하는 제어 신호:
메모리와 입출력장치에 전달하는 신호
내부에 전달하는 제어 신호:
ALU와 레지스터에 전달하는 신호

레지스터 (Register)

프로그램의 명령어와 데이터는 실행 전후로 반드시 레지스터에 저장됨
레지스터 속 값을 관찰하면 CPU 내에서 무슨 일이 벌어지고 있는지, 어떤 명령어가 어떻게 수행되는지 알 수 있음

주요 레지스터 종류

레지스터 명	설명
프로그램 카운터	메모리에서 읽어들일 명령어의 주소를 저장 (명령어 포인터)
명령어 레지스터	방금 메모리에서 읽어 들인 명령어를 저장하는 레지스터
메모리 주소 레지스터	메모리 주소를 저장하는 레지스터
메모리 버퍼 레지스터	메모리와 주고받을 값을 저장하는 레지스터
범용 레지스터	데이터와 주소를 모두 저장할 수 있는 범용 레지스터
플래그 레지스터	ALU 연산 결과에 따른 플래그를 저장
스택 포인터	스택의 꼭대기를 가리키는 레지스터
베이스 레지스터	유효 주소를 얻기 위한 베이스 값을 가지고 있는 레지스터

명령어 사이클 (Instruction Cycle)

명령어들은 일정한 주기가 반복되며 실행됨 (이 주기를 명령어 사이클이라고 함)
- 인출 사이클: 메모리에 있는 명령어를 CPU로 가지고 오는 단계
- 실행 사이클: 제어장치가 명령어 레지스터에 담긴 값을 해석하고, 제어 신호를 발생시키는 단계
- 간접 사이클: 실행을 위해 다시 메모리에 접근하는 단계

인터럽트 (Interrupt)

종류

동기 인터럽트:
CPU가 명령어를 수행하다가 오류 등 예외 상황에서 발생 (예외라고도 함)
비동기 인터럽트:
입출력장치에 의해 발생.
CPU가 지시한 작업을 완료하거나 입력을 받아들였을 때 CPU에 보내는 알림 (하드웨어 인터럽트라고도 함)

하드웨어 인터럽트 처리 순서

입출력장치가 CPU에 인터럽트 요청 신호를 보냄
CPU는 실행 사이클이 끝나고 명령어를 인출하기 전, 항상 인터럽트 여부를 확인함
인터럽트 플래그를 통해 현재 인터럽트를 받아들일 수 있는지 확인
인터럽트를 받아들일 수 있다면 CPU는 지금까지의 작업을 백업
CPU는 인터럽트 벡터를 참조하여 인터럽트 서비스 루틴(ISR)을 실행
ISR 실행이 끝나면 백업해둔 작업을 복구하여 실행 재개

CPU가 인터럽트 요청을 수행하려면 플래그 레지스터의 인터럽트 플래그가 활성화되어 있어야 함
정전이나 고장 등 치명적인 인터럽트는 무시할 수 없음

용어 정리

인터럽트 서비스 루틴(ISR): 인터럽트를 처리하는 프로그램 (인터럽트 핸들러)
인터럽트 벡터: ISR의 시작 주소 등 인터럽트 처리용 정보

예외의 종류

폴트 (fault):
예외를 처리한 직후, 예외가 발생한 명령어부터 실행 재개
트랩 (trap):
예외를 처리한 직후, 다음 명령어부터 실행 재개
중단 (abort):
심각한 오류로 프로그램 강제 중단
소프트웨어 인터럽트:
시스템 호출이 발생했을 때 나타남

컴퓨터 구조 Chapter 03

Sat, 05 Jul 2025 13:38:25 GMT

명령어

언어 번역 방식, 주소 지정 방식 정리

고급 언어와 저급 언어

우리가 작성하는 소스코드는 컴퓨터가 직접 이해하지 못함.

우리는 고급 언어(C, C++, Java, Python 등)를 사용하고,
컴퓨터는 저급 언어(기계어, 어셈블리어)만 이해하기 때문

기계어와 어셈블리어

기계어: 2진수 혹은 16진수로 구성된 컴퓨터가 직접 이해하는 명령어
→ 사람이 해독하기 어려움
어셈블리어: 기계어를 사람이 조금 더 이해하기 쉬운 형태로 표현한 저급 언어
→ 어셈블리어를 알면 프로그램이 어떻게 동작하는지를 근본적인 수준에서 이해할 수 있음

소스 코드 번역 방식

소스코드를 컴퓨터가 이해할 수 있도록 저급 언어로 변환하는 방식은 두 가지가 있다.

1. 컴파일 방식

전체 소스 코드를 한 번에 번역해서 실행
번역된 결과: 목적 코드(object code)
예: C 언어

✅ 장점:

전체를 컴파일해두므로 실행 속도가 빠름

❌ 단점:

컴파일 과정에서 오류가 하나라도 있으면 실행 불가

2. 인터프리터 방식

소스 코드를 한 줄씩 번역하면서 실행
예: Python

✅ 장점:

오류가 있는 줄을 실행하기 전까지는 나머지 코드가 실행됨

❌ 단점:

매번 해석하며 실행하기 때문에 속도는 느림

⚠️ 고급 언어는 컴파일 언어 vs 인터프리터 언어처럼 명확히 나뉘지 않음.
많은 언어가 두 속성을 모두 갖거나 전환 가능하기 때문

명령어 구조

컴퓨터 명령어는 다음 두 부분으로 구성됨.

연산 코드 (Opcode): 어떤 연산을 할지 정의
오퍼랜드 (Operand): 연산에 사용할 데이터

오퍼랜드는 연산의 대상이며, 데이터, 메모리 주소, 레지스터 등이 올 수 있음.
그래서 오퍼랜드 필드를 주소 필드라고도 부름.

주소 지정 방식 (Addressing Modes)

오퍼랜드 필드에 연산 대상의 주소나 값을 명시하는 방식. 대표적으로 다섯 가지 방식

1. 즉시 주소 지정 방식 (Immediate Addressing)

데이터를 오퍼랜드 필드에 직접 명시
가장 단순하고 빠르지만, 표현 가능한 데이터 크기에 제한이 있음

2. 직접 주소 지정 방식 (Direct Addressing)

유효 주소를 직접 명시
표현 가능한 주소의 범위가 연산 코드 길이에 제한받음

3. 간접 주소 지정 방식 (Indirect Addressing)

유효 주소의 주소를 오퍼랜드 필드에 명시
표현 범위는 넓지만, 메모리 접근이 2회 필요하여 느림

4. 레지스터 주소 지정 방식 (Register Addressing)

데이터를 저장한 레지스터를 오퍼랜드 필드에 명시
메모리보다 빠름
그러나 사용 가능한 레지스터 수에 제한

5. 레지스터 간접 주소 지정 방식 (Register Indirect Addressing)

데이터를 메모리에 저장하고,
그 주소를 저장한 레지스터를 오퍼랜드 필드에 명시
간접 주소 지정과 유사하지만, 메모리 접근은 1번만 필요

연산 코드의 유형

명령어의 연산 코드는 다음과 같은 유형으로 나뉨.

데이터 전송 (Data Transfer)
산술/논리 연산 (Arithmetic/Logical Operations)
제어 흐름 변경 (Control Flow)
입출력 제어 (I/O Control)