Amazon Managed Blockchainを利用してHyperledger Fabricのブロックチェーンネットワークでチェーンコードの開発をしていてハマったのでメモ。
Amazon Managed BlockchainやHyperledger Fabricってなんぞ？という方は下記をご参考ください。
Amazon Managed BlockchainがリリースされたのでHyperledger Fabricも合わせて情報をまとめてみた – Qiita
https://cloudpack.media/46950
Amazon Managed BlockchainでHyperledger Fabricのブロックチェーンネットワークを構築してみた – Qiita
https://cloudpack.media/46963
チェーンコードのデプロイでエラー
Peerノードへチェーンコードをデプロイしようとしたらエラーになったのが事の発端でした。
# 環境構築とか初回デプロイ後とかは割愛
> docker exec \
-e "CORE_PEER_TLS_ENABLED=true" \
-e "CORE_PEER_TLS_ROOTCERT_FILE=/opt/home/managedblockchain-tls-chain.pem" \
-e "CORE_PEER_LOCALMSPID=$MSP" \
-e "CORE_PEER_MSPCONFIGPATH=$MSP_PATH" \
-e "CORE_PEER_ADDRESS=$PEER" \
cli peer chaincode upgrade \
-o $ORDERER \
-C mychannel \
-n $cc_name \
-v $cc_version \
-l node \
-c '{"Args":[""]}' \
--cafile /opt/home/managedblockchain-tls-chain.pem --tls
2019-06-05 01:35:06.356 UTC [chaincodeCmd] checkChaincodeCmdParams -> INFO 001 Using default escc
2019-06-05 01:35:06.356 UTC [chaincodeCmd] checkChaincodeCmdParams -> INFO 002 Using default vscc
Error: could not assemble transaction, err Proposal response was not successful, error code 500, msg failed to execute transaction d165aadcc963ff7b3afd404ea76e1209cd84425be35630b489d3f57b0e4117d5: error starting container: error starting container: Error processing tar file(exit status 1): write /usr/local/src/node_modules/grpc/deps/grpc/src/core/lib/iomgr/ev_epollex_linux.cc: no space left on device
Peerノードでnpm install 実行時にno space left on deviceとか。。。
原因調査してみた
Peerノードでディスク容量が枯渇してnpm install できないってのはわかったのですが、そもそもPeerノードのディスク容量がどれくらいなのか公式サイトをあちこちと調べましたがわかりませんでした。
利用しているインスタンスタイプはbc.t3.smallです。
Amazon Managed Blockchain Instance Types
https://aws.amazon.com/managed-blockchain/instance-types/?nc1=h_ls
フルマネージドなサービスだけにPeerノードがどこで動いているのか、開放されているポート以外にアクセスする方法もみつかりませんでした。。。
ディスク容量が枯渇したPeerノードではどうにもならなさそうだったので、新しくPeerノードを追加して、そちらで調べてみました。
チェーンコード(Node.js)でOSコマンドを叩く
チェーンコードでOSコマンドを叩いてディスク容量が確認できるように実装してみました。
チェーンコード抜粋
async queryDf(stub, args) {
const execSync = require('child_process').execSync;
const df_result = execSync('df -h');
return Buffer.from(JSON.stringify({
"df": df_result.toString()
}));
}
実行結果がこちら。
Filesystem Size Used Avail Use% Mounted on overlay 15G 4.0G 10G 29% / tmpfs 64M 0 64M 0% /dev tmpfs 979M 0 979M 0% /sys/fs/cgroup /dev/mapper/app_storage_vg-app_storage_lv 15G 4.0G 10G 29% /etc/hosts shm 64M 0 64M 0% /dev/shm tmpfs 979M 0 979M 0% /proc/acpi tmpfs 979M 0 979M 0% /sys/firmware
15GB…
oh…
チェーンコードのデプロイを10回実行してみた結果がこちら。
Filesystem Size Used Avail Use% Mounted on overlay 15G 4.5G 9.4G 33% / tmpfs 64M 0 64M 0% /dev tmpfs 979M 0 979M 0% /sys/fs/cgroup /dev/mapper/app_storage_vg-app_storage_lv 15G 4.5G 9.4G 33% /etc/hosts shm 64M 0 64M 0% /dev/shm tmpfs 979M 0 979M 0% /proc/acpi tmpfs 979M 0 979M 0% /sys/firmware
0.5GBほど増加しました。
ディスク容量が枯渇したPeerノードでは50回ほどデプロイしていたので、2.5GBは確実に増えてたみたいです。
それに加えてステートDBやブロックチェーンの情報が加わると15GBが枯渇したのもなんとなく納得。
解決策(を模索中)
深く調べていませんが、Amazon Managed Blockchainの管理コンソールやAPIからPeerノードのインスタンスタイプは変更できなさそうです。
Hyperledger FabricのCLIからチェーンコードを削除することも無理そう。(できたらいろいろまずいはず)
今回のように新しいPeerノードを追加するのが妥当なのでしょうか。。。
あとは、
- 開発中はローカルでHyperledger Fabricのネットワークを構築してそこで動作確認する
- Amazon Managed Blockchainで利用できるインスタンスタイプのディスク容量を調べて、想定するデータサイズを見積もる
などが考えられます。。。そもそもフルマネージドなので、自動でスケールアウトしても良さそうなのになぁ。。。
良い解決策がみつかったら追記します。
参考
Amazon Managed Blockchain Instance Types
https://aws.amazon.com/managed-blockchain/instance-types/?nc1=h_ls
