容量の計画

このセクションでは、お使いのrippledサーバーのパフォーマンスを調整し、最適化するために使用できる、構成、ネットワーク、ハードウェアの推奨事項について説明します。これらの考慮事項を知っておくことにより、XRP Ledgerネットワークの現在および将来の容量を処理できるよう、お使いのrippledサーバーを準備するために役立ちます。

構成設定

Rippleでは、rippledサーバーのリソース利用およびパフォーマンスを最適化するために、これらの構成ガイドラインを使用することをお勧めします。

rippled.cfgファイルで、rippledサーバーに使用する次のパラメーターを設定できます。サンプルの構成ファイルrippled-example.cfgは、rippled GitHubリポジトリのcfgディレクトリー にあります。

ノードサイズ

サーバーで予測される負荷と、rippledで使用できるメモリ量に基づいてnode_sizeを設定します。

Rippleでは、お使いのRAMでサポートできる最大のノードサイズを常に使用することをお勧めします。以下の表は推奨設定をまとめたものです。

推奨事項

各node_sizeには、それに対応する使用可能なRAMの要件があります。例えば、node_sizeをhugeに設定すると、rippledがスムーズに稼働できるようにするため、最低でも32GBのRAMが必要です。

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

largeも[node_size]の値として有効ですが、実際に使用するとほとんどの環境でhugeよりもパフォーマンスが悪くなります。Rippleでは、largeの代わりに、常にhugeを使用することを推奨します。

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

ノードDBタイプ

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

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

この値は、RocksDBまたはNuDBに設定できます。

• サーバーがバリデーターの場合には、必要とされる履歴の量が少ないため、最良のパフォーマンスを得るためにRocksDBを使用します。詳細はこちらをご覧ください。

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

• 回転ディスク（非推奨）や、単に遅いSSDを使用している場合でも、RocksDBを使用してください。詳細はこちらをご覧ください。

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

RocksDBの使用の詳細

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

RocksDBは、ソリッドステートディスクに最適です。回転式ディスクと共に使用した場合、RocksDBはパフォーマンスの点でNuDBよりも優れていますが、ソリッドステートディスクを使用しない限りパフォーマンス上の問題が発生する可能性があります。

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

RocksDBを使用するようにバリデーターを構成し、レジャーストアに最大30万件（約2週間分に相当する履歴データ）までのレジャーを格納するように設定する必要があります。

最大のトランザクション処理スループットを達成するため、RocksDBには、rippled.cfgで設定できるパフォーマンス関連の構成オプションがあります。以下は、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はソリッドステートドライブを 必要とします が、大容量のデータベースにアクセスするために使用するRAMがRocksDBよりも大幅に少なくなっています。

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

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

[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コマンドを省略すると、rippledはdebugレべルでディスクにログを書き込み、warningレベルのログをコンソールに出力します。 debug レベルのログは、warningレベルに比べ、トランザクション量とクライアントアクティビティーに基づいて、一日当たりに必要なディスク容量が数GB多くなります。

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

XRP Ledgerネットワーク内の各rippledサーバーは、ネットワークのすべてのトランザクション処理を実行します。このため、実稼働用rippledサーバーのベースラインハードウェアはRippleのパフォーマンステスト で使用されるものと類似している必要があります。

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

推奨事項

企業の本番環境で最良のパフォーマンスを実現するため、Rippleでは、以下の仕様のベアメタルでrippledを実行することを推奨しています。

• オペレーティングシステム: Ubuntu 16.04以上
• CPU: Intel Xeon 3以上、GHzプロセッサー、4コア、ハイパースレッディング有効
• ディスク速度: SSD（7000回以上の書き込み/秒、10,000回以上の読み取り/秒）
• ディスク容量: 場合により異なる。最低50GBを推奨。
• RAM: 32GB
• ネットワーク: ホスト上にギガビットネットワークインターフェイスを備える企業データセンターネットワーク

CPU使用率および仮想化

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

ディスク速度

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

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

ディスク容量

rippledが必要とするディスク容量は、ローカルで維持する予定のレジャー履歴の量によって異なります。コンセンサスプロセスに従い、レジャー全体の状態を報告するには、rippledサーバーは最新の256のレジャーバージョンのみを格納する必要があります。ただし、サーバーで照会できる実行済みトランザクションは、ローカルで保存されたレジャーバージョンにあるものだけです。

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

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

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

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

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

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

Amazon Web Services

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

AWSインスタンスストア（ephemeralストレージ）にはこのような制約はありません。このため、Rippleでは、インスタンスストレージを備えるM3などのホストタイプのrippledサーバーをデプロイすることをお勧めします。database_pathパスとnode_dbパスの両方がインスタンスストレージに存在する必要があります。

注意: AWSインスタンスストレージは、ハードドライブが故障した場合に、必ずしもデータの保護を保証しません。また、インスタンスを停止、開始、またはリブートした場合にもデータが失われます。通常、個々のサーバーは失われたデータをピアサーバーから再取得できるため、後者のタイプのデータ損失はrippledサーバーでは容認できます。

RAM/メモリー

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

ネットワーク

あらゆる企業または通信事業者クラスのデータセンターでは、rippledサーバーの実行をサポートするため、非常に大きなネットワーク帯域幅が必要です。

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