---
title: "アプリの信頼性を築く:Web3成功の鍵"
description: "ノードの信頼性はWeb3アプリにとって重要です。Alchemyのインフラがスケール時の信頼性をどう支えるかをご紹介します。"
---

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

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

なぜでしょうか。

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

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

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

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

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

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

信頼性の低いインフラを使っていた、ある有名な[NFTマーケットプレイス](https://www.alchemy.com/dapps/best/nft-marketplaces)の例を見てみましょう。

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

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

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

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

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

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

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

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

### （1）ノードの信頼性は単独では成立せず、ノードのスケーラビリティおよびデータ精度が伴わなければならない
高機能なアプリを作るには、信頼性に加えて、スケーラビリティとデータ精度が必要です。

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

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

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

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

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

<ExternalVideo
  url="https://vimeo.com/775874944"
  provider="vimeo"
  providerUid="775874944"
/>

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

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

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

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

<ExternalVideo
  url="https://vimeo.com/775874968"
  provider="vimeo"
  providerUid="775874968"
/>

### （4）ノードにはフルタイムのメンテナンスが必要
平均して5日に1度、ノードには以下のような問題が発生する可能性があります。

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

各問題の診断、トラブルシューティング、修正にはかなりの時間がかかり、その分、[フロントエンドのユーザー体験に割ける時間が大幅に減ります](https://www.alchemy.com/case-study/zerion)。

<CalloutBlock>

「Alchemyと連携することで、常時インフラのメンテナンスに張り付かなければならなかったはずのフルタイムエンジニア3人分に相当する工数を節約できました。」 - Evgeny Yurtaev、CEO兼共同創業者、[Zerion](https://www.alchemy.com/dapps/zerion)

</CalloutBlock>

<ExternalVideo
  url="https://vimeo.com/775874996"
  provider="vimeo"
  providerUid="775874996"
/>

### （5）ノードの有効性は、予測不能なタイミングで発生するネットワークアップグレードやハードフォークをうまく乗り切れるかどうかに左右される
ネットワークアップグレードやハードフォークは、あなたのスケジュールではなくプロトコル側のスケジュールで発生します。それぞれに相当な準備が必要であり、対応を誤ればノードがクラッシュし、深刻な影響を及ぼしかねません。

<CalloutBlock>

「Alchemyと統合する前は、自社でブロックチェーンインフラを運用していました。このやり方では、問題なく維持・スケールさせることは不可能でした。業界全体に関わるアップデートが1件あるだけで実装に何時間もかかり、全体に頭痛の種を生んでいました。」 - Evgeny Yurtaev、CEO兼共同創業者、Zerion

</CalloutBlock>

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

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

### 単一ノードの運用
[構築は簡単ですが、単一障害点の問題を抱え](https://www.alchemy.com/overviews/running-your-own-node)、異種性と冗長性のどちらも欠いています。単一ノードの稼働率は72%程度まで低下することがあり、単一ノードのスケーリングは非常に非効率です。

### バックアップ付きノードの運用
これは[単一ノードよりわずかに冗長性を増します](https://www.alchemy.com/overviews/alternative-rpc-endpoint)が、それでも異種性（システムの多様性）はなく、多くの場合、最初のノードをダウンさせるリクエストは2つ目のノードもダウンさせてしまいます。スケーラビリティの問題は依然として残り、さらに[**データ精度**](https://alchemy.com/blog/data-accuracy)の問題も生じます。つまり、各ノードが同じブロックヘッド（あるいは同じチェーン）にあることを保証できるシステムはほとんどないため、ノードごとに異なるレスポンスが返されることになります。

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

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

<ExternalVideo
  url="https://vimeo.com/775875017"
  provider="vimeo"
  providerUid="775875017"
/>

<EmbeddedTable
  table={{
    columns: [
      { key: "1", width: 200, title: "", dataType: "object" },
      { key: "2", width: 200, title: "Reliability", dataType: "object" },
      { key: "3", width: 200, title: "Scalability", dataType: "object" },
      { key: "4", width: 200, title: "Data accuracy", dataType: "object" },
    ],
    data: [
      {
        "1": { title: "<p><strong>Running one node</strong><br/>Heterogeneity<br/>Redundancy</p>", tooltip: "", icon: "" },
        "2": { title: "<p>Lacks heterogeneity and redundancy</p>", tooltip: "", icon: "" },
        "3": { title: "<p>Cumbersome to spin up new nodes</p>", tooltip: "", icon: "" },
        "4": { title: "<p>Yes! Has data accuracy</p>", tooltip: "", icon: "" },
        id: 0,
      },
      {
        "1": { title: "<p><strong>Running one node with a backup</strong><br/>Heterogeneity<br/>Redundancy</p>", tooltip: "", icon: "" },
        "2": { title: "<p>Lacks heterogeneity and redundancy</p>", tooltip: "", icon: "" },
        "3": { title: "<p>Cumbersome to spin up new nodes</p>", tooltip: "", icon: "" },
        "4": { title: "<p>No data accuracy</p>", tooltip: "", icon: "" },
        id: 1,
      },
      {
        "1": { title: "<p><strong>Load balancing across a fleet of nodes</strong><br/>Heterogeneity<br/>Redundancy</p>", tooltip: "", icon: "" },
        "2": { title: "<p>Lacks heterogeneity and redundancy</p>", tooltip: "", icon: "" },
        "3": { title: "<p>Cumbersome to spin up new nodes</p>", tooltip: "", icon: "" },
        "4": { title: "<p>No data accuracy</p>", tooltip: "", icon: "" },
        id: 2,
      },
    ],
  }}
/>

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

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

<CalloutBlock>

「Alchemy以前は、余計な開発リソースを消耗させるバックエンドインフラの管理に悩まされ続けていました。他の開発者向けプラットフォームは提供するソリューションの幅が不十分でした。オンコールインシデントのほとんどがノード関連のものでした。」 - Brad Bayliss、リードテクニカルマネージャー、Enjin

</CalloutBlock>

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

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

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

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

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

<CalloutBlock>

「Alchemyは、間違いなく、私たちが毎日何千回ものコール処理を行いながら、途切れない信頼性でシームレスにスケールできる、包括的なツールセットを提供してくれる唯一のプロバイダーです。」 - Kyle Gusdorf、ソフトウェアエンジニア、Decentral Games

</CalloutBlock>

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

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

<ExternalVideo
  url="https://vimeo.com/775877885"
  provider="vimeo"
  providerUid="775877885"
/>

### ノードへのデータリクエストを最小化する、冗長かつ異種なシステム
Web2インフラは、サーバーからデータストレージを切り離し、外部ストレージセンターを構築することで信頼性とスケーラビリティを実現しています。

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

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

<ImageBlock
  src="https://media.alchemy.com/1704726829-supernode-secondary-infrastructure.jpg"
  alt="Cortexのセカンダリインフラがノードデータを複製する仕組みの図"
  width={1920}
  height={1080}
  caption="Cortexのセカンダリインフラ"
/>

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

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

<ImageBlock
  src="https://media.alchemy.com/1704726923-routing-requests-to-secondary-infrastructure.jpg"
  alt="セカンダリインフラへのリクエストルーティング"
  width={1920}
  height={1080}
  caption="セカンダリインフラへのリクエストルーティング"
/>

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

例を挙げてみましょう。

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

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

<ImageBlock
  src="https://media.alchemy.com/1704727109-secondary-infrastructure-example.jpg"
  alt="セカンダリインフラがリクエストを処理し、ノードがエッジケースを処理する仕組みの図"
  width={1920}
  height={1080}
  caption="セカンダリインフラの例"
/>

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

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

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

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

<CalloutBlock>

「Alchemyのおかげで、セカンダリ／バックアップインフラを使う必要がなくなりました。Alchemyは決してダウンせず、稼働率は非常に安定しています。彼らのプラットフォームは私たちにとって完璧に機能しています。」 - Johnny Rhea、共同創業者兼CTO、Element.Fi

</CalloutBlock>

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

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

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

<EmbeddedTable
  table={{
    columns: [
      { key: "1", width: 200, title: "Node Type", dataType: "object" },
      { key: "2", width: 200, title: "Data Coverage", dataType: "object" },
    ],
    data: [
      {
        "1": { title: "<p>Geth Archive Node</p>", tooltip: "", icon: "" },
        "2": { title: "<p>Since genesis</p>", tooltip: "", icon: "" },
        id: 0,
      },
      {
        "1": { title: "<p>Geth Full (Fast) Node</p>", tooltip: "", icon: "" },
        "2": { title: "<p>Most recent 2,000 blocks</p>", tooltip: "", icon: "" },
        id: 1,
      },
    ],
  }}
/>

<ImageBlock
  src="https://media.alchemy.com/1704727753-mudit-gupta-tweet.png"
  alt="ロードバランシングに関するMudit Guptaのツイート"
  width={846}
  height={242}
  caption="ロードバランシングに関するMudit Guptaのツイート"
/>

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

Alchemyは[複数のタイプのノードを運用](https://www.alchemy.com/overviews/what-is-an-ethereum-node)しています。

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

<ImageBlock
  src="https://media.alchemy.com/1704727971-alchemy-runs-multiple-types-of-nodes.jpg"
  alt="Alchemyは複数種類のノードを運用"
  width={1920}
  height={1080}
  caption="Alchemyは複数種類のノードを運用"
/>

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

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

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

<EbookCta
  eyebrow="無料ガイド"
  title="Build vs. Buy: Blockchain Infrastructure"
  description="インフラチームを採用する前に読んでください：自社構築には、本番リクエストを1件処理する前から年間85万〜100万ドル以上かかることがあります。コストの内訳全体はこちら。"
  ctaLabel="ガイドをダウンロード"
  ctaHref="/resources/build-vs-buy"
  coverImage={{
    src: "https://media.alchemy.com/ebooks/cta-build-vs-buy.png",
    alt: "Build vs. Buy ebook cover",
  }}
/>

### バグの影響を軽減する、異種なクライアント
最後に、Alchemyは[geth](https://www.alchemy.com/overviews/what-is-a-geth-node-and-how-to-run-one)、Erigon、Parityを含む、Ethereumクライアントの異なる実装を運用しています。これによりバックエンドのメンテナンス作業は実質的に3倍に増えますが、異種性を確保するという点では非常に価値があります。これらのクライアントが同じバグを抱える可能性は、実質的にゼロだからです。

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

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

<ImageBlock
  src="https://media.alchemy.com/1704728098-use-alchemy-rpc.png"
  alt="NFTにはAlchemy RPCを使用"
  width={856}
  height={190}
  caption="NFTにはAlchemy RPCを使用"
/>

<CalloutBlock>

「信頼性とスケーラビリティの両方を備えたインフラのおかげで、顧客が私たちを最も必要とするときに稼働し続けられます - これはCollab.Landにとって非常に大きな意味を持ちます。Alchemyはまさにこの分野の第一人者です。」 - Raymond Feng、CTO、Collab.Land

</CalloutBlock>

<ImageBlock
  src="https://media.alchemy.com/1704728160-use-alchemy-rpc-for-your-dapps.png"
  alt="アプリにはAlchemy RPCを使用"
  width={846}
  height={214}
  caption="アプリにはAlchemy RPCを使用"
/>

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

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

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

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