APIに利用制限をかけるとしたらどういうやりかたがあるのか - おもしろwebサービス開発日記

この記事はSmartHR Advent Calendar 2020 11日目の記事です。 僕のお手伝いしているSmartHRでは、毎週バックエンドエンジニアが集まり、技術的なトピックについて共有、相談しあうミーティングを開催しています。そのミーティングでは僕がTipsなどを共有するコーナーが常設されています*1。 このエントリでは、そのコーナーで共有した内容をひとつ紹介します。 APIに制限をかける方法について APIを外部に提供するとき、一定の制限をかけてユーザがAPIを乱用するのを防ぐことはよくあることではないでしょうか。素直に考えると「1時間に5000回までAPIを実行できる」のようなやり方を思いつきますね。GitHubのAPIもそのやり方ですし、SmartHRのAPIも同様です。 じゃあそれでいいのでは。となるかもしれませんが少し待ってください。いろんなクライアントがAPIを大量に

[tkawa]

Retry-After ヘッダをつけるとよりよい

[sugimomoto]

あんまりこういうアプローチのAPIリミット見たことなかったなー。面白い。一つ気になるのは使う側がそれをちゃんと理解してマネージしてくれるか、かな。わかりづらさはUXの低下にも繋がる。

[harumomo2006]

AmazonAPIも似たような制限で10回までは使えるけどそれ以降制限がかかって4秒ごとに1回権利が回復するただし1時間に100回までみたいなタイプ。なお使えるかどうかは実際にコールして使えるか確認しろとのこと

[Ikalga]

「ソシャゲのスタミナ制」って説明でよくない？

[kitokitoki]

利用制限方法

[iga_k]

Leaky Bucketアルゴリズム

[omron]

なるほど、スタミナモデルと

[toritori0318]

きちんとやろうとすると意外と大変

[sho]

確かにソシャゲのスタミナと同じだと思った(そして合理的なルールである)。

[h_taiji]

GCRA覚えておける自信がない

[bopperjp]

レートリミットの方法

[hamamuratakuo]

Leaky Bucketアルゴリズム「穴の空いているバケツに水を入れる」　バケツから水があふれる！というときはAPIを利用できません　同等のアルゴリズムで「一定時間ごとに減少させる」を不要にしたのがGCRA(Generic Cell Rate Algorithm)

[tobigitsune]

API１回起動にT分使用する。ただしそのT分は未来のτ分先まで前借りすることができる。って感じね

[taruhachi]

面白い実装だな。ただ、利用クライアントからすると単純な利用回数制限だとリトライが次の利用回数制限に直結して扱いにくいので、ペナルティとしてレイテンシーを少しづつあげるとそこが調速して嬉しいかも。

[sudow]

AWSのAPI Gatewayのレートリミットも穴あきバケツ方式なのでよかったらどうぞ

[swdrsker]

クライアント全体を走査する方式じゃなくてイベントドリブンな方式にするということか

[korosuke613]

アルゴリズム考えた人頭良いと思った

[asayamakk]

自分だったら自前実装せずに、Cloud Endpoints使っちゃうかなあ。アルゴリズム学んでぴったり使える場面でコード書くのも楽しそうだけど！

[castaneai]

“GCRAは計算不要で自動的に増える値である「現在時間」を使って、時間を計算することでAPIの利用可否を判断します。”