容量の計画
このドキュメントでは、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やスレッドの一部を他のソフトウェア用に確保する必要がある場合や、オペレーティングシステムから報告される量が不正確な場合など、自動設定がシステムに合わない場合は、この値を明示的に設定できます。(これは一部のコンテナで発生する可能性があります。) .
一般的には、使用可能な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=300000 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
を実行することはできますが、Elastic Block Storage(EBS)は使用しないでください。詳しくはシステム要件をご覧ください。
AWSインスタンスストア(ephemeral
ストレージ)では適切なパフォーマンスが提供されます。しかし、インスタンスを開始/停止するときなど、いくつかの状況でデータが失われる可能性があります。しかし、個々のXRP Ledgerサーバは、通常、失われたレジャーの履歴を他サーバから再取得することができるので、これは許容範囲内でしょう。設定内容は、より信頼性の高いストレージに保存する必要があります。
[node_db]
節のpath
と[database_path]
の両方が、適切なストレージを指していることを確認してください。
RAM/メモリー
メモリー要件は、主にnode_size
構成設定の機能であり、履歴データを取得するクライアントトラフィック量です。メモリー要件についての詳細は、ノードサイズをご覧ください。
ネットワーク
企業や企業レベルのデータセンターでは、XRP Ledgerサーバの稼働をサポートするために、非常に大きなネットワーク帯域幅が必要です。実際に必要な帯域幅は、ネットワークにおける現在のトランザクション量に応じて大きく変わります。サーバの動作(レジャー履歴の埋め戻しなど)もネットワークに影響します。一般的な家庭用インターネットでは、信頼性の高いサーバを稼働させるには不十分です。
トランザクション量が非常に多い時期には、サーバが100メガビット/秒のネットワークリンクを完全に飽和してしまうという報告を受けた事業者もあります。そのため、信頼性の高いパフォーマンスを実現するためには、ギガビット・ネットワーク・インターフェースが必要となります。
以下は、一般的なタスクで使用されるネットワーク帯域幅の例です。
タスク | 転送量/受信量 |
---|---|
現在のトランザクション量を処理する | 2Mbpsの転送、2Mbpsの受信 |
ピーク時のトランザクション量を処理 | 100Mbps以上の転送 |
履歴レジャーとトランザクションレポートを提供する | 100Mbps以上の転送 |
rippled の起動 | 20Mbpsの受信 |
P2P通信で圧縮を有効にすることで帯域幅を節約することができますが、その代償としてCPU使用率が高くなります。多くのハードウェア構成では、通常の使用時にはCPUの容量に余裕があるため、ネットワークの帯域幅が限られている場合には、この方法が経済的な選択肢となります。
関連項目
- コンセプト:
- チュートリアル:
rippled
の構成- オンライ削除の設定 - サーバが一度に保持するレジャー履歴のバージョン数を調整します。
rippled
のトラブルシューティング
- リファレンス:
- rippled APIリファレンス
rippled
コマンドラインの使用- logrotate メソッド - サーバのデバッグログを閉じたり再開したりして、標準的なツールでローテーション可能にします。
- server_info メソッド - 同期の状態や、ディスク上で利用可能なレジャー履歴のバージョン数など、サーバに関する一般的な情報を取得します。
- get_counts メソッド - 追加のサーバの正常情報、特にRAM内に様々な種類のオブジェクトをいくつ保持しているかを取得します。
- rippled APIリファレンス