One-Time Password (Redis String)

• One-Time Password 인증을 위해 사용되는 임시 비밀번호(e.g. 6자리 랜덤 숫자)

  

• 임시 코드의 ttl을 입력 (redis의 만료 기능 사용)

Distributed Lock (Redis String)

• 분산 환경의 다수의 프로세스에서 동일한 자원에 접근할 때, 동시성 문제 해결

  

• RDB의 레코드 락을 걸어 안전한게 할 수 있지만, 네임드 락과 같은 어플리케이션 락이 필요

• 네임드락을 분산락으로써 구현 가능

  • 락 이름을 mutex와 같은 형식으로 구현

Rate Limiter (Redis String)

• 시스템 안정성/보안을 위해 요청의 수를 제한하는 기술

  • 시스템의 자원 사용을 제어하고, 과도한 트래픽으로부터 시스템을 보호하기 위해 요청 수를 제한하는 기술
  • 고정된 시간 창(예: 1분, 1시간) 동안 허용되는 최대 요청 수를 정의합니다. 이 시간 창은 일정하게 반복되며, 각 창에서 요청 수가 설정한 한도를 초과하지 않도록 관리합니다.
  • IP-Based, User-Based, Application-Based, etc.

• Fixed-window Rate Limiting 고정된 시간(e.g. 1분) 안에 요청 수를 제한하는 방법

  

• 장점

  • 구현이 간단하고 이해하기 쉬움
  • 고정된 시간 창으로 인해 리소스 사용량을 예측하기 용이함

• 단점

  • 시간 창의 경계에서 요청이 집중될 경우 리소스에 부하가 집중될 수 있음 (예: 시간 창이 리셋되는 순간에 요청이 몰림)
    • 10분 59초에 요청이 몰려서 원하지 않은 부하까지 처리
  • 실제 트래픽 분포가 고르지 않을 경우 일부 시간에 리소스가 낭비될 수 있음

SNS Activity Feed (Redis List)

• Activity Feed 사용자 또는 시스템과 관련된 활동이나 업데이트를 시간순으로 정렬하여 보여주는 기능

  • Redis를 사용하여 Activity Feed를 구현할 때, 주로 Lists, Sorted Sets, Hashes 등의 자료 구조를 활용합니다. 예를 들어, **Sorted Sets**는 활동의 타임스탬프를 점수로 사용하여 활동을 저장하고, 이를 시간순으로 쉽게 검색하고 표시할 수 있게 합니다.

• Fan-Out

  • 단일 데이터를 한 소스에서 여러 목적지로 동시에 전달하는 메시징 패턴
  • Fan-Out은 특정 데이터 또는 이벤트를 소스에서 여러 수신자(목적지)에게 동시에 전송하는 메시징 패턴입니다. 이 패턴은 주로 알림 시스템, 실시간 데이터 피드, 작업 분산 처리 등에 사용됩니다.
    • 예를 들어, 소셜 미디어 플랫폼에서 한 사용자가 게시물을 올리면, 이 게시물은 그 사용자의 모든 팔로워의 피드에 거의 동시에 나타나야 합니다. 이때 Fan-Out 패턴을 사용하면, 게시물을 한 번 저장하고 모든 팔로워의 피드로 효율적으로 전파할 수 있습니다.
  • Fan out 패턴
    • on write
      • 데이터가 쓰여지는(생성되는) 시점에 데이터를 여러 사용자에게 전파합니다.
      • 이 방법은 데이터가 생성될 때 즉시 관련된 모든 사용자의 뷰에 데이터를 분산시키기 때문에, 사용자가 데이터를 요청할 때 추가적인 처리 없이 즉시 데이터를 제공할 수 있습니다.
      • 예를 들어, 소셜 미디어에서 사용자가 새로운 포스트를 작성하면, 이 포스트는 즉시 해당 사용자의 모든 팔로워들의 피드에 추가됩니다. 이는 데이터 쓰기 작업 시에 더 많은 리소스를 사용하지만, 읽기 작업은 빠르고 효율적입니다.
    • on read
      • 사용자가 데이터를 요청할 때(읽을 때) 관련 데이터를 수집하고 전파합니다. 이 방법은 사용자가 실제로 데이터를 요청할 때까지 데이터 전파를 지연시킵니다.
      • 예를 들어, 사용자가 소셜 미디어 피드를 열람할 때, 시스템은 그 순간 사용자의 팔로잉 목록에 있는 사용자들의 최신 포스트를 수집하여 피드에 표시합니다. 이 방식은 쓰기 작업은 빠르지만, 읽기 작업 시에 더 많은 처리가 필요하며, 사용자가 데이터를 요청할 때마다 실시간으로 데이터를 수집하고 처리해야 합니다.
    • On Write는 읽기 작업이 훨씬 더 많이 발생하고, 데이터의 즉각적인 가용성이 중요한 경우에 적합합니다. 하지만, 데이터가 자주 변경되지 않고 대부분의 데이터가 실제로 사용되는 상황에서 효율적입니다.
    • On Read는 쓰기 작업이 읽기 작업보다 많거나, 사용자가 실제로 데이터를 요청할 때까지 데이터의 최신 상태를 유지할 필요가 있을 때 유리합니다. 또한, 데이터가 자주 변경되거나 사용자가 실제로 읽지 않는 데이터가 많을 경우 리소스 낭비를 줄일 수 있습니다.
  • Redis에서는 Pub/Sub 메커니즘을 사용하여 Fan-Out을 구현할 수 있습니다. 게시자(Publisher)가 메시지를 발행하면, 구독자(Subscriber)들이 이 메시지를 받아 처리합니다. 또한, **Lists**나 **Streams**을 사용하여 더 복잡한 Fan-Out 구조를 구현할 수도 있습니다.
  • 이러한 방식으로 Redis를 사용하면, 데이터 처리와 전송을 매우 빠르고 효율적으로 처리할 수 있으며, 대규모 분산 시스템에서의 데이터 흐름 관리를 간소화할 수 있습니다.

  

  • 유저 1이 어떤 포스트를 좋아할 때, 유저 2, 3만이 이 게시글에 관심 가질 것 같은 경우, 이 유저들의 피드에 해당 유저 포스트 라이크 관련 값을 레디스 List에 추가
  • 그 후 유저 2가 자신의 피드를 조회하게 되면, 시간 순으로 정렬하여 보여줌