2021年春に書いた前回の記事は、Symbolがローンチしたてで、XYMの価格も40円前後と景気の良い頃の話です。当時の僕はAWS Lightsailという、格安とは言え月額1万円以上かかるホスティングサービスをつかってsymbolノードを動かしておりました。
2026年4月現在のXYM価格は0.4円だとかをウロウロ・・・100分の1ですね。
僕の少ない保有XYMによるハーベスト収入では、月額1万円以上かかるホスティングサービスはペイするはずもなく、XYM価格が10円を切った頃にLightsailをやめて、自宅サーバー的なIntel N100系のミニPCを自分の事務所で動かし、そこでsymbolノードを運営しています。
前回の記事では、主にSymbolノード運営にあたってのセキュリティ設定の話を書きました。今回はその続編として、2026年現在、実際にどういう構成でノードを動かしているのかを、構成図も含めて書いてみます。
全体の構成
現在の構成をざっくり図にすると、こんな感じです。
+----------------------------------+
| インターネット |
+----------------+-----------------+
|
| HTTPS / Symbol通信用
|
+------------v-------------+
| indigo1 |
| WebArena VPS |
| 月額449円 |
|--------------------------|
| nginx |
| certbot |
| sshd |
| rminis.rellc.jp を公開 |
+------------+-------------+
^
| reverse ssh tunnel
| ssh -R 3000:localhost:3000
| ssh -R 7900:localhost:7900
|
+------------+-------------+
| rminis |
| Intel N100系 ミニPC |
| 事務所内で常時稼働 |
| 電気代月500円程度 |
|--------------------------|
| symbol-bootstrap |
| Docker |
| - node |
| - broker |
| - db(mongo) |
| - rest-gateway |
| health check script |
| Slack通知 |
+--------------------------+ - node
- broker
- db
- rest-gateway
# REST Gateway 用 (HTTPS, port 3001)server { listen 3001 ssl; server_name rminis.rellc.jp; access_log /var/log/nginx/rminis_access.log; error_log /var/log/nginx/rminis_error.log; ssl_certificate /etc/letsencrypt/live/rminis.rellc.jp/fullchain.pem; ssl_certificate_key /etc/letsencrypt/live/rminis.rellc.jp/privkey.pem; location / { proxy_pass https://localhost:3000; proxy_http_version 1.1; proxy_set_header Host $host; proxy_set_header X-Real-IP $remote_addr; proxy_set_header Upgrade $http_upgrade; proxy_set_header Connection "upgrade"; }}
VPS側で3001番をHTTPSで受けて、ローカルの3000番に回している。ローカルの3000番は後述の通りsshでrminis側までもっていく
rminis側からのsshポートフォワード接続
3000番 : SymbolのREST API用7900番 : Symbolのノード間通信用
それぞれ -R 3000:localhost:3000 -R 7900:localhost:7900 としてフォワードするので
ssh -N -f -R 3000:localhost:3000 -R 7900:localhost:7900 indigo1
こーいう接続ですね
この構成にしている理由
理由はコストと安全性のバランスです。
ノード本体をクラウドに置くと、回線や電源の心配は減りますが、個人運営としては固定費が高くなります。一方、N100系のミニPCを事務所で動かせばランニングコストはかなり下げられます。ただし、そのまま事務所内のマシンを直接インターネットにさらすのは、運用上もセキュリティ上もあまり気持ちよくありません。
そこで、公開面だけを月額449円の安いVPSに持たせ、ノード本体は内側に置く形にしています。これなら費用を抑えつつ、公開設定やHTTPS終端もやりやすくなります。
N100ミニPCの電気代を月500円程度と見積もっており、月額449円のVPSと合わせても1000円/月程度と、僕の少ないハーベスト収入でも・・・あ！今のレートでちゃんと計算したらもう赤字かも・・・ギリトントン・・・？
監視と自動復旧
ローカルでノードを動かしている以上、監視は必須です。現在はヘルスチェック用のスクリプトを回していて、REST API の /node/health を見ながら、必要に応じて再起動やトンネル再接続を行っています。
流れとしてはだいたいこんな感じです。
- indigo1 への reverse ssh tunnel が生きているか確認
- REST API の /node/health を確認
- 異常ならトンネル再接続
- それでもだめなら symbol-bootstrap を再起動
- Slack に通知
- ノード本体は事務所内の Intel N100 系ミニPC rminis
- 公開フロントは WebArena の月額449円VPS indigo1
- indigo1 側で nginx + certbot によりリバースプロキシと HTTPS 終端
- rminis から indigo1 へ ssh -R でポート転送
- ノード監視は REST API の /node/health と Slack 通知で対応
rminis に自由に入れる経路は作っていませんし、ssh鍵も rminis の公開鍵を VPS 側に登録しているだけです。公開用VPSがそのまま内側へ踏み込むための踏み台にならないようにしている、というのがこの構成のポイントです。
2021年の頃は「どうやってノードを守るか」を主に考えていましたが、2026年の今は「どういう構成なら、安く、無理なく、そこそこ安全に続けられるか」を考えた結果、今の形に落ち着いています。
余談：cloudflare tunnelはどうよ？
自宅サーバーで動かしているサービスを外から接続するためにcloudflare tunnelがよく使われていますが、今回のようなSymbolノード用途では、少なくとも僕の構成ではメインには採用していません。
理由は単純で、cloudflare tunnel はHTTP/HTTPS系の公開にはかなり便利なのですが、Symbolノードのように peer node として外部ノードから普通のTCP接続を受けたい用途とは相性があまり良くないからです。REST API をHTTPSで見せるだけならかなり相性がいいのですが、ノード間通信用のポートまでまとめて置き換えるのは難しいです。
なので、たとえば「REST API だけ安全に公開したい」とか、「自宅内の管理画面を外から見たい」といった用途なら cloudflare tunnel はかなり有力だと思います。一方で、公開ノードとしてちゃんと外部ノードと通信させたい、という用途では、今の僕の構成だと結局 TCP を素直に受けられる経路を別に持っておいた方がわかりやすい、という判断になります。
あと、個人的には、公開フロントを安価なVPSに分離しておくと、HTTPS終端や名前解決や中継の責務が整理しやすく、構成としても理解しやすいと感じています。WebArena の月額449円VPSならコストもそこまで重くないので、今のところは indigo1 を残す方針です。
便利そうには見えるんですが、Symbolノード用途だと「これ一発で全部解決」という感じではないんですよね。少なくとも僕は、REST API用途ならともかく、ノード間通信用途まで含めると素直にVPSを1枚噛ませる方が安心だと思っています。
なんだかWebArenaの宣伝をしてる気分になってきましたが、残念ながらWebArenaは安すぎてアフィリエイトもないんですね（苦笑）
それではみなさんも、なるべく安く安全なノード運営を！ 投稿者： ほそいりょすけのほめぱげ 投稿日時： 2026年4月6日(月) 03:22