背景
2021年7月末からBacklog APIに対するレート制限が実装される。
レート制限に関するブログ : https://backlog.com/ja/blog/backlog-api-rate-limit-announcement/
このレート制限は、APIの種類ごと・ユーザー単位・分単位での制限となる。
この対応のために、まずBacklog APIを利用している各サービスでのAPI利用状況を把握し影響箇所を調査する必要がある。
方法
「レート制限情報の取得」APIが用意されている。このAPIを利用することで、その時点のAPI利用状況が把握できる。
https://developer.nulab.com/ja/docs/backlog/api/2/get-rate-limit/#
ただし、得られる情報はAPIのリクエストを送った時点の情報のみであり、特定期間内における利用状況を把握するためには、その期間中に定期的にこのAPIを実行し情報を取得する必要がある。
そのために、以下の簡易な監視システムを構築した。
監視システム
リポジトリ
作成したものは以下のリポジトリに格納。
ソースコード等はこのリポジトリを参照
仕様・注意事項
- 調査したいBacklogユーザーのAPIキーを使い、レート制限情報の取得APIを定期実行して利用状況を把握する
- 取得した情報はCloudWatchメトリクスにカスタムメトリクスとして値を格納し、ダッシュボードでグラフを参照できるようにする。
- 上記構成図の通り、バッチ処理はLambda + Eventbridgeで構成。
- 取得頻度は 約5秒
- Lambdaは1分毎に実行される。コード内で5秒置きに取得するように実装。
- 値の精度
- Lambdaの重複実行に対する冪等な実装はしていない。
- レート制限情報を取得する時間とメトリクスを作成する時間同じになるよう実装していないため、ms単位での誤差がある。
- 以上のように 完全に正確な値であるとは保証されないが、利用状況の傾向や大幅なリクエスト増加を見る前提で、この精度で十分であると判断する。
- このレート情報取得自体にreadが使われるため、readの値にはその分が上乗せされたで状態で集計される
メトリクス仕様
Namespace : BacklogApiRate
メトリクス名 | 説明 |
---|---|
Limit | 制限数 |
Remaining | 制限残数 (残り利用可能なリクエスト数) |
Usage | 利用数。Limit - Remaining |
ディメンション | 説明 |
---|---|
ApiKey | 対象のAPIキーの先頭5文字 |
ApiType | 対象のAPI種別。read = 読み込み , update = 更新 , search = 検索 , icon = アイコン。 詳細 |
ダッシュボードを別途作成
収集したメトリクスをダッシュボード化して可視化。ダッシュボードは上記デプロイ後、別途作成。
まとめ
簡易ではあるが、傾向を把握するのには十分な精度で利用状況を可視化することができた。これを元に影響箇所を調査し対応することとした。
ただし、複数のワークロードにまたがって1つのユーザーをAPIに利用されていることもあるため、できればAPIキー単位でレート情報を取得できれば嬉しかった。