share facebook facebook twitter menu hatena pocket slack

2019.06.18 TUE

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

甲斐 甲

WRITTEN BY 甲斐 甲

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

元記事はこちら

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

甲斐 甲

甲斐 甲

2018/7にJOIN。 最近の好みはサーバレスです。なんでもとりあえず試します。

cloudpack

cloudpackは、Amazon EC2やAmazon S3をはじめとするAWSの各種プロダクトを利用する際の、導入・設計から運用保守を含んだフルマネージドのサービスを提供し、バックアップや24時間365日の監視/障害対応、技術的な問い合わせに対するサポートなどを行っております。
AWS上のインフラ構築およびAWSを活用したシステム開発など、案件のご相談はcloudpack.jpよりご連絡ください。