--- title: "Cortexの内部:50ms未満・稼働率99.995%を実現するインフラのエンジニアリング" description: "信頼性の高いブロックチェーン接続は必須条件です。Cortexは、ベアメタルハードウェアからAIによるノードフリート管理まで、専用設計のアーキテクチャによって、大規模環境下で50ms未満のレスポンスタイムと99.995%の稼働率を実現しています。" --- # Cortexの内部:50ms未満・稼働率99.995%を実現するインフラのエンジニアリング 信頼性の高いブロックチェーン接続は譲れない要件です。[Cortex](https://www.alchemy.com/cortex)は、Alchemyプラットフォームを支えるインテリジェントなブロックチェーンエンジンであり、[RPC APIs](https://www.alchemy.com/docs/reference/node-api-overview)、[data APIs](https://www.alchemy.com/docs/reference/data-overview)、[rollups](https://www.alchemy.com/docs/reference/rollups-quickstart)、そして開発者向けプラットフォームの残りの基盤インフラを動かしています。 Cortexはファーストプリンシプルに基づいて構築され、数兆件のリクエストと7年以上のデータで訓練されています。目的はただ一つ、どのスケールでも確実に動作するインフラを提供することです。 その結果が、平均50ミリ秒未満のレスポンスタイム、99.995%のアップタイム、そして数千万ユーザー規模までマイグレーションや新しいツール、設定変更なしでスケールするスループットです。 プロバイダー間の公開比較については、レイテンシー、成功率、失敗リクエストに関するAlchemyの[RPCパフォーマンスベンチマーク](https://www.alchemy.com/benchmarks)を参照してください。 この記事では、Cortexを支えるエンジニアリング上の判断、すなわちレイテンシー、スループット、信頼性にまたがるシステムレベルの取り組みが、これらの数値をどう実現しているのかを詳しく見ていきます。 ## Cortexはどのようにレイテンシーを削減しているのか ### Kubernetesアフィニティによるポッドの同居配置 アプリがリクエストを送信すると、そのリクエストはレスポンスが返るまでに複数の内部サービスを経由します。サーバー間を移動するたびに、レイテンシーのコストが発生します。 ポッドの同居配置とは、頻繁に通信するサービス同士を同じ物理マシン上に配置することです。Kubernetesにはこれを可能にするアフィニティルールがあり、レイテンシーに敏感なワークロードを複数のマシンやラックに分散させず、まとめて実行できます。 その結果、リクエストがローカルに留まり、ネットワークホップが減少してレスポンスタイムが短縮されます。 ### Istioによるロケーション認識ルーティング 単一のデータセンター内であっても、サービスは複数のノードやラックに分散しています。Istioは内部サービス間の通信を管理するネットワーキングレイヤーです。 ロケーション認識ルーティングにより、Istioは各サービスインスタンスの物理的な位置を把握し、可能な限り最も近い利用可能なインスタンスへトラフィックをルーティングします。リクエストを処理するサービスが同じノード上で動作している場合、トラフィックはそこに留まり、遠くのインスタンスへネットワークを跨いで送られることはありません。 これにより、アプリケーションコードを変更することなく、不要なネットワークホップを削減できます。 ### マイクロカーネル型プロキシアーキテクチャ インフラが複雑化するにつれ、密結合したシステムは安全に変更することが難しくなります。ある一つのコンポーネントを更新すると、スタック全体にリスクが波及する可能性があります。 マイクロカーネルのアプローチでは、コアを小さく安定した状態に保ち、クリティカルパスのみを担当させます。ロギング、レート制限、認証、ルーティングロジックなど、それ以外の機能はすべてその上に積み重ねられたモジュール型コンポーネントとして実装されます。 私たちのプロキシレイヤーは、受信リクエストとバックエンドシステムの間に位置します。マイクロカーネルモデルで構築されているため、個々のモジュールはコアのリクエストパスに触れることなく、独立して更新・デプロイできます。これにより、リグレッションのリスクを抑えながら迅速なイテレーションが可能になります。 ### データセンター直結ルーティング エンタープライズワークロードでは、パブリックインターネット経由でトラフィックをルーティングすると、レイテンシーのばらつき、パケットロス、そして制御外の状況によって変動する輻輳経路といった不確実性が生じます。 データセンター直結ルーティングは、エンタープライズトラフィックを、当社のインフラへ直接つながるプライベートな最適化されたネットワーク経路経由で送信することでこれを回避します。これにより、共有されたパブリックルーティングの予測不可能性が排除され、各ホップでより一貫した低レイテンシーのパフォーマンスが得られます。 ## Cortexはどのようにスケールしているのか ### グローバルに展開された数千台のベアメタルサーバー ほとんどのクラウドインフラは仮想マシン上で動作しています。仮想化は柔軟ですが、CPU、メモリ帯域幅、I/Oが同じホスト上の他のワークロードと共有されるため、オーバーヘッドが発生します。 ベアメタルとは、ハイパーバイザーを介さず物理ハードウェア上で直接動作させることを意味します。すべてのリソースがリクエストのために専有されます。これにより、共有環境特有のパフォーマンスのばらつきが排除され、高負荷時でもCortexは一貫したスループットを維持できます。 ### Java Virtual Threads 大量の同時実行リクエストを処理すると、サーバーのスレッディングモデルに負荷がかかります。従来のOSレベルのスレッドはメモリを大量に消費し、並行度が上がるにつれてコンテキストスイッチの管理コストも増大します。 Java 21で導入されたJava Virtual Threadsは、OSではなくJVMが管理する軽量なスレッドです。生成やスイッチにかかるコストが従来のスレッドよりも遥かに低いため、1台のマシンで、通常スループットを制限しているメモリやCPUのオーバーヘッドを抱えることなく、はるかに多くの同時タスクを処理できます。 実際には、既存ハードウェアをより効率的に活用でき、パフォーマンスを劣化させずにトラフィックの急増を吸収する余力が増えることを意味します。 ### 予測的スケーリングロジック 標準的なオートスケーリングは、CPU使用率のような閾値を監視し、その閾値を超えた後でキャパシティを追加します。これは設計上リアクティブであり、需要が先に上昇し、インフラが後から追いつく形になります。 私たちのスケーリングロジックは、CPU、メモリ、ディスクI/O、トラフィックパターンなど複数のシグナルを同時に監視し、過去のデータを用いてスパイクが発生する前にそれを予測します。需要が発生した後ではなく、その前にキャパシティがプロビジョニングされるため、トラフィック増加とそれを吸収するインフラの能力とのギャップが縮まります。 ### AIによるノードフリート管理 私たちのノードフリートは、アップグレード、テスト、モニタリングを扱う完全自動化されたエージェント型システムによって管理されています。アップデートはリアルタイムで検知・適用され、パイプラインには自動テストが組み込まれているため、必須のネットワークアップグレードやハードフォークを見逃すことはありません。 これによりアップタイムが向上し、クリティカルなチェーンイベント発生時に人的な遅延が生じるリスクが排除されます。 ## なぜこれらのシステムは相乗効果を生むのか これらは個別の最適化ではありません。ポッドの同居配置がレイテンシーを削減し、ロケーション認識ルーティングがさらにそれを削減します。マイクロカーネルアーキテクチャにより、不安定さを持ち込むことなく両方を改善できます。ベアメタルハードウェアは、Java Virtual Threadsが効率的に動作するために必要なリソースを提供します。予測的スケーリングは、必要になる前にキャパシティが確保されていることを保証します。 各レイヤーは、その上にあるレイヤーをより高速で堅牢にするよう設計されています。これこそが、ファーストプリンシプルからインフラを再考するということであり、Cortexはその上に構築されています。 これらはすべて裏側で動いています。皆さんの側でマイグレーションも新しいツールも設定も必要ありません。私たちがインフラを構築し続けることで、皆さんは自分たちのプロダクトを作り続けることができます。 今すぐ[Start building](https://dashboard.alchemy.com/)、カスタム価格やインテグレーションに関する質問などについては[contact sales](https://www.alchemy.com/contact-sales)までお問い合わせください。 ## よくある質問 ### Alchemy Cortexとは何ですか Cortexは、RPC APIs、data APIs、rollups、インフラを含むAlchemyの開発者プラットフォームを支えるインテリジェントなブロックチェーンエンジンです。ファーストプリンシプルに基づいて構築され、数兆件のリクエストと7年以上のデータで訓練されており、平均50ミリ秒未満のレスポンスタイム、99.995%のアップタイム、マイグレーションや設定変更なしでスケールするスループットを実現しています。 ### Cortexはどのようにして平均50ミリ秒未満のレスポンスタイムを実現しているのですか Cortexは、頻繁に通信するサービスを同じ物理マシンに配置するKubernetesアフィニティによるポッドの同居配置、最も近いサービスインスタンスへトラフィックを誘導するIstioのロケーション認識ルーティング、安定したコアパフォーマンスのためのマイクロカーネル型プロキシアーキテクチャ、そしてエンタープライズトラフィックをプライベートネットワーク経由で送るデータセンター直結ルーティングを使用しています。 ### Cortexのマイクロカーネル型プロキシアーキテクチャとは何ですか マイクロカーネルのアプローチでは、リクエスト処理を担うコアシステムを小さく安定した状態に保ちながら、ロギング、レート制限、認証、ルーティングロジックをモジュール型コンポーネントとして実装します。これらはクリティカルパスに触れることなく、またスタック全体にリスクを持ち込むことなく独立して更新できます。 ### Cortexはスケーリングをどのように異なる方法で扱っているのですか Cortexは、CPU、メモリ、ディスクI/O、トラフィックパターンなど複数のシグナルを監視する予測的スケーリングロジックを使用し、過去のデータをもとに、閾値超過後に反応するのではなく、需要スパイクの前にキャパシティをプロビジョニングします。 ### なぜCortexは仮想マシンではなくベアメタルサーバーを使用しているのですか ベアメタルサーバーはハイパーバイザーを介さず物理ハードウェア上で直接動作し、すべてのリソースをリクエストに専有させることで、共有された仮想化環境特有のパフォーマンスのばらつきやオーバーヘッドを排除し、高負荷時でも一貫したスループットを実現します。 ### Java Virtual Threadsとは何ですか、そしてなぜCortexはそれを使用しているのですか Java Virtual Threadsは、OSではなくJVMが管理する軽量なスレッドであり、従来のスレッドよりも生成やコンテキストスイッチのコストが遥かに低いため、通常スループットを制限しているメモリやCPUのオーバーヘッドを抱えることなく、1台のマシンでより多くの同時タスクを処理できます。 ### Cortexはブロックチェーンノードのアップグレードをどのように管理しているのですか Cortexは、アップグレード、テスト、モニタリングをリアルタイムで扱う完全自動化されたエージェント型システムを使用しており、パイプラインには自動テストが組み込まれているため、必須のネットワークアップグレードやハードフォークを見逃すことがなく、アップタイムが向上し人的遅延のリスクが排除されます。 ### Cortexを使用するためにマイグレーションや設定が必要ですか 皆さんの側でマイグレーション、新しいツール、設定は一切必要ありません。Cortexは裏側で動作し、プロダクトを作り続けている間に自動的にインフラの改善を提供します。