容量の計画

このドキュメントでは、XRP Ledgerサーバーのパフォーマンスを調整・最適化するために使用できる、構成、ネットワーク、ハードウェアに関する推奨事項を説明しています。

XRP Ledgerのサーバーの負荷は、複数の要因によって変化します。ひとつは、ネットワーク内の活動です。共有レジャーのデータサイズや送信されるトランザクションの総量は、グローバルなXRP Ledgerコミュニティ全体の有機的な要因に基づいて変化します。もうひとつの要因は、APIの使用状況です。異なる種類のAPIコールは、サーバーに異なる負荷をかけます。パブリックなAPIを提供しているサーバーと、特定の統合ソフトウェアにプライベートなAPIを提供しているサーバー、あるいはAPIを全く提供していないサーバーとでは、パフォーマンス特性が大きく異なります。

これらの要素を考慮して、構成するサーバーが現在および将来のXRP Ledgerネットワークの活動を処理する能力を持っていることを確認する必要があります。

構成設定

デフォルトの設定ファイルには、一般的なユースケースを幅広くカバーする設定が含まれています。お使いのハードウェアや使用目的に合わせて設定をカスタマイズすることで、より良いパフォーマンスを得ることができます。

本セクションでの設定は、rippled.cfgファイルのパラメータです。設定ファイルの例である rippled-example.cfg は、rippled GitHubリポジトリ の cfg ディレクトリ からアクセスできます。サンプル設定ファイルの設定は、サーバーと一緒にインストールされたデフォルトの設定と一致しています。

ノードサイズ

[node_size]パラメータは、サーバのハードウェア全体の容量を反映する必要があります。このパラメータを省略すると、システムの総RAMとCPUスレッド数に基づいて、サーバが自動的に適切な設定を選択します。システムのRAMやスレッドの一部を他のソフトウェア用に確保する必要がある場合や、オペレーティングシステムから報告される量が不正確な場合など、自動設定がシステムに合わない場合は、この値を明示的に設定できます。(これは一部のコンテナで発生する可能性があります。) 更新: rippled 1.8.1 .

一般的には、使用可能なRAMがサポートする最大のノードサイズを常に使用する必要があります。推奨される設定については、以下の表を参照してください。

推奨事項

それぞれの[node_size]には、それに対応する利用可能なRAMの要件があります。例えば、[node_size]をhugeに設定した場合、rippledがスムーズに動作するためには、最低でも32GBの利用可能なRAMが必要です。

サーバーを調整するために、まずtinyから初め、ユースケースの要件に合わせてサイズを徐々にsmall、mediumと増やしていくと便利です。

rippledで使用できるRAM node_size 値 注記
8GB未満 tiny 非推奨 この設定をしたサーバーは、ビジー状態のネットワークに同期しないことがあります。
8GB small テストサーバーに推奨。
16GB medium rippled-example.cfgファイルではこの値が使用されます。
32GB large 非推奨 実際には、この設定はほとんどの状況で huge よりもパフォーマンスが低下します。安定性を求めるのであれば、常に huge を使用してください。
64GB huge 実稼働サーバーに推奨。

node_sizeパラメーターを無効な値に設定すると、サーバーは起動しません。

ノードDBタイプ

rippled.cfgファイルの[node_db]節のtypeフィールドでは、レジャーストアを保持するためにrippledで使用されるkey-valueストアのタイプを設定します。

この設定は、直接RAM設定を構成するわけではありませんが、key-valueストアの選択はRAMの使用に大きな影響をもたらします。これは、テクノロジーによって、高速検索のためにデータをキャッシュし、インデックス付けする方法が異なるためです。

  • ほとんどのケースにおいて、ディスクのデータが膨大であってもパフォーマンスが一貫しているNuDBを使用します。高速のSSDが必要です。詳細はこちらをご覧ください。

  • HDD（非推奨）や、単に遅いSSDを使用している場合でも、RocksDBを使用してください。本番サーバーではこの設定は避けるべきです。詳細はこちらをご覧ください。

サンプルのrippled-example.cfgファイルでは、[node_db]節のtypeフィールドがNuDBに設定されています。

RocksDBの使用の詳細

RocksDB は、組み込み可能で永続的なkey-valueストアです。

注記： 2021年後半、元帳の総サイズが大きくなったため、RocksDBを使用しているサーバーはメインネットとの同期を十分に維持できないことがありました。大容量のRAMがあれば問題ありませんが、通常はNuDBを使用してください。

RocksDBは、SSDまたはHHDでの動作を想定しています。RocksDBは、NuDBに比べて必要とするディスク容量が約3分の1少なくてすみ、I/O待ち時間が削減されます。ただし、I/O待ち時間が短い半面、データインデックスを格納するために、RocksDBは大量のRAMを必要とします。

RocksDBには、トランザクション処理のスループットを向上させるために調整できるパフォーマンス関連の設定オプションがあります。以下は、RocksDBを使用するrippledの推奨構成です。

[node_db]
type=RocksDB
path=/var/lib/rippled/db/rocksdb
open_files=512
filter_bits=12
cache_mb=512
file_size_mb=64
file_size_mult=2
online_delete=2000
advisory_delete=0

（pathを、ディスク上でレジャーを維持するディレクトリーに設定します。online_deleteとadvisory_deleteをお使いの構成に合わせて調整します。）

NuDBの使用の詳細

NuDB は、SSDドライブ用に最適化された追加専用のkey-valueストアです。

NuDBは、格納されているデータ量に関係なく、ほぼ一定したパフォーマンスとメモリーフットプリントを提供します。NuDBはSSDを 必要とします が、大容量のデータベースにアクセスするために使用するRAMがRocksDBよりも大幅に少なくなっています。

本番サーバーは、NuDBを使用してユースケースに必要な履歴データ量を格納するように構成する必要があります。

NuDBには、rippled.cfgにパフォーマンス関連の構成オプションがありません。以下は、NuDBを使用するrippledにおける[node_db]の推奨構成です。

[node_db]
type=NuDB
path=/var/lib/rippled/db/nudb
online_delete=2000
advisory_delete=0

（pathを、ディスク上でレジャーを維持するディレクトリーに設定します。online_deleteとadvisory_deleteをお使いの構成に合わせて調整します。）

ログレベル

サンプルのrippled-example.cfgファイルの[rpc_startup]節では、ロギング詳細レベルがwarningに設定されています。この設定を使用すると、より詳細なログ比べ、ディスク容量とI/O要件が大幅に緩和されます。ただし、より詳細なログレベルを設定すると、トラブルシューティングの際により細かな情報が得られます。

注意: [rpc_startup]節でlog_levelコマンドを省略すると、サーバーはdebugレべルでディスクにログを書き込み、warningレベルのログをコンソールに出力します。 debug レベルのログは、warningレベルに比べ、トランザクション量とクライアントアクティビティーに基づいて、一日当たりに必要なディスク容量が数GB多くなります。

ネットワークとハードウェア

XRP Ledgerネットワークの各サーバーは、ネットワークのすべての取引処理作業を行います。ネットワーク上の総活動量は変動しますが、ほとんどが時間の経過とともに増加していますので、現在のネットワーク活動に必要な容量よりも大きな容量のハードウェアを選択する必要があります。

rippledサーバーが、これらのネットワーク要件とハードウェア要件を満たすようにすることは、XRP Ledgerネットワーク全体で一貫した優れたパフォーマンスを実現するために役立ちます。

推奨事項

推奨されるハードウェアのスペックをまとめたものは、システム要件をご覧ください

CPU使用率および仮想化

ベアメタルを使用するとパフォーマンスが最大になりますが、ホストのハードウェアの仕様が十分であれば、仮想マシンでもほぼ同様のパフォーマンスが得られます。

ディスク速度

ストレージの速度は、サーバーの容量を左右する重要な要素の1つです。待ち時間の少ないランダム読み取りと高いスループットを備えた、グレードの高いソリッドステートディスク（SSD）の使用を 強くお勧めします。 Rippleのエンジニアにより、以下の最大読み取り速度（秒）と書き込み速度（秒）が測定されています。

  • （使用率が高いパブリックサーバークラスターで）秒あたり10,000回の読み取り
  • （専用のパフォーマンステストで）秒あたり7,000回の書き込み

ディスク容量

[node_db]節はサーバの_レジャーの保存容量_を制御し、レジャーの履歴を保持します。必要なディスク容量は、どの程度の履歴をローカルに保存するかによって決まります。XRP Ledgerサーバーは、コンセンサス・プロセスを追跡し、レジャーの完全な状態を報告するために、最新の256以上のレジャーバージョンを保存する必要はありません。ただし、サーバーで照会できる実行済みトランザクションは、ローカルで保存されたレジャーバージョンにあるものだけです。[node_db]のpathを設定して、レジャーの保存場所を決めてください。

保持するデータ量は、オンライン削除で管理できます。デフォルトの構成ファイルの設定では、サーバーは最新の2000のレジャーバージョンを保持します。オンライン削除を使用しないと、サーバーのディスク要件が際限なく増え続けます。

以下のテーブルは、本書の執筆時点（2018年12月13日）における、様々な履歴量の要件をまとめたものです。

実際の時間 レジャーバージョンの数 必要なディスク容量（RocksDB） 必要なディスク容量（NuDB）
2時間 2,000 250MB 450MB
1日 25,000 8GB 12GB
14日 350,000 112GB 168GB
30日 750,000 240GB 360GB
90日 2,250,000 720GB 1TB
1年 10,000,000 3TB 4.5TB
2年 20,000,000 6TB 9TB
完全な履歴（2020-11-10まで） 59,000,000+ （非推奨） ~14TB

これらの数値は概算です。様々な要因によって変わりますが、最も重要なのはネットワーク内のトランザクション量です。トランザクション量が増えるにつれ、各レジャーバージョンはより多くの固有データを格納します。今後の拡大に備え、予備のストレージ容量を準備しておくことをお勧めします。

online_delete設定は、古い履歴の削除後に保持するレジャーバージョンの数を指定するものです。オンライン削除が実行される直前レジャーの最大数の2倍を格納できるほどの十分な容量を計画する必要があります。

保持する履歴量の変更方法については、オンライン削除の設定を参照してください。

[database_path]では、個別のデータベースを設定します。これらには、トランザクションデータといくつかのランタイム設定が含まれます。

一般的なルールとして、実行されていないrippledサーバーのデータベースファイル（レジャーストアとデータベースの両方）を安全に削除することができます。これにより、サーバーに保存されているレジャーの履歴はすべて消去されますが、そのデータをネットワークから再取得することができます。ただし、[database_path]にあるwallet.dbファイルを削除すると、Amendment 投票やピアリザベーションなどのランタイムの設定変更を手動で再適用しなければなりません。

レジャー履歴を格納したくても、全履歴を格納するための十分な容量がない場合には、履歴シャーディング機能を使用して個別の共有ストアにランダムな範囲のレジャーを格納できます。履歴シャーディングは、[shard_db]節で構成されます。

Amazon Web Services

Amazon Web Services（AWS）は、人気のある仮想化ホスト環境です。AWSでrippledを実行することはできますが、RippleではElastic Block Storage（EBS）の使用はお勧めしません。Elastic Block Storageの最大IOPS数（5,000）は、非常に高額であるにもかかわらず、rippledの最大負荷には不十分です。

AWSインスタンスストア（ephemeralストレージ）では適切なパフォーマンスが提供されます。しかし、インスタンスを開始/停止するときなど、いくつかの状況でデータが失われる可能性があります。しかし、個々のXRP Ledgerサーバーは、通常、失われたレジャーの履歴を他サーバーから再取得することができるので、これは許容範囲内でしょう。設定内容は、より信頼性の高いストレージに保存する必要があります。

[node_db]節のpathと[database_path]の両方が、適切なストレージを指していることを確認してください。

RAM/メモリー

メモリー要件は、主にnode_size構成設定の機能であり、履歴データを取得するクライアントトラフィック量です。メモリー要件についての詳細は、ノードサイズを参照してください。

ネットワーク

企業や企業レベルのデータセンターでは、XRP Ledgerサーバーの稼働をサポートするために、非常に大きなネットワーク帯域幅が必要です。実際に必要な帯域幅は、ネットワークにおける現在のトランザクション量に応じて大きく変わります。サーバーの動作（レジャー履歴の埋め戻しなど）もネットワークに影響します。一般的な家庭用インターネットでは、信頼性の高いサーバーを稼働させるには不十分です。

トランザクション量が非常に多い時期には、サーバーが100メガビット/秒のネットワークリンクを完全に飽和してしまうという報告を受けた事業者もあります。そのため、信頼性の高いパフォーマンスを実現するためには、ギガビット・ネットワーク・インターフェースが必要となります。

以下は、一般的なタスクで使用されるネットワーク帯域幅の例です。

タスク 転送量/受信量
現在のトランザクション量を処理する 2Mbpsの転送、2Mbpsの受信
ピーク時のトランザクション量を処理 100Mbps以上の転送
履歴レジャーとトランザクションレポートを提供する 100Mbps以上の転送
rippledの起動 20Mbpsの受信

P2P通信で圧縮を有効にすることで帯域幅を節約することができますが、その代償としてCPU使用率が高くなります。多くのハードウェア構成では、通常の使用時にはCPUの容量に余裕があるため、ネットワークの帯域幅が限られている場合には、この方法が経済的な選択肢となります。

関連項目