呼び出し上限で止まった日にすること — 待つ前に、何が数えられているかを読む
データ連携が後から止まる理由では、起きるのは 3 つだと見ました。ここでは、その 1 つ目、呼び出し回数の壁に当たった日の手当てです。
連携が「上限に達した」で止まると、まず待つことを考えます。待つ前に読むものがあります。
まず、何が数えられているかを読む
調査記録で数字が読めた行を並べると、単位が揃っていません。
| 数える時間の幅 | 調査記録にある例 |
|---|---|
| 5 分あたり | 5 分で 300 回（Chatwork）Chatwork レート制限 |
| 1 時間あたり | 1 時間で 5,000 回（BASE）BASE レート制限 ／1 時間で 300 回・3,600 回・無制限とプランで分かれる（マネーフォワード クラウド経費）マネーフォワード クラウド経費 レート制限 |
| 1 日あたり | 1 日 10 万回（BASE）BASE レート制限 ／1 アプリごと・1 日でコースにより 1 万回と 10 万回（kintone） |
| 1 分・1 秒あたり | 1 分あたりの上限が API の種類で変わる（Slack）Slack レート制限 ／接続あたり平均で毎秒 3 回（Notion）Notion レート制限 |
数える主体も違います。 会社ごとに毎時 3,000 回という形（kaonavi）カオナビ レート制限 、接続ごとに数える形、プランで上限が変わる形があります。同じ「1 日 1 万回」でも、会社全体なのか接続ごとなのかで、打てる手が変わります。
すぐやること 3 つ
| 順 | やること | なぜ |
|---|---|---|
| 1 | 止まった時刻と、直前に何回呼んだかを記録する | 単位が分からないときは、これが後で唯一の手がかりになる |
| 2 | 相手の資料で上限の単位を探す | 数字が無い場合も多い。無いと分かることも結論 |
| 3 | 再実行する前に、間隔を空ける設定を入れる | すぐ叩き直すと、次の枠も使い切ります |
3 番目を飛ばすと、同じ日に何度も止まります。 失敗したら少し待って再実行する形にしておくと、上限に達しても自然に収まります。
単位が分かってから選ぶ
| 分かったこと | 打てる手 |
|---|---|
| 時間の幅が短い（5 分・1 分・1 秒） | 呼び出しを時間で散らす。まとめて 1 回にできないか見る |
| 1 日の枠 | 動かす時刻をずらす。夜にまとめる |
| プランで変わる | 上位プランで解けるか、金額と比べる |
| 接続ごと | 処理を分ける。1 つの接続に集めない |
| 公開されていない | こちらで記録を残し、止まった点から推定する |
プランで変わる型は、設計を直さずに解ける場合があります。 調査記録には、1 時間 300 回が上位プランで 3,600 回になる例や、日あたりの枠がプランで 10 倍になる例があります。設計を作り直す前に、料金表を見てください。
こう決める — 繰り返さないために
| 順 | 手順 | こう判定する |
|---|---|---|
| 1 | 止まった相手の上限の単位を確かめる | 数字が読めない相手は「公開されていない」と記録する |
| 2 | いまの呼び出し方が、その単位に対して何回になるかを数える | 数えられない作りなら、まず呼び出しの記録を残す |
| 3 | まとめて呼べる部分を探す | 1 件ずつ呼んでいる処理が、一覧で 1 回になることがある |
| 4 | 失敗したら待って再実行する形にする | 手で再実行する運用は、上限に達する日に人が張り付く |
| 5 | それでも足りなければ、プランと設計を比べる | 上位プランの差額と、作り直す手間を並べて決める |
上限に達すること自体は異常ではありません。 相手のシステムを守る仕組みなので、当たったら設計を合わせるのが筋です。止まったのが自分だけかを見分ける手順は 止まったのは自分だけか、失敗したときの設計は 失敗したときどうするか に置きました。