Alchemyの利用状況:透明性とわかりやすさの向上

背景

Alchemyの料金体系は「コンピュートユニット」という概念に基づいています。これは、お使いのアプリがAlchemy上で使用する計算リソースの総量を示す指標です。AWSの利用料金をAmazonに支払う場合と同様のイメージです。クエリの中には軽量で高速に実行できるもの(例: eth_blockNumber)もあれば、より負荷の高いもの(例: 大規模なeth_getLogsクエリ)もあります。クエリ数ではなく使用されたコンピュート量のみを課金対象とすることで、可能な限り低コストにすることを目指しています。

課題

すべてのリクエストでコンピュートを計測すると、コンピュートユニット(ひいては月間使用量)の予測が難しくなる場合があります。一部のメソッド(例: eth_call)は負荷の変動が非常に大きく、消費するコンピュートユニット数が最大100倍も変わることがあります。これにより、使用量の最適化や月次コストの予測が、本来あるべき以上にわかりにくいものになっていました。

私たちは、すべてのお客様にとってAlchemyの使用量の計測と予測をシンプルでわかりやすいものにしたいと考えています。そのため、そして可能な限り開発者にとって使いやすいプラットフォームを実現するために、コンピュートユニットの計測方法を見直すことにしました。

コンピュートユニットのアップデート

新しいコンピュートユニットモデルでは、各メソッドに対して、その平均的な負荷から導き出された固定のコンピュートユニット数が割り当てられます。つまり、あるコールを実行する前に、それが消費するコンピュートユニット数を正確に把握できるようになり、予測可能性と透明性が大幅に向上します。

このアップデートによって開発者体験がどのように改善されるか、10,000件のtraceリクエストを行うユーザーを例に考えてみましょう。

従来のコンピュートユニットでは、ユーザーは10,000件のtrace_callリクエストを実行しても、完了するまでどれだけのコンピュートユニットが使用されたかわかりませんでした。対象のブロック、コントラクト、コール実行のタイミングによっては、合計で750,000コンピュートユニットになることもあれば、1,000,000コンピュートユニットになることもあります。しかも、次回同じく10,000件のtrace_callリクエストを実行した際に、結果が同じになるとは限りませんでした。

新しいコンピュートユニットモデルでは、1コールあたり75 CUとして10,000件のtrace_callリクエストを実行した場合、常に合計10,000 * 75 = 750,000 CUが消費されます。

推測や変動の余地がない、公平かつ決定論的な使用量の計測方法です。

メソッドごとのCU割り当ての全リストは、長年のベンチマーク使用実績をもとに定められたものです。こちらのドキュメントをご覧ください。

より優れたレート制限

現在、主なレート制限としてQPS(1秒あたりのクエリ数)という概念を使用しています。これはAPIのレート制限としては一般的な方法ですが、比較的大まかな尺度です。そのため、必要以上に厳格なレート制限を設けざるを得ない場合が多々ありました。

コンピュートユニットの定義を更新したことで、QPSをより望ましい尺度であるCUPS(1秒あたりのコンピュートユニット数)に置き換えることが可能になりました。

CUPSによるレート制限は、実質的にQPSを重み付けしたものであり、各メソッドの負荷の大きさを重みとして使用します。この方式は、リクエストの変動性や呼び出されるメソッドの種類を考慮するため、より正確な指標となります。これにより、すべてのお客様に対して、多くの場合これまでより寛容な制限を設けつつ、さらに信頼性の高いサービス全体を提供できるようになります。

まとめ

全体として、この変更はお客様にとって大きな改善になると考えています。私たちは常にお客様からのフィードバックを重視しており、開発者体験を可能な限り良いものにすることで、共に最高のプロダクトづくりに専念できる環境を目指しています。

ご質問や確認したい点がございましたら、お気軽にお問い合わせください。