午前0時3分、監視画面の注文カーブが導火線に火がついたように跳ね上がった。午前0時7分、最初の429が返ってきた――運送会社のラベルAPIがスロットリングを開始した。午前0時12分にはマーケットプレイスの注文取得APIも断続的に拒否し始めた。現場では十数人の梱包作業員が出荷ラベルを待ち、プリンターは不気味な沈黙を保っていた。IT担当者はジョブを再起動しながらグループチャットに「落ち着いて」と打ち込んでいたが、誰の目にも彼がパニック状態なのは明らかだった。その夜は手書きのピッキングシートで2時間を乗り切り、翌日はカスタマーサービスの電話が鳴り止まなかった。
これは出来の悪いソフトウェアの話ではない。ピークシーズンがもたらす当然の結果だ：1日に数万回サードパーティAPIを呼ぶシステムが、一晩でその10倍以上のボリュームに達することがある。サードパーティAPIにはすべてクォータがあり、使い切れば相手は交渉してくれない――ただ「ノー」と言うだけだ。注文が入らなくなり、ラベルが印刷できなくなり、在庫が同期しなくなり、他社のサーバーの前でオペレーション全体が立ち往生する。この記事は理論を飛ばす。ピークシーズン前に実際にやるべきことを書く。
夜に殺されるまで誰も読まないクォータ
第一に、自分が呼ぶサードパーティAPIのクォータをすべて調べて数字を書き出す。運送会社のラベルAPI、マーケットプレイスの注文取得、ERPの在庫同期、SMS通知――それぞれスロットリングの仕方は違う。分単位のものもあれば日単位、口座単位、IP単位のものもある。記憶に頼るな。「1分あたり数百くらいのはず」と思うな。公式ドキュメントを開き、数字をコピーし、単位をメモする。
第二に、計算する。昨年のピークシーズンのスパイク――あるいは年央セールのような小規模なリハーサル――を1.5倍し、真夜中の1時間に何回APIを叩くかをはじき出す。数えるのは注文ではなく呼び出し回数だ：1件の注文が3〜4回のAPI呼び出し（運賃照会、ラベル、追跡プッシュ、在庫更新）を意味することもあり、この倍率は初めて計算する人の大半を驚かせる。結果をクォータの横に置けば、ギャップがこちらを見返す。
第三に、クォータ増枠の申請は早めに。大手プラットフォームも運送会社もピーク前の増枠に対応しているが、手続きとキューがある――2〜3週間前が常識だ。数字だけ送るな、計算根拠を添えろ。申請を審査するエンジニアは「クォータを上げてください」より「ピーク時間帯の呼び出し量、継続時間、エンドポイント別の内訳」にずっとよく反応する。痛い目に遭って学んだことがある：ある年、主力運送会社のクォータを上げてバックアップ経路を忘れた。ピークの夜に主力がぐらつき、トラフィックがフェイルオーバーし、バックアップのクォータが一瞬で吹き飛んだ。あれだけの準備が水の泡だ。実際に叩くすべての口座と経路――バックアップを含めて――をカバーしろ。
リトライは首なし鶏であってはならない
クォータ増枠は万能薬ではない。ピークの夜は必ず想定外が起きる：相手のサーバーがぐらつき、パケットが落ち、エンドポイントが予告なく劣化する。リトライロジックの書き方次第で、うまく切り抜けるか、相手を完全に落とす手伝いをするかが決まる。
愚直な固定間隔リトライは書くな。失敗したリクエストが5秒ごとに再試行するのは、洪水を壁に投げ返しているだけだ――相手が息を吹き返した瞬間、また叩きのめすことになる。指数バックオフを使え：1秒待ち、次は2秒、次は4秒と倍々に伸ばし、ランダムなジッターを少し混ぜる。ジッターを省く人が多いが、省くべきではない：なしでは全クライアントが同じ瞬間にリトライし、同期した新たな洪水が生まれる。ありならリトライが分散する。
バックオフには天井も必要だ：最大リトライ回数と最大総待ち時間、それを超えたら諦めてデグレードする。無限リトライは最も危険なパターンだ。リトライキューが膨らみ続けてアプリケーションサーバーのメモリを食い尽くすのを見たことがある――ベンダーのAPIが回復するより先に自前のシステムが倒れた。リトライ回数とタイムアウトは負荷テストの段階で設定に固定しろ。ピークの夜に設定をいじるのは賭けだ。
そして読み取りと書き込みは別扱いしろ。注文取得のリトライは安い。ラベル印刷や在庫減算のリトライは安くない――だから書き込みをリトライする前に冪等性を確認しろ。同じ注文が2回印刷されたら、運送会社は重複排除してくれるのか、それともラベルが2枚出るのか？2回請求されるのか？穏やかな火曜日には誰もこんな質問をしないが、ピークの夜が代わりに教えてくれる。金銭や現物に触れる書き込み呼び出しにはすべて冪等性キーを付けろ。重複は照合の段階で発見するな。
本当に壊れたら、尊厳をもってデグレードせよ
バックオフとキューは時間を稼ぐ。デグレードは現実を認めることだ：相手のAPIは落ちているが、倉庫は止められない。デグレード計画はピークシーズン前に書いてリハーサルする――午前0時12分に発明するものではない。
主力の手は「今は注文を受け、同期は後回し」だ。マーケットプレイスの注文が取得できない？ローカルにキャッシュした注文で生産し、バックアップ運送会社でラベルを印刷し、APIが回復したらデータを埋め戻す。在庫同期が詰まった？出荷を続け、差異を記録し、後で手で照合する。原則はひとつ：生命線――ドアから出ていく貨物――を守れ。リアルタイムでないものは遅れてよい。
デグレードには段階を設けるべきだ。軽度：重要でない呼び出しを殺す――SMS通知をピーク後のバッチに回し、命綱であるラベル印刷のクォータを空ける。中度：遅くても高くてもバックアップ経路にフェイルオーバーする。重度：手作業へ――白紙ラベルに手書き、スプレッドシート駆動のピック。原始的に聞こえるが、その場にいれば、原始的な計画は死んだ画面を見つめるよりましだ。各段階のトリガーと手順は、印刷した1枚にまとめて当番デスクに貼る。ピークの夜の真夜中に冷静な思考ができる者はいない。
その下にはキューがある。普段サードパーティに直接当てる呼び出しは、ピーク中はすべてまずローカルキューを通し、クォータ以下の一定速度で消費する。キューの深さにアラートの水位線を引く：ラインを超えたら軽度デグレードが自動発動する。これは平時に作るもので、ピークの1週間前ではない――キュー自体の安定性と監視は、実証に時間がかかる。
2週間前になったら、このリストをなぞる
ピーク前チェックリスト、チェック用にどうぞ：すべてのサードパーティのクォータを書き出し済み；ピーク時の呼び出し量を計算済み；増枠申請を提出済み、バックアップ経路も含む；リトライポリシー稼働中――ジッター付き指数バックオフと硬い天井；書き込み呼び出しの冪等性を確認済み；3段階のデグレードを文書化し1回リハーサル済み；平滑化キュー稼働中でアラート水位線を設定済み；当番表とエスカレーションパスを掲示済み。
明日できることがひとつある：システムのサードパーティ連携設定を開き、各APIのクォータ上限を探して表を作る。その1枚の表が、ピークシーズン前夜に眠れるかどうか――この記事の冒頭のような夜をもう一度過ごすかどうか――の分かれ目だ。
英語版からの翻訳。内容に相違がある場合は英語版を優先します。
