> ## Documentation Index
> Fetch the complete documentation index at: https://injectivelabs-mintlify-25e241d4.mintlify.site/llms.txt
> Use this file to discover all available pages before exploring further.
# ハードウェア要件
> Injectiveノードを実行するための最小および推奨ハードウェア仕様
Injectiveのサブ秒ブロックタイムと高スループットなトランザクション処理は、ハードウェアに大きな負荷をかけます。スペック不足のノードは、チェーンの先端から遅れたり、ブロックをミスしたり（バリデーター）、古いデータを配信したり（RPCノード）します。
## バリデーターノード
バリデーターノードはコンセンサスに参加するため、ジェイルを回避するには安定したパフォーマンスを維持する必要があります。ベアメタルサーバーの利用を強く推奨します。
| *最小要件* | *推奨* |
| :---------------: | :---------------: |
| RAMメモリ 128GB | RAMメモリ 128GB |
| CPU 12コア | CPU 16コア |
| CPUベースクロック 3.7GHz | CPUベースクロック 4.2GHz |
| ストレージ 2TB NVMe | ストレージ 2TB NVMe |
| ネットワーク 1Gbps+ | ネットワーク 1Gbps+ |
### 本番バリデーターの参考構成
参考として、Injectiveメインネットの本番バリデーターは、通常以下の範囲のハードウェアを運用しています：
| コンポーネント | 一般的な構成 |
| ---------- | --------------------------------------------------------------- |
| **CPU** | AMD EPYC 4585PXまたはAMD Ryzen 9 9950X（16コア / 32スレッド、ブースト5.75 GHz） |
| **RAM** | 128 GB DDR5 @ 3600 MT/s |
| **ストレージ** | 約2 TBのNVMe 2台をRAID0構成、使用可能容量約3.5 TiB |
| **ネットワーク** | 10〜25 Gbps |
ブロック処理においては、コア数よりも高いシングルスレッド性能（ブーストクロック）の方が重要です。ネットワーク要件は、仕様表に記載された最低1 Gbpsを大きく上回っています。本番バリデーターは、安定したピア接続と高速なブロック伝播のために、10 Gbps以上の回線の恩恵を受けられます。
## RPCノード
ライブのチェーンデータを配信する非バリデーターノードにも同様の要件があります。スラッシングのリスクはありませんが、スペック不足のノードはチェーンの先端から遅れ、信頼性の低いデータを配信することになります。
| *最小要件* | *推奨* |
| :----------------: | :-----------------: |
| RAMメモリ 64GB | RAMメモリ 128GB |
| CPU 8コア | CPU 16コア |
| CPUベースクロック 3.4GHz | CPUベースクロック 4.0GHz以上 |
| ストレージ 1TB NVMe/SSD | ストレージ 2TB NVMe |
| ネットワーク 1Gbps+ | ネットワーク 1Gbps+ |
**CPUのクロック速度はコア数よりも重要です。** Injectiveのブロック処理は、実行中はほぼシングルスレッドです。低クロックのCPU（例：2.6GHzのクラウドインスタンス）で実行されているノードは、コア数に関係なく、チェーンの先端から常に遅れをとります。
## ストレージ
### ディスクI/O要件
ディスクスループットは、Injectiveノードで最も一般的なボトルネックです。チェーンは約650msごとに、潜在的に大きなトランザクションペイロードを含むブロックを生成するため、持続的に高いIOPSが必要です。
* **ベアメタル：** ローカルNVMeドライブが理想的です。複数のNVMeドライブによるRAID0が最高のスループットを提供します。
* **クラウド（GCP）：** 標準の永続ディスク（`pd-balanced`、`pd-ssd`）は、多くの場合、必要なIOPSを維持できません。チェーンデータディレクトリには**RAID0構成のローカルSSD**を使用してください。ローカルSSDは一時的（ephemeral）ですが、チェーンstateは[スナップショット](https://chain-portal.injective.network/snapshots)から容易に復旧できます。あるいは、IOPSとスループットを明示的にプロビジョニングした`hyperdisk-balanced`または`hyperdisk-extreme`を用意してください。
* **クラウド（AWS）：** プロビジョンドIOPS付きの`io2`または`gp3`ボリュームを使用してください。インスタンスストアNVMe（例：`i3`、`i4i`インスタンス）が最高のパフォーマンスを提供します。
### チェーンデータの増加
Injectiveのチェーンデータは、1日あたり約10〜15 GB増加します。プルーニングされたノードでは、ディスク容量を回収してパフォーマンスを維持するために、300〜400 GBごとに新しいスナップショットから復元することを推奨します。スナップショットのダウンロードリンクについては、[Chain Portalのスナップショットページ](https://portal.injective.network/snapshots)を参照してください。
### プルーニング設定
プルーニングは古いstateを削除してディスク容量を節約しますが、それ自体がCPUとI/Oを大量に消費する処理です。スペック不足のハードウェアでは、プルーニング処理によってノードがチェーンの先端から遅れることがあります。
ノードが遅延しており、ハードウェアの限界が疑われる場合：
* `app.toml`で`pruning = "nothing"`を設定してプルーニングのオーバーヘッドを排除することを検討してください
* 代わりに、定期的にノードを停止してスナップショットから復元することでディスク使用量を管理してください
* ダウンタイムなしの運用には、2つのノードを実行してローリング方式でスナップショット復旧を行ってください
### ストレージレイアウト
本番バリデーターは通常、以下のいずれかの構成で2台のNVMeドライブを運用しています：
| レイアウト | 仕組み | トレードオフ |
| ---------- | ------------------------------------------------------------------------ | --------------------------------------------------------------------------------- |
| **RAID0** | データを固定チャンクで両方のドライブにストライピングします。両方のドライブが並列に読み書きされ、潜在的なIOPSとスループットが2倍になります。 | 冗長性はありません。どちらかのドライブが故障するとアレイ全体が失われます。スナップショットからの完全な復旧が必要です。 |
| **LVMリニア** | ドライブを連結して単一のボリュームにします。1台目のドライブを使い切ってから次のドライブに移ります。並列I/Oによる速度向上はありません。 | 冗長性はありません。どちらかのドライブが故障するとVolume Group全体が壊れ、データベースが破損します。パフォーマンスが単一ドライブの速度に制限されます。 |
どちらのレイアウトも冗長性を提供しませんが、チェーンstateに冗長性は必要ありません。Injectiveのサブ秒ブロックタイム要件を満たすには、RAID0を推奨します。ドライブが故障した場合は、[スナップショット](https://chain-portal.injective.network/snapshots)から復旧してください。
## ベアメタル vs クラウド
バリデーターノードにはベアメタルサーバーを強く推奨します。サブ秒ブロックタイムに必要な安定したCPUクロック速度と低レイテンシのNVMeストレージは、共有クラウドインフラでは保証が困難です。
適切にプロビジョニングされていれば（上記のストレージガイダンスを参照）、非バリデーターノードにはクラウドデプロイも利用できますが、信頼性を維持するために、監視や運用ツールへの投資を多めに見込む必要があります。
### 参考となるクラウドインスタンスタイプ
以下のインスタンスタイプはInjectiveノードでの動作が検証されています。プロビジョニングの際の出発点としてご利用ください。
| プロバイダー | インスタンス | vCPU | RAM | ディスク | 用途 |
| ------- | --------------------- | ------------------------------------------ | ------ | ------------------- | --------------------- |
| **GCP** | `c4-standard-16-lssd` | 16 vCPU（Emerald Rapids） | 64 GB | ローカルSSD（NVMe） | セントリー、RPCノード |
| **OVH** | `b3-32` | 8 vCPU | 32 GB | ローカルSSD | セントリー（バリデーターにはスペック不足） |
| **OVH** | 専用サーバー（例：Advance-1） | 12 vCPU（Xeon E-2386G @3.5GHzまたはEPYC 4244P） | 128 GB | 物理NVMe（RAID0/RAID1） | バリデーター、フルノード |
パフォーマンスのためには、（永続ディスクではなく）ローカルSSDを備えたクラウドインスタンスが不可欠です。標準の永続ディスク（`pd-balanced`、`pd-ssd`）は、Injectiveのブロックスループットに必要なIOPSを維持できません。ローカルSSDは一時的ですが、チェーンstateはスナップショットから復旧可能です。
## ネットワークとピアリング
ノードが同期を維持するには、健全なピアのセットが必要です。特にバリデーターセットの大多数から遠いリージョンでは、ピアリング不足によって断続的な同期遅延が発生することがあります。
* 最低でも**15〜25のアクティブなピア**を維持してください。`curl -s localhost:26657/net_info | jq '.result.n_peers'`で確認できます
* `config.toml`で**persistent peers**を設定し、ノードが常に信頼できる既知の接続を持つようにしてください。コミュニティが管理するピアリストについては、[ピアディスカバリー](/jp/infra/join-a-network#ピアディスカバリー)を参照してください
* Injectiveのピアが少ないリージョン（例：アジア太平洋）のノードは、安定した同期を維持するために追加のpersistent peersが必要になる場合があります
* クラウドプロバイダーでは、より低いレイテンシとより安定したルーティングのために**プレミアムティアのネットワーキング**を使用してください