web3-infra
AWS で archive/RPC node を追加するときの容量と分離
archive/RPC node を追加するときの Terraform 境界、disk sizing、instance class、RPC/metrics の閉じ方を公開用に整理した記録。
目的は、archive/RPC capacity を追加し、無関係な既存 host には触らないことだった。 そのため、作業の中心は「起動すること」よりも「Terraform の影響範囲を狭く保つこと」になった。 対象 node だけを enable し、個別の security group を追加し、disk と instance class を明示する。 すでに tuning 済みの大きい構成は、fleet 全体の default ではなく個別の例外として扱った。
用語の説明
| 用語 | 意味 |
|---|---|
| archive node | 過去 block、receipt、trace、過去時点の balance を問い合わせられるように履歴状態を保持する node。 |
| RPC | application や script が node に問い合わせる HTTP API。EVM 系では JSON-RPC が多い。 |
| P2P | 他の node と接続し、block や network data を交換するための port。 |
| security group | AWS の instance や network interface に付く firewall rule。 |
| EBS | AWS の block storage。node の chain database は data volume に置く。 |
| gp3 | 容量、IOPS、throughput を分けて設定できる EBS volume type。 |
| Terraform plan | apply 前に、作成、変更、置換される resource を確認する preview。 |
変更したもの
node はいくつかの profile に分けた。
| Profile | Client | Instance class | Data volume |
|---|---|---|---|
| Large EVM archive node | Erigon archive node | r7i.2xlarge | 4096 GiB |
| Medium EVM archive node | Erigon と必要に応じた consensus client | r7i.2xlarge | 2048 GiB |
| Substrate-style RPC node | archive/RPC workload を持つ chain client | r7i.2xlarge | 4096 GiB |
| Additional Substrate-style RPC node | 同じ client family、独立した network profile | r7i.2xlarge | 4096 GiB |
これらの profile では gp3 の data volume を使い、I/O も明示的に provision した。 disk size は、現時点の参考値ぎりぎりにはしなかった。 blockchain database は空き容量が少なくなると性能も安定性も落ちやすい。 archive/RPC node では、余白も運用設計の一部になる。
すでに tuning 済みの node は、大きい構成のまま残した。
hardfork 対応、client の挙動、storage throughput で別の圧力が出ていたためだ。
新しい node は r7i.2xlarge から始め、CPU、memory、I/O wait、sync speed を見て個別に調整する方が自然だった。
Network boundary
広く開いた security group は使い回さない。 新しい node ごとに security group を分けた。 P2P は chain の peer discovery に必要な port を公開し、RPC と metrics は private network または明示的に許可した source に閉じた。
| Traffic | Boundary |
|---|---|
| P2P | chain-specific な P2P port を internet から到達可能にする。 |
| RPC | trusted private range または明示的に許可した source のみ。 |
| metrics | monitor host から scrape する。public には出さない。 |
| SSH | application port とは別に管理する。 |
一部の EVM node では、RPC/metrics を process 側でも 127.0.0.1 に bind できる。
別の EC2 から使う場合は、proxy、tunnel、host 側 forwarding のような制御された経路を用意する。
security group を開けても、service が loopback にしか bind していなければ外からは届かない。
Client version
Erigon 系 node は upstream Erigon v3.4.4 に固定した。
archive mode は --prune.mode=archive を明示したままにした。
Substrate-style node は client version を固定した。
latest tag は便利だが、restart のたびに検証済み binary からずれる可能性がある。
node infrastructure では、version change は明示的な変更として扱いたい。
一部の EVM network では consensus client も必要になる。 post-merge の network では、execution client 単体では不十分だ。 execution と consensus は local JWT で認証する。 JWT は container argument に直接置かず、file として渡す方が扱いやすい。 command line は process list や container inspect から見えやすいからだ。
Plan の見方
apply 前に確認したいのは、Terraform が成功するかどうかではなく、plan の形が依頼内容と合っているかどうかだ。
| 出てよいもの | 出てはいけないもの |
|---|---|
| 対象 EC2 node | scope 外の既存 node の置換 |
| 対象 node の data volume | 無関係な database や application resource の変更 |
| node-specific security group | 広すぎる rule の使い回し |
| 必要な monitoring rule | global な network policy 変更 |
scope 外の置換が見えたら apply しない。 まず plan を狭くする。 infrastructure では、apply が通ることと、変更が正しいことは別の話だ。
起動後に見たもの
起動直後は、まず単純な状態から見る。
docker ps
df -h /data
curl -s http://127.0.0.1:8545
EVM node では次の RPC が役に立つ。
{"jsonrpc":"2.0","method":"eth_blockNumber","params":[],"id":1}
{"jsonrpc":"2.0","method":"eth_syncing","params":[],"id":1}
{"jsonrpc":"2.0","method":"trace_block","params":["0xf4240"],"id":1}
Substrate-style node では、block height が進むか、peer が安定するか、parachain と relaychain の log が両方動くかを見る。
archive mode で起動したことと、最新 head まで同期済みであることは別だ。 正しく構成された archive node でも、current head に追いつくまでにはかなり時間がかかる。
運用上の持ち帰り
大事なのは、変更範囲を狭く保つことだった。 新しい node は新しい instance、data volume、security group を持つ。 既存 host は巻き込まない。 その後の tuning は chain ごとの CPU、memory、disk I/O、sync speed を見て決めればよい。