バリデーターノード
バリデーターノードはコンセンサスに参加するため、ジェイルを回避するには安定したパフォーマンスを維持する必要があります。ベアメタルサーバーの利用を強く推奨します。本番バリデーターの参考構成
参考として、Injectiveメインネットの本番バリデーターは、通常以下の範囲のハードウェアを運用しています：
ブロック処理においては、コア数よりも高いシングルスレッド性能（ブーストクロック）の方が重要です。ネットワーク要件は、仕様表に記載された最低1 Gbpsを大きく上回っています。本番バリデーターは、安定したピア接続と高速なブロック伝播のために、10 Gbps以上の回線の恩恵を受けられます。
RPCノード
ライブのチェーンデータを配信する非バリデーターノードにも同様の要件があります。スラッシングのリスクはありませんが、スペック不足のノードはチェーンの先端から遅れ、信頼性の低いデータを配信することになります。ストレージ
ディスクI/O要件
ディスクスループットは、Injectiveノードで最も一般的なボトルネックです。チェーンは約650msごとに、潜在的に大きなトランザクションペイロードを含むブロックを生成するため、持続的に高いIOPSが必要です。- ベアメタル： ローカルNVMeドライブが理想的です。複数のNVMeドライブによるRAID0が最高のスループットを提供します。
- クラウド（GCP）： 標準の永続ディスク（
pd-balanced、pd-ssd）は、多くの場合、必要なIOPSを維持できません。チェーンデータディレクトリにはRAID0構成のローカルSSDを使用してください。ローカルSSDは一時的（ephemeral）ですが、チェーンstateはスナップショットから容易に復旧できます。あるいは、IOPSとスループットを明示的にプロビジョニングしたhyperdisk-balancedまたはhyperdisk-extremeを用意してください。 - クラウド（AWS）： プロビジョンドIOPS付きの
io2またはgp3ボリュームを使用してください。インスタンスストアNVMe（例：i3、i4iインスタンス）が最高のパフォーマンスを提供します。
チェーンデータの増加
Injectiveのチェーンデータは、1日あたり約10〜15 GB増加します。プルーニングされたノードでは、ディスク容量を回収してパフォーマンスを維持するために、300〜400 GBごとに新しいスナップショットから復元することを推奨します。スナップショットのダウンロードリンクについては、Chain Portalのスナップショットページを参照してください。プルーニング設定
プルーニングは古いstateを削除してディスク容量を節約しますが、それ自体がCPUとI/Oを大量に消費する処理です。スペック不足のハードウェアでは、プルーニング処理によってノードがチェーンの先端から遅れることがあります。 ノードが遅延しており、ハードウェアの限界が疑われる場合：app.tomlでpruning = "nothing"を設定してプルーニングのオーバーヘッドを排除することを検討してください- 代わりに、定期的にノードを停止してスナップショットから復元することでディスク使用量を管理してください
- ダウンタイムなしの運用には、2つのノードを実行してローリング方式でスナップショット復旧を行ってください
ストレージレイアウト
本番バリデーターは通常、以下のいずれかの構成で2台のNVMeドライブを運用しています：
どちらのレイアウトも冗長性を提供しませんが、チェーンstateに冗長性は必要ありません。Injectiveのサブ秒ブロックタイム要件を満たすには、RAID0を推奨します。ドライブが故障した場合は、スナップショットから復旧してください。
ベアメタル vs クラウド
バリデーターノードにはベアメタルサーバーを強く推奨します。サブ秒ブロックタイムに必要な安定したCPUクロック速度と低レイテンシのNVMeストレージは、共有クラウドインフラでは保証が困難です。 適切にプロビジョニングされていれば（上記のストレージガイダンスを参照）、非バリデーターノードにはクラウドデプロイも利用できますが、信頼性を維持するために、監視や運用ツールへの投資を多めに見込む必要があります。参考となるクラウドインスタンスタイプ
以下のインスタンスタイプはInjectiveノードでの動作が検証されています。プロビジョニングの際の出発点としてご利用ください。パフォーマンスのためには、（永続ディスクではなく）ローカル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を設定し、ノードが常に信頼できる既知の接続を持つようにしてください。コミュニティが管理するピアリストについては、ピアディスカバリーを参照してください- Injectiveのピアが少ないリージョン（例：アジア太平洋）のノードは、安定した同期を維持するために追加のpersistent peersが必要になる場合があります
- クラウドプロバイダーでは、より低いレイテンシとより安定したルーティングのためにプレミアムティアのネットワーキングを使用してください