gethが求めるサーバスペック(aws編)

※2024/01追記

すでにEthereumはPOSに移行しており、ExecutionレイヤーとConsensusレイヤーに分かれています。
Execution側のノードはgeth等のノード、Consensusレイヤー側はprysm等を使うようになっていますので各自ググってください。
本記事は昔話として残しておきます。

Execution layer:
- Besu
- Erigon
- Geth
- Nethermind
- Reth

Consensus layer:
- Lighthouse
- Lodestar
- Nimbus
- Prysm
- Teku


---

k8sの激しい脆弱性で青ざめている皆様おこんにちわ。[@Derorisan](https://twitter.com/Derorisan)こと村田です。
gethのノードを使いたいと思ったときには良い子はinfura.ioを使うのが一般的かと思いますが、軽い気持ちでawsのec2で立ち上げてみようと思いました。

・・・のがいけなかった。

fastmodeにてt3.mediumで試していたがぜんぜんsyncが終わらずに涙目になる結果に。
昔はラズパイてきなものでも楽勝だったのに・・・・

ということで、どのくらいのスペックが必要になっているのか検証してみました。

infura.ioの記事では2018/3にm5.xlargeからi3.xlargeに上げれば2倍処理できるからコスパ(・∀・)ｲｲ!!みたいな記事がありましたのでそのあたりのインスタンスで試します。
[Optimizing Performance and Cost: Infura Benchmark Analysis](https://blog.infura.io/optimizing-performance-and-cost-infura-benchmark-analysis-f083ccf8f6ac) 


# 目的

まぁ上記の通り予想外の事案なので、とりあえず良い感じに動くインスタンスを探そうと思います。
どうせすぐに要求スペックは変動してしまうと思うので、沼にハマりすぎないように注意！

# 確認方法

## 環境

- aws オレゴンリージョン
- amazon linux 2: 4.14.77-81.59.amzn2.x86_64
- goのバージョン: amazon-linux-extras golang1.9 (go version go1.9.4 linux/amd64)
- geth のバージョン: v1.8.19
- 起動オプション: `./build/bin/geth --datadir=/extend-data/geth --syncmode=fast`

awsのセキュリティグループはTCPとUDPで30303を開けておくとよろしい。(ノード同士の通信ポート)

# やっていく

## i3.xlearge

まずはsyncされたデータを作りたいので2018/3月にinfura.ioが検証していたi3.xleargeで行う。
i3.xlargeはNVMeのEBSがついてくるのでそれのマウントから行う。

### EBSマウント

```bash
[ec2-user@ip-10-242-0-241 ~]$ uname -a
Linux ip-10-242-0-241.us-west-2.compute.internal 4.14.77-81.59.amzn2.x86_64 #1 SMP Mon Nov 12 21:32:48 UTC 2018 x86_64 x86_64 x86_64 GNU/Linux
[ec2-user@ip-10-242-0-241 ~]$ sudo parted -l
Model: Xen Virtual Block Device (xvd)
Disk /dev/xvda: 8590MB
Sector size (logical/physical): 512B/512B
Partition Table: gpt
Disk Flags: 

Number  Start   End     Size    File system  Name                 Flags
128     1049kB  2097kB  1049kB               BIOS Boot Partition  bios_grub
 1      2097kB  8590MB  8588MB  xfs          Linux


Error: /dev/nvme0n1: unrecognised disk label
Model: NVMe Device (nvme)                                                 
Disk /dev/nvme0n1: 950GB
Sector size (logical/physical): 512B/512B
Partition Table: unknown
Disk Flags: 

[ec2-user@ip-10-242-0-241 ~]$ sudo mkfs.xfs /dev/nvme0n1
meta-data=/dev/nvme0n1           isize=512    agcount=4, agsize=57983399 blks
         =                       sectsz=512   attr=2, projid32bit=1
         =                       crc=1        finobt=0, sparse=0
data     =                       bsize=4096   blocks=231933593, imaxpct=25
         =                       sunit=0      swidth=0 blks
naming   =version 2              bsize=4096   ascii-ci=0 ftype=1
log      =internal log           bsize=4096   blocks=113248, version=2
         =                       sectsz=512   sunit=0 blks, lazy-count=1
realtime =none                   extsz=4096   blocks=0, rtextents=0
[ec2-user@ip-10-242-0-241 ~]$ sudo mkdir /extend-data
[ec2-user@ip-10-242-0-241 ~]$ sudo mount /dev/nvme0n1 /extend-data
[ec2-user@ip-10-242-0-241 ~]$ df -h
Filesystem      Size  Used Avail Use% Mounted on
devtmpfs         15G     0   15G   0% /dev
tmpfs            15G     0   15G   0% /dev/shm
tmpfs            15G  412K   15G   1% /run
tmpfs            15G     0   15G   0% /sys/fs/cgroup
/dev/xvda1      8.0G  1.2G  6.9G  15% /
tmpfs           3.0G     0  3.0G   0% /run/user/1000
/dev/nvme0n1    885G   33M  885G   1% /extend-data
```

EBSボリュームが/extend-dataにマウントできたのでそこをgethのdatadirに指定する予定。

### golangのインストール

golangはamazon linux extraより入れる。

```bash
[ec2-user@ip-10-242-0-241 ~]$ sudo amazon-linux-extras install golang1.9 -y
Installing golang
Loaded plugins: extras_suggestions, langpacks, priorities, update-motd
Cleaning repos: amzn2-core amzn2extra-golang1.9
9 metadata files removed
4 sqlite files removed
0 metadata files removed
Loaded plugins: extras_suggestions, langpacks, priorities, update-motd
amzn2-core                                                                                                                                           | 2.4 kB  00:00:00     
amzn2extra-golang1.9                                                                                                                                 | 1.3 kB  00:00:00     
(1/4): amzn2-core/2/x86_64/group_gz                                                                                                                  | 2.4 kB  00:00:00     
(2/4): amzn2-core/2/x86_64/updateinfo                                                                                                                |  56 kB  00:00:00     
(3/4): amzn2extra-golang1.9/2/x86_64/primary_db                                                                                                      | 3.9 kB  00:00:00     
(4/4): amzn2-core/2/x86_64/primary_db                                                                                                                |  23 MB  00:00:00     
Resolving Dependencies
--> Running transaction check
---> Package golang.x86_64 0:1.9.4-1.amzn2.0.2 will be installed
--> Processing Dependency: golang-src = 1.9.4-1.amzn2.0.2 for package: golang-1.9.4-1.amzn2.0.2.x86_64
--> Processing Dependency: golang-bin = 1.9.4-1.amzn2.0.2 for package: golang-1.9.4-1.amzn2.0.2.x86_64
--> Running transaction check
---> Package golang-bin.x86_64 0:1.9.4-1.amzn2.0.2 will be installed
--> Processing Dependency: gcc for package: golang-bin-1.9.4-1.amzn2.0.2.x86_64
---> Package golang-src.noarch 0:1.9.4-1.amzn2.0.2 will be installed
--> Running transaction check
---> Package gcc.x86_64 0:7.3.1-5.amzn2.0.2 will be installed
--> Processing Dependency: cpp = 7.3.1-5.amzn2.0.2 for package: gcc-7.3.1-5.amzn2.0.2.x86_64
--> Processing Dependency: glibc-devel >= 2.2.90-12 for package: gcc-7.3.1-5.amzn2.0.2.x86_64
--> Processing Dependency: libubsan.so.0()(64bit) for package: gcc-7.3.1-5.amzn2.0.2.x86_64
--> Processing Dependency: libtsan.so.0()(64bit) for package: gcc-7.3.1-5.amzn2.0.2.x86_64
--> Processing Dependency: libquadmath.so.0()(64bit) for package: gcc-7.3.1-5.amzn2.0.2.x86_64
--> Processing Dependency: libmpxwrappers.so.2()(64bit) for package: gcc-7.3.1-5.amzn2.0.2.x86_64
--> Processing Dependency: libmpx.so.2()(64bit) for package: gcc-7.3.1-5.amzn2.0.2.x86_64
--> Processing Dependency: libmpfr.so.4()(64bit) for package: gcc-7.3.1-5.amzn2.0.2.x86_64
--> Processing Dependency: libmpc.so.3()(64bit) for package: gcc-7.3.1-5.amzn2.0.2.x86_64
--> Processing Dependency: liblsan.so.0()(64bit) for package: gcc-7.3.1-5.amzn2.0.2.x86_64
--> Processing Dependency: libitm.so.1()(64bit) for package: gcc-7.3.1-5.amzn2.0.2.x86_64
--> Processing Dependency: libcilkrts.so.5()(64bit) for package: gcc-7.3.1-5.amzn2.0.2.x86_64
--> Processing Dependency: libatomic.so.1()(64bit) for package: gcc-7.3.1-5.amzn2.0.2.x86_64
--> Processing Dependency: libasan.so.4()(64bit) for package: gcc-7.3.1-5.amzn2.0.2.x86_64
--> Running transaction check
---> Package cpp.x86_64 0:7.3.1-5.amzn2.0.2 will be installed
---> Package glibc-devel.x86_64 0:2.26-28.amzn2.0.1 will be installed
--> Processing Dependency: glibc-headers = 2.26-28.amzn2.0.1 for package: glibc-devel-2.26-28.amzn2.0.1.x86_64
--> Processing Dependency: glibc-headers for package: glibc-devel-2.26-28.amzn2.0.1.x86_64
---> Package libatomic.x86_64 0:7.3.1-5.amzn2.0.2 will be installed
---> Package libcilkrts.x86_64 0:7.3.1-5.amzn2.0.2 will be installed
---> Package libitm.x86_64 0:7.3.1-5.amzn2.0.2 will be installed
---> Package libmpc.x86_64 0:1.0.1-3.amzn2.0.2 will be installed
---> Package libmpx.x86_64 0:7.3.1-5.amzn2.0.2 will be installed
---> Package libquadmath.x86_64 0:7.3.1-5.amzn2.0.2 will be installed
---> Package libsanitizer.x86_64 0:7.3.1-5.amzn2.0.2 will be installed
---> Package mpfr.x86_64 0:3.1.1-4.amzn2.0.2 will be installed
--> Running transaction check
---> Package glibc-headers.x86_64 0:2.26-28.amzn2.0.1 will be installed
--> Processing Dependency: kernel-headers >= 2.2.1 for package: glibc-headers-2.26-28.amzn2.0.1.x86_64
--> Processing Dependency: kernel-headers for package: glibc-headers-2.26-28.amzn2.0.1.x86_64
--> Running transaction check
---> Package kernel-headers.x86_64 0:4.14.77-81.59.amzn2 will be installed
--> Finished Dependency Resolution

~snip;

[ec2-user@ip-10-242-0-241 ~]$ go version
go version go1.9.4 linux/amd64
```

### gethのビルド

何も考えずにec2-userのホームディレクトリへ。
https://github.com/ethereum/go-ethereum/releases から今のところ最新のNo Nick (v1.8.19)をDLしてビルドする。


```
[ec2-user@ip-10-242-0-241 ~]$ wget https://github.com/ethereum/go-ethereum/archive/v1.8.19.tar.gz
~snip;
[ec2-user@ip-10-242-0-241 ~]$ tar zxfv v1.8.19.tar.gz 
~snip;
[ec2-user@ip-10-242-0-241 ~]$ cd go-ethereum-1.8.19/

[ec2-user@ip-10-242-0-241 go-ethereum-1.8.19]$ make geth
build/env.sh go run build/ci.go install ./cmd/geth
>>> /usr/lib/golang/bin/go install -v ./cmd/geth
github.com/ethereum/go-ethereum/vendor/golang.org/x/sys/unix
github.com/ethereum/go-ethereum/common/hexutil
github.com/ethereum/go-ethereum/crypto/sha3

~snip;
Done building.
Run "/home/ec2-user/go-ethereum-1.8.19/build/bin/geth" to launch geth.
```

これでビルドできた。


### gethの起動

おっとその前に`/extend-data/geth`ディレクトリをほっておこう

```bash

[ec2-user@ip-10-242-0-241 go-ethereum-1.8.19]$ sudo mkdir /extend-data/geth
[ec2-user@ip-10-242-0-241 go-ethereum-1.8.19]$ sudo chown ec2-user:ec2-user /extend-data/geth
```


起動しよう。

```bash

[ec2-user@ip-10-242-0-241 go-ethereum-1.8.19]$ ./build/bin/geth --datadir=/extend-data/geth --syncmode=fast
INFO [12-06|02:48:18.614] Maximum peer count                       ETH=25 LES=0 total=25
INFO [12-06|02:48:18.616] Starting peer-to-peer node               instance=Geth/v1.8.19-stable/linux-amd64/go1.9.4
INFO [12-06|02:48:18.616] Allocated cache and file handles         database=/extend-data/geth/geth/chaindata cache=512 handles=512

~snip;
```

数秒もすればStateとblockを落とし始める。

```
WARN [12-06|02:48:33.918] Header broke chain ancestry              peer=d7af2b1b359c1e65 number=2 hash=b495a1…4698c9
INFO [12-06|02:48:34.972] Imported new block headers               count=384 elapsed=842.399ms number=384 hash=d3d5d5…c79cf3 age=3y4mo3w
INFO [12-06|02:48:34.980] Imported new block receipts              count=2   elapsed=81.303µs  number=2   hash=b495a1…4698c9 age=3y4mo3w  size=8.00B
INFO [12-06|02:48:35.118] Imported new state entries               count=1624 elapsed=192.602µs processed=1624 pending=20672 retry=0 duplicate=0 unexpected=0
INFO [12-06|02:48:35.136] Imported new block receipts              count=4    elapsed=124.871µs number=6   hash=1f1aed…6b326e age=3y4mo3w  size=1.10kB
INFO [12-06|02:48:35.282] Imported new block receipts              count=26   elapsed=313.617µs number=32  hash=88be69…60ae13 age=3y4mo3w  size=1.18kB
INFO [12-06|02:48:35.402] Imported new state entries               count=768  elapsed=1.190ms   processed=2392 pending=26243 retry=0 duplicate=0 unexpected=0
INFO [12-06|02:48:35.999] Imported new state entries               count=787  elapsed=2.067ms   processed=3179 pending=26495 retry=0 duplicate=0 unexpected=0
INFO [12-06|02:48:36.268] Imported new state entries               count=1152 elapsed=2.651ms   processed=4331 pending=26817 retry=0 duplicate=0 unexpected=0
INFO [12-06|02:48:36.816] Imported new state entries               count=1152 elapsed=3.468ms   processed=5483 pending=26124 retry=0 duplicate=0 unexpected=0
```


syncの状態を確認すると・・・

```
[ec2-user@ip-10-242-0-241 ~]$ go-ethereum-1.8.19/build/bin/geth attach --datadir=/extend-data/geth
Welcome to the Geth JavaScript console!

instance: Geth/v1.8.19-stable/linux-amd64/go1.9.4
 modules: admin:1.0 debug:1.0 eth:1.0 ethash:1.0 miner:1.0 net:1.0 personal:1.0 rpc:1.0 txpool:1.0 web3:1.0

> eth.syncing
{
  currentBlock: 195698,
  highestBlock: 6834170,
  knownStates: 826618,
  pulledStates: 761756,
  startingBlock: 0
}
```

一番高いブロックhighestBlockが入っていれば稼働確認はOK。（https://etherscan.io/ などのlast Blockの数字と比べるとよいかも)
問題なのはpulledStatesとknownStatesで、こいつらは追いつけ追い抜けでどんどん上がっていく。
数日前に確認したら同期完了間近で250,000,000ぐらいの値を叩き出していた。
同期が完了するとeth.syncingがfalseを返すようになる。ログも急におとなしくなる。



現在2018/12/06 12:00頃である。
とりあえずコレで夕方まで放置！


1時間ほどが経過した13時ごろ。

```
> eth.syncing
{
  currentBlock: 3875877,
  highestBlock: 6834321,
  knownStates: 23398655,
  pulledStates: 23353466,
  startingBlock: 0
}
```


14時ごろ

```
> eth.syncing
{
  currentBlock: 4936260,
  highestBlock: 6834321,
  knownStates: 54538287,
  pulledStates: 54393822,
  startingBlock: 0
}
```

16時ごろ 
Stateは250,000,000以上なのでまだまだ。Blockは追いついてきているのにねー。

```
> eth.syncing
{
  currentBlock: 5784354,
  highestBlock: 6834321,
  knownStates: 78447926,
  pulledStates: 78395039,
  startingBlock: 0
}
```

ほんとは定時観測でState部分のデータを取りたかったんだけどやり直すのも時間かかるので許してネ。
24時間かからないぐらいで同期が追いつく気がするよ。

## t3.medium EBS io1 10000IOPS

さてsyncが終わったi3.xlargeを別途ご用意しておりますので、それのデータを使ってt3.mediumあたりでgethを起動する。
syncが追いつかないと予想しているのでeth.synckingが値を返すようになるハズである。
あらかじめ用意しておいたi3.xlargeでのsyncデータをEBSにコピーしてアタッチして起動してみる。

こんな感じになっているはず。

```
[ec2-user@ip-10-242-1-67 ~]$ df -h
Filesystem      Size  Used Avail Use% Mounted on
devtmpfs        1.9G     0  1.9G   0% /dev
tmpfs           1.9G     0  1.9G   0% /dev/shm
tmpfs           1.9G  364K  1.9G   1% /run
tmpfs           1.9G     0  1.9G   0% /sys/fs/cgroup
/dev/nvme0n1p1  8.0G  1.5G  6.6G  19% /
tmpfs           389M     0  389M   0% /run/user/1000
/dev/nvme1n1    200G  148G   53G  74% /extend-data
```

gethをビルドして起動

```
[ec2-user@ip-10-242-1-67 go-ethereum-1.8.19]$ ./build/bin/geth --datadir=/extend-data/geth --syncmode=fast
INFO [12-06|05:51:38.911] Maximum peer count                       ETH=25 LES=0 total=25
INFO [12-06|05:51:38.912] Starting peer-to-peer node               instance=Geth/v1.8.19-stable/linux-amd64/go1.9.4
INFO [12-06|05:51:38.912] Allocated cache and file handles         database=/extend-data/geth/geth/chaindata cache=512 handles=512
INFO [12-06|05:51:42.444] Initialised chain configuration          config="{ChainID: 1 Homestead: 1150000 DAO: 1920000 DAOSupport: true EIP150: 2463000 EIP155: 2675000 EIP158: 2675000 Byzantium: 4370000 Constantinople: <nil> Engine: ethash}"
INFO [12-06|05:51:42.445] Disk storage enabled for ethash caches   dir=/extend-data/geth/geth/ethash count=3
INFO [12-06|05:51:42.445] Disk storage enabled for ethash DAGs     dir=/home/ec2-user/.ethash        count=2
INFO [12-06|05:51:42.445] Initialising Ethereum protocol           versions="[63 62]" network=1
INFO [12-06|05:51:42.489] Loaded most recent local header          number=6834406 hash=0f5295…7fe787 td=8157890197157576340349 age=2h1m29s
INFO [12-06|05:51:42.489] Loaded most recent local full block      number=6834406 hash=0f5295…7fe787 td=8157890197157576340349 age=2h1m29s
INFO [12-06|05:51:42.489] Loaded most recent local fast block      number=6834406 hash=0f5295…7fe787 td=8157890197157576340349 age=2h1m29s
INFO [12-06|05:51:42.495] Loaded local transaction journal         transactions=0 dropped=0
INFO [12-06|05:51:42.496] Regenerated local transaction journal    transactions=0 accounts=0
WARN [12-06|05:51:42.496] Blockchain not empty, fast sync disabled 
INFO [12-06|05:51:42.627] New local node record                    seq=9 id=418734a7558f8c27 ip=127.0.0.1 udp=30303 tcp=30303
INFO [12-06|05:51:42.628] IPC endpoint opened                      url=/extend-data/geth/geth.ipc
INFO [12-06|05:51:42.628] Started P2P networking                   self=enode://a625ff5093e694d48c5efca9beac26dee818f1c3ada7c3353bde25edff21bb25159a3869c51e4505f1b1b6f50dde5c77624f44ab4be9ec18c77708422e164306@127.0.0.1:30303
INFO [12-06|05:51:46.958] New local node record                    seq=10 id=418734a7558f8c27 ip=34.219.58.204 udp=30303 tcp=30303
```

2時間ほど前のデータなので、age=2h1m29sと出ている。fastmodeはsyncが終わるとfullmodeになってfullブロックも落とし始めるらしいので値が入っている。(よく知らない)

```
> eth.syncing
{
  currentBlock: 6834508,
  highestBlock: 6834923,
  knownStates: 250942264,
  pulledStates: 250942264,
  startingBlock: 6834406
}
```

を想定通りeth.syncingが値を返すようになっている。
1時間ほど放置してみよう。

```
> eth.syncing
{
  currentBlock: 6835252,
  highestBlock: 6835254,
  knownStates: 250942264,
  pulledStates: 250942264,
  startingBlock: 6835252
}
```

1時間半ほど放置したら、

```
> eth.syncing
false
```
となりsyncが終わってしまった。追いつかないのを想定していたんだけどっ？
すでにあるデータを利用したのでsyncできたが、ゼロからのsyncだとどのくらいかかるのか・・・(1週間ぐらいやったがだめでした。)

起動してからsyncが追いついて1時間ほど経過したメトリクス
EC2
![image.png](https://qiita-image-store.s3.amazonaws.com/0/56925/436dd2f5-f6cb-37a6-72da-72625bbccb43.png)

EBS
![image.png](https://qiita-image-store.s3.amazonaws.com/0/56925/f5710c34-fd87-5fad-2c37-3cf28633c44e.png)


う〜ん。なんかイマイチこう、ボトルネックがわからないよね。
(t3系なのでcpu creditがなくなっても自動で課金バーストします。)

追いつかないと思ったが一度syncされてしまえばt3.mediumでも稼働はするといったところか。
まぁとりあえず動く、クエリも問題なく戻ってくる。

## m5.xlarge EBS io1 10000IOPS

上のt3.mediumを実行するときに使ったEBSのスナップショットから開始。

```
[ec2-user@ip-10-242-1-67 ~]$ ./go-ethereum-1.8.19/build/bin/geth --datadir=/extend-data/geth --syncmode=fast                                                                                                                                                                                
INFO [12-06|09:08:26.444] Maximum peer count                       ETH=25 LES=0 total=25
INFO [12-06|09:08:26.445] Starting peer-to-peer node               instance=Geth/v1.8.19-stable/linux-amd64/go1.9.4
INFO [12-06|09:08:26.445] Allocated cache and file handles         database=/extend-data/geth/geth/chaindata cache=512 handles=512
INFO [12-06|09:08:29.626] Initialised chain configuration          config="{ChainID: 1 Homestead: 1150000 DAO: 1920000 DAOSupport: true EIP150: 2463000 EIP155: 2675000 EIP158: 2675000 Byzantium: 4370000 Constantinople: <nil> Engine: ethash}"
INFO [12-06|09:08:29.626] Disk storage enabled for ethash caches   dir=/extend-data/geth/geth/ethash count=3
INFO [12-06|09:08:29.626] Disk storage enabled for ethash DAGs     dir=/home/ec2-user/.ethash        count=2
INFO [12-06|09:08:29.627] Initialising Ethereum protocol           versions="[63 62]" network=1
INFO [12-06|09:08:29.662] Loaded most recent local header          number=6834406 hash=0f5295…7fe787 td=8157890197157576340349 age=5h18m16s
INFO [12-06|09:08:29.662] Loaded most recent local full block      number=6834406 hash=0f5295…7fe787 td=8157890197157576340349 age=5h18m16s
INFO [12-06|09:08:29.662] Loaded most recent local fast block      number=6834406 hash=0f5295…7fe787 td=8157890197157576340349 age=5h18m16s
INFO [12-06|09:08:29.674] Loaded local transaction journal         transactions=0 dropped=0
INFO [12-06|09:08:29.675] Regenerated local transaction journal    transactions=0 accounts=0
WARN [12-06|09:08:29.675] Blockchain not empty, fast sync disabled 
INFO [12-06|09:08:29.820] New local node record                    seq=9 id=418734a7558f8c27 ip=127.0.0.1 udp=30303 tcp=30303
INFO [12-06|09:08:29.821] Started P2P networking                   self=enode://a625ff5093e694d48c5efca9beac26dee818f1c3ada7c3353bde25edff21bb25159a3869c51e4505f1b1b6f50dde5c77624f44ab4be9ec18c77708422e164306@127.0.0.1:30303
INFO [12-06|09:08:29.823] IPC endpoint opened                      url=/extend-data/geth/geth.ipc
INFO [12-06|09:08:38.034] New local node record                    seq=10 id=418734a7558f8c27 ip=34.217.61.97 udp=30303 tcp=30303
INFO [12-06|09:09:29.821] Block synchronisation started 
INFO [12-06|09:09:44.705] Imported new chain segment               blocks=2 txs=324 mgas=15.908 elapsed=7.644s mgasps=2.081 number=6834408 hash=9d97eb…8e3add age=5h18m55s cache=2.18mB
INFO [12-06|09:09:54.412] Imported new chain segment               blocks=4 txs=702 mgas=24.354 elapsed=9.697s mgasps=2.511 number=6834412 hash=30b7d6…31931a age=5h18m9s  cache=5.59mB
INFO [12-06|09:10:04.607] Imported new chain segment               blocks=7 txs=797 mgas=42.340 elapsed=10.195s mgasps=4.153 number=6834419 hash=0211af…430e5f age=5h16m53s cache=11.35mB
```

age=5h18m16sが、20分ほどでsyncされた。

体感もそりゃ早い。

EC2(t3.mediumのインスタンスタイプを変更して作ってしまったのでt3のときのデータが残っています。切れているところあたりからm5.xlarge)
![image.png](https://qiita-image-store.s3.amazonaws.com/0/56925/d0e7b9a9-c32f-5f3d-8289-03fe66c99075.png)


EBS
![image.png](https://qiita-image-store.s3.amazonaws.com/0/56925/2c0fe3fc-0982-6933-53c4-5abc0132cf24.png)


# まとめ

## sync中と追いついたあとの負荷が段違い

i3.xlargeあたりのスペックを利用すると余裕を持った運用ができそう。辛抱強くやるのであればm系のlargeあたりでもよいかもしれないが、syncに時間がかかってしまう上、オートスケーリングやk8sなどを利用した場合、インスタンス(Pods)が入れ替わった際にsyncが終わるまで待つ必要がある。
それでも本番運用などしたい！ということであればEBSのスナップショットを取りながら新しいインスタンスは最新のソレから。みたいなことをするのがよさそう。

要するに最新ブロックまで追いつくのに必要なスペックと稼働するだけのスペックの差がハンパねぇってことですね。

ちなみにEFSでも試してみたがぜんぜん遅かったでござる。オススメしない。

## Stateのsync

ブロックのsyncよりもStatesのほうが時間がかかるので注意。
Blockだけ気にしていると値が追いつきそうで追いつかない状況が続く。まじでぐぬぬぬ感を味わうことになるのでご注意ください。

## 予想を上回る要求スペック

ラズパイでgethを動かしていたのはもう遠い昔の話、今はそんなんじゃ無理。（遠い目
maxpeersやcacheのオプションをいじると速くなるかもしれないが、どちらにせよあまったPCで云々とかの場合はご注意あれ。

## 理由がないのであればinfura.io か lightmodeでの利用を！

i3.xlargeって0.366USD/時間かかるわけで、月額3万円ぐらいかかってしまうので、なにかに魅せられた人と、わざわざお金を払って自身でノードを管理したい人以外は、 https://infura.io/ を利用するか、geth syncmodeをlightにして利用しましょう。lightならばt3.mediumでもラクラク動きます。

※ infura.io は consensys とawsがやっているEthereumノードのホスティングサービス。~~今のところタダです。~~ 2019/10月ぐらいから有料プランが出ています。1日10万リクエスト以内なら無料です。