2026年現在の僕のSymbolノード運営構成とコスト削減について

投稿者:rhosoiカテゴリー:crypto、lanタグ:、、

2021年春に書いた前回の記事は、Symbolがローンチしたてで、XYMの価格も40円前後と景気の良い頃の話です。当時の僕はAWS Lightsailという、格安とは言え月額1万円以上かかるホスティングサービスをつかってsymbolノードを動かしておりました。

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通知                |
                  +--------------------------+

ノード本体は事務所内で動かしている rminis にあり、外部公開の入口だけを indigo1 に持たせています。indigo1 は WebArena の月額449円のVPSで、ここでは nginx と certbot を使ってリバースプロキシと HTTPS 終端を担当させています。

つまり、Symbolノードの実体はあくまで rminis 側にあり、インターネットに見えているフロントだけを安価なVPS側に分離している形です。

また、月額維持コストは約1000円と、Lightsail時代の10分の1以下を達成しています。

役割分担について

rminis

事務所内で動いている Intel N100 系のミニPCです。ここがSymbolノード本体です。symbol-bootstrap を使って mainnet の dual 構成で動かしていて、実際には以下のコンテナ群が動いています。

  • node
  • broker
  • db
  • rest-gateway

ノードの本体機能はすべてこちらにあります。ハーベストも当然こちらです。

indigo1

こちらは公開用のフロントです。WebArena の月額449円VPSを使っています。ここで nginx によるリバースプロキシと certbot による証明書管理を行い、 rminis.rellc.jp への外部アクセスを受けています。

REST Gateway用のnginx設定

# 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 http://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 を見ながら、必要に応じて再起動やトンネル再接続を行っています。

流れとしてはだいたいこんな感じです。

  1. indigo1 への reverse ssh tunnel が生きているか確認
  2. REST API の /node/health を確認
  3. 異常ならトンネル再接続
  4. それでもだめなら symbol-bootstrap を再起動
  5. Slack に通知

ローカル運用だと、「ノード本体が止まった」のか「公開側とのトンネルが死んだ」のかを分けて見ないと原因を取り違えやすいので、そのあたりも含めて監視しています。

2021年との違い

2021年との一番の違いは、クラウド上に全部載せるのをやめたことです。

当時は AWS Lightsail に全部を置いていましたが、個人運営では固定費が重すぎました。今は、ノード本体は事務所内のN100系ミニPCで動かし、公開面とHTTPS終端だけを WebArena の月額449円VPSに分けています。

この形にしてから、固定費はかなり軽くなりましたし、しかも公開面の整理やセキュリティ上の見通しも良くなりました。クラウド1台完結ほどシンプルではないですが、個人で長く回すにはかなりバランスの良い構成だと思っています。

まとめ

2026年現在の僕のSymbolノード構成は以下のようになっています

  • ノード本体は事務所内の Intel N100 系ミニPC rminis
  • 公開フロントは WebArena の月額449円VPS indigo1
  • indigo1 側で nginx + certbot によりリバースプロキシと HTTPS 終端
  • rminis から indigo1 へ ssh -R でポート転送
  • ノード監視は REST API の /node/health と Slack 通知で対応

派手な構成ではありませんが、コストを抑えつつ、公開面とノード本体を分離できるので、個人運営としてはかなり実用的です。特に、公開用VPSが万一侵害されても、内側の rminis までは侵入されにくいという点は、この構成の大きな利点ですね。

もちろん、これは魔法のように絶対安全という話ではありません。ただ、少なくとも公開用VPS側から内側の 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は安すぎてアフィリエイトもないんですね（苦笑）

それではみなさんも、なるべく安く安全なノード運営を！

投稿者: rhosoi

アールホソイです。

コメントを残す

rhosoi blogをもっと見る

今すぐ購読し、続きを読んで、すべてのアーカイブにアクセスしましょう。

続きを読む