もともとTinyrackのすべてのサービスは、自宅で直接運用していました。まだ初期段階でトラフィックも多くなかったので、十分に対応できるだろうと考えていました。
ところが、引っ越しをしなければならない状況になりました。これはつまりサービス停止を意味するため、不安が大きくなりました。いろいろ考えた結果、自分だけが使う用途以外のサーバーは、ユーザーのためにも外部クラウドで安定して運用したほうがよいという結論になりました。
最終的に、Hetzner Cloudの仮想マシンを借り、Kubernetesでインフラを新しく構築しました。今回はその過程を紹介します。
クラウドサービスの選定
最初に悩んだのは、どのクラウドサービスを使うかです。開発者であればAmazon AWS、Microsoft Azure、Google Cloud Platformのような大手クラウドを思い浮かべるでしょう。しかし私はまだサービスの収益化を考えていないため、こうした大手クラウドは金銭的な負担が大きく感じられました。最初は無料で始められても、サービスの成長に伴って費用が急激に増える構造だからです。
いろいろ探した結果、最終的に選んだのはドイツのHetznerです。この会社には、非常に安いサーバーレンタル費用と、寛大な利用量ポリシーという大きな利点がありました。
Hetznerの最も安い共有サーバーは4ドル程度で借りられますが、コンピューティング資源とトラフィック制限は他社と比べて圧倒的でした。
これは Vultr という会社の共有サーバー料金表です。最低価格は少し低いものの、割り当てられる資源を見るとHetznerが非常に安いことがわかります。
ここまで安いと、通常は二つの点が心配になります。サービスの安定性と接続速度です。まず安定性については、いくつかのコミュニティで評判を見たところ、大きな問題はないという意見が多くありました。私はすでにHetznerでメールサーバーを安定運用していたため、この点は大きな心配にはなりませんでした。
次に接続速度ですが、サーバーがヨーロッパにあるため特に心配でした。Webページの読み込みが遅いと、ユーザーの離脱率が高くなる可能性があるからです。
そこでまず、Hetznerが提供するサーバー地域の中で、韓国から最も速くアクセスできる場所を調べました。コミュニティを見ていると Hetzner latency test というページを見つけ、韓国からはファルケンシュタイン地域のサーバーを借りるのが最も有利に見えました。米国やシンガポールのサーバーのほうが速いものの、トラフィック費用が高いため候補から外しました。
また、私は Cloudflareプロキシ を使う予定だったため、サーバーとの距離が遠くてもある程度の速度改善が期待できると考えました。テストサーバーを構築してレンダリング速度を確認したところ、十分満足できると判断しました。
今見ているページや私のフォーラムの速度が遅すぎると感じなければ、私の選択は正しかったのだと思います。
最終的に構成したサーバーと価格は次のとおりです。
- 仮想サーバー種別: Dedicated vCPU
- CPU: 4コア
- RAM: 16GB
- ストレージ: 160GB
- 無料トラフィック: 20TB
- OS: Ubuntu 24.04
- 価格: 月額26.49ドル
現時点では要求より少し高めの仕様にしていますが、Hetznerはストレージ容量が同じであればダウングレードも可能です。必要に応じて後から調整するつもりです。
サービス構築
Dockerの限界
サーバーが用意できたので、次はソフトウェアの設定です。以前はDocker環境だけでサービスを構築していました。しかしこの場合、水平スケーラビリティと災害復旧性が低いという二つの問題がありました。
水平スケーラビリティとは、ひとつのサーバーでは処理できないほどユーザーが増えたとき、複数のサーバーへ簡単に分散処理できるかどうかを意味します。Dockerは単一マシンでコンテナを管理するためのソフトウェアなので、この用途には適していませんでした。
災害復旧性とは、サーバーが故障したりインフラを移転しなければならない状況で、サーバー構成とデータを素早く復元できるかどうかです。Dockerには独自のバックアップソリューションがないため、サービスごとにバックアップと復旧を個別に構成する必要があり、とても不便でした。
Kubernetesの導入
そこで今回はDockerだけでなくKubernetesを活用することにしました。Kubernetesは分散コンピューター環境、つまりクラスタでコンテナ管理を自動化するソフトウェアで、コンテナオーケストレーションソフトウェアとも呼ばれます。これにより水平スケーラビリティを実現しやすくなります。
またKubernetesにはインフラのバックアップと復旧のためのツールも多く発展しているため、災害復旧性も高めやすくなります。Hetznerが合わなかったりサーバーが故障したりしても、インフラを移転しやすいという利点があります。
ただし、良い点ばかりではありませんでした。最大の問題はKubernetesの学習曲線が高いことです。きちんと活用できる程度まで学ぶにはかなり苦労しました。仮想マシンでクラスタを作っては消す作業を何度も繰り返し、慣れるまで多くの時間を使いました。
二つ目は、Kubernetesに適用しにくいソフトウェアもあることです。代表的な例は、私が運用しているフォーラムエンジンのDiscourseでした。Kubernetesで動かす方法を探すのにかなり苦労しました。最終的には別プロジェクトを作って解決しましたが、管理ポイントが増えた感じがするので、いつか改善したいです。
Headlamp Kubernetes Dashboard
オープンソース
多くの試行錯誤の末、Kubernetesインフラを完成させました。その後、Dockerベースの既存サービスのデータをKubernetesへ復元し、最後にドメインを接続して移行作業を完了しました。
この過程をほかの人も参考にできるようオープンソースとして残すとよいと思い、GitHubプロジェクトを公開しました。私の作業が気になる方や、Kubernetesでホームラボを構築したい方は参考にしてみてください。
セキュリティ戦略
最近はサーバーのハッキング事件をよく見かけます。そこでサーバーを再構築する過程で、セキュリティを点検し改善する作業も行いました。
今回はゼロトラストのセキュリティ戦略を適用しました。これは基本的にすべてのネットワークアクセスを疑い、確認するという考え方です。そのため、サーバーの公開IPを通じたすべてのネットワークアクセスをファイアウォールで遮断し、外部からは Cloudflare Tunnel 経由でのみサービスへアクセスできるよう構成しました。サーバー管理も Tailscale による仮想プライベートネットワークからのアクセスだけを許可しています。
これは公開IPの露出をできるだけ防ぎ、露出したとしてもすべてのネットワークリクエストを遮断して守る戦略です。完璧なセキュリティ方法はありませんが、この程度ならネットワークレベルの攻撃は十分防げると期待しています。
データ保護
私のようにセルフホスティングで何かを構築する場合、最も心配な点のひとつはデータをどう守るかです。
高価なマネージドクラウドでは、通常データベースやストレージのバックアップを自動で行ってくれるため、大きく気にする必要はありません。しかし私のようにサービスのデータを自分で管理する場合、バックアップと復元を常に考える必要があります。
そこで私は 3-2-1バックアップ戦略 を適用しました。これは次の意味を持ちます。
- 元データ以外に少なくとも2つのバックアップを保存する
- ひとつのバックアップは物理的に別の装置に保存する
- ひとつのバックアップは物理的に別の地域に保存する
これを実現するため、サービスのすべてのデータは一定周期で自宅のホームラボストレージサーバーにバックアップされ、さらに海外のストレージサーバーへ再バックアップされるよう構成しました。
こうしておけば、サーバーに問題が起きてもドイツと韓国のバックアップのどちらか一方が残っていれば、サービスを正常に復元できます。これなら十分安全だと思います。
次のステップ
もともとはクラウドへ移行するだけの作業だったのに、思ったより大きな作業になりました。それでも新しい技術を楽しく学び、より安全なサーバーを構築できましたし、今後Kubernetesを使って自分のホームラボも改善したいという意欲まで湧いてきました。
まだインフラには改善点が多くあります。Discourseのデプロイ方式も改善が必要ですし、現在のKubernetes構成は単一マシンを前提としているため、将来的には水平スケール可能な構造へ変更する必要があります。
ただし今の規模では十分にトラフィックを処理できるので、まずはコンテンツ制作にもう少し集中しようと思います。インフラに大きな変化があれば、そのときまた紹介します。それではまた。