1
1

Delete article

Deleted articles cannot be recovered.

Draft of this article would be also deleted.

Are you sure you want to delete this article?

More than 5 years have passed since last update.

Amazon Managed BlockchainのPeerノードでディスク容量が枯渇してハマった

Posted at

Amazon Managed Blockchainを利用してHyperledger Fabricのブロックチェーンネットワークでチェーンコードの開発をしていてハマったのでメモ。

Amazon Managed BlockchainやHyperledger Fabricってなんぞ?という方は下記をご参考ください。

Amazon Managed BlockchainがリリースされたのでHyperledger Fabricも合わせて情報をまとめてみた - Qiita
https://qiita.com/kai_kou/items/5a968f42c5f96296f6fe

Amazon Managed BlockchainでHyperledger Fabricのブロックチェーンネットワークを構築してみた - Qiita
https://qiita.com/kai_kou/items/e02e34dd9abb26219a7e

チェーンコードのデプロイでエラー

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

1
1
0

Register as a new user and use Qiita more conveniently

  1. You get articles that match your needs
  2. You can efficiently read back useful information
  3. You can use dark theme
What you can do with signing up
1
1

Delete article

Deleted articles cannot be recovered.

Draft of this article would be also deleted.

Are you sure you want to delete this article?