ダッシュボードを離れずにスループット容量を増やす

ローンチ、ミント、インデックスのバックフィルは、1分足らずでアプリのスループット容量を超過させることがあります。朗報は、有料プランでは容量の引き上げをチームが自分たちで行えるようになったことです。私たちに連絡する必要はありません。ダッシュボードのUsageページを開き、必要な追加容量を選んで確定してください。新しいベースは数秒以内に適用されます。

アドオンはダッシュボードからいつでもキャンセルできます。追加された容量は現在の請求期間中は有効なままで、その後チームは元のベーススループット容量に戻ります。

スループット容量とは何か

スループットとは、リクエストを送信できる速度のことで、1秒あたりのコンピュートユニット数(CU/s)で計測されます。私たちが計測するのはリクエストの生の件数ではなくリクエストの総コストです。これは各RPCメソッドが、処理にかかる作業量に応じてそれぞれ異なるコンピュートユニットコストを持っているためです。

容量要件のサイズ計算は、単にコストを足し合わせるより少し手間がかかります。コスト表にはCU列と、それとは別のThroughput CU列があり、メソッドによっては両者の値が異なります。そのため、月間使用量に対しては安く済む呼び出しでも、スループットに対しては高くつくことがあります。容量のサイズを決める際はThroughput CU列を基準にしてください。

• 容量はアカウント単位で割り当てられ、アプリ単位ではありません。 スループットはかつてアプリごとに設定されていましたが、現在はアカウント全体で構成されるため、チームの全アプリの合計使用量が1つの数値としてカウントされます。2つ目のアプリを立ち上げても余裕は増えません。
• 10秒のローリングウィンドウで計測します。 スループットのドキュメントでは、10秒間で評価されるトークンバケット方式について説明しており、10,000 CU/sの上限であれば、任意の10秒間で100,000コンピュートユニットが使えることになります。短いバーストは通過しますが、その線を超え続けるトラフィックはエッジレイヤーからHTTP 429(too many requests)として返されます。

数値そのものより、このウィンドウの方が重要です。あるワークロードは平均としては上限内に余裕で収まっていても、ピーク時にはスロットリングされることがあります。だからこそ429を受け取ったチームは大抵驚くことになります。

スループットのアップグレードはどう機能するか

ダッシュボードのUsageページを開き、スループットのセクションを見つけて_Upgrade limit_を選択してください。このコントロールを見るには、チームの請求管理者である必要があります。容量のドロップダウンには各増分とその月額料金が並んで表示されるため、コミットする前にコストを確認できます。同じページには、直近のチーム使用量が現在のスループット容量を超えた場合にバナーが表示され、クリックするとアップグレードフローに進みます。

確定後に起きること:

• アップグレードは即座に適用され、月次で更新されます。 新しい容量は確定から数秒以内に反映されます。
• ダウングレードは請求サイクルの終了時に適用されます。 キャンセルした場合、追加容量はそれまで有効なままなので、長引くバックフィルが突然打ち切られることはありません。
• セルフサーブの増分が残っていない場合、ダッシュボードは営業への問い合わせを案内します。 私たちのチームは、ダッシュボードがセルフサーブとして提供する以上のスループット上限を設定できます。

どこまで引き上げられるかはプランによって異なります:

Pay-as-you-goのチームは10,000 CU/sから始まり、Enterpriseの契約も発注書も必要なく自力で30,000 CU/sまで到達できます。Enterpriseの初期容量は契約ごとに設定されるため、ベースラインはアカウントによって異なります。アップグレードモーダルにはチームの正確な最大値が表示され、フルの増分バケットが下に収まる限り、固定の増分で上限に向かって引き上げていくことができます。

つまり、プランのセルフサーブ最大アップグレード容量に達するまでは、私たちを介さずチームだけで1分足らずで決められる範囲です。ただし決定を下す人が請求管理者である必要があります。

実際にどれだけのスループットが必要か

Usageページのピークスループットのカードとチャートから始めてください。平均ではありません。平均はスパイクをならしてしまい、次のローンチで失敗しかねない上限を選ばせてしまいます。

そのピークは読み取り値というよりも下限値として扱ってください。上限は10秒単位で適用されますが、チャートは1分間の平均値をプロットするため、実際に429を引き起こしたバーストはその前後の1分間の中でならされ、実際より低く表示されます。そのスパイクがリクエストの喪失につながったのか、それとも際どいだけで済んだのかを知るには、Request Logsを429レスポンスでフィルタしてください。

この2つのウィンドウの差こそが、ピークに合わせるのではなくピークを上回る余裕を買うべき理由の大半です。一度12,000 CU/sでピークに達したトラフィックは、いずれさらに高いピークを迎えます。そして余裕を持たせる方がインシデントより安上がりです。

リトライと追加のスループットは別の問題を解決するものなので、自分がどちらの問題を抱えているかを把握しておくと役立ちます:

• リトライが向いているのは429のごく一部と、余分なレイテンシを許容できるワークフローです。まさにこのケース向けに、私たちのドキュメントでRetry-Afterヘッダーと指数バックオフについて解説しています。
• レイテンシに敏感な経路には、追加のスループットが答えであり、一時的に上限を超えるのではなく持続的に上限を上回るトラフィックにも同様です。単純に今より多くの容量を必要とするワークロードは、どんなバックオフ戦略でも解決しません。

アップグレードの大半を引き起こすワークロードは3種類あります。アプリがユーザーを獲得するにつれて生じる持続的な成長、エンドポイントが許す限りの速度で履歴を取り込むインデックスのバックフィル、そしてエアドロップ、トークンローンチ、ミントのようなスケジュールされたイベントです。1つ目は恒常的で、残り2つは一時的です。そのため、このフローは購入と同じくらいきれいにキャンセルもサポートしています。

どういうときに私たちに連絡すべきか

セルフサーブは一般的なケースをカバーしますが、すべてのケースをカバーするわけではありません。次のような場合はご連絡ください:

• プランのセルフサーブ最大値を超えており、なお成長を続けている場合。
• 月次のアドオンとしてではなく、契約にスループットを組み込みたい場合。
• ワークロード内の特定のチェーン、アプリ、またはメソッドだけが他よりはるかに大きくスパイクしており、チーム全体の容量よりもカスタムのスループットの方が適している場合。

これらはボリュームと構造に関する話し合いであり、私たちの専門チームがサポートできます。スパイクを乗り切るために5,000 CU/sの余裕を買うといった小さな決定は、ダッシュボード内で自分たちのタイミングで行えるようになっています。

数秒でスループットを増やす

今すぐAlchemyダッシュボードから容量を引き上げてください。必要なのはドロップダウンの操作だけで、契約変更なしに即座に適用されます。まだ有料プランをご利用でない場合、RPC APIは無料で始められ、Pay-as-you-go料金には最低利用料もありません。そのため、最初に課金が発生する日からアップグレードの道は開かれています。

トラフィックが実際にどこへ向かっているかを確認するには、Alchemy Monitorがリクエスト量、エラー、レイテンシを一箇所にまとめて表示します。同じ使用状況データをAlchemy CLIから取得することもできます。

セルフサーブの範囲を超えてスケールする場合は、ボリューム料金について営業チームに相談してください。実際に見込まれるトラフィックに合わせて、必要な容量を算出します。