Dockerでサービスを運営できたら便利そうだと思い、勉強も兼ねて自宅サーバーでDocker Swarmの運用に挑戦していました。
しかし、数々の失敗と試行錯誤を繰り返した結果、最終的には「やらなければよかった」という結論に行き着きました。
今回は、その失敗の軌跡と、回り道をして気づいた「本当に最適な構成」について振り返ってみたいと思います。
第1期:GCPの格安インスタンス時代
最初は、GCPの「定期的に落ちる代わりに安い」インスタンス(プリエンプティブルインスタンス)を組み合わせてクラスターを構築しました。
落ちたらまた立ち上げるという自動化を組んでみたものの、かなりの頻度でインスタンスが落ちるため、再起動を繰り返すうちにクラスター全体が不安定になってしまいました。
結局、この構成は使い物にならず断念しました。
第2期:さくらのVPS時代
次に、さくらのVPSを契約して構築を試みました。
しかし、Docker Swarmでクラスターを維持するには最低3台のノードが必要になります。
個人で3台も契約するとかなりの維持費がかかってしまうため、これも長くは続きませんでした。
第3期:Raspberry Pi + VPNのハイブリッド時代
「それなら自宅のRaspberry Piを混ぜれば安く済むのでは」と考え、自宅のRaspberry PiとさくらのVPS1台をVPNで繋ぎ、3台構成のクラスターを作りました。
コストも抑えられて最初は「これは良い!」と思ったのですが、思わぬ落とし穴がありました。
家庭用のインターネット回線は、普通に使っている分には気づかないレベルで「プツプツと瞬断する」ことがあるようです。
ルーター自体は通信できていても、グローバルへの接続が不安定になるタイミングがあり、結果としてクラスターの同期が取れずまともに機能しなくなってしまいました。
結局、絶対に落ちてはいけないサービスはさくらのVPS側に集めることになり、クラスターを維持するためにさくらのVPSを2台借りるという本末転倒な状態に。
なんだかよくわからない複雑な構成になっただけで、サービスを安定して運営することはできませんでした。
そもそも、なぜ自宅サーバーが必要だったのか?
原点に立ち返ってみると、自宅にサーバーを置きたかった最大の理由は「家の中のソーラーパネルや温度計のデータを収集したかったから」です。
特にソーラーパネルのデータはローカルネットワークから取得する必要がありました。
しかし、その目的を果たすためだけなら、複数台のクラスターなんて全く不要でした。
「Raspberry Pi 1台の上でSwarmを動かし、そこにCloudflare Tunnelで接続する」
ただそれだけで十分だったのです。
これならルーターのポートを開けることなく、安全かつ無料でグローバルからアクセスできます。
ちなみに、SwarmをCloudflareでゼロトラスト化する具体的な手順は以前まとめています。
👉 【脱VPN】自宅SwarmのWebサービスをCloudflare Access + Terraformでゼロトラスト化する
外部公開サービスにDockerは不要だった
そして最も痛感したのは、グローバルに公開するWebサービスについての気づきです。
わざわざDockerイメージを作って自前でホスティングしなくても、Astroでサイトを作ってCloudflare Pagesにデプロイするだけでよかったのです。
インフラの構築や維持という「手段」に縛われすぎたせいで、肝心のサービスを開発して公開することが全くできず、開発者としての時間を大きく無駄にしてしまいました。
この時間的な損失の方が、サーバー代よりもよほど恐ろしい話です。
モノを持たないことの身軽さ
今回の自宅サーバー構築にあたり、停電対策として無停電電源装置(UPS)も購入していました。
しかし、結局構成を廃止したため不要になり、処分するのにお金を払って引き取ってもらうなど本当に大変な思いをしました。
👉 自宅にUPS(無停電電源装置)はいらない。導入して後悔した変態の話
振り返ってみれば、自宅サーバーはうまくいった試しがなく、気づけば落ちていてトラブル対応に追われるばかりでした。
さくらのVPS上で組んだSwarmですら、いつの間にか停止していることがありました。
極端な話、ソーラーパネルのデータを集めること自体も、本当に自分にとって必要なことだったのか疑問に感じています。
何も持たず、何もしないのが一番身軽で正解だったのかもしれません。
少し嫌な気分にもなりましたが、たくさん失敗して「これは自分には不要だ」と心底理解できたので、もう二度と同じ過ちを繰り返さずに済みそうです。
結論
本当に作りたいものを形にして公開したいのなら、自前でサーバーを抱えるべきではありません。
Cloudflare Pagesのようにすべてを管理してくれるモダンな環境や、あるいは昔ながらのレンタルサーバーを使う方が、確実で、堅牢で、そして何よりスピーディです。
インフラのトラブルに悩まされることなく、これからも身軽に開発を楽しんでいこうと思います。
追記(2026-09-07):この2か月後、また建てました
この記事は「自宅サーバーもDocker Swarmも全部手放した」で終わっています。正直に書くと、そのあとまた建てました。今は自宅のRaspberry Pi 5でSwarmが動いていて、監視のPrometheusとGrafana、Thanos、それにブックマーク管理のLinkdingや太陽光発電の記録などが載っています。二度と繰り返さないと書いた本人が、2か月後には同じことをしているわけです。
言い訳ではなく、何が違ったかを書いておきます。
手放したのは「公開サービスを自宅から出すこと」で、建て直したのは「自分だけが使う道具」です。 当時の失敗は、外向けのWebサービスを自宅回線とVPNで支えようとしたところにありました。回線が落ちれば止まりますし、証明書もポート開放も自分の責任になります。この記事で「外部公開サービスにDockerは不要だった」と書いたのは今でも正しくて、公開しているサイトは全部Cloudflare側にあります。
一方で、監視やログのように外に出す必要がなく、外部サービスに置くと課金が積み上がるものは、手元のマシンで動かすほうが合っていました。しかも当時の記事の中で「Raspberry Pi 1台とCloudflare Tunnelで十分だったのでは」と自分で書いています。今の構成はまさにそれです。結論の形は変わりましたが、そこへ至る診断は当時のもので合っていました。
もうひとつ、記事の最後で「ソーラーのデータ収集も本当に必要だったのか疑問」と書きました。これも今は答えが出ていて、発電量の記録は今のSwarmでちゃんと動いています。見えるようになると洗濯機を回す時間が変わるので、必要でした。
「全部やめる」と「全部やる」の間に、用途で切り分ける線があったというのが、2か月かけて分かったことです。この記事を読んで自宅サーバーを畳もうとしている人には、外向けだけ畳んで手元の道具は残す、という選択肢もあると伝えておきます。