[1권 - 8장] URL 단축기 설계

[KimH4nKyul]

테크루타 세션에 URL 단축기 설계를 읽고 실시간 혹은 아고라에 사용할 질의응답 문항 작성

[KimH4nKyul]

10년간 3650억 개 레코드가 저장되었다면 어떻게 저장해야 자원을 효율적으로 사용(읽기/쓰기 시)할 수 있을까?

[KimH4nKyul]

• 필요하다면 삭제 정책 또는 이관한다?

[renechoi]

“필요하다면 삭제 정책 또는 이관한다” → 이것이 가장 기본적인 접근 중 하나입니다.
그러나 실제 운영 환경에서는 더 구체적인 데이터 라이프사이클, 파티셔닝/샤딩, 계층화 스토리지, 빅데이터 솔루션 등을 종합적으로 적용해야,
10년간 3650억 건처럼 매우 방대한 데이터를 무리 없이 관리할 수 있습니다.
정리하자면, 오래된 데이터는 싸고 느린 스토리지로 이관하거나 압축/아카이브하고, 자주 사용되는 최근 데이터만 빠른 DB에 두는 식으로 자원과 비용을 절감할 수 있습니다.

또한, 파티셔닝/샤딩을 적극 활용해 운영과 쿼리 효율을 높이고,
장기간 보관된 빅데이터는 필요한 시점에만 OLAP/분석 엔진으로 조회하는 구조가 일반적입니다.

[KrongDev]

우선 도메인관점으로 접근을 해볼 필요성이 있어 보입니다.

Full Url의 도메인부터 분류를 통해 데이터 조회 시 접근해야하는 DB를 특정하도록 하고,
만약 하나의 도메인 DB에 많은 데이터가 저장될 경우 파티셔닝을 통해 좀더 효율적으로 관리가 가능할 것 같습니다.

[KimH4nKyul]

301응답과 302응답의 차이점은 뭘까?

[cruellaDev]

✅ 단축 URL 서비스에서 301을 사용하는 이유

1️⃣ 리디렉션을 위한 표준적인 방식

• 단축 URL의 역할은 짧은 URL → 원래 URL로 리디렉션하는 것입니다.
• HTTP에서는 클라이언트(브라우저)가 새로운 URL로 이동하도록 지시하는 리디렉션 상태 코드가 존재합니다.
• **301 (Moved Permanently)**는 원래 URL이 영구적으로 이동했음을 의미하며, 단축 URL 서비스에 적합합니다.

🔹예제

HTTP/1.1 301 Moved Permanently Location: https://www.example.com/original-page

• 브라우저는 Location 헤더의 값을 보고 즉시 https://www.example.com/original-page로 이동합니다.

---

2️⃣ SEO(검색 엔진 최적화, Search Engine Optimization)

• 301 리디렉션은 SEO에서 원본 URL의 랭킹을 유지하는 데 도움이 됩니다.
• 검색 엔진(예: Google, Bing)은 301을 만나면 원본 URL로 검색 랭킹을 유지하며, 단축 URL을 중복 콘텐츠로 간주하지 않습니다.
• 반면, **302 (Found, 일시적 리디렉션)**을 사용하면, 검색 엔진이 "이 URL이 잠시 다른 곳으로 이동했다"고 해석하여 SEO 점수가 원본에 전달되지 않을 수 있습니다.

🔹301 vs 302 비교

리디렉션 코드	의미	검색 엔진 처리 방식
301 (Moved Permanently)	영구 이동	검색 엔진이 원본 URL의 SEO 점수를 유지
302 (Found, Temporary Redirect)	일시적 이동	검색 엔진이 새 URL을 임시로 사용하고 원본 점수를 유지하지 않음

---

3️⃣ 브라우저 캐싱 최적화

• 301 응답은 브라우저가 캐시(Cache)할 수 있음
• 브라우저는 301 응답을 받으면 단축 URL과 원본 URL 간의 매핑을 캐시하고, 다음 번 요청 시 서버에 다시 요청하지 않고 원본 URL로 직접 이동합니다.
• 즉, 서버 부하를 줄이고 속도를 높이는 효과가 있습니다.

🔹캐싱 적용 예제

Cache-Control: max-age=31536000

• 위 헤더를 추가하면, 브라우저는 1년(31,536,000초) 동안 301 리디렉션을 캐싱하여 불필요한 서버 요청을 방지합니다.

---

4️⃣ 클라이언트가 올바르게 동작하도록 보장

• HTTP 클라이언트(브라우저, 모바일 앱, 봇 등)는 301 상태 코드를 만나면 자동으로 원본 URL로 이동하도록 구현되어 있음.
• 사용자가 단축 URL을 클릭하면 자동으로 원본 URL로 이동해야 하므로, 301을 사용하면 브라우저, 크롤러, API 클라이언트 모두 표준 동작을 따르게 됨.

---

✅ 그럼 302 리디렉션을 사용하면 안 되나요?

302(Found, Temporary Redirect)도 가능하지만, 단축 URL 서비스에서는 301이 더 적합합니다.

💡 302를 사용할 경우 단점

1. SEO 문제: 검색 엔진이 원본 URL을 올바르게 평가하지 못할 가능성이 있음.
2. 캐싱 비효율성: 302는 브라우저가 캐시하지 않으므로, 동일한 단축 URL에 대해 서버에 계속 요청이 들어올 수 있음.
3. 의도한 동작이 아님: 단축 URL은 원래 URL로 영구적으로 연결되는 것이므로, 301이 더 적합.

📌 하지만, A/B 테스트나 일시적인 리디렉션이 필요한 경우 302를 사용할 수 있음. 예를 들어:

• 마케팅 캠페인에서 특정 단축 URL을 다른 URL로 동적으로 변경하는 경우.
• 특정 기간 동안 다른 URL로 유도해야 하는 경우(예: "오늘만 특별 할인 페이지로 이동").

---

✅ 결론

1. URL 단축기에서는 301(Moved Permanently)이 표준적인 선택
2. SEO(검색 엔진 최적화) 관점에서 원본 URL의 점수를 유지할 수 있음
3. 브라우저 캐싱을 활용하여 성능을 최적화하고 서버 부하를 줄일 수 있음
4. 클라이언트(브라우저, 크롤러, API)가 예측 가능한 방식으로 동작

---

🎯 추가 고민해볼 문제

1. 단축 URL의 만료 기한을 설정해야 할 경우, 301과 302 중 어느 것이 적절할까?

[KimH4nKyul]

해시 테이블을 사용하는 것의 장/단점은 뭘까?

[KimH4nKyul]

해시 충돌을 방지하면서 단축 URL을 저장할 수 있는 방법은 없을까?

[renechoi]

find your answer

@KrongDev

1.

url 단축 엔드포인트를 설계 할 때 다음과 같은 형태로 작성한다.

• POST /api/v1/data/shorten
• 파라미터 : longUrl (str)
• 반환: 단축 URL

그런데 왜 여기서 post 요청일까? GET 요청은 왜 아닐까?

2.

url 단축에 있어서 리디렉션이 301과 302로 다를 수 있다

서버에서는 유저의 접속 로그를 상세히 출력하기를 윈하는 상황이다. 어떤 방식이 적절할까?

c.f.

• 301은 permantently moved로 이 응답을 받으면 브라우저가 캐시함
• 302는 not found로 일시적으로 location header가 지정하는 url에 처리되도록 함

그러면 각기 다른 장단점은 무엇이고 어떤 경우에 쓰일 수 있을까?

3.

url을 해싱하는 과정에서 충돌을 방지해야 합니다. 블룸필터를 사용해서 이 문제를 해결할 수 있을까요 ?

4.

단축 url을 만드는 방법으로 해싱 후 충돌 해소 전략, base-62 (0-9, a-z, A-Z의 hashvalue 기반) 전략을 사용할 수 있을 텐데요. 두 방식의 차이가 어떻게 될까요?

5.

base62 변환의 단점를 보안하거나 해결할 수 있는 방법이 무엇이 있을까요 ?

6.

DB와 어플리케이션이 모두 분산된 환경이라면, base62를 만들 때 직면할 수 있는 도전 과제로 무엇이 있을까요? 또 어떤 점을 중점으로 보아야 하며 문제가 있다면 어떻게 해결할 수 있을까요 ?

7.

URL 단축기를 실제로 설계한다고 했을 때 플로우 (혹은 시퀀스)가 어떻게 되는지 설명해주세요 (url을 단축하는 메커니즘, url을 리디렉션 하는 메커니즘)

[renechoi]

분산 환경에서 고유 ID(오토 인크리먼트, 이하 AI)를 중앙에서 관리하는 것은 직관적으로 간단해 보이지만, 성능과 확장성, 가용성 측면에서 여러 트레이드오프가 생깁니다. 아래에서는 중앙 DB를 두어 AI를 관리하는 방법의 장단점과, 대안적인 분산 ID 생성 전략을 간단히 정리해 보겠습니다.

---

1. 중앙 AI 관리(DB) 방식

1) 개념

• 분산된 여러 DB나 서비스가 오토 인크리먼트 값을 필요로 할 때, 중앙 DB(또는 서버)에 요청하여 번호를 받아오는 구조
• 중앙 DB는 단일 시퀀스(Sequence) 테이블 또는 컬럼을 갖고, 각 요청마다 새로운 고유 번호를 발급해줌

2) 장점

1. 고유성(Unique) 보장이 비교적 단순
   • 모든 아이디(ID)가 한 곳에서 발급되므로, 중복될 가능성이 사실상 0에 가까움
   • 충돌이나 중복 검증 로직을 분산 노드에서 중복으로 처리할 필요가 없음
2. 관리 용이
   • 여러 노드/샤드가 어떤 범위를 쓰고 있는지 추적할 필요 없이, 중앙에서 일관되게 관리
   • 운영/모니터링 시 “현재 시퀀스 얼마까지 갔는지” 한눈에 파악 가능

3) 단점

1. 단일 장애점(SPOF, Single Point Of Failure)
   • 중앙 DB에 문제가 생기면 모든 노드가 ID 발급을 못 받아 서비스 전체가 중단될 수 있음
2. 병목(Bottleneck) 현상
   • 모든 분산 노드가 한 곳에 몰려 요청 → 부하가 커지면 중앙 DB가 성능 한계에 도달
   • 특히 대규모 트래픽 환경에서 문제
3. 지연 시간 증가
   • 분산 노드가 중앙 DB로부터 ID를 받아오는 통신 오버헤드가 발생
   • 서버 간 물리 거리나 네트워크 상태에 따라 응답 속도에 영향

---

2. 대안적인 분산 ID 생성 전략

1) DB-기반 Sharding + Range 분배 (Hi/Lo, Block Allocation)

1. 개념
   • 각 노드(샤드)가 **ID 번호 구간(range/블록)**을 일정 크기로 미리 할당받아 사용
   • 예: 노드1은 11,000,000, 노드2는 1,000,0012,000,000, … 이런 식
   • 소진되면 중앙에서 새로운 Range를 가져오거나, 일정 로직에 따라 재할당
2. 장점
   • Node마다 독립적으로 AI 발급 가능 → 중앙 서버 부하 감소
   • 중복 없이 분산 운영 가능
3. 단점
   • Range를 너무 작게 잡으면 자주 중앙에 재요청해야 함 → 빈번한 갱신
   • Range를 너무 크게 잡으면 낭비 공간이 발생하거나 ID 폭이 과도하게 커짐

---

2) UUID/Guid 사용

1. 개념
   • 각 노드가 OS 차원 또는 라이브러리를 통해 UUID(v4 등)를 직접 생성
   • 128비트(16바이트)로 매우 큰 공간을 사용해 실질적으로 충돌 가능성이 극도로 낮음
2. 장점
   • 중앙 서버 필요 X, 각 노드가 독립적으로 ID 생성
   • 중복 가능성이 사실상 무시해도 될 정도로 작음
3. 단점
   • 기존 숫자형 AI(오토 인크리먼트)보다 문자열 길이가 길고, 색인 인덱스(인덱싱)나 가독성이 떨어짐
   • 정렬 시 순차성이 보장되지 않는 UUID(특히 랜덤 기반)라면, DB 인덱스에 부담이 될 수 있음

---

3) Twitter Snowflake / Instagram ID 등 분산 알고리즘

1. 개념
   • 타임스탬프 + 머신 ID + 시퀀스 등을 조합해 전 세계에서 유일한 64비트 정수를 생성 (ex. 트위터 스노우플레이크 알고리즘)
2. 장점
   • 고유성 + 시간순 정렬을 어느 정도 보장
   • 각 노드(워크자)마다 고유 ID를 부여해 충돌 방지
3. 단점
   • 구현이 다소 복잡
   • 시간을 잘못 설정하는 경우(서버 시간 역행 등) 주의 필요

---

4) 중앙 서버를 분산 이중화(Clustering)하는 방식

1. 개념
   • 중앙을 완전히 제거하긴 어렵지만, 중앙 DB나 중앙 ID 발급 서버를 여러 대로 클러스터링해 고가용성(HA)을 구성
2. 장점
   • 장애 및 부하가 한 서버에 몰리지 않도록 로드밸런싱
   • 중앙 집중형이지만, SPOF를 완화하고 확장 가능
3. 단점
   • 구성 복잡도 증가
   • 여전히 중앙화에 준하는 구조이므로 대규모 트래픽에 대한 무한 확장은 어려울 수 있음

---

3. 결론 및 권장사항

1. 중앙 DB에 AI 시퀀스를 두는 방법은 구조가 명확하고 실현하기 쉽지만,

   • 트래픽이 폭증하면 **병목(Bottleneck)**이 되거나
   • 단일 장애점(SPOF) 문제가 발생할 수 있습니다.

2. 규모가 작을 때는 크게 문제 되지 않지만,

   • 고가용성, 수평 확장이 중요한 대규모 시스템에서는 중앙 집중형 AI 발급이 제한적일 수 있습니다.

3. 대안으로는

   • Range 할당(Hi/Lo, Block Allocation),
   • UUID 기반 전역 고유 ID 사용,
   • Snowflake 등 분산 ID 알고리즘,
   • 중앙 서버 클러스터링(고가용성)
     등이 있습니다.

4. 각 방안은 운영 편의, 트래픽 규모, DB 구조, ID 정렬 필요성 등의 요인을 고려하여 선택해야 합니다.

   • 예: “ID가 짧고 순차적이길 원한다”면 Range 할당 방식
   • “완벽히 분산 & 중복 없는 전역 ID”를 원한다면 Snowflake/UUID 등
   • “규모가 작고 구현이 단순한 게 좋다”면 중앙 AI도 괜찮음

즉, 분산 환경에서 중앙 DB를 둬서 AI를 관리하는 것은 작은 규모나 제한적 상황에서는 괜찮지만, 서비스가 커질수록 성능·안정성 문제가 커질 수 있으므로 위 대안들을 검토해보는 것이 좋습니다.

[renechoi]

분산 환경에서 **각 DB(또는 노드/샤드)에 고유한 ‘Prefix(Shard ID 등)’**를 부여하고, 거기에 해당 DB가 발급하는 AI(오토 인크리먼트) 값을 조합하여 전역적으로 유니크한 ID를 생성하는 아이디어는 꽤 흔히 쓰이고, 효과적인 방식 중 하나입니다. 다만, 구현/운영 측면에서 몇 가지 주의할 점이 있으니 정리해 보겠습니다.

---

1. 기본 원리

• Shard(혹은 DB) 식별자로 쓸 고유 Prefix를 미리 정해둡니다.
  • 예: 샤드1은 prefix=1, 샤드2는 prefix=2, … 또는 더 큰 범위로 분할 가능
• 각 샤드(DB)는 자신의 로컬(지역) AI를 가지고 있고, 오토 인크리먼트가 충돌 없이 올라감.
• 최종 ID는 ShardPrefix + LocalAI 형태로 만들거나(문자열),
  • 정수형 필드라면 (ShardPrefix << N) + LocalAI(비트 연산) 형태도 가능.
  • 즉, 특정 비트 영역을 shard 식별용으로, 나머지 비트를 AI로 활용.

이렇게 하면 각 샤드는 독립적으로 AI를 발급하되, prefix가 달라서 최종 결과가 전역에서 유니크해지는 원리입니다.

---

2. 장점

1. 중앙 서버 없이도 충돌 없는 전역 ID

   • 모든 샤드에서 동시에 ID를 만들어도, prefix가 달라 전역 충돌이 없음
   • “중앙에 요청”이 없어 병목이나 단일 장애점(SPOF) 없이 동작

2. 구현이 비교적 간단

   • DB 레벨의 auto-increment 또는 시퀀스 기능을 그대로 쓰고, 최종 단계에서 prefix만 더해주면 됨
   • 여러 복잡한 알고리즘(예: Snowflake)보다는 구현 난이도가 낮은 편

3. 순차성 유지(샤드 내)

   • 해당 샤드 내부의 ID는 오름차순으로 증가(로컬 AI) → 인덱스 효율성 측면에서 유리
   • 대량으로 insert할 때, 샤드 내부적으로는 인덱스 fragmentation이 적어 성능에 유리

---

3. 단점 및 주의 사항

1. Shard Prefix 할당 관리

   • shard를 추가/삭제/분할/통합할 때, prefix(번호)를 재할당해야 함
   • 한번 사용한 prefix를 다시 사용할 경우(샤드 재활용) 과거 ID와 충돌 위험이 있지 않은지 관리 필요

2. ID 길이(비트 수 혹은 문자열 길이)

   • 정수(숫자형)로 저장한다면, prefix와 AI를 어떻게 나눌지 설계해야 함 (예: 64비트 정수 안에서 몇 비트를 prefix로 쓸지)
   • 너무 큰 prefix 범위 + 많이 증가하는 AI 조합 → 오버플로(overflow) 위험이 없는지 확인해야 함
   • 문자열로 구성한다면, prefix + AI가 점차 길어질 수 있어 인덱스 효율을 고려해야 함

3. 전역 시점의 순차성 보장 어려움

   • 샤드 간에는 각기 속도가 달라, prefix가 다르다 해도 전체 “시간 순”을 맞추기는 불가능
   • 예를 들어 샤드2가 더 빨리 많은 ID를 만들면, numeric값 자체가 샤드1보다 훨씬 커질 수 있음
   • 시간 정렬이 필요한 경우엔 Snowflake나 타임스탬프를 포함한 알고리즘 고려

4. Shard 개수가 너무 많아지는 경우

   • prefix로 할당할 수 있는 범위가 제한적이면(예: 정수형에서 10비트만 shard ID로 씀 → 1024개 샤드 제한) 확장성 문제가 생김
   • 반대로 너무 큰 shard ID 비트를 잡으면, 로컬 AI 비트가 줄어드는 등 설계 이슈

5. 특정 샤드 폭주

   • 어떤 샤드가 유난히 많은 데이터를 처리해 AI 값이 빠르게 증가한다면, shard 간 ID 길이 편차가 발생할 수 있음(일반적으로 큰 문제는 아니지만, DB나 인덱스에서 숫자가 커지는 것에 대한 고려 필요)

---

4. 종합 검토

1. 규모가 중소형 or 샤드 수가 제한적:

   • 중앙 없이 샤드별 prefix를 설정해 쓰는 건 매우 효율적이며 심플한 방식입니다.
   • 운영 중 prefix 관리만 잘 하면, 특별한 병목이나 SPOF 없이 잘 동작합니다.

2. 샤드가 매우 많고, 동적 확장이 자주 일어나는 상황:

   • prefix를 무제한으로 관리하기 어렵고, 샤드 증설·감소 시 ID 할당 관리가 귀찮을 수 있음
   • 이런 경우엔 Twitter Snowflake 같이 “타임스탬프+워커ID+시퀀스” 조합 알고리즘이나, UUID 방식도 검토해봐야 합니다.

3. 시간 정렬·순차성이 중요한 경우:

   • 순전히 prefix + AI 모델은 샤드 간 ID를 발급하는 순서를 전체적으로 조율하기 어렵습니다.
   • 전역에서 시간 순 ID가 필요하면 “Local AI + Timestamp”를 함께 사용하는 등 보완이 필요합니다.

---

5. 결론

• “DB마다 고유 Prefix(Shard ID)를 주고, 로컬 AI를 합쳐 전역 유니크 ID로 사용” 하는 전략은 분산 시스템에서 매우 흔하고 실용적인 패턴입니다.
• 중앙 서버 없이 충돌을 방지하고, 샤드 간 독립성을 확보하는 등 장점이 많습니다.
• 다만,
  • Shard Prefix 할당/변경 관리,
  • ID 비트 분할(가능 범위),
  • 전역 시간순 정렬 필요성,
  • 샤드 폭주 시 불균형 문제
  • (그리고 혹시 DB 병합/분할/재활용 상황)
    등에 대해서 미리 정책을 세우고, 구체적으로 운영 절차를 마련해야 합니다.

결국 샤드가 여러 개라도 자주 바뀌지 않고(샤딩 구조가 비교적 안정적), 전역 시간순 정렬이 필수적이지 않다면 이 방식은 구현이 쉽고 확실히 유니크하므로 좋은 선택이 될 수 있습니다. 반면에, 샤드가 동적으로 자주 생기고 사라지는 매우 대규모/유연한 환경이라면, Snowflake나 UUID처럼 조금 더 동적인 분산 ID 알고리즘을 적용하는 편이 낫습니다.

[KimH4nKyul]

URL의 해시값 기반으로 데이터를 분산시키는 구체적인 방법은?

[KimH4nKyul]

안정 해싱을 이용해 볼 수 있지 않을까?

[KimH4nKyul]

블룸필터가 URL 단축 설계시에 이용되는 흐름은?

[KimH4nKyul]

[쓰기]

• 블룸 필터에 단축 URL 저장
• DB에 매핑 정보 저장

[읽기]

• 블룸 필터로 빠르게 존재 여부 확인 (존재하면 DB 조회)

[KimH4nKyul]

레이트 리미터, DB 샤딩 또는 레플리케이션에 대한 고려는?

[yw7148-riiid]

Base62를 사용할 때 유일 ID 생성 문제

1. 7자리라는 제한에 의해서 유일 ID는 62^7 (3,521,614,606,208)보다 작아야 한다.
2. snowflake 유일 ID 생성기의 최대 값은 64비트 = 18,446,744,073,709,551,616 이다.

snowflake 유일 ID 생성기를 사용하지 못할 것 같은데 어떻게 해결해야 할까?

[yw7148-riiid]

1. snowflake를 customizing해서 36bit내로 줄인다.

• data center 등 필요 없는 데이터 삭제
• 밀리 초 단위를 초 단위로 바꾸고 초당 개수를 제한한다. (rate limit)

2. 7자리 라는 제한을 완화한다.

[yw7148-riiid]

시간 정보가 필요 없을 지도...?

• snowflake가 시간 정보를 사용하는 이유는 ID만을 보고 시간순을 정렬을 하기 위함
• 단축 url에서는 시간순 정렬이 필요 없을 수도...

[yw7148-riiid]

1. base62의 단점: "예측이 가능하다"는 게 왜 단점일까?
   hashing전략이 노출이 돼서 "원래 url" > "단축 url"을 마음대로 예측할 수 있다면 이게 보안상 문제일까?

[KimH4nKyul]

• 단순히 유일 ID로 인한 단축 URL 예측이 문제라면, 쓰기 전에 Salt Hashing을 이용해서 원본을 마스킹하면 될까?

[renechoi]

쉽게 “링크 열거(Enumeration)” 가능

공격자가 특정 단축 URL을 알게 되면, 비슷한(앞뒤) ID를 대입해보면서 다른 링크를 무작위로 열어볼 수 있습니다.
일부 서비스에서는 ‘공유용 단축 링크’를 만들어두고 인증 절차를 생략(혹은 약한 인증)하는 경우가 있는데, 이런 링크들이 예측으로 인해 **“원치 않는 접근”**을 허용할 여지가 생김.

[KrongDev]