text：森下 恵里 日本アイ・ビー・エム システムズ・エンジニアリング
IBM Blockchain Platformとは
コンソーシアム型のブロックチェーン基盤は、OSS製品であるHyperledger Fabric（以下、HLF）を使うことによって、コンテナが稼働可能なインフラ環境さえ準備できれば、誰でも構成することが可能である。
しかしながらHLFネットワークの構成に際しては、参加組織ごとにPeerやOrderer、CAなど複数のコンポーネントが必要であり、通常はそれらを構成するためにHLFネットワーク定義や各コンポーネント用の証明書生成などの作業を、すべてCLI（コマンドライン・インターフェース）で行う必要がある。構成が単純であればサンプルのネットワーク構成スクリプトを利用して比較的容易にHLFネットワークを構成できるが、組織が多かったり、Orderer構成を変更したりとスクリプトの編集を要する場合、複数ファイルの修正と確認が煩雑になり人的ミスも発生しやすくなる。
IBM Blockchain Platform（以下、IBP）は、こういったCLIでの構成作業をGUIでインタラクティブに操作することが可能であり、修正が可能なパラメータも画面上わかりやすく構成されているため、CLIよりスムーズに、また作業ミスも少なくHLFネットワークを構成できるようになっている。
IBP自体はコンテナ・ベースの製品であるため、稼動環境としてKubernetes（k8s）やOpenShift Container Platform（以下、OCP）基盤があれば導入できる。ただし基盤のバージョンによってサポート状況が異なるので、導入先のオンプレミスや各種クラウドベンダーで利用可能な基盤のバージョンとサポート状況を別途確認する必要がある。
IBPの導入によって構成されるコンポーネントには、以下のようなものがある（HLFのコンポーネントについての説明はここでは割愛する）。
IBPオペレーター
IBPコンソールやHLFコンポーネントの生死を監視してコンテナ再作成をトリガーする。
IBPコンソール
IBPのGUIを提供する。
IBP Webフック
IBP 2.5.1以降HLFコンポーネントのAPIバージョンの更新のために必要。
これらのIBPのコンポーネントと、IBPコンソールで構成を行うHLFのコンポーネントには、図表1のような種類がある。また、各コンポーネント（ポッド）とそれに内包されるコンテナに必要なシステムリソースは、デフォルトで図表1のように定義されている。CPU単位のmはミリ（1/1000）を示す。こちらのリソースはあくまでもデフォルトの参考値であるため、扱うアセットのデータサイズやトランザクション量に応じて、PoCやシステムテストを実施してリソースの追加割り当ての要否を検証すること。なお、環境がHLF1.4か2.xかで必要リソースは異なるため、環境に応じて確認が必要となる。
HLFのコンポーネントについては、IBPコンソールから「リソースの再割り振り」を行うことによって、運用後もリソース（CPU、メモリ）を容易に変更することが可能だが、ポッドの再作成プロセスが実行される。
コンポーネント全体のアーキテクチャイメージを図表2に示す（説明の簡素化のために最小限のHLFネットワークを同一基盤上に構成した場合の図表で説明する）。これらのコンポーネントは基本的にインターネット越しのアクセスを受け付けるコンポーネントで、OCPではパススルーモードのセキュアrouteを経由して、インターネットの向こうのアプリケーションサーバーやHLFネットワークのコンポーネントに公開される。
ユースケースとロギング
ロギングや監視の要件は、ビジネスユースケースに紐づいて設計されるべきものではあるが、例としていくつかのシステムユースケースを示し、監査、監視対象となり得るログについて示す。
図表3にIBP固有のユースケース、およびHLF運用のユースケース例とそのログ出力先のポッド（コンテナ）一覧を示す。IBPコンソールの操作ログについては、クライアント・ログ、およびサーバー・ログの2種類があり、出力するロギングレベルをIBPコンソール上の設定で変更することができる。2種類のログは、IBPコンソール上のディレクトリ、/home/athena/logsにファイル出力される（clientXX.logまたはserverXX.log）。HLFコンポーネント群のログは、IBPを構成しない場合と変わらず、コンテナの標準出力として出力されるため、OCP基盤では“oc logs”コマンドやOCPコンソールから確認することができる。
ログイン／ログアウトのoptoolsのログには、ユーザー名とログイン可否が出力される。このログは、ドメイン以前の文字列の最初と最後以外の文字がアスタリスク（*）でマスクされており、これだけで監査に利用できるものではないため、ログインユーザー側のブラウザログや前述のクライアント・ログなどフルユーザー名を含むログが必要になる。一方でログイン試行回数やエラー回数などはこのログから生成できるため、たとえば5回連続失敗などの条件でアラートを出すなどの仕組みをこのログから生成できる。
リソースの再割り振りといったユースケースは、CPU、メモリといったインフラ・リソースの増強を行うものである。
CPU、メモリ容量に関しては、チェーンコード・トランザクションが当初設計より頻繁になるなど、ピアやOrdererノードの負荷が増大してしまうケースが考えられる。いずれのケースもIBPコンソール上で変更後のリソース値を指定し、ポッドの再作成をトリガーすることができる。
永続ストレージ増強のトリガーとしては、長期運用によってピアが保持するチェーンコードのジェネシスブロックからの履歴が溜まってしまったり、ステートDB容量が増大した場合初期に作成した永続ストレージが足りなくなったりするケースが挙げられる。現時点での仕様上、IBPコンソールからリソース割り振りによる永続ストレージ容量の変更はできない。この場合、ストレージ容量の大きい新たなピアをチャネルに参加させ、同期させる方法で対応する。再作成したノードはサービス提供可能になるまでタイムラグがあるため、可用性の要件によってはアプリケーションサーバーからの接続先ノードは固定にならないよう設計を行う必要もある。
なお、IBPコンソール上で指定するリソース値は、OCP基盤上でのrequest、limit値として設定されるため、クラスター全体としてリソースに余裕がある場合は、あらかじめ多めにとっておくことで再作成を行わずに後々の業務負荷の増大に耐え得る。
HLF2.xからの新しい要素として、スマートコントラクトの提案からなる一連の合意プロセスがある。現時点のIBPコンソールでは、新しい提案があった場合に通知メニュー上に未合意（または未リジェクト）の処理案件として表示される。HLFネットワークが小規模でメールやslackなどでスマートコントラクトの更新オペレーションを回せてしまう分には特段監視しておく必要性はない。一方で、合意に必要なチャネルメンバー（組織）数が多かったり、エンドースメントポリシー自体が複雑であったりする場合は、承認数に必要な全体のチャネルメンバーのピアが確実に稼働していることを監視したり、チャネルメンバーの承認・リジェクト自体を検知しておくことで、ある程度スマートコントラクト提案者側は更新プロセスを円滑に運用することができると考えられる。
アプリケーションサーバーからHLFコンポーネントへアクセスするユースケースを図表4に示す。通常は他のコンポーネント同様、接続に認証情報が必要な操作ではあるが、エンロール失敗の異常な回数の検知や、不正なスマートコントラクト呼び出しなど、セキュリティ・レベルによっては多段のセキュリティ検知も考えられる。
監視項目
前述のユースケースから、監視項目として図表5が挙げられる。実装に際してはツールにより手法は変わるが、ログ監視項目についてはIBP、HLFコンポーネントの前述の特定のコンテナログを監視し、キーワード検知することになる。たとえば、ログインエラーであれば、以下のような条件となる。
- kubernetes.container_name:”optools”
- message:”*[auth]invalid”
リソース監視項目については、標準で導入されているPrometheusのメトリクスを利用することができる。
サービス監視としては、IBPとHLFでは、liveness proveにてhttpsのGETメソッドのリターンコードを基準にしている。
また、IBPやHLFに限ったことではないが、HLFのコンポーネント群はセキュアルートでネットワーク外部からのアクセスを可能にしているため、ネットワーク的には該当URLポートへの接続情報なしの不正なリクエストの検知やネットワーク監視も考えられる。
ロギング・監視の構成
OCPではロギング・監視の構成はさまざまに組めるが、ここでは公式にガイドされている構成に則った場合を紹介する。
OCPでコンテナログを分析する場合、可観測性を備えたツールとして、Elastic Searchでログを収集し、Kibanaで可視化する方式が標準構成となる。OCPコンソールのOperator Hubからサブスクライブすることができる。Elastic Search構成時の注意点としては、メモリ容量が必要となるため、最低検証環境でも8コア・32GBメモリ程度のIAサーバーからなるクラスターを推奨する。
監視については、リソース監視項目はほぼ標準で構成済みのPrometheusとGrafanaで監視を行うことができ、アラート・ルールを設定することができる。メトリクスとしては、pod:container_cpu_usage:sum、container_memory_usage_bytesなどを利用することができる。ログ監視としては、Kibana上で先述の抽出条件を組むことができる。
通知機能としては、リソース監視項目はメールやSlack連携などを設定することが可能である。ただしログ監視項目においては、OCP 4.6で構成するKibana 6.8.1ではログ可視化やモニタリングのカスタマイズに長けているものの、アラート・ルール作成や通知機能はないため、以下の検討も必要になる。
- Elastic社提供のElasticsearch Operator（ECK）構成により、Kibana7.x アップのアラート機能を利用する。
- OpenShift Elasticsearch OperatorのLog forwarderを利用して、Elasticsearchだけでなくsyslogサーバーなどに転送し、NetcoolやZabbixなどにアラート・ルールを定義する。
ロギング・監視要件のポイント・注意点
IBPおよびHLFのロギング・監視要件について、想定ユースケースと注意点を紹介した。ポイントは以下の点が挙げられる。
- IBPコンソールのログ監査向けにはクライアント・ログ、サーバー・ログを合わせて保持する必要がある。
- ライフサイクル・エンドースメントポリシーの要件の複雑さに応じて、HLFの検証構成が成り立つためのピア、Orderer稼働数や、提案、承認、リジェクト、コミットのログを監視する必要がある。
- 業務拡張に耐えるリソースの閾値監視および増強予測が必要。永続ストレージの拡張時には、新規ピアごとチャネルに参加（および同期）させる必要があるため、リソース計画ならびに増強時の一時的なクラスタ負荷を考慮に入れる必要がある。
- アプリケーションからの不正な呼び出しや、公開ポートに対するトラフィック監視など、外部からのアクセスに対するセキュリティについても通常システム同様に考慮する。
また構成上の注意点としては以下の点が挙げられる。
- ログ監視の通知においては、標準機能（Kibana）以外の追加検討が必要。
- 実際の導入環境に応じて、SaaSサービスや既存オンプレ環境ツールへの統合も適宜検討が必要。
◎本稿の想定環境
・ブロックチェーン基盤
IBP 2.5.1（IBM Blockchain Platform。HLF 2.x環境を提供）
＊本稿で紹介するIBPの仕様は2021年6末時点
・前提環境
OpenShift 4.6
・対象読者
BlockchainやHLF2.xについての仕組みやコンポーネントについて基本的な知識がある。オンプレのIA環境やIaaSへのHLF導入経験や同程度の知識を保持していると望ましい。
◎参考
・Hyperledger Fabricコンポーネントの概要
https://cloud.ibm.com/docs/blockchain-sw-252?topic=blockchain-sw-252-blockchain-component-overview
・Hyperledger Fabric Key Concepts
https://hyperledger-fabric.readthedocs.io/en/latest/key_concepts.html
・IBM Blockchain Platform for IBM Cloudの概説
https://cloud.ibm.com/docs/blockchain?topic=blockchain-ibp-v2-deploy-iks
・Fabric v2.x を使用したスマート・コントラクトのデプロイ:
https://cloud.ibm.com/docs/blockchain?topic=blockchain-ibp-console-smart-contracts-v2
・ライフサイクル・エンドースメント・ポリシー
https://cloud.ibm.com/docs/blockchain?topic=blockchain-ibp-console-govern#ibp-console-govern-update-channel-available-parameters-advanced
・IBM Blockchain Platform用いたHLFネットワークの構築手順
https://cloud.ibm.com/docs/blockchain-sw-252?topic=blockchain-sw-252-ibp-console-build-network
森下 恵里 氏
日本アイ・ビー・エム システムズ・エンジニアリング株式会社
ITスペシャリスト
2012年日本IBM入社以降、製造業を中心にシステム基盤更改案件に参画し、AIXやストレージなどの設計構築、企画支援に携わる。2016年のISE出向を機にブロックチェーン技術やクラウドでのシステム構築に携わる。また近年はIA系システムの計画支援やシステム評価支援を行っている。
［i Magazine・IS magazine］
