4장

• 처리율 제한 장치란?

  • 클라이언트 또는 서비스가 보내는 트래픽의 처리율(rate)을 제어하기 위한 장치.

  • 예시

    • 사용자는 초당 2회 이상 새 글을 올릴 수 없다.

    • 같은 IP 주소로는 하루에 10개 이상의 계정을 생성할 수 없다.

    • 같은 디바이스로는 주당 5회 이상 리워드(reward)를 요청할 수 없다.

  • 처리율 제한 장치가 필요한 이유

    • Dos 공격에 의한 자원 고갈 방지

    • 비용 절감

    • 서버 과부하 방지

  • 어디에 구현할 것인가?

    • 서버 측 구현

      • 현재 프로그래밍 언어가 충분히 효율이 좋은가?

      • 알고리즘을 자유롭게 선택할 수 있다.

    • 게이트웨이

      • 마이크로서비스에 기반하고 있고 API 게이트웨이를 설계에 포함시킨 경우

      • 상용 API 게이트웨이를 쓰는 것도 바람직함

  • 알고리즘

    • 토큰 버킷

      • 설명

        • 폭넓게 이용된다 (아마존, 스트라이프)

        • 지정된 용량을 가진 버킷에 토큰을 채우고, 토큰이 다 차면 더 이상의 토큰을 추가하지 않는다.

        • 각 요청이 처리될 때마다 하나의 토큰을 사용한다. 충분한 토큰이 없는 경우 요청을 버린다.

      • 장점

        • 구현이 쉽다

        • 메모리 사용 측면에서 효율적

        • 짧은 시간에 집중되는 트래픽도 처리 가능

      • 단점

        • 버킷 크기와 토큰 공급률을 적절하게 튜닝하는 것이 까다로움

    • 누출 버킷

      • FIFO 큐 - 요청이 올때마다 처리하고 고정 속도로 처리한다.

      • 쇼피파이에서 사용중

      • 장점

        • 메모리 사용량 측면에서 효율적

        • 안정적 출력이 필요한 경우 적합

      • 단점

        • 트래픽이 몰리는 경우 큐에 요청이 쌓이고 최신 요청이 버려지게 된다

        • 인자 튜닝이 까다로울 수 있다.

    • 고정 윈도 카운터

    • 이동 윈도 로그

    • 이동 윈도 카운터

  • 개략적인 아키텍처

    • 카운터를 두고, 카운터의 값이 한도를 넘어가면 요청을 거부한다.

    • 카운터 - redis같은 캐시 메모리가 적당하다

  • 상세 설계

    • 처리율 제한 규칙은 어떻게 만들어지고 어디에 저장되는가?

    • 처리가 제한된 요청들은 어떻게 처리되는가?

    • 처리율 제한 규칙은 디스크에 보관한다 - 수시로 디스크에서 읽어 캐시에 저장한다

    • 처리율 제한 미들웨어가 제한 규칙을 캐시에서 가져오고, 레디스에서 타임스탬프를 가져온다.

      • API 서버로 보내거나, 처리율 제한에 걸렸다면 에러를 보낸다.

  분산 환경에서는 조금 더 어려워진다. 두 가지 문제를 풀어야 한다.

  • 경쟁 조건

  • 동기화

경쟁 조건 이슈

• 해결책 1. 락을 건다 - 성능이 떨어진다

• 해결책 2. 루아 스크립트

• 새결책 3. 정렬 집합 (레디스 자료 구조)

동기화 이슈

• 처리율 제한 장치가 여러 대 있을 때, 클라이언트가 원래 보내던 장치가 아닌 다른 장치로 보낼 수 있다.

• 해결책 1. 고정 세션(sticky session)을 사용한다 → 하지만 확장가능하지도 않고 유연하지 않다.

• 해결책 2. 중앙 집중형 저장소(redis)를 쓴다.

성능 최적화

• 사용자의 트래픽을 가장 가까운 에지 서버로 전달하여 지연시간을 줄인다

• 데이터를 동기화할 때 최종 일관성 모델을 사용한다.

다음과 같은 부분을 언급하는 게 도움이 될 수 있음

클라이언트 설계

• 클라이언트 측 캐시를 사용하여 API 호출 횟수를 줄인다.

• 재시도 로직을 구현할 때는 충분한 백오프 시간을 둔다.