ヘルスチェックの導入

Health Checkメソッドは、自動監視によってrippledサーバが正常でないことを認識し、サーバの再起動や人間の管理者への警告などの介入を促すために利用することができます。

インフラモニタリング、そしてより一般的な信頼性の設計は、複数のデータソースを利用して状況に応じて意思決定を行う高度な学問分野です。本書では、ヘルスチェックを最も効果的に使用する方法についていくつかの提案を行いますが、これらの提案は、より大きな対策の一環としてのガイドラインに過ぎません。

瞬間的な障害

ヘルスチェックのmetricsの中には、急速に正常でない範囲に変動し、その後すぐに自動的に回復するものがあります。ヘルスチェックが不正常なステータスを報告するたびにアラートを上げることは不要であり、望ましくありません。自動化されたモニタリングシステムは、health checkメソッドを頻繁に呼び出しますが、問題が深刻で一貫している場合にのみ、より高いレベルの介入に拡張する必要があります。

例えば、1秒に1回サーバのヘルスチェックを行う場合、サーバが「警告」ステータスを3回連続して報告した場合、または5秒間に4回報告した場合にアラートを発生させることができます。また、サーバが5秒間に2回"critical"ステータスを報告した場合にも、アラートを発生させることができます。通常、サーバが"warning"と報告するたびにアラートを発生させるのは過剰です。

ヒント: サーバは通常、起動後の最初の数秒間は"critical"ステータスを報告し、ネットワークへの接続が確立されると"warning"ステータスに切り替わり、ネットワークへの同期が完了すると"healthy"ステータスを報告します。再起動後、追加の介入を行う前に、サーバの同期に5～15分ほど時間が必要です。

特殊なケース

サーバの構成によっては、正常に動作していても常に”warning"ステータスを報告する場合があります。あなたのサーバがこのような特殊なケースに当てはまる場合は、正常なステータスと実際の問題の違いを認識できるように自動監視を設定する必要があります。これにはおそらく、ヘルスチェックメソッドのJSONレスポンスボディを解析し、その値を期待される正常な範囲と比較することが含まれます。

特殊なケースの例としては、次のようなものがあります。

• プライベートピアは通常、既知のサーバのみに接続するごく少数のピアツーピア接続を持ちますが、サーバが7つ以下のピアに接続している場合、ヘルスチェックはpeersメトリックで警告を報告します。サーバが設定されているピア数を正確に把握し、その値をチェックする必要があります。
• 新しいトランザクションが継続的に送信されていない並列ネットワークまたはテストネットワークでは、ネットワークは新しいトランザクションを最大20秒待ってから新しいレジャーバージョンの検証を試みますが、検証された最新のレジャーが7秒以上古い場合、ヘルスチェックはvalidated_ledgerメトリックで警告を報告します。本番環境でないネットワークでrippledを実行している場合、トランザクションが定期的に送信されていることが分かっていない限り、これに対するwarningメッセージを無視することができます。XRP Ledgerプロトコルは、処理する新しいトランザクションがなくても、少なくとも20秒に一度は新しいレジャーバージョンを検証するように設計されているからです。

推奨される対策

ヘルスチェックに失敗し、それが単なる瞬間的な障害でない場合、障害から回復するために取るべき行動は原因によって異なります。インフラストラクチャを設定することで、いくつかのタイプの障害を自動的に修正できるかもしれません。組織の構造によっては、管理者のレベルが異なり、スキルの低い下位レベルの管理者が単独で特定の問題を解決できても、より大規模で複雑な問題を解決するには上位レベルの管理者に連絡する必要があります。いつ、どのように対応するかは、固有の状況によって異なりますが、ヘルスチェックの結果で報告される情報は、これらの決定の要因になる可能性があります。

以下のセクションでは、試みるべき一般的な介入と、それらの介入を促す可能性が最も高いヘルスチェックのステータスを提案します。自動化されたシステムや人間の管理者は、これらの介入やその他の介入によって選択的に状況を確認することができます。

• トラフィックのリダイレクト: 影響を受けたサーバからトラフィックをリダイレクトします。
• 再起動: サーバソフトウェアまたはハードウェアを再起動します。
• 更新: rippledをアップグレードします。
• ネットワークの調査: 問題が他の場所で発生した場合のためにネットワークを調査します。
• ハードウェアの交換

トラフィックのリダイレクト

一般的な信頼性のためのテクニックは、1つ以上の負荷分散プロキシを通して冗長なサーバのプールを実行することです。これはrippledサーバではできますが、バリデータではすべきではありません。場合によっては、ロードバランサはプール内のサーバの健全性を監視し、現在健全であると報告しているサーバだけにトラフィックを向けることができます。これにより、サーバは一時的な過負荷から回復し、自動的にアクティブなサーバのプールに戻ることができます。

特にhealthステータスがwarningと表示されたサーバに対しては、不健全なサーバからトラフィックをリダイレクトすることが適切な対応です。criticalの範囲にあるサーバはより重要な介入が必要かもしれません。

再起動

最も簡単な方法は、サーバを再起動することです。これにより、以下のmetricsのいずれかを含む、いくつかのタイプの障害の一時的な問題を解決できます。

• load_factor
• peers
• server_state
• validated_ledger

rippledサービスのみを再起動するには、systemctlを使ってください：

$ sudo systemctl restart rippled.service

より強力な介入は、マシン全体を再起動することです。

注意n: サーバの起動後、ネットワークへの同期には通常最大15分を要します。この間、ヘルスチェックはcriticalまたはwarningステータスを報告する可能性があります。自動化システムでは、サーバを再起動する前に、同期に十分な時間をかける必要があります。

更新

サーバがヘルスチェックで"amendment_blocked": trueと報告した場合、これはXRP Ledgerがサーバが理解できないプロトコルの修正(Amendment)を有効にしたことを示しています。ネットワークの改訂されたルールを誤って解釈して損害を被らないようにするため、このようなサーバは正常に動作する代わりに"amendment blocked(Amendmentブロック)"となります。

Amendmentブロックを解消するには、サーバをアップデートして、Amendmentプログラムを理解できる新しいバージョンのソフトウェアにしてください。

また、ソフトウェアのバグによってサーバが同期できない状態になることもあります。この場合、server_stateメトリクスはwarningまたはcriticalな状態になっている可能性があります。最新の安定版リリースを使用していない場合は、アップグレードして、この問題を引き起こす可能性のある既知の問題に対する最新の修正を入手してください。

ネットワークの調査

信頼性の低いネットワーク接続や不十分なネットワーク接続が原因で、サーバが停止を報告することがあります。以下のMetricsのwarningまたはcriticalの値は、ネットワークの問題を示している可能性があります。

• peers
• server_state
• validated_ledger

この場合、必要な介入には、次のような他のシステムへの変更が含まれることがあります。

• 必要なトラフィックがサーバに到達できるようにする、または外部からの有害なトラフィックをブロックするためのファイアウォールルールの調整
• ネットワークインターフェース、スイッチ、ルーター、ケーブルの再起動または交換
• 他のネットワークサービスプロバイダーに連絡して、そのプロバイダー側での問題の解決

ハードウェアの交換

ハードウェアの故障や、ハードウェアの処理能力を超える高負荷が原因で障害が発生した場合、コンポーネントの交換やサーバ全体の交換が必要になることがあります。

XRP Ledgerのサーバにかかる負荷の量は、ネットワークのトランザクション量に一部依存し、それはランダムに変化します。また、負荷は利用者の利用パターンにも依存します。状況に応じて適切なハードウェアと設定を計画する方法については、容量の計画をご覧ください。

次の metricsのwarningまたはcriticalの値は、ハードウェアが十分でないことを示している可能性があります。

• load_factor
• server_state
• validated_ledger