Collaborative Recovery CorDapps_LedgerRecover

公開日

Aug 26, 2021

カテゴリ

Corda技術を知る

タグ

🛠️Node運用 🎡可用性

筆者

この記事で学べること

ノード間で発生したデータ破損の回復をサポートするCollaborative Recoveryのうち、トランザクションの差異を検出するLedgerSyncについて理解できる。

Collaborative Recovery CorDapps概要

Collaborative Recovery はノード間で発生したトランザクション差異の検出、及び回復をサポートするツール群の総称です。Collaborative Recovery は目的に応じた複数のアプリケーションで構成されます。指定したノード間でのトランザクションの差異を検出する LedgerSync や、台帳のデータの差異を修正し整合性を取る LedgerRecover があります。

LedgerRecover

LedgerRecover を使用する事で、ロストしたデータを自動または手動で復旧可能です。デフォルトでは自動処理となりますが、手動復旧を選択する事も可能です。

構成パラメータ

LedgerRecoverは、他のCorDappsと同様、LedgerRecoverの構成用の.jarファイルの後に構成ファイルを作成することで設定することができます。例えば、LedgerRecover の .jar ファイルが ledger-recover-1.0.jar と呼ばれている場合、設定ファイルは <corda_node_dir>/codeapps/config/ledger-recover-1.0.conf となります。

以下にある構成パラメータを使用してLedgerRecoverの動作を定義することができます。構成パラメータが指定されていない場合や構成ファイルが存在しない場合は、デフォルト値が使用されます。

maxAllowedTransactions

リカバリー要求により実行可能なトランザクション数の最大値

デフォルト：30

指定可能値：1 ～ 1000

maxAllowedSizeInBytes

timeWindowForMaxAllowedSizeとセットで使用。指定時間内に他のノードからのリカバリー要求に対する応答を送信するトランザクションの合計サイズを制御。例）1000000 byte / min

デフォルト：3000000

指定可能値：1 ～ 10000000

timeWindowForMaxAllowedSize

maxAllowedSizeInBytes とセットで使用。指定時間内に他のノードからのリカバリー要求に対する応答を送信するトランザクションの合計サイズを制御。例）1000000 byte / min

デフォルト：1h

指定可能値：1m ～ 24h

maxAllowedRequests

timeWindowForMaxAllowedRequests とセットで使用。ノードが所定の時間内に他のノードからの回復要求を開始または応答する頻度を制御。例）10リクエスト / min

デフォルト：30

指定可能値：1 ～ 100

timeWindowForMaxAllowedRequests

maxAllowedRequests とセットで使用。ノードが所定の時間内に他のノードからの回復要求を開始または応答する頻度を制御。例）10リクエスト / min

デフォルト：1h

指定可能値：1m ～ 24h

manualExportTransactionsBatchSize

手動エクスポート中にバッチとして読み取られるトランザクションの数を定義。

手動エクスポートのパフォーマンスを向上させるために、これを変更することを検討してください。このプロパティには、WHERE value IN(...)の制限を超えないように保守的なデフォルト値が設定されていますが、これはデータベースによって異なります。変更する前にデータベース・ベンダーのドキュメントを確認してください。

（パフォーマンスに影響）

デフォルト：100

指定可能値：100 ～ 100000

manualImportNumberOfTransactionsToCommitAfter

インポートするトランザクションの数を定義。

デフォルト：1000

指定可能値：1000 ～ 10000

Flow仕様

自動レッジャー復旧のプロセスを開始してモニタリングするには、Flowを使用する必要があります。下記は使用できる各Flowについて、パラメータ、戻り値のタイプ、コマンドラインインターフェイス、および例とともに詳細に説明します。

AutomaticLedgerRecoverFlow

指定した取引先ノードに対して自動データ回復プロセスを開始するFlow。

要求ノードは応答ノードに対して自ノード間とのレッジャーの差異を確認します。

次に、要求ノードは、Vaultに既に存在するTransactionをフィルタリングします。これは同時に自動回復の結果として、台帳上に既に存在する回復すべきtransactionを再要求することを防ぐために行われます。

実行に成功すると、要求するノードと応答するノードの両方でカスタム CorDapp テーブルにRecoveryRequest の記録が永続化されます。

RecoveryRequestの記録が要求元によって永続化される前に、以下がチェックされます。

要求されたトランザクションのリストが空ではない
要求されたトランザクションの数が設定された制限を超えていない
時間枠内の回復要求の数が設定された制限を超えていない（例えば、1 時間ごとに 3 つの要求）
時間枠内に要求された回復のためのトランザクションの合計数が設定された制限を超えていない（例えば、1時間あたり30トランザクション）
要求するノードが同じ役割を持っている（例えば、回復の要求者としてリストされている）現在のRecoveryRequestがない。

RecoveryRequest の記録を保持した後、要求元は回収が必要なTransactionのリストを応答側に送信します。応答側ノードは、同様の検証を行うとともに、要求元がそのTransactionのデータを受け取る権利があることを保証します。これは、プライバシーの漏洩を防ぐために必要なことであり、要求されたTransactionの参加者、もしくは、要求されたTransactionがそれらのTransactionのそれぞれのバックチェーンの一部であるかのいずれかでなければならないことを意味します。

上記は、プライベートなデータが誤って送信されたり、LedgerRecover で悪意を持って送信されたりしないことを保証するために実装されています。

各Transactionは、標準の SendTransaction/ReceiveTransaction Corda プラットフォームFlowの拡張バージョンを使用して、要求元に送り返され、要求元によって受信されます。Transactionの送信と受信、および関連する成果物（バックチェーン・トランザクション、添付ファイル、ネットワーク・パラメータ）は、CR_RECOVERY_LOG テーブルに記録されます。送信されるデータの正確なサイズがこの段階で測定可能になるので、送信されるデータ量の制限が適用され、該当する場合はリクエストがスロットル化されます。

RecoveryRequest が成功した場合、要求元と応答元の両方のノードで COMPLETED としてマークされます。失敗した場合、理由と共にFAILEDに更新します。

失敗した場合、アーティファクト(副産物)の送信に標準的な Corda Flowを使用することで、レッジャーの一貫性が失われるのを防ぎます。これは、送信が途中で停止された場合にも当てはまります。

自動LedgerRecoverが正常に完了すると、（回復の）要求元ノードによって開始されたすべてのReconciliationStatusesがリフレッシュされます。これは、新たに取得したTransactionが照合結果の差分として表示されないようにするために行われます。

パラメーター

parties：データ回復の実施を依頼する取引先ノード名

戻り値

無し

コマンド例

Node01 が Node02 に依頼してデータ回復を実施する

例外

AutomaticRecoveryException：回復対象のTransaction無し、または受信したTransactionが要求されたTransactionのリストに存在しない

TransactionLimitExceededException ：回復対象のTransaction数が制限値を超過

RequestLimitExceededException：時間枠内のデータ回復リクエスト回数が制限値を超過

SizeLimitExceededException：時間枠内に送信するTransactionの合計サイズ（ maxAllowedSizeInBytes ）が制限値を超過

RecoveryAlreadyInprogressException：別のデータ回復が進行中

RecoveryRequestVerificationException：要求側ノードからの受信に要求が許可されていないTransactionが含まれている場合

FailAutomaticRecoveryFlow

通常はデータ回復失敗時にノードが処理ステータスを FAILED に更新する際に使用するFlowです。データ回復が正常に終了しない場合、手動実行し処理ステータスを FAILED にする必要があります。本Flowを手動で使用する場合、事前に killFlow を使用して強制終了した後にFailAutomaticRecoveryFlow を使用して処理ステータスを FAILED に更新する必要性があります。

失敗したRecoveryRequestは、記録保持とクエリのためのCR_RECOVERY_REQUESTテーブルのレコードとして残ります。

パラメーター

requestId：RecoveryRequestの処理ステータスを FAILED にする対象の UUID

failReason：RecoveryRequestがFAILED の理由

戻り値

無し

コマンド例

指定した UUID の処理ステータスを「FailAutomaticRecoveryFlow 」にて FAILED に更新する

例外

RecoveryNotFoundException：処理ステータスを FAILED にする対象の UUID が存在しない

AutomaticRecoveryException ：処理ステータスを FAILED に更新する対象のステータスが IN_PROGRESS では無い

ShowInitiatedAutomaticRecoveryProgressFlow

要求ノードによって開始されたデータ回復の進行状況（回復対象のトランザクション総数に対する受信の数）を応答

パラメーター

party：データ回復処理中の取引先ノード名

戻り値

RecoveryProgress：回復トランザクション総数と受信の数を含んだデータクラス

出力例

RecoveryProgress(done=13, total=20)

コマンド例

ノードに対して実施中のデータ回復状況を照会する

例外

RecoveryNotFoundException：自ノードが開始したデータ回復処理が存在しない

GetRecoveryRequestsFlow

要求ノードによって開始されたデータ回復の状況を応答

パラメーター

全パラメータ指定可能

party：データ回復処理中の取引先ノード名

isRequester：データ回復の要求側・応答側かを確認する際に使用（ true / false ）

statuses：照会する処理ステータスのリスト。Set<RecoveryStatusFlag> で指定

なお、すべてのパラメータはnullにすることも可能です。ゼロ引数で使用される場合、このFlowはすべてのRecoveryRequestの記録を返します。

戻り値

進行状況：進行状況を示すデータクラス

出力例

コマンド例

パラメータを全て指定した例

GetCurrentRecoveryRequestWithPartyFlow

各カウンターパーティから現在の処理ステータスを取得するFlow。

パラメーター

party：データ回復処理中の取引先ノード名

isRequester：データ回復の要求側・応答側かを確認する際に使用（ true / false ）

戻り値

進行状況：進行状況を示すデータクラス

出力例

コマンド例

例外

MultipleRecoveryRecordsException：ノードのデータベースに回復が複数ある場合

GetRecoveryLogsFlow

特定のRecoveryRequestに関連するすべてのRecoveryLogを取得します。

パラメーター

recoveryRequestId：ログが取得される処理ステータスのUUID。

戻り値

RecoveryLogのリスト

出力例

コマンド例

Collaborative Recovery CorDapps_LedgerRecover

公開日

Aug 26, 2021

カテゴリ

Corda技術を知る

タグ

🛠️Node運用 🎡可用性

筆者

この記事で学べること

ノード間で発生したデータ破損の回復をサポートするCollaborative Recoveryのうち、トランザクションの差異を検出するLedgerSyncについて理解できる。

Collaborative Recovery CorDapps概要

LedgerRecover