좋아! 이 슬라이드는 HTTP의 **3xx 상태 코드**, 즉 **리다이렉션(redirect)** 관련 응답 코드들을 정리한 거야. 아래에서 각각 설명해줄게.
---
## 🚥 3xx 리다이렉션 상태 코드 요약
### 🔁 301 Moved Permanently
* 클라이언트가 요청한 리소스가 **영구적으로 다른 URL로 이동됨**
* **브라우저나 검색엔진이 캐시**함 (SEO에서도 사용됨)
* **GET** 요청으로 리다이렉션되고, **`Location` 헤더**에 새 URL 명시
### 🔁 302 Found (기존엔 "Moved Temporarily")
* **임시 리다이렉션**
* 요청한 URL이 **일시적으로** 다른 곳으로 이동했음을 알림
* 보통은 \*\*같은 메서드(POST → POST)\*\*로 요청을 이어감
* 자주 쓰이지만 **모호해서 303이나 307이 생김**
### 🔁 303 See Other
* 클라이언트가 **다른 URL로 리다이렉트**되지만, **GET 메서드**로 바꾸어 요청해야 함
* 보통 **POST 후 리다이렉션**할 때 많이 씀
### 🔁 304 Not Modified
* 클라이언트가 보낸 `If-Modified-Since` 또는 `ETag` 헤더 기준으로, **변경된 게 없을 때**
* 브라우저 캐시를 이용하라는 의미
* **리다이렉션은 아니지만 3xx라서 포함됨**
### 🔁 305 Use Proxy (deprecated)
* 요청은 특정 프록시 서버를 통해서만 접근 가능함
* 보안 문제로 **현대 웹에서는 거의 사용 안 함**
### 🔁 306 Switch Proxy
* 현재는 사용되지 않음 (reserved for future use)
### 🔁 307 Temporary Redirect
* 302보다 **명확한 임시 리다이렉션**
* 요청 메서드를 **변경하지 않고 그대로 유지**함 (POST → POST)
* HTTP/1.1부터 명확히 구분
### 🔁 308 Permanent Redirect
* 301과 비슷하지만, **요청 메서드를 그대로 유지**함
* `Location` 헤더를 통해 새 URL 제공
* 301은 POST → GET으로 바뀌는 경우가 있지만, 308은 **POST → POST 유지**
---
## 💡 URL Shortener와 어떤 관련 있어?
* Bitly 같은 단축 URL 시스템에서는 주로 **302 redirect** 사용함.
> 왜?
> → \*\*Analytics (조회수 추적)\*\*를 위해 **캐시되지 않는 일시적 리다이렉션**이 좋기 때문이야.
> → 브라우저나 프록시가 301처럼 캐시하지 않게 하고 싶음.
---
필요하면 각 코드에 맞는 예시 HTTP 응답 포맷도 보여줄 수 있어!
좋아! 이 슬라이드는 \*\*"어떻게 short URL의 유일성(uniqueness)을 보장할 것인가?"\*\*에 대한 설계 전략을 비교해주는 아주 중요한 내용이야. 아래에서 각 솔루션을 쉽게 정리해줄게.👇
---
## 🎯 목표: **short URL이 절대 중복되지 않도록 만드는 방법**
---
## ❌ 1. Bad Solution: Long URL Prefix
> 긴 URL의 앞부분 일부를 따서 short URL을 만드는 방식
* 단점:
* 고유성이 보장되지 않음
* 긴 URL 구조가 유사하면 중복될 가능성 있음
* predictable (보안에 취약)
---
## ✅ 2. Good Solution: Random Number Generator or Hash Function
* 예: 랜덤하게 7자리 base62 문자열 생성 (`abc1234`)
* 해시 방식: `md5(longUrl) → base62 → 앞 6~8자`
* 장점:
* 간단하고 빠름
* 단점:
* **충돌 가능성 존재** → DB에서 중복 체크 필요
* 해시 기반은 동일 longUrl이면 항상 같은 short 나옴
---
## 🌟 3. Great Solution: Unique Counter + Base62 인코딩
* 전역 카운터를 사용해 **중복 없는 숫자 생성**
* 이를 \*\*base62 (0-9, A-Z, a-z)\*\*로 변환 → 짧고 유일한 문자열
* 예: `1000000 → Gho59`
### 🔧 확장성 고려 (Scalable하게 만드는 법)
* **Redis에서 글로벌 카운터 유지** (또는 shard 별 prefix로 분산)
* 예: `GET redis.incr(counter)` → 그걸 base62 인코딩
### ✅ 장점:
* 유일성 보장
* 순차 증가 → 충돌 없음
* 짧고 깔끔한 URL 생성 가능
---
## 🔐 Key Generation Service (KGS)
> 👉 대규모 시스템에서 **충돌 없이** 빠르게 키를 뽑아내기 위한 전용 서비스
### 동작 방식:
* 미리 랜덤한 7자리 문자열들을 생성해서 DB에 저장
* 클라이언트 요청 시 **미사용 키**를 하나 꺼내줌
* 꺼낸 키는 즉시 "사용됨"으로 마킹
* 장애 대비: **스탠바이 KGS 인스턴스 준비** (단일 장애점 방지 - SPOF)
### 장점:
* 완전 랜덤 + 고속 응답
* DB만 보면 되니까 빠르고 충돌 없음
### 단점:
* 키가 선점되어야 하므로 **공간 낭비 가능성** 있음
* 실시간 키 부족 → 키 refill 지연 가능
---
## 🧠 정리
| 방법 | 유일성 | 확장성 | 복잡도 | 비고 |
| ---------------- | ------ | --- | ---- | --------------- |
| Prefix | ❌ | 🔻 | 🔻 | 비추천 |
| Random / Hash | ✅(확률적) | 🔼 | 🔼 | 충돌 가능성 존재 |
| Counter + Base62 | ✅ | ✅ | 🔼 | Redis 이용 권장 |
| KGS | ✅ | ✅ | 🔼🔼 | 운영 부담 있지만 성능 최고 |
---
필요하면 Base62 인코딩 방식, Redis 카운터 샘플 코드, KGS 설계도 같이 그려줄게!
물론이죠! 🙌
이 슬라이드는 **CAP 이론**과 **읽기/쓰기 부하 특성에 따른 분산 시스템 설계 전략**을 정리한 거예요. 아래에 핵심을 정리해드릴게요.
---
## 🧠 CAP 이론: "Availability > Consistency"
* **CAP Theorem**: 분산 시스템에서는 **Consistency, Availability, Partition tolerance** 중 **두 개만** 보장할 수 있다.
* 여기서는 \*\*가용성(Availability)\*\*을 \*\*일관성(Consistency)\*\*보다 더 중요하게 선택했다는 전략임.
* 즉, 시스템이 언제든 **응답은 해야 하며**, 다소 일관성이 늦게 맞춰져도 괜찮다 (**eventual consistency**).
---
## ✅ High Availability + Eventual Consistency
* 고가용성을 위해 **Async 복제**를 사용함.
* 예: Primary → Secondary DB로 비동기 복제
* 일부는 1개의 Secondary에 대해서만 동기 복제를 설정하기도 함
* 결과적으로 **일관성은 Eventually (결국) 맞춰짐**
---
## 📖 Read Heavy System (읽기 많은 시스템)
> **읽기 요청이 쓰기보다 훨씬 많음 (Read ≫ Write)**
### 아키텍처 구성:
* Primary DB 하나: **쓰기 전용**
* 여러 Secondary DB: **읽기 전용 (replica)**
* 예: 뉴스, 블로그, 제품 카탈로그 등
### 성능 최적화 전략:
* **CDN 사용**: 정적 콘텐츠 캐싱
* **로드 밸런싱**
* **DB 인덱싱**: 검색 최적화
* **데이터 파티셔닝**: 스케일링
---
## ✍️ Write Heavy System (쓰기 많은 시스템)
> **쓰기 요청이 많음 (예: 로깅, 센서 데이터, SNS 게시물 등)**
### 전략:
* **NoSQL DB 사용**: Cassandra, MongoDB처럼 쓰기 처리에 특화된 DB 선택
* **Write Batching & Buffering**: 여러 개의 쓰기를 모아서 한 번에 처리
* **비동기 처리 (Async Processing)**: 쓰기 요청을 큐에 넣고 나중에 처리
* **CQRS**:
* \*\*Command (쓰기)\*\*와 \*\*Query (읽기)\*\*를 분리
* 시스템 복잡도 줄이면서 성능 최적화
* **Data Partitioning**: 쓰기 부하 분산
* **Event Sourcing / Streaming / Batching**: Kafka 같은 스트리밍 시스템으로 처리
---
## 🔗 정리하면
| 시스템 유형 | 전략 요약 |
| ----------- | ------------------------ |
| Read-heavy | Replica DB, 캐시, CDN, 인덱스 |
| Write-heavy | NoSQL, 배치 처리, CQRS, 파티셔닝 |
---
### ❓왜 이걸 Bitly 설계에서 얘기할까?
Bitly 같은 단축 URL 시스템은 \*\*읽기 많은 시스템 (Read-heavy)\*\*이기 때문에:
* Secondary DB를 활용한 읽기 최적화가 중요
* consistency는 잠깐 늦어져도 괜찮고, redirect는 항상 빨라야 하니까 **Availability 우선** 전략이 유효함
---
필요하면 CQRS 구조 예시, 읽기/쓰기 부하 패턴별 DB 구조도 그려줄게요!
좋아! 😎
이 슬라이드는 **Bitly 같은 단축 URL 서비스에서의 부가적인 요구사항 — Analytics(분석)와 Security(보안)** 를 정리한 거야. 아래에 쉽게 설명해줄게.
---
## ✅ 주제: `CAP (Availability > Consistency)` + 부가기능들
---
## 📊 Analytics (클릭 분석 기능)
> 단축 URL이 몇 번 클릭됐는지, 누가, 언제, 어디서 클릭했는지 추적하는 기능
### 포함 요소:
* **클릭 이벤트 추적**
* 유저가 단축 URL을 클릭할 때마다 이벤트 기록
* **통계 데이터 제공**
* 클릭 수
* Referrer (어디서 왔는지)
* 브라우저 종류
* 디바이스 종류 (PC, 모바일 등)
### 기술 예시:
* **Event Stream & Processor** 사용
→ 실시간으로 수많은 클릭 이벤트를 처리
* 예: Kafka + Flink / Spark Streaming
* 슬라이드에서는 `Ad clicker aggregator`로 표현됨 (광고 클릭 분석기와 유사한 구조)
---
## 🔒 Security (보안 기능)
> 악의적인 사용자가 **피싱 사이트나 악성코드 사이트로 연결되는 단축 URL을 생성**하는 걸 막아야 함
### 보안 고려 사항:
1. **악성 링크 생성 방지**
* 사용자 입력 URL에 대해 **안전성 검사**
* 외부 URL 검사 서비스 (예: Google Safe Browsing API) 활용 가능
2. **DDoS 및 Brute-force 공격 방어**
* 너무 많은 요청(트래픽)을 보내는 공격 방어
* 비정상적인 URL 생성 요청 또는 redirect 요청 감지
3. **방어 전략**
* **Firewall**: 기본 네트워크 보안
* **Rate Limiting**: 사용자당 요청 횟수 제한 (예: 1분에 10개까지만 허용)
* **Authentication**: 사용자 인증을 통해 권한 제한 (API Key 또는 OAuth 등)
---
## 🧠 이 슬라이드의 핵심 요약
| 영역 | 설명 |
| --------- | --------------------------------------------------------- |
| Analytics | 사용자 클릭을 실시간으로 분석해서 통계 제공 |
| Security | 악성 링크 차단 + 공격 방어 (DDoS, brute force 등) |
| 기술적 키워드 | Kafka, event stream, rate limit, firewall, authentication |
---
필요하면 Analytics 파이프라인 설계 예시나 SafeBrowsing 연동 방식도 보여줄 수 있어!
'미국유학 > Hello 시스템디자인스터디' 카테고리의 다른 글
| 5월 2일 Web Crawler (0) | 2025.05.03 |
|---|---|
| 4.22(화) Ad click aggregator (0) | 2025.04.23 |
| 25.04.18 금, Twitter (0) | 2025.04.19 |
