クラウドネイティブのサブグラフの解放: 効率的なカスタム インデックス作成への飛躍
完全なクラウドネイティブ技術を取り入れた後、Chainbaseは正式にローンチされ、100以上のコアデータセットサブグラフをホスティングしています：https://console.chainbasehq.com/indexer
1. 背景
Uniswap（DeFi）やBored Ape Yacht Club（NFT）などの複雑なスマートコントラクトを持つプロジェクトでは、そのすべてのデータがブロックチェーン上に保存されています。ブロックチェーンとの直接的なやり取りでは基本的な契約データのみを抽出できます。たとえば、特定のBored Apeの所有者を見つけるためにeth_callを使用して、そのIDに基づいてエイプのコンテンツURIを取得したり、総供給を決定したりすることができます。
しかし、集計、検索、リレーショナルクエリなどの高度な操作は行えません。たとえば、特定のアドレスがどのエイプを所有しており、特定の特性に基づいてそれらをフィルタリングしたい場合、オンチェーンの契約との直接的なやり取りではこの情報を直接取得することはできません。
この情報にアクセスするには、ゼロからブロック高さを開始して契約によって発行されるすべての転送イベントを処理するバックエンドプログラムを開発する必要があります。このプログラムは、トークンIDとIPFSハッシュを使用してIPFSからメタデータを取得します。このデータを要約して計算した後に、開発者が求める情報を導出できます。このバックエンドプログラムは、私たちがサブグラフと呼ぶものです。
サブグラフは、The Graphの分散型アプリケーションインデックスプロトコルの特定の実装です。それはさまざまなスマートコントラクトのためのインデックスエンジンとして機能し、開発者が迅速かつ効率的にクエリするためのデータセットを提供します。
2. 課題
ブロックチェーンエコシステムが進化するにつれ、サブグラフの構築は、ブロックチェーンデータへのアクセスと提供のための開発者のお気に入りのツールとなりました。各サブグラフは特定のスマートコントラクトに対応し、さまざまなユーザーやシナリオのニーズを満たすために構築およびホスティングする必要があります。私たちはエコシステムの中で最もコアなサブグラフのほとんどをホスティングおよびサポートすることに成功し、データセットが最もホストされているコンポーネントです。
ただし、このホスティングのスケーリングにより、既存のフレームワークと運用方法に多くの問題と課題が導入されました。
2.1 大規模なキャッシュを持つモノリシックなPostgreSQLデータベース、読み書きの分離なし
デフォルトでは、Graph Nodeはバックエンド関係データベースとしてPostgreSQLを使用し、すべてのサブグラフが1つのデータベースインスタンスを共有しています。また、設定されたchains.providerに基づいてオンチェーンのRaw Data**を強制的にキャッシュし、これを無効にすることはできません。
複数のプロバイダーを持つ構成では、データベーススペースのほとんどはRaw Dataによって占有され、常にデータベースインスタンスの容量とIOPSの拡張が必要です。最も致命的な問題は、データベースインスタンスの容量が増加するにつれて、データベース全体の読み書きパフォーマンスが著しく低下することです。最終的には、クエリリクエストの読み取りのために別個の読み取り専用データベースインスタンスを起動する必要があります。各サブグラフが個別のインスタンスを開始する場合、各データベースが完全なセットのRaw Dataをキャッシュする問
題が発生し、重大なデータの冗長性とリソースの浪費につながります。
2.2 リソースの奪取に対するサブグラフタスクの脆弱性、リソースのスケールが困難
サブグラフが最初にデプロイされると、設定されたstartBlockからインデックスを開始します。初期の契約トランザクションは比較的小さいため、インデックス速度は比較的速く、リソースの消費も少ないです。しかし、コアトランザクションブロックに到達すると、トランザクションのボリュームが増加し、eventsの数が増加します。これによりインデックスが遅くなり、リソースの消費が増加します。一つのノードでのGraph Nodeのデプロイメントの利用可能なリソースは、それがインストールされているマシンのハードウェア仕様によって決まります。他のソフトウェアと同様に、Graph Nodeの最大の能力は、このマシンのハードウェアリソース、処理能力、メモリ、ストレージによって制限されます。
これらの物理的なマシンリソースの利用率は、しばしばピークと谷を経験します。これにより、サブグラフがリソースを必要とする際にタイムリーにスケーリングアップすることができず、サブグラフが最新のブロックまでインデックスされ、多くのリソースが必要ない場合にスケーリングダウンすることができません。
2.3 リソース奪取に対するサブグラフタスクの脆弱性
同じノードで複数のサブグラフが一緒にデプロイされ、サブグラフのすべてのdebug、info、warn、errorログが混在しています。これにより、どのサブグラフのエラーログであるかを正確に判断することが難しくなっています。
2.4 安定した高性能なRPCノードの必要性
サブグラフのインデックスパフォーマンスは、RPCノードの通信パフォーマンスに大きく依存しています。RPCノードのリクエストの遅延が低いほど、サブグラフのインデックス速度は速くなり、新しくデプロイされたサブグラフのデータが最新のブロックに追いつくまでの時間が短くなります。ただし、RPCノードを自身でデプロイするコストは高いです。
3. Chainbaseの解決策のアプローチ
3.1 ストレージと計算の分離、およびPostgreSQLデータベースクラスター
計算とストレージの独立したスケーリングを可能にし、システムの柔軟性を向上させるために、各サブグラフのデータベースと各チェーンのRaw Data Cacheを区別する必要があります。たとえば、ethereumとpolygonそれぞれに個別のデータベースインスタンスが必要です。新しいサブグラフがデプロイされると、そのサブグラフがどのパブリックチェーンのものかを検出し、対応するCache接続アドレスを自動的に割り当てます。
このアプローチの利点は、グローバルなCacheデータセットを維持するだけでよいため、各サブグラフがCacheデータをキャッシュする必要がないということです。単一のCacheはすべての他のサブグラフで共有でき、データの冗長性の問題を解決します。
さら
に、kubernetesでpvcを使用して各個別のデータベースインスタンスのリソースを拡張できます。拡張のスケールは、サブグラフのインデックスデータのボリュームとインデックスの進行率に応じて細かく制御できます。これにより、サブグラフが必要とする総リソースを明確に予測できます。
3.2 サブグラフリソースの分離と自動スケーリング
各サブグラフは、deploymentを使用してステートレスなアプリケーションに抽象化され、ステートフルなpostgresqlデータベースインスタンスにstatefulsetを介してバックエンドに接続します。これにより、各サブグラフの計算、ストレージ、ネットワークリソースを効果的に分離します。
各サブグラフに対してグローバルな初期リソースのrequestとlimitが設定されています。limit内で、サブグラフはリソースを動的に調整できます。リソース利用率が80%以上になると、スケーリングアップします。利用率が30%未満の場合、スケーリングダウンします。
ただし、現在のバージョンのサブグラフはシングルスレッドで実行され、並行してインデックスをサポートしていないため、従来のHorizontal Pod Autoscaler（HPA）水平スケーリングはインデックス速度を向上させることはできません。その代わりに、Vertical Pod Autoscaler（VPA）垂直スケーリングを使用してリソースリミットを動的に増やし、サブグラフの望ましいインデックスパフォーマンスを実現します。
3.3 メトリクスの監視とログの収集
kubernetesのコンテナ化によるサブグラフのリソース分離機能のおかげで、特定のpodsに基づいて各サブグラフの特定の監視メトリックデータを収集できます。クラスターデータを一元的に収集するためにkube-metricsを使用し、サブグラフの安定性監視、アラート、ダイナミックなリソーススケーリングに使用します。この段階ではdebugログを有効にし、elasticを使用して統一的な収集を行い、各サブグラフのデバッグログ情報を簡単にクエリできるAPIを公開します。
3.4 安定した高性能なRPCノード
RPCノードは高い並行性、高い可用性、低いレイテンシをサポートする必要があり、安定したSLAサービスを提供する必要があります。自己ホスティングおよびRPCノードのデプロイは高いハードウェアコストだけでなく、ノードの後段での保守と最適化も困難です。安定したRPCサービスプロバイダーの選択は、サブグラフのインデックスの基本的な保証です。
4. 利点と効果
従来の展開アーキテクチャでは、Ethereumアーカイブノードを展開する必要がある場合、現在の最良の選択肢はErigonクライアントを使用することです。ただし、必要な最小ハードウェアリソース構成（AWSクラウドリソースインスタンスi4i.4xlargeを参照）は次のとおりです：
| ID | 名前 | 構成 |
|---|---|---|
| 1 | CPU | 16vCPU |
| 2 | メモリ | 128GB |
| 3 | PCIE（SSD） | 3.4T + |
| 合計収益 | ≈936USD/月 |
ChainbaseのRPCサービスを利用すると、基本パッケージに申し込むだけで、コストを90%以上節約できます。
さらに、クラウドネイティブ環境でのサブグラフのホスティング後、モノリシックアーキテクチャのデータベースボトルネックによるインデックス化パフォーマンスとキャッシュリソースの冗長性の問題を解決しました。**kubernetesエコシステムの助けを借りて、リソースの動的スケーリングを対処し、subgraph**のインデックス化リソース要件と組み合わせて、リソース利用率が大幅に向上しました。
- インデックス化速度は、RPCノードとデータベースの読み書きパフォーマンスの改善により30%以上向上しました。
- サブグラフの平均リソース利用率は80%増加しました。
5. 未来
サブグラフがブロックを順次インデックス化するしかないという内在的な制約があるため、まったく新しいサブグラフのインデックス化速度を大幅に向上させることは現在はできません。Chainbaseは、この技術的な制約を突破する方法を積極的に検討しており、将来的にはブロックのインデックス化を同時に実行できる方法を提供する予定です。Chainbaseは、新しいクラウドネイティブ技術を取り入れ、サブグラフのホスティングを向上させ、インデックス化速度を向上させ、リソース利用率を最適化するための新しいアプローチを提供しています。**EVM**ブロックチェーンエコシステムの成熟に向けて、より効率的でスケーラブルなインフラストラクチャを提供し続けることを目指しています。
Chainbaseについて
Chainbaseは、Web3のための包括的なデータインフラストラクチャであり、On-Chainデータをインデックス化、変換、活用することをサポートします。 Chainbaseは、豊富なOn-Chainデータとストリーミングコンピューティング技術を活用し、ブロックチェーンデータのインデックス化とクエリを自動化することで、開発者がより少ない労力でより多くのことを達成できるようにします。
Chainbaseについてもっと知りたいですか？
chainbase.comのウェブサイトを訪れ、無料アカウントを作成してドキュメントを参照してください。
ウェブサイト｜ブログ｜Twitter｜Discord｜Link3
original link:https://chainbase.com/blog/article/unleashing-cloud-native-subgraphs-a-leap-towards-efficient-custom-indexing
