배경

2021년 7월 말부터 Backlog API에 대한 레이트 제한이 구현된다.

속도 제한에 대한 블로그 : htps : //바 ckぉg. 코 m / 그럼 / b ぉ g / ba ck ぉ g - 아피 라테 - ぃ 미 t - 안 오 응 센 t /

이 레이트 제한은, API의 종류마다·유저 단위·분 단위로의 제한이 된다.

이 대응을 위해 먼저 Backlog API를 이용하고 있는 각 서비스에서의 API 이용 상황을 파악하고 영향 개소를 조사할 필요가 있다.

방법

「레이트 제한 정보의 취득」API가 준비되어 있다. 이 API를 이용함으로써, 그 시점의 API 이용 상황을 파악할 수 있다.
htps : //로 ゔぇぺぺr. 누 b. 코 m / 그럼 / 두 cs / 바 ck ぉ g / 아피 / 2 / 게 t 라테 ぃ 미 t / #

다만, 얻어지는 정보는 API의 요구를 송신한 시점의 정보뿐이며, 특정 기간내에서의 이용 상황을 파악하기 위해서는, 그 기간중에 정기적으로 이 API를 실행해 정보를 취득할 필요가 있다.

이를 위해 다음과 같은 간단한 모니터링 시스템을 구축했습니다.

감시 시스템

리포지토리

작성한 것은 이하의 리포지토리에 격납.

소스 코드 등은이 리포지토리를 참조

사양・주의사항

조사하고 싶은 Backlog 사용자의 API 키를 사용해, 레이트 제한 정보 취득 API를 정기 실행해 이용 상황을 파악한다

htps : //에서 ゔぇぺぺr. 누 b. 코 m / 그럼 / 두 cs / 바 ck ぉ g / 아피 / 2 / 게 t 라테 ぃ 미 t / #

검색된 정보는 CloudWatch 지표에 사용자 지정 지표로 값을 저장하여 대시보드에서 그래프를 참조할 수 있도록 합니다.

상기 구성도와 같이, 배치 처리는 Lambda + Eventbridge로 구성.

취득 빈도는 약 5초

Lambda는 1분마다 실행된다. 코드 내에서 5 초 넣어 얻을 수 있도록 구현.

값의 정밀도

Lambda의 중복 실행에 대한 명예적인 구현은 하지 않는다.

속도 제한 정보를 취득하는 시간과 메트릭스를 작성하는 시간 동일하게 되도록 구현하고 있지 않기 때문에, ms 단위로의 오차가 있다.

이상과 같이 완전하게 정확한 값이라고는 보증되지 않지만, 이용 상황의 경향이나 대폭적인 요구 증가를 보는 전제로, 이 정밀도로 충분하다고 판단한다.

이 레이트 정보 취득 자체에 read가 사용되기 (위해)때문에, read의 값에는 그 만큼이 올라간 상태로 집계된다

지표 사양

네임스페이스 : BacklogApiRate


지표 이름
설명


Limit
제한 수

Remaining
제한 잔수 (사용 가능한 남은 요청 수)

Usage
이용 수. Limit - Remaining



차원
설명


ApiKey
대상 API 키의 처음 5자

ApiType
대상 API 유형. read = 읽기 , update = 업데이트 , search = 검색 , icon = 아이콘. 상세

대시보드를 별도로 작성

수집한 지표를 대시보드화하여 시각화. 대시보드는 상기 배포 후 별도 작성.

작성 예

요약

단순하지만, 경향을 파악하기에는 충분한 정밀도로 이용 상황을 가시화할 수 있었다. 이것을 바탕으로 영향 개소를 조사해 대응하기로 했다.
다만, 복수의 워크로드에 걸쳐 1개의 유저를 API에 이용되고 있는 일도 있기 때문에, 가능하면 API 키 단위로 레이트 정보를 취득할 수 있으면 기뻤다.