はじめに
初めまして。 『DApps開発入門』という本や色々記事を書いているかるでねです。
以下でも情報発信しているので、興味ある記事があればぜひ読んでみてください！
今回は「Alchemy Supernode」と「Vox Nodi」についてまとめていきます。
ブロックチェーンアプリケーションを開発する上で、ノードインフラの選択は非常に重要です。 なぜAlchemyが多くの大規模プロジェクトに採用されているのか、その技術的な背景を理解していきましょう。
ブロックチェーンノードの課題
従来のノード構成の問題点
ブロックチェーンアプリケーションを構築する際、多くの開発者はノードを単純にロードバランサーの背後に配置する構成を取ります。 しかし、この構成には根本的な問題があります。
The traditional Web 2.0 approach to scaling infrastructure uses multiple, indistinguishable servers managed by a load balancer. With blockchain, however, applications can't treat nodes indistinguishably because each node syncs and stores data from the blockchain asynchronously.
（従来のWeb 2.0におけるインフラのスケーリング方法は、ロードバランサーで管理された複数の同一サーバーを使用します。しかしブロックチェーンでは、各ノードがブロックチェーンからデータを非同期的に同期・保存するため、アプリケーションはノードを同一視して扱うことができません。）
ブロックチェーンでは、各ノードがネットワークから非同期的にデータを同期・保存します。 ピアツーピアネットワークの特性上、情報がすべてのノードに同時に届くことはありません。 そのため、あるノードでは最新ブロックが100番でも、別のノードでは99番という状況が頻繁に発生します。
以下の図は、従来のロードバランサー構成で発生するデータ不整合の仕組みを示しています。
sequenceDiagram
participant Client as クライアント
participant LB as ロードバランサー
participant Node1 as ノード1<br/>(Block #100)
participant Node2 as ノード2<br/>(Block #99)
Client->>LB: eth_blockNumber (1回目)
LB->>Node1: リクエスト転送
Node1-->>LB: Block #100
LB-->>Client: Block #100
Client->>LB: eth_blockNumber (2回目)
LB->>Node2: リクエスト転送
Node2-->>LB: Block #99
LB-->>Client: Block #99 (不整合!)この図は、同じクライアントが連続してブロック番号を問い合わせた場合に、ロードバランサーが異なるノードにリクエストを振り分けることでデータ不整合が発生する様子を示しています。 1回目のリクエストでBlock #100を受け取った後、2回目のリクエストでBlock #99が返却されると、アプリケーションは「時間が巻き戻った」ような状態になり、予期しないエラーが発生します。
データ不整合が引き起こす問題
データ不整合は以下のような深刻な問題を引き起こします。
| 問題 | 影響 |
|---|---|
| ブロック番号の不一致 | ユーザーのトランザクションが失敗する |
| nonce値の誤り | トランザクションが拒否される |
| トランザクションログの欠落 | イベント監視が正しく機能しない |
| 残高情報の遅延 | ユーザーに誤った残高を表示する |
Data inconsistencies force developers to introduce tons of complicated workarounds and lead to inevitable errors that crash applications and ruin user experience. Without a new approach to blockchain infrastructure, developers are forced to choose between scale, reliability, and correct data.
（データの不整合は、開発者に多くの複雑な回避策を強いることになり、アプリケーションをクラッシュさせユーザー体験を損なう避けられないエラーを引き起こします。ブロックチェーンインフラへの新しいアプローチなしには、開発者はスケール、信頼性、正確なデータのいずれかを犠牲にせざるを得ません。）
Alchemyのベンチマーク実験では、Ethereumメインネットに対して24時間で100万回以上eth_blockNumberをクエリした結果、競合他社（Quicknode）は712回の不正確なブロック番号を返したのに対し、Alchemyは0件でした。
After more than 1 million eth_blockNumber queries in 24 hours, the results showed that Quicknode returned 712 inaccurate block numbers compared to Alchemy which returned zero incorrect block numbers.
（24時間で100万回以上のeth_blockNumberクエリの結果、Quicknodeが712回の不正確なブロック番号を返したのに対し、Alchemyは0回でした。）
このベンチマークは以下のツールで自分でも検証できます。
Supernodeとは
概要と目的
Supernodeは、Alchemyが開発したWeb3向けのインフラストラクチャエンジンです。
Alchemy Supernode is an infrastructure engine specifically designed for Web 3.0. The blockchain-native architecture delivers peak reliability by powering each piece of node functionality with dedicated, distributed infrastructure — the same kinds of systems used by Facebook and Amazon for achieving massive scale.
（Alchemy SupernodeはWeb 3.0向けに特別に設計されたインフラストラクチャエンジンです。ブロックチェーンネイティブなアーキテクチャは、各ノード機能を専用の分散インフラストラクチャで動作させることで最高の信頼性を実現します。これはFacebookやAmazonが大規模スケールを達成するために使用しているのと同じ種類のシステムです。）
単なるノードクラスタではなく、カスタム設計されたスケーラブルな分散システムの集合体です。 このシステムにより、AlchemyのAPIは単一のノードのように振る舞い、データの正確性に関する問題をすべて解決します。
Supernode is much more than just a bunch of connected nodes - it's a combination of custom, scalable and distributed systems that essentially allow the API to act as a single node, which solves accuracy issues.
（Supernodeは単なる接続されたノードの集まりではありません。カスタム設計されたスケーラブルな分散システムの組み合わせであり、APIを本質的に単一のノードとして動作させることで、正確性の問題を解決します。）
アーキテクチャの全体像
公式ドキュメントによると、Supernodeは各ノード機能を専用の分散インフラストラクチャで動作させています。
The blockchain-native architecture delivers peak reliability by powering each piece of node functionality with dedicated, distributed infrastructure.
（ブロックチェーンネイティブなアーキテクチャは、各ノード機能を専用の分散インフラストラクチャで動作させることで、最高の信頼性を実現します。）
以下の図は、公式情報を基に筆者が推定したアーキテクチャの概要です。 実際の内部実装は公開されていないため、参考としてご覧ください。
graph TB
subgraph Client["クライアント"]
App[アプリケーション]
end
subgraph Supernode["Supernode (推定構成)"]
Coordinator[コーディネーターサービス<br/>Vox Nodi]
subgraph NodeClients["複数クライアント実装"]
Geth[Geth]
Erigon[Erigon]
Parity[Parity]
end
end
App --> Coordinator
Coordinator --> Geth
Coordinator --> Erigon
Coordinator --> Parityこの図は、クライアントからのリクエストがコーディネーターサービス（Vox Nodi）を経由して、複数のEthereumクライアント実装に振り分けられる様子を示しています。 公式情報によると、Alchemyは異なるEthereumクライアント実装を並行して運用しています。
Alchemy runs different implementations of the Ethereum client, including geth, Erigon and Parity. This essentially triples the backend maintenance work required, but it is hugely valuable in service of heterogeneity: the chance that these clients have the same bug is essentially zero.
（Alchemyはgeth、Erigon、Parityを含む異なるEthereumクライアント実装を運用しています。これはバックエンドのメンテナンス作業を実質的に3倍にしますが、異種性の観点から非常に価値があります。これらのクライアントが同じバグを持つ確率は実質ゼロです。）
これにより、特定のクライアントにバグがあっても他のクライアントでカバーでき、システム全体の信頼性が向上します。
コーディネーターサービスの役割
Supernodeの中核を担うのがプロプライエタリ（独自開発）のコーディネーターサービスです。
Alchemy Supernode also ensures the data is always correct, real-time, and in sync across every corner of the system thanks to a proprietary coordinator service. This allows Alchemy Supernode to scale quickly, gracefully, and infinitely so developers never need to worry about maintaining infrastructure again.
（Alchemy Supernodeは、独自のコーディネーターサービスにより、データが常に正確でリアルタイムであり、システムの隅々まで同期されていることを保証します。これによりAlchemy Supernodeは迅速かつスムーズに、そして無限にスケールできるため、開発者はインフラの維持を心配する必要がなくなります。）
コーディネーターサービスは以下の機能を担当しています。
flowchart TB
subgraph Coordinator["コーディネーターサービス"]
Sync[データ同期管理]
Route[クエリルーティング]
Validate[データ検証]
Scale[スケーリング制御]
end
subgraph Functions["主要機能"]
F1[リアルタイム同期の維持]
F2[適切なノードへの振り分け]
F3[データ正確性の検証]
F4[負荷に応じた動的スケーリング]
end
Sync --> F1
Route --> F2
Validate --> F3
Scale --> F4この図は、コーディネーターサービスが持つ4つの主要機能を示しています。 データ同期管理はシステム全体のリアルタイム同期を維持し、クエリルーティングはリクエストを適切なノードに振り分けます。 データ検証は返却されるデータの正確性を確認し、スケーリング制御は負荷に応じてインフラを動的に拡張します。
Vox Nodiの仕組み
Vox Nodiとは
Vox Nodi（ラテン語で「ノードの声」の意味）は、Alchemyが開発した整合性レイヤーです。
Alchemy built an explicit consistency layer called Vox Nodi (the voice of the nodes). Vox Nodi's responsibility is to guarantee that any blockchain request will return a consistent result.
（AlchemyはVox Nodi（ノードの声）と呼ばれる明示的な整合性レイヤーを構築しました。Vox Nodiの責務は、あらゆるブロックチェーンリクエストが一貫した結果を返すことを保証することです。）
コンセンサスアルゴリズムの仕組み
Vox Nodiは、Alchemyのインフラストラクチャ全体でコンセンサスアルゴリズムを実行します。 各インフラストラクチャのコンポーネントが、ブロックチェーンの正しい状態について「投票」を行います。
This works by essentially running a consensus algorithm across the infrastructure, where each piece of the infrastructure can vote on the correct state of the blockchain. By correctly routing and tweaking queries, this system ensures that despite various nodes having different views of transaction data at any given time, the results are always consistently accurate.
（これは本質的にインフラストラクチャ全体でコンセンサスアルゴリズムを実行することで機能します。インフラの各部分がブロックチェーンの正しい状態について投票できます。クエリを適切にルーティングし調整することで、このシステムは、さまざまなノードが任意の時点でトランザクションデータの異なるビューを持っていても、結果が常に一貫して正確であることを保証します。）
投票プロセスは以下のように動作します。
sequenceDiagram
participant Client as クライアント
participant VoxNodi as Vox Nodi
participant Node1 as ノード1
participant Node2 as ノード2
participant Node3 as ノード3
Client->>VoxNodi: データリクエスト
VoxNodi->>Node1: 状態クエリ
VoxNodi->>Node2: 状態クエリ
VoxNodi->>Node3: 状態クエリ
Node1-->>VoxNodi: Block #100
Node2-->>VoxNodi: Block #100
Node3-->>VoxNodi: Block #99
VoxNodi->>VoxNodi: 投票集計・合意形成
VoxNodi-->>Client: Block #100（検証済み）この図は、Vox Nodiがどのようにノード間の状態を調整するかを示しています。 各ノードが受信したデータに対して投票を行い、データが正確であると確認された場合にのみクライアントに返却されます。 この例では、ノード1とノード2がBlock #100を返し、ノード3がBlock #99を返しています。 Vox Nodiは多数決で Block #100を正しい値として採用し、クライアントに返却します。
データ整合性の保証方法
Vox Nodi, Supernode's coordination layer, runs constant system checks to ensure the secondary infrastructure has the latest data, and therefore, any requests for data (e.g., block number, txn logs, txn receipts) will be accurate.
（Vox NodiはSupernodeのコーディネーション層として、セカンダリインフラストラクチャが最新のデータを持っていることを確認するために常にシステムチェックを実行します。したがって、ブロック番号、トランザクションログ、トランザクションレシートなどのデータリクエストは正確になります。）
Vox Nodiは、セカンダリインフラストラクチャが最新のデータを持っていることを確認するために、常にシステムチェックを実行しています。 これにより、ブロック番号、トランザクションログ、トランザクションレシートなどのデータリクエストが正確であることが保証されます。
整合性を保証するための主要な技術的要素を以下の表にまとめます。
| 要素 | 説明 |
|---|---|
| 継続的なシステムチェック | すべてのノードが最新データを持っているか常時監視する |
| クエリルーティング | リクエストを適切なノードに振り分ける |
| 投票ベースの検証 | 複数ノードの合意によりデータの正確性を確認する |
| リアルタイム同期 | ノード間のデータ差異を即座に検出し解消する |
以下の図は、Vox Nodiがどのようにデータ整合性を維持しているかの概念図です。
flowchart TB
subgraph Monitor["継続的監視"]
Check[システムチェック]
end
subgraph Nodes["ノード群"]
N1[ノード1<br/>Block #100]
N2[ノード2<br/>Block #100]
N3[ノード3<br/>Block #99]
end
subgraph Action["整合性アクション"]
Detect[遅延検出]
Sync[同期待ち/除外]
end
Check --> N1
Check --> N2
Check --> N3
N3 --> Detect
Detect --> Syncこの図は、Vox Nodiがすべてのノードを継続的に監視し、遅延しているノード（この例ではノード3）を検出してリクエスト振り分けから一時的に除外する、または同期完了を待つ仕組みを示しています。
クエリルーティングの詳細
Vox Nodiのクエリルーティングは、単純なロードバランシングとは異なります。 リクエストの種類や必要なデータの鮮度に応じて、最適なノードを選択します。
flowchart LR
subgraph Request["リクエスト分類"]
R1[最新ブロック参照]
R2[過去ブロック参照]
R3[トランザクション送信]
end
subgraph Routing["ルーティング判断"]
Latest[最新同期ノードのみ]
Archive[アーカイブノード]
Broadcast[全ノードへブロードキャスト]
end
R1 --> Latest
R2 --> Archive
R3 --> Broadcastこの図は、リクエストの種類に応じたルーティング判断を示しています。 最新ブロックを参照するリクエストは最も同期が進んでいるノードに振り分けられ、過去のブロックデータはアーカイブノードから取得します。 トランザクション送信は、確実に処理されるよう複数のノードにブロードキャストされます。
拡張機能
Smart WebSockets
Supernodeは、イベント監視のための拡張WebSocket機能を提供しています。
Alchemy includes enhanced API methods and upgraded WebSockets to continuously listen for changes and automatically handle reconnection and backfilling missed events.
（Alchemyは拡張APIメソッドとアップグレードされたWebSocketsを提供し、変更を継続的にリッスンし、再接続と見逃したイベントのバックフィルを自動的に処理します。）
従来のWebSocket接続では、接続が切断された場合、その間に発生したイベントを見逃してしまいます。 Smart WebSocketsはこの問題を解決します。
sequenceDiagram
participant App as アプリケーション
participant WS as Smart WebSocket
participant Node as ノード
App->>WS: イベント購読開始
WS->>Node: 接続確立
Node-->>WS: Event A
WS-->>App: Event A
Note over WS,Node: 接続切断（ネットワーク障害等）
WS->>Node: 自動再接続
Node-->>WS: Event B, C（見逃し分）
WS-->>App: Event B, C（バックフィル）
Node-->>WS: Event D
WS-->>App: Event Dこの図は、Smart WebSocketsの自動再接続とバックフィル機能を示しています。 接続が切断されている間に発生したイベント（Event B, C）は、再接続後に自動的にバックフィルされます。 ただし、接続が120ブロック（約20分）以上切断されていた場合、一部のイベントを見逃す可能性があります。
アーカイブデータアクセス
Supernodeは、ブロックチェーンの履歴データに無制限でアクセスできます。
Archive data is data on the blockchain that is older than 128 blocks, which is approximately 4 epochs or 25.6 minutes old.
（アーカイブデータは、128ブロック以上前（約4エポックまたは25.6分前）のブロックチェーン上のデータです。）
通常のフルノードは直近128ブロック分のステート（状態）しか保持していません。 それより古いデータにアクセスするにはアーカイブノードが必要ですが、アーカイブノードの運用コストは非常に高くなります。
graph LR
subgraph FullNode["フルノード"]
Recent[直近128ブロック<br/>約25分]
end
subgraph ArchiveNode["アーカイブノード"]
All[Genesisから全履歴]
end
subgraph Supernode["Supernode"]
Both[両方にアクセス可能<br/>無料プランでも利用可]
endこの図は、フルノードとアーカイブノードのデータ保持範囲の違い、そしてSupernodeが両方にアクセスできることを示しています。 Supernodeでは無料プランでもアーカイブデータにアクセスでき、Genesisブロック（最初のブロック）からチェーン全体をフォークすることも可能です。
Cortexへの進化
Vox NodiからCortexへ
Vox Nodiは整合性レイヤーとして成功を収め、2021年までにOpenSea、0x、Polymarketなどの大規模トラフィックを処理していました。 Alchemyはその後、Vox Nodiを基盤としてマルチリージョンインフラストラクチャへと拡張しました。
Architected from the ground up over the last 2 years, Cortex was trained on data from 7 years powering hundreds of billions in transactions for the top crypto companies worldwide.
（過去2年間でゼロから設計されたCortexは、世界のトップ暗号通貨企業向けに数千億のトランザクションを処理してきた7年間のデータで訓練されました。）
そして現在、Cortexという新しいエンジンが開発者プラットフォーム全体を動かしています。 CortexはRPC API、Data API、Gasless Transactions、Rollupsを含むすべてのサービスを支えています。
Cortexの特徴
Alchemy has built Cortex, the first intelligent blockchain engine, designed to deliver what other providers can't.
（Alchemyは、他のプロバイダーが提供できないものを提供するよう設計された、世界初のインテリジェントブロックチェーンエンジンであるCortexを構築しました。）
Cortexは「世界初のインテリジェントブロックチェーンエンジン」と位置付けられています。 7年間の実運用データと数兆件のリクエストから学習したAIを活用し、ブロックチェーンとのやり取りを根本から変革しています。
Alchemy launched Cortex, an AI-powered blockchain engine that reduces latency to under 50 ms and boosts node throughput by up to 1000x.
（Alchemyは、レイテンシを50ms未満に削減し、ノードスループットを最大1000倍に向上させるAI搭載のブロックチェーンエンジン、Cortexをローンチしました。）
Cortexがもたらす改善を以下の表に示します。
| 指標 | 改善幅 | 出典 |
|---|---|---|
| 速度 | 2.5倍高速化 | Alchemy公式 |
| 信頼性 | 5倍向上 | Alchemy公式 |
| スループット | 最大1000倍 | The Block |
| 平均レスポンス時間 | 50ms未満 | Alchemy公式 |
以下の図は、Cortexのレイヤー構造を示しています。
graph TB
subgraph Intelligence["インテリジェンス層"]
AI[AIルーティング<br/>数兆件のクエリで訓練]
end
subgraph Infra["インフラ層"]
Bare[ベアメタルサーバー]
Dark[ダークファイバー接続]
Multi[マルチリージョン]
end
subgraph Reliability["信頼性層"]
Failover[自動フェイルオーバー]
Threat[AI脅威検知]
end
AI --> Bare
AI --> Dark
AI --> Multi
Bare --> Failover
Multi --> Failover
Failover --> Threatこの図は、Cortexが3つの主要な層で構成されていることを示しています。 インテリジェンス層ではAIがリクエストの最適なルーティングを決定し、インフラ層ではベアメタルサーバーとダークファイバー接続により高速な通信を実現し、信頼性層では自動フェイルオーバーとAI脅威検知により可用性を確保しています。
AIベースのルーティング
Smart routing algorithms trained on trillions of global queries and intelligent request segmentation deliver up to 2.5x faster queries, all around the world.
（数兆件のグローバルクエリで訓練されたスマートルーティングアルゴリズムとインテリジェントなリクエストセグメンテーションにより、世界中で最大2.5倍高速なクエリを実現します。）
CortexはAIを活用したトラフィック最適化を行っています。 コンテキストを認識したルーティングにより、リクエストを最適なノードに振り分けます。
Cortex employs AI-driven traffic optimization and context-sensitive routing to manage increases in global activity without experiencing downtime or reduced performance.
（Cortexは、AIドリブンのトラフィック最適化とコンテキストを認識したルーティングを採用し、ダウンタイムやパフォーマンス低下なしにグローバルなアクティビティの増加を管理します。）
AIルーティングシステムは数兆件のクエリで訓練されており、ピーク時でも高いスループットと低レイテンシを維持します。
flowchart TB
subgraph AIRouting["AIルーティングシステム"]
Input[リクエスト入力]
Analysis[リクエスト分析<br/>メソッド種類/データ要件/地域]
ML[機械学習モデル<br/>数兆件のクエリで訓練]
Decision[最適ノード選択]
end
subgraph Factors["考慮要素"]
F1[ノードの現在負荷]
F2[地理的距離]
F3[データ同期状態]
F4[過去の応答時間]
end
Input --> Analysis
Analysis --> ML
F1 --> ML
F2 --> ML
F3 --> ML
F4 --> ML
ML --> Decisionこの図は、AIルーティングシステムの判断プロセスを示しています。 入力されたリクエストを分析し、ノードの現在負荷、地理的距離、データ同期状態、過去の応答時間などの要素を機械学習モデルで評価して、最適なノードを選択します。
実績（2024年）
During the 2024 U.S. Presidential election, Polymarket processed $3.3 billion in bets with 125,000 concurrent users, at one point handling 20% of all transactions on the Polygon network. Not a single transaction failed due to infrastructure.
（2024年のアメリカ大統領選挙期間中、Polymarketは125,000人の同時接続ユーザーで33億ドルの賭けを処理し、一時はPolygonネットワーク上の全トランザクションの20%を処理しました。インフラストラクチャに起因するトランザクションの失敗は1件もありませんでした。）
2024年のアメリカ大統領選挙期間中、PolymarketはCortexを使用して33億ドル相当の取引を処理しました。 125,000人の同時接続ユーザーを抱え、一時はPolygonネットワーク全トランザクションの20%を処理していましたが、インフラ起因の障害は1件も発生しませんでした。
アーキテクチャ詳細
Shuffle Sharding
Shuffle Shardingは、マルチテナント環境でテナント間の影響を最小化するための技術です。 この技術はもともとAWSが開発したもので、Supernodeでも採用されています。
Its shuffle sharding architecture isolates tenants to prevent performance degradation caused by noisy neighbors.
（シャッフルシャーディングアーキテクチャは、ノイジーネイバーによるパフォーマンス低下を防ぐためにテナントを分離します。）
Shuffle Shardingの仕組みを以下に説明します。 通常のシャーディングでは、ノードを固定のグループに分割します。 一方、Shuffle Shardingでは、カードを配るように各テナントにランダムなノードの組み合わせを割り当てます。
A standard deck of cards has 52 different playing cards and 2 jokers. If we shuffle a deck thoroughly and deal out a four card hand, there are over 300,000 different hands.
（標準的なトランプのデッキには52枚のカードと2枚のジョーカーがあります。デッキを十分にシャッフルして4枚の手札を配ると、30万通り以上の組み合わせがあります。）
graph LR
subgraph Traditional["従来のシャーディング"]
T1A[テナントA] --> S1[シャード1]
T1B[テナントB] --> S1
T1C[テナントC] --> S2[シャード2]
T1D[テナントD] --> S2
end
subgraph Shuffle["Shuffle Sharding"]
T2A[テナントA] --> N1[ノード1]
T2A --> N2[ノード2]
T2B[テナントB] --> N2
T2B --> N3[ノード3]
T2C[テナントC] --> N3
T2C --> N4[ノード4]
endこの図は、従来のシャーディングとShuffle Shardingの違いを示しています。 従来のシャーディングでは、同じシャードに割り当てられたテナント間で相互に影響を受けます。 Shuffle Shardingでは、各テナントが異なるノードの組み合わせを持つため、あるテナントに問題が発生しても、他のテナントへの影響は統計的に最小化されます。
In a pool of 52 servers with a shard size of 4, we can accommodate 270,725 shards (i.e., 270,725 clients) with virtually no impact of one client on another.
（52台のサーバープールでシャードサイズを4とした場合、270,725個のシャード（つまり270,725クライアント）を、クライアント間の影響をほぼゼロにして収容できます。）
例えば、52台のサーバーでシャードサイズを4とした場合、270,725通りの組み合わせが可能です。 統計的に、ランダムに選ばれた2つのテナントがまったく同じインスタンスを共有しない確率は非常に高くなります。
Alchemy Edge Proxy
Alchemy Edge Proxyは、Alchemyが社内で開発したDDoS防御およびルーティングレイヤーです。 これにより、クリティカルパス上の最後のサードパーティ依存を排除しました。
Purpose-built bare-metal hardware, dark fiber connections, and elastic scaling deliver throughput far beyond industry standards.
（専用設計のベアメタルハードウェア、ダークファイバー接続、弾力性のあるスケーリングにより、業界標準をはるかに超えるスループットを実現します。）
Edge Proxyを社内化した効果は以下のとおりです。
| 改善点 | 詳細 |
|---|---|
| レイテンシ低減 | ユーザーに近い場所でルーティングが行われる |
| 信頼性向上 | ベンダーレベルの障害カテゴリを排除 |
| 制御強化 | より厳密な信頼性保証が可能に |
2024年11月18日のグローバルCloudflare障害時、Alchemyのサービスはほとんど影響を受けませんでした。 これは、Cortexがこのような信頼性シナリオに耐えられるよう設計されていることを示しています。
Kubernetesとの統合
The Cortex engine runs on bare-metal servers, not generic cloud infrastructure. Alchemy optimized the system with Kubernetes pod co-location and Istio for locality-aware routing.
（Cortexエンジンは汎用クラウドインフラストラクチャではなく、ベアメタルサーバー上で動作します。AlchemyはKubernetesのPodコロケーションとIstioによるローカリティ認識ルーティングでシステムを最適化しました。）
Cortexは深いシステムレベルのエンジニアリングを特徴としています。 汎用のクラウドインフラストラクチャではなく、ベアメタルサーバー上で動作し、仮想化のオーバーヘッドを回避しています。
Kubernetesとの統合における最適化ポイントを以下に示します。
- Podコロケーション Kubernetes affinityを使用して、レイテンシに敏感なワークロードを同一マシン上で実行します。
- Istioローカリティ認識ルーティング ノード内トラフィックを優先し、不要なネットワークホップを削減します。
- GitOpsスタイルのルーティング設定 安全なロールアウトのための設定管理を実現します。
信頼性機能
Multi-region infrastructure, autonomous failovers, and AI-based threat detection keep apps performant even under extreme conditions.
（マルチリージョンインフラストラクチャ、自律的フェイルオーバー、AIベースの脅威検知により、極端な条件下でもアプリケーションのパフォーマンスを維持します。）
Cortexは99.995%のアップタイムを実現しています。 これを支える信頼性機能は以下のとおりです。
- リージョナルフェイルオーバー リージョンが劣化すると即座にトラフィックを再ルーティングします。
- 分離された緊急バックアップスタック エッジケースの障害に対応します。
- 厳格なバージョニングとレプリケーションロジック 古いデータの読み取りを防止します。
- マルチレイヤーフェイルオーバー 複数層での障害対応により可用性を最大化します。
最後に
今回は「Alchemy Supernode」と「Vox Nodi」についてまとめてきました。
Supernodeは単なるノードの集合ではなく、データ整合性、スケーラビリティ、信頼性を同時に実現するための高度に設計されたインフラストラクチャです。 Vox Nodiによるコンセンサスベースの整合性保証と、Cortexによる次世代のインテリジェントルーティングにより、開発者は安心してブロックチェーンアプリケーションを構築できます。
詳しくは以下の公式ドキュメントを参考にしてください。