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

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ノードへチェーンコードをデプロイしようとしたらエラーになったのが事の発端でした。


```console
# 環境構築とか初回デプロイ後とかは割愛
> 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コマンドを叩いてディスク容量が確認できるように実装してみました。

```js:チェーンコード抜粋
    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()
      }));
    }
```

実行結果がこちら。

```console
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