EKSでのブロックチェーンノード運用クイズ
このクイズでは、StatefulSetの設定、ストレージ、ヘルスチェック、ハードフォーク管理について理解度を確認します。
多肢選択問題
- EKSでブロックチェーンノードを動かすか判断する際、どのような基準が示されていますか？
- A) ノードが10台以上あるか
- B) インデクサー、API、監視など、ノードの周囲で他のワークロードが動くか。ノード単体ならEC2の方がシンプル
- C) チェーンがパブリックかプライベートか
- D) バリデーターを実行するか
回答を表示
回答: B) インデクサー、API、監視など、ノードの周囲で他のワークロードが動くか。ノード単体ならEC2の方がシンプル
解説: ブロックチェーンノードの特性は、Kubernetesの強みの一部（高速な再スケジュール、水平スケーリング、ローリングアップデート）とは相性がよくありません。それでもEKSを使う理由には、運用の標準化、複数チェーンや複数環境の管理、周辺コンポーネントとの統合があります。インデクサー、API、監視がすでにクラスター内で動いているなら、ノードも一緒に管理するのが合理的です。バリデーターを1つだけ実行する場合は、EKSの抽象化がメリットなしに複雑さを増やします。
- ブロックチェーンノードのStatefulSetでは、
terminationGracePeriodSecondsに十分な時間を設定する必要があるのはなぜですか？- A) イメージのpullに時間がかかるため
- B) クライアントは終了時にメモリ内の状態をディスクへ書き出す必要があり、強制終了するとデータベースが破損して再同期が必要になるため
- C) シャットダウンをピアへ通知する必要があるため
- D) ボリュームの切り離しに時間がかかるため
回答を表示
回答: B) クライアントは終了時にメモリ内の状態をディスクへ書き出す必要があり、強制終了するとデータベースが破損して再同期が必要になるため
解説: デフォルトの30秒では通常不十分です。ブロックチェーンクライアントは状態をメモリにキャッシュしており、終了時にディスクへ書き出す必要があります。強制終了（SIGKILL）によってデータベースへの書き込み途中で終了して破損すると、数時間から数日かかる再同期が必要になる場合があります。同じ理由から、メモリ上限にも余裕を持たせてください。OOM killも強制終了です。
- ブロックチェーンノードのストレージでは、容量より先にIOPSがボトルネックになりやすいのはなぜですか？
- A) チェーンデータが圧縮して保存されるため
- B) 状態トライ（Merkle Patricia Trieなど）の走査や更新で、離れたキーにアクセスするランダムアクセスパターンになるため
- C) ブロックは常にシーケンシャルにしか書き込まれないため
- D) スナップショットが頻繁に取得されるため
回答を表示
回答: B) 状態トライ（Merkle Patricia Trieなど）の走査や更新で、離れたキーにアクセスするランダムアクセスパターンになるため
解説: ブロックチェーンノードのディスク利用の大部分は、ランダムな読み書きです。容量に余裕があってもIOPSが不足すると同期が遅れ、同期が遅れたノードはリクエストを処理できません。そのため、gp3の重要な利点は、容量とは独立してIOPSとスループットを設定できることです。gp2は容量に応じてIOPSが決まるため、不要な容量を追加購入しなければIOPSを増やせませんでした。
- 同期状態をliveness probeに含めてはいけないのはなぜですか？
- A) 同期チェックでRPC負荷が増えるため
- B) 同期が遅れているノードが再起動され、再起動でさらに遅れ、また再起動される無限ループになるため
- C) liveness probeはexec方式に対応していないため
- D) 同期状態を確認できるのはreadinessだけのため
回答を表示
回答: B) 同期が遅れているノードが再起動され、再起動でさらに遅れ、また再起動される無限ループになるため
解説: livenessでは「プロセスが稼働し、応答しているか」だけを確認してください。同期状態を含めると、遅れているノードが終了させられます。再起動によって同期がさらに遅れ、追いつけなくなります。一方、readinessには同期状態を含める必要があります。 含めないと、遅れたノードにトラフィックが送られ、古いチェーンに基づく誤ったデータを返します。この分離がブロックチェーンノードのヘルスチェックの要点です。
- インバウンドのP2Pトラフィックを許可したのにピアが接続してきません。典型的な原因は何ですか？
- A) Security Groupのルールがない
- B) アドバタイズするアドレスが設定されていない。コンテナ内から見えるPod IPと外部から到達可能なアドレスが異なるため、他のピアが接続できない
- C) TCPではなくUDPポートだけを開いた
- D) ピアの上限が0に設定されている
回答を表示
回答: B) アドバタイズするアドレスが設定されていない。コンテナ内から見えるPod IPと外部から到達可能なアドレスが異なるため、他のピアが接続できない
解説: P2Pプロトコルは、自身のアドレスをピアに通知します。コンテナ内から見えるアドレス（Pod IP）が、外部から到達可能なアドレス（ノードのパブリックIPやロードバランサーのアドレス）と異なる場合、ピアは通知されたアドレスに接続できません。多くのクライアントには--nat extip:<addr>のようなオプションがあります。これを設定しないと、インバウンドを許可してもピアは接続してきません。 Podごとに異なるアドレスを通知する必要があるため、StatefulSetの序数やdownward APIを使った初期化処理が必要です。
- ブロックチェーンノード専用のノードを割り当てる場合も、CPU制限に注意する必要があるのはなぜですか？
- A) CPU制限がメモリ使用量に影響するため
- B) 専用ノードでテナント間の競合は減るが、システムデーモン用の予約と余裕は引き続き必要なため
- C) 専用ノードではCPU制限が無視されるため
- D) Guaranteed QoSには専用ノードが必要なため
回答を表示
回答: B) 専用ノードでテナント間の競合は減るが、システムデーモン用の予約と余裕は引き続き必要なため
解説: Kubelet、CNI/CSI、監視、OSの各サービスは引き続き実行されます。アプリケーションのCPU制限を設定しない場合でも、持続的な負荷とノードの健全性をテストしてください。
- PectraのEIP-7251によって、運用面ではどのような影響がありましたか？
- A) ノードのディスク要件が半減した
- B) EIP-7251によって条件を満たすバリデーターを統合できるが、バリデーターの鍵とプロセスやVMは1対1で対応しない
- C) ExecutionクライアントとConsensusクライアントが1つに統合された
- D) ハードフォークの予定が年1回になった
回答を表示
回答: B) EIP-7251によって条件を満たすバリデーターを統合できるが、バリデーターの鍵とプロセスやVMは1対1で対応しない
解説: 1つのバリデータークライアントで、多数の鍵を管理できます。バリデーターのレコードや鍵管理の作業が減っても、インフラやコストが同じ割合で減ることの証明にはなりません。
- Fabric MSP/TLS証明書の期限切れに対応する保守作業はどれですか？
- A) OrdererのRaftコンセンサス障害
- B) MSP/TLS証明書の有効期限を監視し、チャネル、ポリシー、コンセンサスの運用と併せて更新をリハーサルする
- C) Chaincodeの実行エラー
- D) チャネルポリシーの競合
回答を表示
回答: B) MSP/TLS証明書の有効期限を監視し、チャネル、ポリシー、コンセンサスの運用と併せて更新をリハーサルする
解説: 証明書の期限切れは具体的なリスクですが、この資料では最も発生頻度が高い障害だと測定されているわけではありません。Operatorとの互換性とPeerによるトランザクション検証も確認してください。
- ハードフォーク後に不可欠な検証は何ですか？
- A) Podを再起動する
- B) 他のノードやパブリックエクスプローラーとブロックハッシュを比較し、同じチェーン上にいることを確認する
- C) ストレージ容量を再計算する
- D) ピア一覧をリセットする
回答を表示
回答: B) 他のノードやパブリックエクスプローラーとブロックハッシュを比較し、同じチェーン上にいることを確認する
解説: 互換性のないクライアントは正規チェーンの追従を停止したり、有効化後に分岐したりすることがあります。プロセスが稼働しているだけでは、正しい状態とは言えません。独立した信頼できるノードやエクスプローラー間で、同じブロック高とファイナリティ状態のハッシュを比較してください。通常の伝播遅延と同期の遅れも考慮します。無関係な最新ヘッド同士の比較や、1つのエクスプローラーだけを決定的な根拠とせず、クライアントのバージョン、フォーク認識、同期の各チェックとあわせて判断してください。