AlchemyはSolana上で最速のアーカイブメソッドをどう構築したか

昨年末、Solana向けの新しいプロダクトを発表しました。このプロダクトの主要な特徴の一つが、アーカイブメソッドのパフォーマンスです。市場に出ている他のどのソリューションよりも最大20倍高速です。

Alchemyの Solana向けオファリングでは、開発者は標準のJSON RPCインターフェースを通じて、過去のトランザクション、ブロック、署名を前例のない速度でクエリできます。これを実現するのは簡単ではありませんでした。この記事では、その実現方法を詳しく説明します。

Solanaにおけるアーカイブメソッドとは

Solanaにおいて、アーカイブメソッドとは、getTransaction、getBlock、getSignaturesForAddressのような、過去のブロックチェーンデータを取得するRPC呼び出しを指します。

これらのアーカイブエンドポイントは、オンチェーンアプリの基盤です。ウォレット、インデクサー、分析プロバイダー、エクスプローラーなど、多くのサービスがこの過去のデータに依存し、ユーザーにより豊富なデータを提供し、一貫した体験を構築しています。

しかし、Solanaにおけるアーカイブアクセスの取得は非常に難しいことで知られています。データセットは膨大で、深く相互に関連しており、クエリには大きな計算負荷がかかります。ほとんどの開発者にとって、これらのエンドポイントはレイテンシと不整合の問題が最初に、そして最も顕著に現れる箇所です。

Solanaのアーカイブメソッドにおけるパフォーマンスの問題

今日のSolanaインフラのほとんどは、Google Bigtableとバリデータベースのノードを組み合わせて動作しています。

このスタックはデプロイが容易であるため多くのチームに選ばれていますが、スケールを前提に構築されたものではありません。CPU負荷が高く、メモリを大量に消費し、大規模なバッチリクエストへの対応に苦しみます。大規模にクエリを行うと、これらのメソッドはスループットを絞り込んでアプリの動作を著しく遅くしたり、さらに悪い場合にはレスポンス内のデータを丸ごと欠落させたりすることがあります。

このため、評判の良いプロバイダーであっても、過去のデータをクエリした際に不完全な、あるいは遅延したレスポンスを返すことがよくあります。開発者にとって、こうしたブロックの欠落や遅い呼び出しは、すぐにアプリ内の体験の破綻へとつながります。

私たちはこれを解決したいと考えました。単にハードウェアを増やすだけでなく（それも行いましたが）、インフラ全体のアーキテクチャを見直すことで対応しました。

Google Bigtableでの最適化における苦労

多くのSolanaインフラプロバイダーと同様、私たちもGoogle Bigtableから始め、時間とともに上記のパフォーマンス上の問題を発見しました。この問題は、二つの要因によってさらに悪化していました。

第一に、Solanaのブロックサイズの大きさです。Bigtableは行が約1KBのときに最も高いパフォーマンスを発揮します。しかし、Solanaのトランザクションデータやアカウントステートは、それよりもはるかに大きいことが多いです。大きなバイナリオブジェクトを取得するには、Googleの基盤ストレージ（Colossus）からより多くのI/Oが必要になります。

第二に、コストの問題がありました。クラウドデータベースは高価です。Solana上のデータの多く（投票トランザクションなど）はそれほど価値が高くなく、そのようなデータをクラウド上に維持することは経済的に現実的ではありません。また、Google Bigtableは使用量に応じた課金であるため、より高いRPSを提供する上でさらに圧力がかかり、柔軟性も低くなります。

こうした制約があったものの、私たちはこの構成に対しても最適化を試みました。例えば、トランザクション取得の最適化です。Google Bigtableのデフォルト構成では、getTransactionで1件のトランザクションをリクエストすると、署名からブロックIDを引くために1回のクエリがtxテーブルに発行されます。その後、単一のトランザクションを返すためにすべてのブロックを取得します。リモートのクラウドデータベースからわずかなデータを返すためだけに、多くの処理を要していたわけです。

このよくあるリクエストをより効率的にするため、私たちはtx-fullという追加のテーブルを導入しました。ここには、ブロックへの参照だけでなく、トランザクション全体を保存します。これによりレスポンスタイムは大きく改善しましたが、データセンターの地理的な距離によるレイテンシの増加には、依然として悩まされていました。

デフォルトのスタックに合わせようと努力しましたが、開発は非常に遅いままでした。フルRPCノード／バリデータからの単純な書き込みでさえ大きな負担で、変更のたびにノードの完全な再起動が必要でした。このプロセスには30分から数時間かかることもありました。データベースを地理的に近くに置けないこと、また一部のパラメータを制御できないことも、すべてをより困難かつ高コストにしていました。しばらく試行錯誤した末、データの取り込みからRPCサーバー自体まで、スタック全体を書き直す方が良いと判断しました。

私たちの解決策：書き直したスタック

この取り組みにおける主な目標は、開発サイクルを短縮することでした。つまり、データの書き込みと配信を行う重いRPCノードをなくすということです。代わりに、書き込みと配信を小さな別々のサービスに分離し、セルフホスト型のオープンソースデータベースに切り替えました。

この新しいシステムは以下を実現します：

• ハードウェアとソフトウェアの共同最適化： ディスクレイアウトからメモリアクセスまで、スタックのあらゆる層をスループットの最大化と計算オーバーヘッドの最小化に合わせて調整しています。
• マルチリージョンのデータ分散： アーカイブデータはグローバルに分散され、リクエストの発信元にかかわらず低レイテンシなアクセスを実現します。
• 三重検証による取り込み： 各レコードは2回書き込まれ、プログラムによって正確性が検証され、継続的に完全性がスキャンされます。
• 自己修復パイプライン： 不整合が検出された場合、欠落したエントリを自動的に再取り込みし、ブロックごとに最大30〜50個の関連アドレスを相互チェックしてデータの整合性を保証します。

このソリューションの各部分を見ていきましょう。なお、このソリューションはオープンソース化されています（このコードはDexterLabのリポジトリに存在し、昨年Alchemyが買収しました）。

ArchivalRPC

私たちはアーカイブサービスをゼロから作り直し、数秒で起動・再起動できる、はるかに高性能なサービスにしました。フルRPCノードを扱っていた頃の30分から数時間かかっていた起動時間からの劇的な改善です。

シリアライズ・デシリアライズには引き続き公式のSolanaライブラリを使用しているため、このサービスは今後の変更にも常に互換性を保ちます。つまり、新しいカスタムスタックであっても、データそのものは一切変更しておらず、処理過程でデータが破損しないことを保証しています。

そして、データベースに依存する軽量なサービスであるため、必要に応じて（わずか数秒で）容易にスケールでき、大量のトラフィックにも対応できます。これはスパイクの多いアプリケーションに特に有用で、単一のDBインスタンスでも、データベースの構成次第でこのサービスは10〜20万RPSに達することができます。

ArchivalRPC ingestor

このスタックの部分は、複数のソースからSolanaデータを取り込み、データベース層に書き込む役割を担っています。新しいインスタンスをブートストラップする際に使用する生のgzipブロックアーカイブなどの一括インポートと、Kafkaのようなシステムからのリアルタイムストリームの両方を処理します。

また、インジェスターには細かい制御機能を組み込み、インスタンスが保存すべきデータ種別を正確に選択できるようにしました（例：ブロックのみ、署名のみ、トランザクションのみ、あるいはそれらの任意の組み合わせ）。この選択的取り込みモデルにより、単一障害点が減り、信頼性が向上し、ユースケースに応じてストレージコストを最適化するための有効な手段が得られます。

Hbase

読み書きのパフォーマンスを改善した後、私たちは次の課題であるクラウドデータベースのレイテンシに目を向けました。ArchivalRPCは当初から複数のストレージバックエンドをサポートするように設計されていたため、代替案の検討は容易でした。

最終的にHBaseを選びました。これはBigTableに代わるオープンソースでセルフホスト型のもので、データベースをRPCサーバーと同じ場所に配置できるため、ストレージのレイテンシを実質ゼロにまで下げることができました。この実装により、既存のデータモデルと実装原則をそのまま使うこともでき、アーキテクチャ上のリスクを増やすことなくパフォーマンスの恩恵を得られました。

しかし、HBaseの強みをもってしても、いくつかの問題に直面しました。例えば、Solanaのブロックサイズの大きさに対応するため、当初はHBaseのBucketCacheを利用しようとしました。これはオフヒープメモリや高速SSDをセカンダリキャッシュ層として使うよう設定でき、より多くのデータを「ウォーム」な状態に保つことができます。

しかし、最終的にはBucketCacheが信頼性に欠けることが分かりました。データのランダム性とその変化の速さにより、システムの速度が低下してしまったのです。そこで代わりに、大きなデータを扱うための別のアプローチを採用しました。ブロックの保存方法そのものを変更したのです。データベース（このような大きなデータ構造を扱うようには設計されていません）にフルのblobを保存する代わりに、メタデータのみをデータベースに保存し、それがCARファイルを指すようにしました。CARファイルは任意のストレージに置くことができ、非常にスケーラブルです。

サービスの最適化とマルチリージョン分散

数百万、さらには数十億件のリクエストにまで拡張できるソリューションを構築するには、スタック全体にわたる最適化が必要でした。単にデータベースアーキテクチャを別のものに置き換えるだけでは、求めていたパフォーマンスには到底届きませんでした。異なるハードウェア上でさまざまなデプロイ構成を試し、異なるアーキテクチャを検証する必要がありました。時間をかけて取り込みおよび配信サービスを改善し、目標としていた結果を得ることができました。

大量のリクエストを処理できるようハードウェアとソフトウェアを最適化することは、解決すべき課題の一つでした。もう一つはレイテンシとの戦いでした。負荷の高いアーカイブ呼び出しでは、レイテンシを制御下に置くために、ハードウェアを複数のリージョンに展開し、世界中で一貫した高速レスポンスを確保する必要があることがわかりました。

このマルチリージョン構成は可用性も向上させ、より高い信頼性基準を維持するのに役立ちます。障害は避けられないものであり、地理的に分散したフォールバックオプションを持つことで、一つのリージョンがダウンしても顧客へのサービス提供を継続できます。また、この同じマルチリージョン構成は、スケーリングとトラフィックの分散にも役立ちます。一つのリージョンが容量の限界に近づいた場合、デプロイをスケールしながら別のリージョンにトラフィックをルーティングできます。

三重検証による取り込み

このプロダクトにおける作業の多くはパフォーマンスの改善でしたが、それは戦いの半分に過ぎません。Solanaのアーカイブメソッドにおける継続的な問題の一つは、データが丸ごと欠落することです。私たちはシステムの信頼性を改善する必要がありました。

Bigtableベースの多くのプロバイダーは、取り込みパイプラインがスケールするにつれ、ブロック、署名、トランザクションを気づかぬうちに見落としています。この見落としは、バリデータからのデフォルトのデータ取り込み方法に起因します。再起動のたびにデータ書き込みにギャップが生じる可能性があるのです。

同じデータを書き込む複数のバリデータを維持する構成に縛られていたとしても、データが正しく書き込まれているかを確認する二次チェックがないため、データの整合性は保証されません。そして、そのインフラを利用する開発者にとっては、下流で何かが壊れるまで、データが欠落していることに気づく術がありません。

私たちのインフラは、設計によってこの問題を防ぎます。データを書き込んだ後、二次パイプラインを実行してすべてのレコードを読み取り、そのデータを継続的に検証し、不整合が発生した場合は自動的に修復します。また、初期ブートストラップ後にはデータベース全体の完全チェックを行い、ライブでの書き込みについてもほぼリアルタイムでチェックを続けています。

私たちが構築したのは、単に速いデータだけではありません。信頼できるデータです。

自己修復パイプライン

signaturesのような一部の複雑なデータについては、フォールバック手法を信頼することができません。つまり、上述の三重検証プロセスだけでは不十分な場合があるということです。

これに対処するため、私たちはプログラムによる検証を用いて、ブロックごとに最大30〜50個のアドレスにわたってトランザクションを相互チェックしています。システムが不整合を検出した場合、バックアップおよび復旧プロセスが自動的に欠落エントリを修復します。

このプロセスでは、正となるブロックを取得し、そこからすべてのアドレスと署名の関係を抽出します。ここでHBaseのスキャンコストを最適化するため、これらのマッピングをアドレスごとに連続する広範なスロット範囲にわたって蓄積し、個別のキーベースクエリの代わりにスキャンクエリを実行します。その結果を比較することで、SIGSクラスタ内のギャップを特定できます。

これらのギャップを特定した後、該当するブロックをインデックス作成パイプラインに再投入し（このデータ種別に適したKafkaトピックへ）、再インデックスを行います。また、ギャップが埋まらない場合はこの操作を繰り返す整合性チェッカープロセスも追加しており、障害状態が続く場合には最終的にチームへアラートを送ります。

このような冗長性と自己修復により、私たちのメソッドをSolanaにおける過去データの最も完全かつ一貫性のあるソースとして信頼していただけます。

この取り組みがスループットに与えた成果

これらすべての取り組みは、実質的なキャパシティの向上につながりました：

• getTransactionのリージョンあたり100,000 RPS
• getSignaturesForAddressのリージョンあたり50,000 RPS
• getBlockのリージョンあたり2,000 RPS

私たちはSolana向けオファリングへの投資を続けており、さらなる信頼性とレイテンシ改善のため、近いうちに対応リージョンを拡大する予定です。これはまだ始まりに過ぎません。

試してみる

SolanaでのAlchemyのアーカイブメソッドを試してみたい場合は、ダッシュボードアカウントを作成することでAPIキーを生成し、無料で始めることができます。その後、ドキュメントでSolanaのエンドポイントを確認できます。

よくある質問

Solanaにおけるアーカイブメソッドとは何ですか？

アーカイブメソッドとは、getTransaction、getBlock、getSignaturesForAddressのような、過去のブロックチェーンデータを取得するRPC呼び出しです。これらのエンドポイントにより、開発者は標準のJSON RPCインターフェースを通じて過去のトランザクション、ブロック、署名にアクセスできます。

Solanaのアーカイブメソッドはなぜ通常遅いのですか？

Solanaインフラのほとんどは、CPU負荷が高く、メモリを大量に消費し、大規模なバッチリクエストへの対応に苦しむGoogle Bigtable上で動作しています。このスタックはスケールを前提に構築されておらず、スループットを絞り込んだり、パフォーマンスを低下させたり、レスポンス内のデータを欠落させたりすることがあります。

AlchemyのSolanaにおけるアーカイブメソッドはどれくらい高速ですか？

Alchemyのアーカイブメソッドは他のソリューションと比べて最大20倍高速で、getTransactionについてはリージョンあたり100,000 RPS、getSignaturesForAddressについては50,000 RPS、getBlockについては2,000 RPSのキャパシティを備えています。

Alchemyはどのようにデータの完全性と信頼性を確保していますか？

私たちは三重検証による取り込みを採用しており、各レコードは2回書き込まれ、プログラムによって正確性が検証され、継続的に完全性がスキャンされます。自己修復パイプラインは、ブロックごとに最大30〜50個の関連アドレスを相互チェックすることで、欠落したエントリを自動的に再取り込みします。

AlchemyはSolanaのアーカイブデータにどのデータベースを使用していますか？

私たちはHBaseを使用しています。これはオープンソースでセルフホスト型のデータベースで、データをRPCサーバーと同じ場所に配置し、ストレージのレイテンシを実質ゼロにまで下げることができます。これはGoogle Bigtableに代わるもので、パフォーマンスの向上とコスト削減を実現しています。

AlchemyはSolanaの大きなブロックサイズをどのように扱っていますか？

Alchemyは、フルブロックをデータベースに保存する代わりに、CARファイルを指すメタデータのみを保存します。CARファイルは任意のストレージに置くことができ、高いスケーラビリティを持ちます。このアプローチにより、Solanaのブロックサイズの大きさによりよく対応できます。

なぜAlchemyはアーカイブスタック全体をゼロから作り直したのですか？

フルRPCノードを使用するデフォルトのスタックでは、再起動に30分から数時間を要し、開発が遅く、コストもかさんでいました。Alchemyはデータの書き込みと配信を小さなサービスに分離し、数秒で再起動でき、必要に応じてスケールできるようにしました。

Alchemyはグローバルに低レイテンシをどのように維持していますか？

アーカイブデータは複数のリージョンにグローバルに分散され、リクエストの発信元にかかわらず低レイテンシなアクセスを実現しています。このマルチリージョン構成は、需要の高い時期のトラフィック分散にも役立ち、可用性の向上にも寄与しています。