# 容量の計画

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

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

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

## 構成設定

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

本セクションでの設定は、`rippled.cfg`ファイルのパラメータです。設定ファイルの例である `rippled-example.cfg` は、`rippled` GitHubリポジトリ の [`cfg` ディレクトリ](https://github.com/XRPLF/rippled/blob/develop/cfg/rippled-example.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`パラメーターを無効な値に設定すると、[サーバは起動しません](/ja/docs/infrastructure/troubleshooting/server-wont-start#node_size%E3%81%AE%E5%80%A4%E3%81%8C%E6%AD%A3%E3%81%97%E3%81%8F%E3%81%AA%E3%81%84)。

### ノードDBタイプ

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

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

- ほとんどのケースにおいて、ディスクのデータが膨大であってもパフォーマンスが一貫している`NuDB`を使用します。高速のSSDが必要です。[詳細はこちらをご覧ください。](#nudb%E3%81%AE%E4%BD%BF%E7%94%A8%E3%81%AE%E8%A9%B3%E7%B4%B0)
- HDD（非推奨）や、単に遅いSSDを使用している場合でも、`RocksDB`を使用してください。本番サーバではこの設定は避けるべきです。[詳細はこちらをご覧ください。](#rocksdb%E3%81%AE%E4%BD%BF%E7%94%A8%E3%81%AE%E8%A9%B3%E7%B4%B0)


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

#### RocksDBの使用の詳細

[RocksDB](https://rocksdb.org/docs/getting-started.html)は、組み込み可能で永続的なkey-valueストアです。

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

RocksDBは、SSDまたはHHDでの動作を想定しています。RocksDBは、NuDBに比べて必要とする[ディスク容量](#%E3%83%87%E3%82%A3%E3%82%B9%E3%82%AF%E5%AE%B9%E9%87%8F)が約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](https://github.com/vinniefalco/nudb#introduction)は、SSDドライブ用に最適化された追加専用のkey-valueストアです。

NuDBは、[格納されているデータ量に関係なく](#%E3%83%87%E3%82%A3%E3%82%B9%E3%82%AF%E5%AE%B9%E9%87%8F)、ほぼ一定したパフォーマンスとメモリーフットプリントを提供します。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ネットワーク全体で一貫した優れたパフォーマンスを実現するために役立ちます。

### 推奨事項

推奨されるハードウェアのスペックをまとめたものは、[システム要件](/ja/docs/infrastructure/installation/system-requirements)をご覧ください

#### CPU使用率および仮想化

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

#### ディスク速度

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

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


#### ディスク容量

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

保持するデータ量は、[オンライン削除](/ja/docs/infrastructure/configuration/data-retention/online-deletion)で管理できます。デフォルトの構成ファイルの設定では、サーバは最新の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倍を格納できるほどの十分な容量を計画する必要があります。

保持する履歴量の変更方法については、[オンライン削除の設定](/ja/docs/infrastructure/configuration/data-retention/configure-online-deletion)をご覧ください。

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

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

##### Amazon Web Services

Amazon Web Services（AWS）は、人気のある仮想化ホスト環境です。AWSで`rippled`を実行することはできますが、Elastic Block Storage（EBS）は使用しないでください。詳しくは[システム要件](/ja/docs/infrastructure/installation/system-requirements)をご覧ください。

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

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

#### RAM/メモリー

メモリー要件は、主に`node_size`構成設定の機能であり、履歴データを取得するクライアントトラフィック量です。メモリー要件についての詳細は、[ノードサイズ](#%E3%83%8E%E3%83%BC%E3%83%89%E3%82%B5%E3%82%A4%E3%82%BA)をご覧ください。

#### ネットワーク

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

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

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

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


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

## 関連項目

- **コンセプト:**
  - [`rippled`サーバ](/ja/docs/concepts/networks-and-servers)
  - [コンセンサスについて](/ja/docs/concepts/consensus-protocol)
- **チュートリアル:**
  - [`rippled`の構成](/ja/docs/infrastructure/configuration)
    - [オンライ削除の設定](/ja/docs/infrastructure/configuration/data-retention/configure-online-deletion) - サーバが一度に保持するレジャー履歴のバージョン数を調整します。
  - [`rippled`のトラブルシューティング](/ja/docs/infrastructure/troubleshooting)
- **リファレンス:**
  - [rippled APIリファレンス](/ja/docs/references/http-websocket-apis)
    - [`rippled`コマンドラインの使用](/ja/docs/infrastructure/commandline-usage)
      - [logrotateメソッド](/ja/docs/references/http-websocket-apis/admin-api-methods/logging-and-data-management-methods/logrotate) - サーバのデバッグログを閉じたり再開したりして、標準的なツールでローテーション可能にします。
      - [server_infoメソッド](/ja/docs/references/http-websocket-apis/public-api-methods/server-info-methods/server_info) - 同期の状態や、ディスク上で利用可能なレジャー履歴のバージョン数など、サーバに関する一般的な情報を取得します。
      - [get_countsメソッド](/ja/docs/references/http-websocket-apis/admin-api-methods/status-and-debugging-methods/get_counts) - 追加のサーバの正常情報、特にRAM内に様々な種類のオブジェクトをいくつ保持しているかを取得します。