アプリの信頼性を築く:Web3成功の鍵

多くのチームのweb3アプリは失敗する運命にあります。

なぜでしょうか。

アプリはノードに完全に依存しており、そのノードの維持がきわめて難しいからです。理由はいくつかあります。

1. ノードの信頼性は単独では成立せず、ノードのスケーラビリティおよびデータ精度が伴わなければならない
2. ノードはフルスケールの本番用ソリューションとして設計されていない
3. ノードには過剰な数の役割が期待されている
4. ノードにはフルタイムのメンテナンスが必要
5. ノードの有効性は、予測不能なタイミングで発生するネットワークアップグレードやハードフォークをうまく乗り切れるかどうかに左右される

こうした複雑な事情により、ノードの管理と維持は困難になっています。

しかし、ノードの信頼性、すなわちユーザーが必要なときにあなたのアプリと確実にやり取りできる能力を大きく改善する、アーキテクチャ上の2つの要素があります。

• 異種性（Heterogeneity）: 異なるリクエストを処理できる、多様で相補的なシステム
• 冗長性（Redundancy）: あるシステムがダウンしても他のシステムが稼働し続けられる、バックアップシステム

web3において、信頼性の欠如は深刻な結果をもたらしかねません。

信頼性の低いインフラを使っていた、ある有名なNFTマーケットプレイスの例を見てみましょう。

彼らのプラットフォームは不安定で、以下の状況を生み出していました。

• 重いエンジニアリング負荷
• 劣化したUX
• 四半期で190時間を超えるダウンタイム

その影響は？600万ドルの収益損失です。

同じことがあなたに起きないようにしましょう。

本記事では、以下について説明します。

1. ノードの信頼性維持が困難である理由
2. よくあるノードインフラのパターンと、それらが失敗する理由
3. Alchemyが信頼性の課題にどう対応し、スケールする信頼性をどう構築しているか

ノードの信頼性維持が困難である理由

web3において信頼性の維持が特に難しい理由は、主に5つあります。

（1）ノードの信頼性は単独では成立せず、ノードのスケーラビリティおよびデータ精度が伴わなければならない

高機能なアプリを作るには、信頼性に加えて、スケーラビリティとデータ精度が必要です。

• スケーラビリティ: アプリへのトラフィックが10倍、100倍、1000倍、あるいはそれ以上にスケールしても、ブロックチェーンとのやり取りを継続できる能力。
• データ精度: アプリがすべてのユーザーに対して正確かつ一貫したデータを返す状態。

（2）ノードはフルスケールの本番用ソリューションとして設計されていない‍

ノードはもともと、個人が個人的な、あるいは小規模なユースケースのために運用することを想定して設計されていました。コストは高額（月1000ドル）ですが、その限定的なユースケースにおいては十分な信頼性を生み出し、以下を維持できます。

• スケーラビリティ：リクエスト量が予測可能な範囲でコントロールされているため、必要なスケーラビリティに関するリスクは限定的
• データ精度：ノードが1つしか存在しないため、ノード間でのデータ不整合が起きる余地がありません

しかし、開発環境は本番環境ではなく、本番環境にはまったく異なるツールが必要です。

（3）** **ノードには過剰な数の役割が期待されている

ノードには、ピアツーピアソフトウェアの実行、スケーラブルなデータベースとしての機能、任意のコードの実行など、無制限とも言える数の役割が期待されています。

また、ノード自体には、何をすべきで何をすべきでないかという「判断基準」がありません。

これには主に2つの影響があります。

• スケーラビリティ：リクエスト量の増加に合わせてスケールするには新しいノードを立ち上げる必要があり、その新しいノード一つひとつに、あの長い機能リストを組み込んで構築しなければなりません。これは非効率で、コストもかさみます（繰り返しになりますが、安くてもノード運用には月1000ドルかかります）。
• エッジケース：ノードには基本的な保護機構がないため、たった1つのクエリでノードがクラッシュすることがあります。

（4）ノードにはフルタイムのメンテナンスが必要

平均して5日に1度、ノードには以下のような問題が発生する可能性があります。

• メモリリーク
• データストレージの問題
• CPUの上限到達
• ピアリングの不整合
• 内部データベースの破損
• トランザクションのブロードキャストに関する問題
• バグおよびリグレッション
• 「安定版リリース」の6分の1は不具合を含んでいる

各問題の診断、トラブルシューティング、修正にはかなりの時間がかかり、その分、フロントエンドのユーザー体験に割ける時間が大幅に減ります。

（5）ノードの有効性は、予測不能なタイミングで発生するネットワークアップグレードやハードフォークをうまく乗り切れるかどうかに左右される

ネットワークアップグレードやハードフォークは、あなたのスケジュールではなくプロトコル側のスケジュールで発生します。それぞれに相当な準備が必要であり、対応を誤ればノードがクラッシュし、深刻な影響を及ぼしかねません。

よくあるインフラアーキテクチャのパターンと、それらが失敗する理由

信頼性のあるノードインフラを運用することは本質的に難しく、web3で一般的なアーキテクチャの多くは信頼性の構築という点で効果的ではありません。

単一ノードの運用

構築は簡単ですが、単一障害点の問題を抱え、異種性と冗長性のどちらも欠いています。単一ノードの稼働率は72%程度まで低下することがあり、単一ノードのスケーリングは非常に非効率です。

バックアップ付きノードの運用

これは単一ノードよりわずかに冗長性を増しますが、それでも異種性（システムの多様性）はなく、多くの場合、最初のノードをダウンさせるリクエストは2つ目のノードもダウンさせてしまいます。スケーラビリティの問題は依然として残り、さらにデータ精度の問題も生じます。つまり、各ノードが同じブロックヘッド（あるいは同じチェーン）にあることを保証できるシステムはほとんどないため、ノードごとに異なるレスポンスが返されることになります。

‍ノード群全体でのロードバランシング

このモデルは冗長性は高まりますが、それでも異種性はありません。データ精度とスケーラビリティの問題は残ったままです（一連のリトライがノード群全体を巻き込んでダウンさせることがあります）。

ノードはよくダウンし、その修復は本当に、本当に手間がかかります。

はっきり言ってしまうと、ブロックチェーンに接続するための多くの「ソリューション」は、異種性や冗長性を十分に提供できておらず、そのために結局は破綻します。破綻は深刻な影響をもたらします。

ノードが再び稼働するまでの復旧には、数日から数週間かかることもあります。こうした問題はコストがかさみ、解決が難しく、チーム全体で集中的に取り組む必要があります。

2019年、BlockCypherはEthereumのConstantinopleハードフォークへの対応を試みました。その際にデータ欠損のエラーに直面し、根本原因を診断できませんでした。彼らは1か月を超えるダウンタイムに見舞われ、最終的にはほぼゼロからの再構築を余儀なくされました。

同じことがあなたに起きないようにしましょう ;)

web3インフラの異種性と冗長性が高まるほど、その信頼性も高まります。

Alchemyがスケールする信頼性をどう構築しているか

Alchemyの Cortex エンジンは、独自に構築されたスケーラブルかつ分散型のシステムを組み合わせ、信頼性とスケーラビリティを実現すると同時に、当社の API が単一ノードのように振る舞うことを可能にし、データ精度を確保しています。

Cortexは、スケーラブルで多様なシステムによって冗長性と異種性の両方を実現する

ノードへのデータリクエストを最小化する、冗長かつ異種なシステム

Web2インフラは、サーバーからデータストレージを切り離し、外部ストレージセンターを構築することで信頼性とスケーラビリティを実現しています。

しかし、ノードアーキテクチャの特殊な性質上、ノードからデータストレージを切り離すことは実質的に不可能です。

信頼性とスケーラビリティを実現するため、Alchemyの Cortex エンジンは、セカンダリインフラと呼ばれる高度なアーキテクチャを用いて、ノードのデータを複製しています。

Cortexの協調レイヤーであるVox Nodiは、セカンダリインフラが常に最新のデータを保持していることを確認するため、継続的にシステムチェックを行います。これにより、ブロック番号、トランザクションログ、トランザクションレシートといったデータへのリクエストは正確なものになります。

リクエストをまずセカンダリインフラに振り分けることで、ノードは保護され、その「作業負荷」が軽減されます。

ほとんどのリクエストはセカンダリインフラで処理でき、ノードに回されるのはエッジケースのみです。

例を挙げてみましょう。

ユーザーがさまざまなデータ種別とブロックについての情報を求めているとします。

• ユーザー1はブロック82までのTransactionsデータを要求
• ユーザー2はブロック85からのLogsデータを要求
• ユーザー3はブロック92からのBlocksデータを要求

ユーザー1のリクエストはセカンダリインフラシステムで処理できます（重要な点として、このようなリクエストがノードに直接届いた場合、ノードはクラッシュしていたはずですが、セカンダリインフラシステムであればこの負荷をシームレスに処理できます）。

ユーザー2のリクエストもセカンダリインフラで処理できます。

ユーザー3のリクエストは、システムがまだブロック92以降のBlocksデータを持っていないため、セカンダリインフラでは処理できません。このリクエストはノードから処理されることになります。

この例において、ユーザー1、2、3の体験はまったく同じです。セカンダリインフラ経由で応答するか、ノードから直接応答するかで、ダウンタイムに違いはありません。しかし、リクエストをまずセカンダリインフラシステムに振り分けることで、ノードは保護され、その「作業負荷」は軽減されます。

コード実行のための冗長かつ異種なシステム

Ethereum Virtual Machine（EVM）はチューリング完全であるため、ノードにコードの実行をリクエストすることができます。ノードは自己制御ができないため、任意のリクエストがノード群全体をダウンさせる可能性が常に存在します。

これを防ぐため、Alchemyは自社システムがこれまでに応答したすべてのリクエストを重複排除した上で保存しています。

これにより、真に新規性のあるリクエストのみがノード上で実行され、それ以外の大半のリクエストはこれらのストレージシステムによって処理できます。

さまざまなリクエストに特化した、異種なノード

セカンダリインフラシステムに加えて、Alchemyは異なるタイプのノードを用いることで異種性を高めています。セカンダリインフラがリクエストに応答できない例外的なケースでは、システムは最もスケーラブルなノードにフォールバックします。

Alchemyは複数のタイプのノードを運用しています。

• Light: ネットワーク上で取引を行うために必要な最小限のデータであるブロックヘッダーのみをダウンロードします。Light ノードはネットワークと効率的にやり取りでき、数メガバイトの帯域幅と数ギガバイトのストレージを節約できますが、完全なデータにアクセスできないという制約があります。
• Full: ネットワーク上のブロックが正しいことを検証するために必要なすべてを持ち、あらゆるスマートコントラクトとやり取りし、自らデプロイすることもできます。Full ノードにはかなりのコンピューティングリソースと帯域幅が必要です。
• Archive: Full ノードよりもさらに踏み込んだものです。Full ノードは検証に不要となったエントリを削除しますが、Archive ノードはすべて（膨大な追加データ）を保持します。この詳細さは情報をより効率的に照会するのに優れており、一部のアプリケーションには便利ですが、多くの場合には過剰です。
• Debug: Debug ノードはArchive ノードよりもさらに踏み込み、あらゆるノードタイプの中で最も多くの情報を保持するため、スマートコントラクトの実行を極めて詳細にステップ実行できます。

ノードタイプごとに異なる特性があるため、それぞれ得意分野が異なります。そのため、あるノードがリクエストに応答できなくても、他のノードは正常に稼働していて対応に適している可能性が高いのです。

例えば、まだセカンダリインフラに記録されていない可能性のある最新データへのリクエストがあった場合、そのリクエストはFast ノードに振り分けられ、Archive ノードは「保護」されます。Archive ノードのデータをふるいにかけるのは、それよりもはるかにコストがかかるためです。

必要に応じて新しいノードを容易に立ち上げられるようにするため、Cortex エンジンはノードの「スナップショット」を取得しています。これにより、新しいノードを作成する際、システムは直近の「チェックポイント」から開始でき、同期プロセスを大幅に短縮できます。

バグの影響を軽減する、異種なクライアント

最後に、Alchemyはgeth、Erigon、Parityを含む、Ethereumクライアントの異なる実装を運用しています。これによりバックエンドのメンテナンス作業は実質的に3倍に増えますが、異種性を確保するという点では非常に価値があります。これらのクライアントが同じバグを抱える可能性は、実質的にゼロだからです。

冗長性と異種性による信頼性の構築

Alchemyでは、Cortexのエンジニアリングに数十万時間を費やしてきました。これはゼロから異種性と冗長性を備えるように構築された複雑なシステム群であり、耐障害性を大幅に高め、あらゆるブロックチェーンリクエストに確実に応答できるようにしています。

この信頼性を可能にする複雑で相互依存的なシステムを構築するのに、私たちは何年もかけてきました。信頼性を制御できるように構築することは非常に困難ですが、信頼できるインフラを活用することは、あなたのアプリの成功にとって不可欠です。

インフラの選択肢を検討する際、プロバイダーに最初に尋ねるべき質問の一つは次のとおりです。「あなたのインフラはどれほど異種性と冗長性を備えていますか。そして、そのシステムの信頼性を裏付ける証拠として何を示せますか。」

公開されているRPCプロバイダーのベンチマークは、プロバイダーのアーキテクチャに関する主張と併せて、レイテンシ、成功率、失敗したリクエストを評価するのに役立ちます。

あなたのアプリの成功は、この選択にかかっています。何かお手伝いできることがあれば、ぜひお知らせください。