YouTube Data APIのクォータ設計：探すほうが書くより高い

クォータは「回数」ではなく「ユニット」で減る

YouTube Data APIには、1日あたり10,000ユニットという上限があります。ここで勘違いしやすいのが、「10,000回叩ける」わけではないという点です。エンドポイントごとに消費ユニットが違い、しかもその差がかなり大きい。

私が実際に使っている3つを並べるとこうなります。

「何に返信するか探す」処理のほうが、「実際に書く」処理よりも高い——これがこのAPIの一番大事な性質だと思っています。書き込みという、いかにも重そうな操作が50。読み取りのはずの検索が100。直感と逆です。

1日5件コメントする設計の実際の消費

私が組んでいるのは、1日5件コメントする構成です。内訳はこうなります。

search.list            100 × 1回 = 100
commentThreads.insert   50 × 5回 = 250
------------------------------------
合計                              350

350ユニットは10,000のうち3.5%です。枠を使い切る心配より先に、検索1回で拾ってきた候補をどう捌くかを考えたほうがいい水準でした。

逆に言うと、検索を増やす設計にした瞬間にコストが跳ねます。キーワードを5本に分けて毎回検索する、というような作りにすると、それだけで500ユニット。投稿5件分の倍です。私は検索を1回に絞り、そこから得た動画IDに対してvideos.list（1ユニット）で詳細を補う形にしています。検索は最小、周辺情報は安いエンドポイントで埋めるという方針です。

チャンネルが増えたら、プロジェクトを分ける

複数チャンネルを回すようになると、10,000という枠を共有するのが気になってきます。ここで効いたのが、Google Cloudプロジェクトを分けるという手です。

クォータはプロジェクト単位で管理されるので、チャンネルごとにプロジェクトを分ければ、クォータも別々になります。私は現在2チャンネルを、それぞれ別プロジェクトで運用しています。片方の処理が暴走しても、もう片方の投稿が止まらない。この隔離が実運用ではありがたいです。

ただし、これは私が「クォータが別々になる」という挙動を実際に確認した、というだけの話です。この分け方が規約上どこまで許容されるのかは、私は確認できていません。そこを保証するつもりはないので、同じことをする方はご自身で確認してください。

分かっていないこと

• なぜsearch.listが投稿の2倍のコストなのか、その理由
• プロジェクト分割が規約上どう扱われるか
• クォータを使い切ったときの挙動（350ユニット運用なので、まだ到達していません）

上限に当たっていないので、上限に当たった話は書けません。逆に言えば、1日5件・350ユニットという設計は、上限を意識せずに済む水準だったということです。

設計の順番

1. 検索を1日何回叩くかを先に決める（ここが100ユニット単位で効く）
2. 投稿件数×50を足して、1日の合計ユニットを出す
3. 足りない情報はvideos.listやchannels.list（1ユニット）で補う
4. チャンネルが増えたら、プロジェクトを分けて枠を独立させる