Dockerを巡る違和感とネイティブ実行の合理性
個人開発において、GoやRustによるシングルバイナリの生成と、データストアとしてのSQLiteを採用していると、Dockerの導入に対して常に一定の疑問がつきまといます。仮想化によるオーバーヘッドやビルド手順の複雑化、ボリュームの管理コストを支払ってまで、環境の分離や統一を求める動機が薄いからです。
一般にDockerのメリットとして挙げられる環境汚染の防止やクロスプラットフォーム対応は、適切な言語選定やPure Go/Pure Rustによる依存関係の排除によって、アーキテクチャのレベルで事前に回避できます。CGOなどのC言語ライブラリ依存や特殊な共有ライブラリが存在せず、OSネイティブのバイナリを単一ファイルとして配置できるのであれば、Dockerデーモンを挟まずに直接実行する方が開発体験もデプロイ手順も極めて軽快になります。
もちろん、Cloud RunやAWS ECSのようにコンテナイメージをデプロイ単位とするPaaSを利用する場合や、外部のミドルウェアを複数束ねて構成を完全にコード化したい場合にはDockerの価値が生まれます。しかし、Linux向けのバイナリをクロスコンパイルしてサーバーに転送し、systemd 等で常駐させるだけで運用が完全に成立している段階では、仮想化レイヤーを挟むことは余計な複雑性を持ち込むだけに過ぎません。
スケーリングを拒絶する制約とセルフホストモデル
アプリケーションの提供形態を考える際、当初から中央集権的なマルチテナントSaaSを目指して大規模化を前提に設計するのか、それとも独立して動作する道具として設計するのかによって、アーキテクチャの選択は根本から分かれます。
ここで有効に機能するのが、スケーリングするほどの規模で運用させないという意図的な制約です。1台のサーバーや限られたリソースの中で収容人数や定員を厳格に決め、それ以上の規模を求めないという割り切りを行うことで、マイクロサービス化や分散トランザクション、キャッシュの同期といった過度な複雑性の侵入を物理的に排除できます。現代のハードウェア性能は十分に高いため、適切に最適化された単一プロセスとSQLiteがあれば、1台のマシンでも実用上十分なトラフィックを処理することが可能です。
もしサービスを広く普及させたいのであれば、開発者自身が巨大な単一インフラを抱えて何十万人もの面倒を見る必要はありません。関心を持った利用者がそれぞれバイナリをダウンロードし、自身の持つリソースの範囲内で自律した管理者になればよいという結論に至ります。このセルフホスト前提のモデルに倒すことで、開発者側はインフラコストや常時監視、データ分離の重責から解放され、利用者は自身のデータ主権を手元に確保できるようになります。
プロセス隔離の現実と本質的なセキュリティ
コンテナを導入する動機としてプロセス隔離（サンドボックス化）が挙げられることがありますが、教科書的な正論と運用上のリアリティの間には乖離が存在します。
Dockerなどのコンテナ機構は、本質的にはLinuxカーネルの機能（Namespaces、cgroups、seccompなど）を扱いやすくまとめた仕組みです。自分が書いたコードを自身が管理する専用環境で動かす範囲においては、一般ユーザー権限での実行や、systemd のサンドボックス機能（ProtectSystem=strict や NoNewPrivileges=true など）を活用することで、コンテナデーモンを常駐させずともOSネイティブの機能だけで実用上十分な防御線を構築できます。
そもそも、脆弱性や悪意あるコードが存在する場合、コンテナに入れているから安全であるとは言えません。カーネル脆弱性を突いたコンテナエスケープのリスクは常に存在し、たとえホストOSに脱出されずとも、コンテナ内の環境変数に置かれた秘密鍵やマウントされたSQLiteファイル自体はそのプロセスの権限で容易に窃取されます。根本的なセキュリティは、入力値の検証や依存関係の最小化といったコード自体の規律によって担保されるものであり、コンテナは粗雑な設計を帳消しにする魔法の盾ではありません。
プラットフォームの全滅と分散型のリスクヘッジ
サーバーの管理下には常に侵害のリスクが存在しますが、システム全体として最も強固なリスクヘッジは、防御壁を何重にも厚くした単一の巨大要塞を作ることではなく、サーバーも管理者もバラバラに分散させることです。
これは「個人ブログ」と「中央集権的なプラットフォーム」の対比によく現れます。個別の個人ブログはセキュリティやリソースの観点から個別に停止させることが容易に見えますが、世界中に散らばる無数の個人ブログを一度に全滅させることは原理的に不可能です。一方で、巨大なプラットフォームは個々の防御力が高く見えても、運営企業の倒産や規約変更、認証基盤への攻撃によって、数億人分のデータや発信拠点が一夜にして同時に消滅する全滅シナリオを常に内包しています。
1箇所にデータを集中させた中央サーバーは、攻撃者にとって最も費用対効果の高い標的となります。これに対し、独立したノードが分散していれば、ある管理者のサーバーが侵害されたり設定ミスで停止したりしても、その被害範囲は局所的に閉じたまま保たれます。
完璧に安全な中央サーバーを構築することを目指すのではなく、どこかのサーバーが破綻することを前提として、全体が共倒れしない疎結合な自立分散環境を作る。この思想に立つとき、軽量なシングルバイナリとSQLiteによる最小構成のアプリケーションは、最も頑健で理にかなった設計の答えとなります。
