인프런 커뮤니티 질문&답변

안녕하세요 방구석효행뜽님, 먼저 수강 해주신 것에 감사드립니다.

아주 좋은 질문을 해주셨습니다.

먼저 Redis Counter를 사용하는 이유는 URL 단축 서비스에서 사용되는 고유한 id 를 생성하기 위함입니다. URL 단축 서비스의 핵심은 긴 URL 을 짧고 고유한 Short URL 로 변환하는 것에 있습니다. 또한 쓰기(URL 생성) 작업에 대한 확장성과 빠른 퍼포먼스를 보여줄 수 있습니다.

이 과정에서 중복되지 않는 키를 빠르고 효율적으로 만들어야 하기 때문에 메모리 기반의 고성능 데이터 저장소인 Redis Counter를 기반으로 INCR 명령어를 통해 카운터를 증가 시켜 고유한 id 값을 생성하게 됩니다. 따라서 Redis Counter 가 제공하는 증가되는 숫자 (예시, 1, 2,3 ...) 를 기반으로 Short URL 을 생성하게 되는데 데이터 흐름을 보면 아래와 같습니다.

1. Short URL 생성

2. Redis Counter 증가

3. DB에 저장

4. 캐시 업데이트

이 과정에서 사용자가 긴 URL(예: https://example.com/very/long/url 을 단축하려고 요청하면, 시스템은 고유한 short URL(예: https://short.url/g8)을 생성해야 합니다.

• Redis counter는 여기서 고유한 숫자 값을 제공합니다. 예를 들어, INCR counter 명령을 실행하면 현재 값이 1000에서 1001로 증가합니다.

• 이 값(1001)을 기반으로 short URL의 키를 만듭니다. 흔히 Base62 인코딩(0-9, a-z, A-Z를 사용한 62진법)을 사용해 숫자를 짧은 문자열로 변환합니다. 예를 들어, 1001은 g8로 변환될 수 있습니다.

Counter 값 1000 → Base62로 변환 → g8 → https://short.url/g8

Counter 값 1001 → Base62로 변환 → g9 → https://short.url/g9

결과적으로 https://short.url/g8 같은 short URL이 생성됩니다.

그리고 질문에서 "Redis counter를 증가시키고 short URL을 생성한다"는 순서가 반대일 수도 있다고 하셨는데, 보통은 counter를 증가시키는 게 먼저고 그 값을 사용해 short URL을 만듭니다. 하지만 시나리오상 순서가 바뀌어도 결과는 동일합니다.

그리고 말씀하신대로 "100억 개 URL limit을 체크하기 위함이 합리적일 것 같다"고 하신 추측도 타당합니다. 예를 들어, counter가 10,000,000,000(100억)에 도달하면 시스템이 더 이상 새로운 URL을 생성하지 않도록 제한할 수 있습니다.

• 하지만 이건 주로 모니터링 목적입니다. 실제 URL 생성 로직 자체는 counter 값이 100억을 넘어도 계속 동작할 수 있고, 100억 제한은 시스템 설계상 의도된 한계일 뿐입니다.

   

따라서, 100억 URL 제한: Redis counter로 생성된 URL 수를 모니터링해 한도를 체크할 수 있지만, 생성 로직과 DB 저장에는 직접 영향을 주지 않습니다.

감사합니다. 좋은 질문을 해주셔서 감사드리며

좋은 하루 되세요

안녕하세요, 인프런 AI 인턴입니다. 방구석효행뜽님께서 질문하신 URL 단축 서비스에서의 Redis counter 사용에 대해 설명드리겠습니다.

Redis Counter의 용도

1. Short URL의 생성:

   • Redis counter는 URL 단축 서비스에서 중요한 역할을 하는데, 바로 short URL의 고유한 키 값을 생성하는 데 사용됩니다. Redis의 INCR 또는 INCRBY 명령어를 통해 atomic하게 증가시키는 방식으로 short URL의 유일한 식별자를 생성할 수 있습니다. 이러한 고유 ID는 매우 빠르고, 경합 없이 서로 다른 요청 간에 중복되지 않게 보장됩니다.
     

2. 확장성과 성능:

   • Redis는 메모리 내 데이터 저장소이기 때문에 빠른 읽기/쓰기 속도를 제공할 수 있어 높은 QPS(초당 쿼리 요청 수)를 지원하는 URL 단축 서비스에서 유리합니다.
     
   • Atomic한 실행을 통해 분산 환경에서도 race condition 없이 단일 counter를 안전하게 관리할 수 있습니다. 이는 동시성 문제가 발생할 수 있는 환경에서 매우 중요합니다.
     

3. 기타 기능:

   • Counter를 사용하면 URL 요청 수와 같은 analytics 역할도 함께 처리할 수 있어 유용합니다. 특정 URL이 얼마나 많은 요청을 받았는지 측정하여 사용자 통계나 서비스 분석에 활용할 수 있습니다.
     

Limit 체크 및 DB 저장

• 100억 개의 URL limit 체크: 주어진 요구사항에 맞추어 특정한 갯수를 넘지 않도록 제약을 두기 위함입니다. Counter 값이 100억에 도달할 경우 새로운 URL 생성을 막을 수 있습니다.
  
• DB 저장: Redis에 counter를 저장하여 URL의 고유 식별자를 빠르게 생성하는 반면, 생성된 URL의 메타 정보나 사용자 관련 정보는 시스템의 영속성을 위해 지속성이 보장되는 RDBMS나 NoSQL DB에 저장합니다. Redis는 일반적으로 캐시처럼 사용되어 volatile한 데이터를 저장하며, 시스템 장애 시 휘발될 수 있다는 점에서 중요 데이터 백업을 위해 별도의 DB 저장이 필요합니다.
  

관련된 질문을 통해 더 자세한 설명이 있는 답변을 확인해볼 수 있습니다:
- “URL 생성 시나리오에서 Redis Counter 사용의 이유”

저는 질문자님의 이해를 돕고자 지식공유자님의 기존 답변을 참고하여 유사한 답변 링크를 추천해드리고 있습니다.
현재 베타 기능으로 답변이 만족스럽지 않을 수 있는 점 양해 부탁드립니다. 🙏
추가적으로 궁금한 점이 있으시면, 이어서 질문해 주세요. 곧 지식공유자께서 답변해 주실 것입니다.