[Chapter 04] Q&A

[janeljs]

[Chapter 04] 처리율 제한 장치의 설계

• 궁금한 점 혹은 이야기하고 싶은 주제 코멘트로 정리
• 추가로 같이 보면 좋을 것 같은 기술 블로그, 아티클 등 공유

[zziri]

지훈

• 클라이언트 측 제한 장치와 서버 측 제한 장치의 차이

  • 결론적으로는 클라이언트 측에는 처리율 제한 장치를 둘 수 없음

• 상용 API GW는 어떤게 있을까??

  • Amazon, GCP, Azure, ...

• 루아스크립트

  • https://redis.io/docs/manual/programmability/eval-intro/ (Redis guarantees the script's atomic execution.)
    • atomic하게 실행되는데, 락과 다른게 뭐지?

• 레디스의 정렬집합

  • https://redis.io/docs/manual/data-types/#sorted-sets
    • Redis Sorted Sets are, similarly to Redis Sets, non repeating collections of Strings.
      • https://redis.io/docs/manual/data-types/#strings
        • Use Strings as atomic counters using commands in the INCR family

• 고정세션은 왜 규모 확장과 유연함에 불리한지??

  • 클라이언트에 대해서 대응되는 처리율 제한 장치가 고정적이라면, 처리율 제한 장치를 늘렸을 때 새로 도입한 장치들에는 할당된 클라이언트가 없고 이것을 해결하기 위해서 스케일이 바뀔때 마다 재할당해야할 것

[travelbeeee]

현석

• 레디스 정렬집합
  • 정렬집합이란 구성원들이 모인 우리가 아는 그 집합 + 구성원들이 정렬에 필요한 값도 가지고 있다.
  • 정렬집합 명령어
  • Redis ZADD 명령어로 이용
• ❓ 레디스 정렬 집합을 이용하면 race condition 문제를 해결할 수 있다. ( sorted set 이 race condition 을 어떻게 해결하는거지...?? )
  • 첫 번째 시도
  • 토큰 버킷 방식
    • 사용자마다 토큰이 포함된 버킷 연결
    • 요청을 보낼 때 버킷의 토큰 수를 확인해서 요청 limit 에 맞춰 처리한다.
    • -> 수백만 명의 사용자가 처리율 제한 장치가 필요한 작업마다 버킷을 생성 & 주기적으로 리필
    • ---> Redis 인스턴스에 지속 불가능한 로드 발생
  • 두 번째 시도
  • 사용자마다 토큰이 포함된 버킷 + 버킷이 다시 채워진 마지막 시간의 타임스탬프 연결
  • 타임스탬프를 이용해 사용자에게 부여되어야 하는 토큰 수를 계산
  • -> (분산환경) 처리율 제한 장치 서버가 여러 대라면 redis 에서 토큰 수와 타임스탬프를 읽고, 리필해야되는 토큰 수를 계산하는 과정에 다른 서버에서 값을 읽어올 수 있다.
  • --> Redis 의 부하를 줄일 수는 있으나 race condition 상황은 해결하지 못한다.
  • ❓ 이 방법은 버킷에 토큰 리필 작업 과정을 최적화한건가??
  • ❓ 부여되어야 하는 토큰 수를 처리율제한장치 서버에서 처리해서 redis 부하를 줄이는건가?? ( 도긴개긴이 아닌가...?? )
  • 세 번째 시도 ( Redis sorted set 이용 )
  • Each user has a sorted set associated with them. The keys and values are identical, and equal to the (microsecond) times when actions were attempted.
    • 각 사용자는 자신과 연결된 정렬된 집합을 가지고 있다.
    • Redis Sorted Set 에는 key - value - member 가 필요하다. key - value 를 모두 동일하게 클라 요청 타입스탬프로 지정
  • When a user attempts to perform an action, we first drop all elements of the set which occured before one interval ago.
    • 사용자가 요청을 보낼 때, 한 간격 전에 발생한 모든 타입 스탬프를 날린다.
  • We fetch all elements of the set.
    • 집합의 모든 요소를 가지고 온다. ( 모든 타임 스탬프를 가지고온다, 바로 전에 날려버린 스탬프 제외하고 )
  • We add the current timestamp to the set.
    • 현재 타임스탬프를 정렬집합에 추가한다.
  • We set a TTL equal to the rate-limiting interval on the set (to save space).
    • Redis TTL : 시간제한이 있는 key의 남은 수명 시간
    • 공간을 절약하기 위해 처리율 제한 장치 interval 과 동일하게 TTL 은 셋팅한다.
  • After all operations are completed, we count the number of fetched elements. If it exceeds the limit, we don’t allow the action.
  • We also can compare the largest fetched element to the current timestamp. If they’re too close, we also don’t allow the action.
  • 책 자료 링크

[meloncha]

민석

이동 윈도 로깅 알고리즘

위의 예시에서 궁금증

• 1:00:50 요청은 무시, 타임스탬프 기록
• 1:01:29 요청은? → 1분 전이 1:00:29 이므로 그 사이에 30, 50이 있어서 무시, 타임스탬프 기록
• 1:01:40 요청은? → 1:00:40 부터 00:50, 01:29 2개 있어서 무시, 타임스탬프 기록
• 이게 뭐야
• 02:28 요청도 무시, 스탬프 기록 -> 이러면 계속 무시되는 걸까요?

주요 사이트의 처리율 제한 응답

• 모든 사이트가 HTTP 429 too many requests 를 보내는 것은 아니다. API 확인 필요
• HTTP 헤더의 경우에도 사이트마다 조금씩 다르다
• 이 책에 나온 내용은 RFC 표준이다. RateLimit Header Fields for HTTP

경쟁 조건 문제를 해결하는 해결책

루아 스크립트

• Redis 서버에 내장된 Lua 인터프리터에서 EVAL 명령어를 이용하여 임의의 명령어를 조합한 처리를 수행하는 기능
• 스크립트 자체가 하나의 큰 명령어로 해석되기 때문에 스크립트가 atomic하게 처리된다 -> race condition 문제 해결
• 참고 문헌) https://engineering.linecorp.com/ko/blog/atomic-cache-stampede-redis-lua-script/

Redis sorted set

• Better Rate Limiting With Redis Sorted Set

Redis 는 싱글스레드라서 atomic 한데 왜 race condition 문제가 생기는가?

• 명령어 하나하나는 atomic 하지만 위의 예시처럼 read_counter 와 check_and_increment 를 따로 실행하여 그 사이에 다른 프로세스가 끼어들 수 있어서 경쟁 조건 문제가 발생한다
• read 와 check, increment 명령을 하나의 스크립트로 합치는 것이 Lua Script가 제공하는 기능

분산형 인메모리 비율 제한기 : 클라이언트에 처리율 제한 적용

• https://engineering.linecorp.com/ko/blog/high-throughput-distributed-rate-limiter/

[KKambi]

한비

DoS 공격

Denial of Service

• 시스템을 악의적으로 공격해 리소스를 부족하게 만들어 서비스 중단
• DDoS (Distributed Denial of Service) - 다수의 공격자를 분산 배치하여 동시에 공격 (일반 사용자의 PC를 감염시킨 좀비PC)
• 대안 - 처리할 수 있는 만큼으로 트래픽 제한 및 합법적 트래픽 수용

API 게이트웨이의 역할 중 SSL 종단

SSL Termination = SSL Offloading

• 클라이언트와 서버의 중간에서 요청을 암호화/복호화하는 일
• 클라이언트 ~ API 게이트웨이는 HTTPS 통신, 게이트웨이 ~ 서버는 HTTP 통신을 하게 된다.
• ssl certificate를 확인하는 부하를 서버가 아닌 게이트웨이에 넘길 수 있다.

분산 환경에서의 락

Lua script 또는 Redis sorted set을 사용하라고 나와있는데, Reddison을 이용하면 쉽게 사용 가능

• Lettuce와 같은 Java Redis Client
• 트랜잭션 + Lua 스크립트로 atomic 연산 구현
• 스핀 락이 아닌 pub/sub을 통한 락

트랜잭션으로 하나의 atomic 연산을 만들고, 트랜잭션 결과를 다른 트랜잭션에서 활용할 수 있도록 Lua 스크립트를 이용 간단하게 설명해놓은 하이퍼커넥트 글

최종 일관성 (Eventual Consistency)

분산 컴퓨팅에서 사용되는 일관성 모델로, 데이터에 대한 변경이 없다면 결과적으로 모두 마지막 반영된 값을 조회하게 된다는 것

• 낙관적 복제
• 단기적으로는 일관성을 잃더라도 결국에는 유지한다
• 분산 시스템에서 데이터 변경사항을 전파하는데 시간이 걸리기 때문
• ex) 과거의 AWS S3는 PUT 작업 이후, 모든 GET / LIST 요청에서 시간 지연이 있었다고 함

[kihyun-yang]

기현

레디스(nbase-arc) 실제 사용 경험

• api 호출 빈도 조절
  • 특정 시점을 기준으로 이후 데이터를 조회하는 증분 API
    • 특정 시점에 해당하는 데이터는 요청 파라미터로 받음
  • 해당 API의 호출 빈도를 최소화 시키기 위해 데이터가 추가/업데이트 될때마다 마지막 업데이트 일시를 레디스에 저장
  • 추후, 해당 API를 호출하기 이전에 레디스에 저장된 값을 먼저 보고 API를 호출할지 말지를 결정하는데 사용
    • redis를 이용해 빠른 데이터 접근이 가능
  • 결국, 이번 주제였던 처리율 제한 컨셉과 비슷한 것 같아서 정리.
• auto-increment sequence 생성
  • MongoDB는 RDB처럼 auto-increment 기능을 기본적으로 제공하지는 않지만 별도의 카운터 컬렉션을 구현하여 유사한 결과를 얻을 수 있다.
    • https://www.mongodb.com/basics/mongodb-auto-increment
    • https://bigexecution.tistory.com/2
  • mongodb에서 모든 샤드에 유일한 sequence를 보장할 수 있는지? 원자성 보장 가능한지?
  • redis를 이용하면 atomic한 auto increment sequence 생성하고 빠르게 조회 가능
    • https://github.com/spring-projects/spring-data-redis/blob/main/src/main/java/org/springframework/data/redis/support/atomic/RedisAtomicLong.java#L282
    • https://redis.io/commands/incr/#pattern-counter
    • https://keichee.tistory.com/249

고가용성을(HA) 위한 레디스 구성 방법

• 센티널
  • 센티널이라는 별도의 노드가 마스터와 복제 노드를 계속 모니터링
  • 정상적인 기능을 위해서는 적어도 세 개의 센티널 노드가 필요
  • 장애 상황에는 복제 노드를 마스터로 승격시키기 위해 자동 페일오버를 진행
  • 세 대 이상의 sentinel 노드 중 과반수 이상(quorum)이 동의해야만 페일오버를 시작
  • 센티널 노드 과반 수 이상이 master 장애를 감지하면 slave 중 하나를 master로 승격시키고 기존의 master는 slave로 강등시킨다
  • 센티널은 one master 구조이기 때문에 데이터 사이즈가 커지면 스케일 업해야 함
• 클러스터
  • 센티널보다 더 발전된 형태
  • Multi-master, Multi-slave 구조
  • 다수의 마스터 존재 가능, 1000대의 노드까지 확장 가능
    • 확장성이 중요하다면 클러스터를 사용하는 것이 scale out 용이
  • 클러스터에서 모든 노드는 서로서로 연결된 Full Mesh 구조
  • 샤딩기능 제공
• 참고
  • https://meetup.toast.com/posts/226
  • https://velog.io/@always/Redis-%EC%9A%B4%EC%98%81-%EB%B0%A9%EC%8B%9D-Cluster-vs-Sentinel-%EC%96%B4%EB%96%A4-%EA%B2%83%EC%9D%84-%EC%84%A0%ED%83%9D%ED%95%B4%EC%95%BC-%ED%95%A0%EA%B9%8C

[janeljs]

• api gateway = 외부 서비스가 사내 API 쓸 수 있도록 단일 도메인 제공한 뒤, 요청들을 사내 API 서버로 전달하는 것
• 처리율 제한 규칙을 디스크에 보관한다는 것의 의미? 여기서 작업 프로세스는 어느 프로세스?
  • conf 말하는 듯, rate_limit 설정
• 메시지 큐에 보관된 요청은 다시 처리율 제한 미들웨어를 거치게 되는가?
• 루아스크립트나 정렬 집합을 쓰면 어떻게 race condition을 해결하는지?
• sticky session을 사용하면 확장에 불리한 이유?
  • 결국 특정 서버에 트래픽이 집중될 수 있음, 확장 의미 유실
• nginx rate limit이랑은 다른거?
  • https://www.nginxplus.co.kr/?page_id=4332
• soft한 처리율 제한 구현 예시
  • https://docs.sensedia.com/en/api-platform-guide/4.6.x.x/interceptors/traffic_rate-limit.html
• open feign에서 retryer, client의 커넥션 풀 설정해주는 거랑 관련이 있을까? 이런건 어떤 기준으로 설정해야 할까?
  • https://github.com/OpenFeign/feign