【ITニュース解説】Twice the workers, 14% faster, three broken calls: what a 110-call map taught me about API latency

ある開発者が「トークンの保有者は韓国とアメリカのどちらに多いのか」という質問に答えるため、「Holder Atlas」というアプリケーションを開発した。このアプリケーションは、特定のトークンの主要保有者がどの国の取引所を利用しているかを世界地図上に表示するものだ。しかし、この地図の描画には約40秒もの時間がかかっていた。数学的な計算が難しいわけではなく、約110回ものAPI呼び出しが必要で、それぞれの呼び出しに平均約2秒かかっていたためである。

Holder Atlasは、Nansenというブロックチェーンデータ提供サービスのAPIを複数利用している。具体的には、トークンのコントラクト情報を取得するAPI、上位100名の保有者情報を取得するAPI、そして最もコストがかかる各ウォレットの取引履歴とトークン転送履歴を調べるAPIなどだ。合計で52のウォレットを調査するために、約107回のAPI呼び出しが必要となり、そのほとんどが1.7～2.0秒の処理時間を要した。これらを順番に処理すると3分半以上かかってしまうが、アプリケーションのデフォルト設定である4つの同時実行スレッド（4-wide pool）と1秒あたり5リクエスト（5 rps）の制限により、約40秒で完了していた。しかし、地図がゆっくりと埋まっていく40秒は、利用者にとっては長く感じられる時間だった。

そこで開発者は、この遅延を改善するため、API呼び出しの同時実行数を4から8に、1秒あたりのリクエスト制限を5から10に引き上げる実験を行った。これは、「同時実行数を増やせば処理時間は半分になるだろう」という仮説に基づいていた。同じベンチマークスクリプトと4つのトークンを使って、変更前と変更後のパフォーマンスを比較した。

実験結果は開発者の予想とは異なっていた。処理時間の半分にあたるp50（半数のリクエストが完了するまでの時間）は40.3秒から34.5秒へと約14%改善したものの、p95（95%のリクエストが完了するまでの時間）は59.0秒から58.1秒とほとんど変化がなかった。さらに、同時実行数を増やした設定では、合計441回のAPI呼び出しのうち3回が失敗するという問題が発生した。デフォルト設定では一度も失敗はなかったため、これは看過できない結果だった。このため、開発者は結局、同時実行数を4スレッドに戻すことにした。

この実験結果から、開発者は自身の思い込みが間違っていたことに気づいた。処理時間が「N回の呼び出しをW個のワーカーで処理すればN/W倍の速度になる」という単純なものではないと理解したのだ。個々のAPI呼び出しに平均2秒もかかるような場合、特に処理が遅いAPI呼び出しがいくつか存在すると、全体の処理時間はその遅い呼び出しに引きずられてしまう。これを「ロングポール」と呼ぶことがある。同時実行数を増やしても、遅いAPIの処理時間自体は変わらないため、全体の最も遅い部分（p95）は改善しなかったのである。同時実行数を増やすと、APIを提供するサーバー側にも負荷がかかり、それが原因でエラーが発生したり、逆にパフォーマンスが低下したりすることもある。今回の失敗した呼び出しは、8秒のタイムアウトと1回の再試行を経ても応答がなかったため、それぞれの失敗が最大17秒もの間ワーカーを占有し、全体の処理時間をさらに悪化させた可能性もあった。

この経験から、開発者はAPIのレイテンシの問題は、アプリケーション側の同時実行数を増やすだけでは解決できないことが多いと結論付けた。真の解決策は、APIを提供する側が処理時間を短縮するか、複数のリクエストをまとめて処理できるようなバッチAPIを提供することにある。例えば、複数のトランザクションハッシュを一度に渡して、複数の転送情報をまとめて返すようなバッチエンドポイントがあれば、大きく改善されるだろうと考えた。

しかし、この実験には副次的な良い成果もあった。Nansen APIの利用制限は「1分あたり300リクエスト」である。以前のクライアントは「1秒あたり5リクエスト」という制限しか考慮していなかったため、短時間に複数のユーザーがアクセスすると、意図せず1分あたりの制限を超過してしまう可能性があった。今回の実験を機に、開発者は「1秒あたりの制限」と「1分あたりの制限」の二つのスライディングウィンドウを監視するレートリミッターを導入した。これにより、API利用がNansenの制限を確実に守れるようになり、安定性が向上した。スライディングウィンドウとは、過去1秒間や過去1分間といった動的な時間の範囲内で、API呼び出し回数を計測し、制限を超えないように制御する仕組みだ。

また、ベンチマークテスト中に、データ解釈の誤りも発見された。Nansenのデータでは、取引所エンティティを示すために「🏦」の絵文字が使われているが、これが必ずしも中央集権型取引所（CEX）を意味するわけではないことが判明した。分散型取引所（DEX）のプールやステーキングコントラクト、ブリッジなどもこの絵文字で示されることがあったのだ。たとえば、「Uniswap: V3 Liquidity Pool」のようなものも「🏦」マークが付いていた。このため、当初はこれらの情報を「どこの国かわからない取引所」として扱っていたが、実際には取引所ではない「構造的なエンティティ」として区別する必要があることが判明した。この誤りを修正することで、データの正確性が大幅に向上し、地図の表示内容もより現実を反映したものになった。

最終的に、Holder Atlasはまだいくつかの課題を抱えている。例えば、Solanaブロックチェーンのトークンには対応しておらず、分析された供給量のうちクジラ（大量保有者）が占める割合が大きい場合、そのウォレットに取引所の痕跡がないと「追跡不能」とみなされ、全体のうち国が特定できる割合が低く表示されてしまう問題がある。また、地図に表示される「国」は、あくまで取引所が拠点を置く管轄地域であり、実際にそのトークン保有者が居住する国を直接示しているわけではない点も留意が必要だ。

このように、アプリケーションのパフォーマンス改善は、単純な方法では解決しない複雑な問題に直面することがある。APIのレイテンシはAPIを提供する側の性能に大きく依存する場合があり、クライアント側でできる最適化には限界があることをこの経験は示している。同時に、外部APIを利用する際には、提供されるデータの意味合いを深く理解し、意図しない解釈を避けるための厳密なデータ処理が重要であることも浮き彫りになった。このプロジェクトを通じて得られた知見は、APIを利用するシステムの開発において、パフォーマンス、安定性、そしてデータの正確性を追求するための貴重な教訓となるだろう。