
2026/08/09 7:49
我がサーバーは今や電話機です
RSS: https://news.ycombinator.com/rss
要約▶
Japanese Translation:
著者は、ハードウェアコストの高さと Chrome における共有 CPU 性能の悪化という要因により、高額な Hetzner VPS を使用済みの CMF Phone 1 に代替することに成功した。初期に postmarketOS のフラッシュを試みたところ、破損したドライバーのためデバイスが機能しなくなったが、復旧プロセスでは MediaTek ドライバーの問題を調べるために QEMU で Windows をインストールし、その後標準の Nothing OS に復元を行った。最終的に安定して動作する設定は、仮想マシンを使わずに Android 上で直接 Termux をホスト環境として実行し、管理には OpenSSH、Caddy、Tailscale を活用している。パフォーマンスは、PRoot からネイティブ chroot(特に Surf ブラウザ向け)へのアプリケーション移行によりシステムコールのオーバーヘッドを排除することで最適化され、電源管理は Ansible スクリプトを用いてアイドル状態を無効化し、ウェイクロックを有効化することで確保されている。
システムの信頼性は以下の特殊なブートチェーンに依存する:Android ブート → Tailscale 常時接続 VPN → Termux:Boot → runit → 常驻サービス → ヘルスチェック。インフラストラクチャはプライベート Git リポジトリから Ansible で完全に管理され、バージョン付きファイルは原子シンボリックリンク、秘密情報は 1Password SSH エージェント署名による派生キーではなく格納されたキーを使用しない方式で扱っている。ネットワークトラフィックは以下のように特定の方法で処理されている:HTTP アプリには Cloudflare Tunnel、低遅延要求のある Surf バックエンドにはカスタム WebSocket でラップされた TLS ストリームが使用される。Chromium(Surf)や個人資産トラッカーといった特定の常驻サービスを動作させることで、静かなバッテリーバックアップ付きのホスト環境を提供する。Android カーネルを共有するため OS 更新の影響を受け得るものの、この設定は VPS コストを実質的に排除しながらも、信頼できるリモートアクセス機能を維持することに成功している。
本文
中古スマホで VPS に代わる個人インフラを構築してみた話(CMF Phone 1 の事例)
長らく個人のサーバー環境は安価な Hetzner VPS に依存していました。しかし、支払に対する嫌悪感と、特定のアプリケーションである「Surf」の性能不足から、より効率的な解決策を探すことになりました。
最終的に、引き出しに眠っていた中古スマホ CMF Phone 1 をサーバーとして転用し、従来の VPS を完全に置き換えることに成功しました。
📱 なぜ CMF Phone 1 か?:機材選定の理由
新規購入や既存機器の活用には以下の課題がありました。
- 新機購入: DRAM 価格の高騰により、快適なメモリを搭載した新規構築はタイミングが悪すぎる。
- 中古 PC/デスクトップ: これらの検討も一瞬浮かんだが、CMF Phone 1 という「すでに所有済み」の高性能な選択肢を見出せた。
CMF Phone 1 のスペック概要:
- SoC: 8 コア ARM プロセッサ(性能過剰)
- メモリ (RAM): 8 GB
- ストレージ: 128 GB フラッシュ
- 通信: Wi-Fi 6, 5G モデム搭載
- バッテリー: 内蔵(停電時にも動作可能)
当初は「過剰な性能を持つ」と考えましたが、いざ運用してみると十分な計算能力と低消費電力というメリットを発見しました。
⚠️ 失敗体験と学び:Linux 化の試行錯誤
1. 最初の誤り:Android の置換 (postmarketOS)
標準的な Linux 分布(
postmarketOS)を導入しようとしたのが最初の試みでした。
- 結果: デバイスは起動したが、ディスプレイは黒くなり、Wi-Fi や Bluetooth、GPU アクセラレーションなどの重要な機能が動作せず使用不可能になった。
- 復旧の苦労: Windows VM を作成し、QEMU でフラッシュツールを回してようやく元の
へ戻ったが、非常に時間と労力を要した。Nothing OS - 教訓: **「Android はすでにすべてのハードウェアに対応するドライバーを持っている」**ため、それを捨てるのは不適切なトレードだった。
2. 二つの誤り:proot の使用
多くのアプリは ARM64 イメージとして提供されているため、
proot-distro を使って Debian をインストールしやすかったが、性能面での限界が見えた。
- 初期の成功:
はファイルシステムをインターセプトするため、ルート権限なしでアプリを動作させるのに適していた。Proot - Surf のボトルネック: ブラウザ系(Surf)はプロセス起動やライブラリ読み込みにおいて PRoot の翻訳層でのオーバーヘッドがあり、CPU 資源を使っても効率が低かった。
- 解決策: スマホをルート化 (Root) し、Debian ファイルシステムを正しくマウントして「真の chroot」環境に構築した。これによりパフォーマンスが劇的に向上した。
- 補足: GPU 加速試行(VirGL/Vulkan)は破損ページなどを伴うため断念し、ソフトウェアレンダリングの方が高性能だったことも確認。
🛠️ アーキテクチャ:どうやって動かしているか?
最終的な構成は「二重の層」で構成されています。
レイヤー構成表
| レイヤー | 役割・責任分野 | コンポーネント (スタック) |
|---|---|---|
| Android / Termux ホスト (OS レベル) | ハードウェア制御 ネットワーク Ingress (アクセス制御) 監視 | , , , , オペレーションダッシュボード |
| ルート済み Linux chroot (アプリレベル) | アプリケーション実行 ワークロード処理 | (Chrome), , その他の ARM64 OCI イメージ |
具体的な実装ポイント
- ホスト OS: Termux を採用。
で自動起動を管理し、SSH や Tailscale を常時接続させます。Termux:Boot - サービス管理:
がすべての驻留サービス(プロセス)を監視・制御します。runit - Ansible による管理: 手動設定ではなく、
とプライベート Git リポジトリで完全に自動化しています。Ansible- シークレットは
に保存せず、Git
で暗号化管理(1Password SSH エージェント連携)。Ansible Vault - アトミックな更新:バージョン付きディレクトリへのインストール → シンボリックリンクによる切り替え。
- シークレットは
- 健康管理: 再起動後にも自動的にすべてのサービスが立ち上がり、ローカル・パブリック両方のヘルスチェックが通過するまで待機します。
Android 起動 -> Tailscale (VPN 接続確立) -> Termux:Boot (Supervisor 起動) -> runit (全驻留サービス開始) -> ヘルスチェック (ローカル・パブリックパス検証)
デプロイフローの概要
- リリース準備: OCI イメージを作成し、Git にチェックサム/ダイジェストをピン留め。
- Ansible 適用: SSH を介してスマホへファイルを転送(バージョン付きディレクトリに)。
- スイッチ切り替え: アトミックなシンボリックリンクを変更して新バージョンへ。
- 検証: ローカルおよびパブリックのヘルスチェック実行。失敗時はロールバック自動対応。
この構成は、**「電話機が死んでも構成ファイルは有効」**であり、別の同機種(ルート可能な ARM64 スマホ)でも同じ設定で運用可能です。
🌐 外部アクセス:Ingress (入港) の解決策
自宅ルーターには静的 IP がなく、ポート開放も望まないので、以下の工夫を行いました。
1. Web アプリケーション (Caddy, Finances など)
- 手法:
を使用。Cloudflare Tunnel - 動作原理: スマホから外へ一方向接続だけ。外部からは Cloudflare → スマホ内部の
というルートでアクセスされます。127.0.0.1:Caddy - メリット: スマホを別の場所(カフェなど)に持っていっても、インターネット接続さえあればトンネルが再接続され、ドメイン経由で正常に動作します。
2. リモートブラウザ Surf (iPad から)
Surf は低レイテンシーと古い OS (iPad) の互換性が要求されるため、単純なトンネルでは不十分でした。
- 課題: 通常は Cloudflare で TLS を終端させるが、Surf は自前の旧式な認証プロトコルを使用するため、直接接続を望む。
- 解決策: WebSocket ネスト化。
- 完全な Surf TLS ストリームを通常の WebSocket プロトコルの中にラップする。
- Cloudflare が WebSocket を検知して転送し、内部ではエンドツーエンド暗号化されたままになる。
- 性能: 家庭外でも約 60ms のレイテンシー増しかないが、2012 年の OS (iPad) でも動作するトンネルを実現できた。
結果としての運用: 自宅(スマホ)←→Tailscale←→MacBook で SSH 接続し、その中にブラウザ経由で iPad を介して Surf を操作しました。VPS が不要なことで解放感に満ちています。
✅ これを実行すべきでしょうか?
推奨されるケース
- 未使用の高性能スマホがある場合(8GB RAM, Wi-Fi, バッテリーあり)。
- VPS の月額費用を節約したいが、完全にフリーウェアで済ませるほど簡素化はしたくない場合。
- 「電話機としての携帯性」と「サーバーとしての安定性」の両立を図りたい場合。
推奨しないケース(注意点)
- 重要なデータを置換せず: Android データや chroot 内のデータを、自動バックアップなしで依存するのはリスクがあります。
- 高負荷な GPU 処理が必要な場合: ソフトウェアレンダリングは CPU 負荷が高く、専用ワークステーションには勝てません(Surf の例を除く)。
- 完全なセキュリティ境界を求める場合: Android カーネルと共有しているため、完全に隔離された環境ではありません。
結論
「静かで、バッテリーが予備電源となり、どこからでもアクセス可能、Git で完全に再現可能な」個人インフラとして、VPS よりも満足度の高い選択肢です。すでに所有しているスマホを有効活用すれば、**「無駄遣いではなく、真に有用なリソース再利用」**になります :)