ARCHIVE/xrpl-dev-portal
1
0
Fork 0
mirror of https://github.com/XRPLF/xrpl-dev-portal.git synced 2025-11-20 19:55:54 +00:00
Code Issues Packages Projects Releases Wiki Activity

support commi f0945c3560, commit aa32eae473

Browse Source
This commit is contained in:
develoQ
2021-12-08 23:30:38 +09:00
parent 57fd8106c2
commit f46c987b8a
2 changed files with 84 additions and 65 deletions
Download Patch File Download Diff File Expand all files Collapse all files

118
content/tutorials/manage-the-rippled-server/installation/capacity-planning.ja.md
View File

@@ -8,68 +8,65 @@ labels:
---
# 容量の計画
このセクションでは、お使いの`rippled`サーバーのパフォーマンスを調整し、最適化するために使用できる、構成、ネットワーク、ハードウェアの推奨事項について説明します。これらの考慮事項を知っておくことにより、XRP Ledgerネットワークの現在および将来の容量を処理できるよう、お使いの`rippled`サーバーを準備するために役立ちます。
このドキュメントでは、XRP Ledgerサーバーのパフォーマンスを調整・最適化するために使用できる、構成、ネットワーク、ハードウェアに関する推奨事項を説明しています。
XRP Ledgerのサーバーの負荷は、複数の要因によって変化します。ひとつは、ネットワーク内の活動です。共有レジャーのデータサイズや送信されるトランザクションの総量は、グローバルなXRP Ledgerコミュニティ全体の有機的な要因に基づいて変化します。もうひとつの要因は、APIの使用状況です。異なる種類の[APIコール](rippled-api.html)は、サーバーに異なる負荷をかけます。パブリックなAPIを提供しているサーバーと、特定の統合ソフトウェアにプライベートなAPIを提供しているサーバー、あるいはAPIを全く提供していないサーバーとでは、パフォーマンス特性が大きく異なります。
これらの要素を考慮して、構成するサーバーが現在および将来のXRP Ledgerネットワークの活動を処理する能力を持っていることを確認する必要があります。
## 構成設定
Rippleでは、`rippled`サーバーのリソース利用およびパフォーマンスを最適化するために、これらの構成ガイドラインを使用することをお勧めします。
デフォルトの設定ファイルには、一般的なユースケースを幅広くカバーする設定が含まれています。お使いのハードウェアや使用目的に合わせて設定をカスタマイズすることで、より良いパフォーマンスを得ることができます。
`rippled.cfg`ファイルで、`rippled`サーバーに使用する次のパラメーターを設定できます。サンプルの構成ファイル`rippled-example.cfg`は、`rippled` GitHubリポジトリの[`cfg`ディレクトリー](https://github.com/ripple/rippled/blob/develop/cfg/rippled-example.cfg)にあります。
本セクションでの設定は、`rippled.cfg`ファイルのパラメータです。設定ファイルの例である `rippled-example.cfg` は、`rippled` GitHubリポジトリ の [`cfg` ディレクトリ](https://github.com/ripple/rippled/blob/develop/cfg/rippled-example.cfg)からアクセスできます。サンプル設定ファイルの設定は、サーバーと一緒にインストールされたデフォルトの設定と一致しています。
### ノードサイズ
サーバーで予測される負荷と、`rippled`で使用できるメモリ量に基づいて`node_size`を設定します。
`[node_size]`パラメータは、サーバのハードウェア全体の容量を反映する必要があります。このパラメータを省略すると、システムの総RAMとCPUスレッド数に基づいて、サーバが自動的に適切な設定を選択します。システムのRAMやスレッドの一部を他のソフトウェア用に確保する必要がある場合や、オペレーティングシステムから報告される量が不正確な場合など、自動設定がシステムに合わない場合は、この値を明示的に設定できます。(これは一部のコンテナで発生する可能性があります。) [更新: rippled 1.8.1][].
Rippleでは、お使いのRAMでサポートできる最大のノードサイズを常に使用することをお勧めします。以下の表は推奨設定をまとめたものです。
一般的には、使用可能なRAMがサポートする最大のノードサイズを常に使用する必要があります。推奨される設定については、以下の表を参照してください。
#### 推奨事項
各`node_size`には、それに対応する使用可能なRAMの要件があります。例えば、`node_size`を`huge`に設定すると、`rippled`がスムーズに稼働できるようにするため、最低でも32GBのRAMが必要です。
それぞれの`[node_size]`には、それに対応する利用可能なRAMの要件があります。例えば、`[node_size]`を`huge`に設定した場合、`rippled`がスムーズに動作するためには、最低でも32GBの利用可能なRAMが必要です。
サーバーを調整するために、まず`tiny`から初め、ユースケースの要件に合わせてサイズを徐々に`small`、`medium`と増やしていくと便利です。
| `rippled`で使用できるRAM | `node_size` 値 | 注記 |
| `rippled`で使用できるRAM | `node_size` 値 | 注記 |
|:----------------------------|:------------------|:---------------------------|
| 8GB未満 | `tiny` | テストサーバーにも実稼働サーバーにも推奨できません。`rippled.cfg`で値を指定しないと、これがデフォルト値になります。 |
| 8GB未満 | `tiny` | **非推奨** この設定をしたサーバーは、ビジー状態のネットワークに同期しないことがあります。 |
| 8GB | `small` | テストサーバーに推奨。 |
| 16GB | `medium` | `rippled-example.cfg`ファイルではこの値が使用されます。 |
| 32GB | `huge` | 実稼働サーバーに推奨。 |
`large`も`[node_size]`の値として有効ですが、実際に使用するとほとんどの環境で`huge`よりもパフォーマンスが悪くなります。Rippleでは、`large`の代わりに、常に`huge`を使用することを推奨します。
| 32GB | `large` | **非推奨** 実際には、この設定はほとんどの状況で `huge` よりもパフォーマンスが低下します。安定性を求めるのであれば、常に `huge` を使用してください。 |
| 64GB | `huge` | 実稼働サーバーに推奨。 |
`node_size`パラメーターを無効な値に設定すると、[サーバーは起動しません](server-wont-start.html#node_sizeの値が正しくない)。
### ノードDBタイプ
`rippled.cfg`ファイルの`[node_db]`スタンザの`type`フィールドでは、レジャーストアを保持するために`rippled`で使用されるkey-valueストアのタイプを設定します。
`rippled.cfg`ファイルの`[node_db]`節の`type`フィールドでは、レジャーストアを保持するために`rippled`で使用されるkey-valueストアのタイプを設定します。
この設定は、直接RAM設定を構成するわけではありませんが、key-valueストアの選択はRAMの使用に大きな影響をもたらします。これは、テクノロジーによって、高速検索のためにデータをキャッシュし、インデックス付けする方法が異なるためです。
この値は、`RocksDB`または`NuDB`に設定できます。
- サーバーがバリデーターの場合には、必要とされる履歴の量が少ないため、最良のパフォーマンスを得るために`RocksDB`を使用します。[詳細はこちらをご覧ください。](#rocksdbの使用の詳細)
- ほとんどのケースにおいて、ディスクのデータが膨大であってもパフォーマンスが一貫している`NuDB`を使用します。高速のSSDが必要です。[詳細はこちらをご覧ください。](#nudbの使用の詳細)
- 回転ディスク（非推奨）や、単に遅いSSDを使用している場合でも、`RocksDB`を使用してください。[詳細はこちらをご覧ください。](#rocksdbの使用の詳細)
- HDD（非推奨）や、単に遅いSSDを使用している場合でも、`RocksDB`を使用してください。本番サーバーではこの設定は避けるべきです。[詳細はこちらをご覧ください。](#rocksdbの使用の詳細)
サンプルの`rippled-example.cfg`ファイルでは、`[node_db]`スタンザの`type`フィールドが`RocksDB`に設定されています。
サンプルの`rippled-example.cfg`ファイルでは、`[node_db]`節の`type`フィールドが`NuDB`に設定されています。
#### RocksDBの使用の詳細
[RocksDB](https://rocksdb.org/docs/getting-started.html)は、組み込み可能で永続的なkey-valueストアです。
RocksDBは、ソリッドステートディスクに最適です。回転式ディスクと共に使用した場合、RocksDBはパフォーマンスの点でNuDBよりも優れていますが、ソリッドステートディスクを使用しない限りパフォーマンス上の問題が発生する可能性があります。
**注記：** 2021年後半、元帳の総サイズが大きくなったため、RocksDBを使用しているサーバーはメインネットとの同期を十分に維持できないことがありました。大容量のRAMがあれば問題ありませんが、通常はNuDBを使用してください。
RocksDBは、NuDBに比べて必要とする[ディスク容量](#ディスク容量)が約3分の1少なくてすみ、I/O待ち時間が削減されます。ただし、I/O待ち時間が短い半面、データインデックスを格納するために、RocksDBは大量のRAMを必要とします。
RocksDBは、SSDまたはHHDでの動作を想定しています。RocksDBは、NuDBに比べて必要とする[ディスク容量](#ディスク容量)が約3分の1少なくてすみ、I/O待ち時間が削減されます。ただし、I/O待ち時間が短い半面、データインデックスを格納するために、RocksDBは大量のRAMを必要とします。
RocksDBを使用するようにバリデーターを構成し、レジャーストアに最大30万件（約2週間分に相当する[履歴データ](#ディスク容量)）までのレジャーを格納するように設定する必要があります。
最大のトランザクション処理スループットを達成するため、RocksDBには、`rippled.cfg`で設定できるパフォーマンス関連の構成オプションがあります。以下は、RocksDBを使用する`rippled`の推奨構成です。
RocksDBには、トランザクション処理のスループットを向上させるために調整できるパフォーマンス関連の設定オプションがあります。以下は、RocksDBを使用する`rippled`の推奨構成です。
```
[node_db]
@@ -90,11 +87,11 @@ advisory_delete=0
[NuDB](https://github.com/vinniefalco/nudb#introduction)は、SSDドライブ用に最適化された追加専用のkey-valueストアです。
NuDBは、[格納されているデータ量に関係なく](#ディスク容量)、ほぼ一定したパフォーマンスとメモリーフットプリントを提供します。NuDBはソリッドステートドライブを _必要とします_ が、大容量のデータベースにアクセスするために使用するRAMがRocksDBよりも大幅に少なくなっています。
NuDBは、[格納されているデータ量に関係なく](#ディスク容量)、ほぼ一定したパフォーマンスとメモリーフットプリントを提供します。NuDBはSSDを _必要とします_ が、大容量のデータベースにアクセスするために使用するRAMがRocksDBよりも大幅に少なくなっています。
バリデーター以外の実稼働サーバーは、NuDBを使用してユースケースに必要な履歴データ量を格納するように構成する必要があります。
本番サーバーは、NuDBを使用してユースケースに必要な履歴データ量を格納するように構成する必要があります。
NuDBには、`rippled.cfg`にパフォーマンス関連の構成オプションがありません。以下は、NuDBを使用する`rippled`の推奨構成です。
NuDBには、`rippled.cfg`にパフォーマンス関連の構成オプションがありません。以下は、NuDBを使用する`rippled`における`[node_db]`の推奨構成です。
```
[node_db]
@@ -109,28 +106,21 @@ advisory_delete=0
### ログレベル
サンプルの`rippled-example.cfg`ファイルの`[rpc_startup]`スタンザでは、ロギング詳細レベルが`warning`に設定されています。この設定を使用すると、より詳細なログ比べ、ディスク容量とI/O要件が大幅に緩和されます。ただし、より詳細なログレベルを設定すると、トラブルシューティングの際により細かな情報が得られます。
サンプルの`rippled-example.cfg`ファイルの`[rpc_startup]`節では、ロギング詳細レベルが`warning`に設定されています。この設定を使用すると、より詳細なログ比べ、ディスク容量とI/O要件が大幅に緩和されます。ただし、より詳細なログレベルを設定すると、トラブルシューティングの際により細かな情報が得られます。
**注意:** `[rpc_startup]`スタンザで`log_level`コマンドを省略すると、`rippled`は`debug`レべルでディスクにログを書き込み、`warning`レベルのログをコンソールに出力します。 `debug` レベルのログは、`warning`レベルに比べ、トランザクション量とクライアントアクティビティーに基づいて、一日当たりに必要なディスク容量が数GB多くなります。
**注意:** `[rpc_startup]`節で`log_level`コマンドを省略すると、サーバーは`debug`レべルでディスクにログを書き込み、`warning`レベルのログをコンソールに出力します。 `debug` レベルのログは、`warning`レベルに比べ、トランザクション量とクライアントアクティビティーに基づいて、一日当たりに必要なディスク容量が数GB多くなります。
## ネットワークとハードウェア
XRP Ledgerネットワーク内の各`rippled`サーバーは、ネットワークのすべてのトランザクション処理を実行します。このため、実稼働用`rippled`サーバーのベースラインハードウェアはRippleの[パフォーマンステスト](https://ripple.com/dev-blog/demonstrably-scalable-blockchain/)で使用されるものと類似している必要があります。
XRP Ledgerネットワークの各サーバーは、ネットワークのすべての取引処理作業を行います。ネットワーク上の総活動量は変動しますが、ほとんどが時間の経過とともに増加していますので、現在のネットワーク活動に必要な容量よりも大きな容量のハードウェアを選択する必要があります。
`rippled`サーバーが、これらのネットワーク要件とハードウェア要件を満たすようにすることは、XRP Ledgerネットワーク全体で一貫した優れたパフォーマンスを実現するために役立ちます。
### 推奨事項
企業の本番環境で最良のパフォーマンスを実現するため、Rippleでは、以下の仕様のベアメタルで`rippled`を実行することを推奨しています。
- オペレーティングシステム: Ubuntu 16.04以上
- CPU: Intel Xeon 3以上、GHzプロセッサー、4コア、ハイパースレッディング有効
- ディスク速度: SSD（7000回以上の書き込み/秒、10,000回以上の読み取り/秒）
- ディスク容量: 場合により異なる。最低50GBを推奨。
- RAM: 32GB
- ネットワーク: ホスト上にギガビットネットワークインターフェイスを備える企業データセンターネットワーク
推奨されるハードウェアのスペックをまとめたものは、[システム要件](system-requirements.html)をご覧ください
#### CPU使用率および仮想化
@@ -138,14 +128,16 @@ XRP Ledgerネットワーク内の各`rippled`サーバーは、ネットワー
#### ディスク速度
Rippleは、待ち時間の少ないランダム読み取りと高いスループットを備えた、グレードの高いソリッドステートディスク（SSD）の使用を _強くお勧めします。_ Rippleのエンジニアにより、以下の最大読み取り速度（秒）と書き込み速度（秒）が測定されています。
ストレージの速度は、サーバーの容量を左右する重要な要素の1つです。待ち時間の少ないランダム読み取りと高いスループットを備えた、グレードの高いソリッドステートディスク（SSD）の使用を _強くお勧めします。_ Rippleのエンジニアにより、以下の最大読み取り速度（秒）と書き込み速度（秒）が測定されています。
- （使用率が高いパブリックサーバークラスターで）秒あたり10,000回の読み取り
- （専用のパフォーマンステストで）秒あたり7,000回の書き込み
<!--{# TODO 2021-11: 測定内容が新しくなっているのであれば、更新が必要 #}-->
#### ディスク容量
`rippled`が必要とするディスク容量は、ローカルで維持する予定の[レジャー履歴](ledger-history.html)の量によって異なります。コンセンサスプロセスに従い、レジャー全体の状態を報告するには、`rippled`サーバーは最新の256のレジャーバージョンのみを格納する必要があります。ただし、サーバーで照会できる実行済みトランザクションは、ローカルで保存されたレジャーバージョンにあるものだけです。
`[node_db]`節はサーバの_レジャーの保存容量_を制御し、[レジャーの履歴](ledger-history.html)を保持します。必要なディスク容量は、どの程度の履歴をローカルに保存するかによって決まります。XRP Ledgerサーバーは、コンセンサス・プロセスを追跡し、レジャーの完全な状態を報告するために、最新の256以上のレジャーバージョンを保存する必要はありません。ただし、サーバーで照会できる実行済みトランザクションは、ローカルで保存されたレジャーバージョンにあるものだけです。`[node_db]`の`path`を設定して、レジャーの保存場所を決めてください。
保持するデータ量は、[オンライン削除](online-deletion.html)で管理できます。デフォルトの構成ファイルの設定では、サーバーは最新の2000のレジャーバージョンを保持します。オンライン削除を使用しないと、サーバーのディスク要件が際限なく増え続けます。
@@ -160,7 +152,7 @@ Rippleは、待ち時間の少ないランダム読み取りと高いスルー
| 90日 | 2,250,000 | 720GB | 1TB |
| 1年 | 10,000,000 | 3TB | 4.5TB |
| 2年 | 20,000,000 | 6TB | 9TB |
| 完全な履歴（2018まで） | 43,000,000+ | （非推奨） | ~9TB |
| 完全な履歴（2020-11-10まで） | 59,000,000+ | （非推奨） | ~14TB |
これらの数値は概算です。様々な要因によって変わりますが、最も重要なのはネットワーク内のトランザクション量です。トランザクション量が増えるにつれ、各レジャーバージョンはより多くの固有データを格納します。今後の拡大に備え、予備のストレージ容量を準備しておくことをお勧めします。
@@ -168,16 +160,20 @@ Rippleは、待ち時間の少ないランダム読み取りと高いスルー
保持する履歴量の変更方法については、[オンライン削除の設定](configure-online-deletion.html)を参照してください。
レジャー履歴を格納したくても、全履歴を格納するための十分な容量がない場合には、[履歴シャーディング](history-sharding.html)機能を使用して個別の共有ストアにランダムな範囲のレジャーを格納できます。履歴シャーディングは、`[shard_db]`スタンザで構成されます。これは`[node_db]`スタンザでレジャーストアに定義したものとは別のタイプのkey-valueストアを使用できます。
`[database_path]`では、個別のデータベースを設定します。これらには、トランザクションデータといくつかのランタイム設定が含まれます。
一般的なルールとして、実行されていない`rippled`サーバーのデータベースファイル（レジャーストアとデータベースの両方）を安全に削除することができます。これにより、サーバーに保存されているレジャーの履歴はすべて消去されますが、そのデータをネットワークから再取得することができます。ただし、`[database_path]`にある`wallet.db`ファイルを削除すると、[Amendment 投票](configure-amendment-voting.html)や[ピアリザベーション](use-a-peer-reservation.html)などのランタイムの設定変更を手動で再適用しなければなりません。
レジャー履歴を格納したくても、全履歴を格納するための十分な容量がない場合には、[履歴シャーディング](history-sharding.html)機能を使用して個別の共有ストアにランダムな範囲のレジャーを格納できます。履歴シャーディングは、`[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`ストレージ）にはこのような制約はありません。このため、Rippleでは、インスタンスストレージを備える`M3`などのホストタイプの`rippled`サーバーをデプロイすることをお勧めします。`database_path`パスと`node_db`パスの両方がインスタンスストレージに存在する必要があります。
AWSインスタンスストア（`ephemeral`ストレージ）では適切なパフォーマンスが提供されます。しかし、インスタンスを開始/停止するときなど、いくつかの状況でデータが失われる可能性があります。しかし、個々のXRP Ledgerサーバーは、通常、失われたレジャーの履歴を他サーバーから再取得することができるので、これは許容範囲内でしょう。設定内容は、より信頼性の高いストレージに保存する必要があります。
**注意:** AWSインスタンスストレージは、ハードドライブが故障した場合に、必ずしもデータの保護を保証しません。また、インスタンスを停止、開始、またはリブートした場合にもデータが失われます。通常、個々のサーバーは失われたデータをピアサーバーから再取得できるため、後者のタイプのデータ損失は`rippled`サーバーでは容認できます。
`[node_db]`節の`path`と`[database_path]`の両方が、適切なストレージを指していることを確認してください。
#### RAM/メモリー
@@ -185,12 +181,38 @@ AWSインスタンスストア（`ephemeral`ストレージ）にはこのよう
#### ネットワーク
あらゆる企業または通信事業者クラスのデータセンターでは、`rippled`サーバーの実行をサポートするため、非常に大きなネットワーク帯域幅が必要です。
企業や企業レベルのデータセンターでは、XRP Ledgerサーバーの稼働をサポートするために、非常に大きなネットワーク帯域幅が必要です。実際に必要な帯域幅は、ネットワークにおける現在のトランザクション量に応じて大きく変わります。サーバーの動作（[レジャー履歴](ledger-history.html)の埋め戻しなど）もネットワークに影響します。一般的な家庭用インターネットでは、信頼性の高いサーバーを稼働させるには不十分です。
以下は、一般的な`rippled`タスクで使用されるネットワーク帯域幅の例です。
トランザクション量が非常に多い時期には、サーバーが100メガビット/秒のネットワークリンクを完全に飽和してしまうという報告を受けた事業者もあります。そのため、信頼性の高いパフォーマンスを実現するためには、ギガビット・ネットワーク・インターフェースが必要となります。
| タスク | 転送/受信 |
以下は、一般的なタスクで使用されるネットワーク帯域幅の例です。
| タスク | 転送量/受信量 |
|:------------------------------------------------|:---------------------------|
| 現在のトランザクション量を処理する | 2Mbpsの転送、2Mbpsの受信 |
| 履歴レジャーとトランザクションレポートを提供する | 100Mbpsの転送 |
| `rippled`の起動 | 20Mbpsの受信 |
| ピーク時のトランザクション量を処理 | 100Mbps以上の転送 |
| 履歴レジャーとトランザクションレポートを提供する | 100Mbps以上の転送 |
| `rippled`の起動 | 20Mbpsの受信 |
[P2P通信で圧縮を有効にする](enable-link-compression.html)ことで帯域幅を節約することができますが、その代償としてCPU使用率が高くなります。多くのハードウェア構成では、通常の使用時にはCPUの容量に余裕があるため、ネットワークの帯域幅が限られている場合には、この方法が経済的な選択肢となります。
## 関連項目
- **コンセプト:**
- [`rippled`サーバー](the-rippled-server.html)
- [コンセンサスについて](intro-to-consensus.html)
- **チュートリアル:**
- [`rippled`の構成](configure-rippled.html)
- [オンライ削除の設定](configure-online-deletion.html) - サーバーが一度に保持するレジャー履歴のバージョン数を調整します。
- [`rippled`のトラブルシューティング](troubleshoot-the-rippled-server.html)
- **リファレンス:**
- [rippled APIリファレンス](rippled-api.html)
- [`rippled`コマンドラインの使用](commandline-usage.html)
- [logrotate メソッド][] - サーバーのデバッグログを閉じたり再開したりして、標準的なツールでローテーション可能にします。
- [server_info メソッド][] - 同期の状態や、ディスク上で利用可能なレジャー履歴のバージョン数など、サーバーに関する一般的な情報を取得します。
- [get_counts メソッド][] - 追加のサーバの正常情報、特にRAM内に様々な種類のオブジェクトをいくつ保持しているかを取得します。
<!--{# common link defs #}-->
{% include '_snippets/rippled-api-links.md' %}
{% include '_snippets/tx-type-links.md' %}
{% include '_snippets/rippled_versions.md' %}

31
content/tutorials/manage-the-rippled-server/installation/system-requirements.ja.md
View File

@@ -7,31 +7,28 @@ labels:
---
# システム要件
## 推奨される仕様
企業の本番環境で最良のパフォーマンスを実現するため、以下の仕様のベアメタルで`rippled`を実行することが推奨されています。
- オペレーティングシステム: Ubuntu (LTF) 、CentOS または RedHat Enterprise Linux (最新版)
- CPU: Intel Xeon 3GHz以上のプロセッサー、8コア以上、ハイパースレッディング有効
- ディスク: SSD / NVMe（10,000 IOPS以上）
- RAM: 64GB
- ネットワーク: ホスト上にギガビットネットワークインターフェイスを備える企業データセンターネットワーク
## 最小仕様
ネットワークに参加するための費用を抑えるため、`rippled`サーバーは一般製品のハードウェア上で快適に実行できる必要があります。Rippleでは、現時点で以下の最小要件を推奨します。
テスト目的やたまにしか使わない場合は、一般的なハードウェア上でXRP Ledgerサーバーを稼働させることができます。以下の最低要件を満たせば、ほとんどの場合は動作しますが、必ずしも[ネットワークと同期](server-doesnt-sync.html)しているとは限りません。
- オペレーティングシステム:
- 本番環境: CentOSまたはRedHat Enterprise Linux（最新リリース）、Ubuntu（16.04以降）、Debian（9.x）をサポート
- 開発環境: Mac OS X、Windows（64ビット）、またはほとんどのLinuxディストリビューション
- CPU: 64ビット x86_64、2つ以上のコア
- オペレーティングシステム: Mac OS X、Windows（64ビット）、またはほとんどのLinuxディストリビューション(Red Hat、 Ubuntu、 Debianをサポート)
- CPU: 64ビット x86_64、4コア以上
- ディスク: データベースパーティション用に最低50GB。SSDを強く推奨（最低でも1000IOPS、それよりも多いことが望ましい）
- RAM: 8GB以上
- RAM: 16GB以上
作業負荷によっては、Amazon EC2の`m3.large` VMサイズが適切な場合があります。高速のネットワーク接続が望ましいです。サーバーのクライアント処理負荷が増加すると、必要なリソースも増加します。
## 推奨される仕様
企業の本番環境で最良のパフォーマンスを実現するため、Rippleでは、以下の仕様のベアメタルで`rippled`を実行することを推奨しています。
- オペレーティングシステム: Ubuntu 16.04以上
- CPU: Intel Xeon 3以上、GHzプロセッサー、4コア、ハイパースレッディング有効
- ディスク: SSD（7000回以上の書き込み/秒、10,000回以上の読み取り/秒）
- RAM:
- テスト用: 8GB以上
- 本番環境用: 32GB
- ネットワーク: ホスト上にギガビットネットワークインターフェイスを備える企業データセンターネットワーク
## システム時刻