はじめに
インフラエンジニアとして、長年「なぜか遅い」「アップデートできない」という悲鳴を上げるレガシーシステムと向き合ってきました。
そんな中、私が抱いた野望は 「日本の基幹システムを、その苦しみから解放する自作クラウドを作る」 というものでした。
設計が一周し、理想と現実の狭間でトレードオフを繰り返した結果、ようやく納得のいくアーキテクチャに辿り着きました。本稿では、その葛藤のプロセスを詳細に記録します。
1. 理想の追求：Windows Server S2D という最強の選択肢
最初の設計思想は、 「究極の互換性」 でした。
多くの現場では、古い .Net Framework や Oracle Database が「動いているから」という理由で、石化するように残っています。これらを救うには、Microsoftのライセンス体系を逆手に取った戦略が最適だと思いました。
- Windows Server Datacenter Edition の採用:
- 物理ノードにライセンスを付与すれば、その上のVMに対するWindowsライセンスは無制限。これは「古いWindows Server OSをいくつでも立てられる」という、レガシー救済における最大の武器です。
- S2D（Storage Spaces Direct）によるHCI:
- 標準機能でソフトウェアデファインドストレージを構築し、RemoteAppを提供することで、クライアントの環境すら選ばないシステム環境を構想しました。
私の経験上、これが最も「ユーザーが喜ぶ」形だと確信していました。
現実という名の壁：2000万円の見積書
しかし、ハードウェアの見積もりを見た瞬間、思考が停止しました。S2Dの要件を満たす高信頼なサーバーは、1ノード500万円。4ノードで2000万円。
個人で始めるスタートアップには、あまりにも非情な数字でした。「ライセンスの正当性」と「初期投資の限界」。 数日間悩み抜いた末、私は魂とも言える「Windowsネイティブ環境の無制限提供」を、一度手放す決断をしました。
2. 転換と葛藤：Linuxへの舵切りと「捨てられない思想」
Windowsを諦めることは、主要ターゲットから .Net Framework を外すことを意味します。しかし、サービスインできなければ救えるものも救えません。
ターゲットを Tomcat / .NET Core / Node.js に再定義しました。
ここで、私は自分自身に問いかけました。
「ただのLinux VPSの集合体を作って、何が楽しいのか？ それで誰が幸せになるのか？」
そこで、インフラに「付加価値」を組み込むことにしました。
「載せるだけで速くなる」ための Apache Ignite
OracleやSQL Serverからの移行先としてPostgreSQLを据えつつ、そのフロントに Apache Ignite を配置しました。
- 単なるキャッシュではなく、分散データベースとしての永続化層（Native Persistence）への期待。
- ユーザーが「このクラウドに移行するだけ」で、SQL資産を活かしたまま劇的なパフォーマンス向上を体験できること。
- VMのオートスケーリングを実現するため、セッション管理を外部のIgniteクラスタへ強制的に切り離す設計。
「なぜ遅い？」をゼロにする Apache SkyWalking
現役時代、最も苦労したのは「どこがボトルネックか分からない」ことでした。
Apacheプロジェクト同士の親和性を活かし、SkyWalking を標準の観測基盤として組み込むことにしました。インフラ側でAPM（性能管理）まで面倒を見ることで、開発者が「コードのどこが遅いのか」を即座に特定できる環境を目指しました。
3. 回帰と確信：Proxmox + Ceph による「自営HCI」への着地
最初はハイパーバイザー、Ignite（キャッシュ）、DB、Ceph（ストレージ）の4層を別々のハードウェアで組む「4層構造」を検討していました。しかし、それではリソースの偏りや管理の複雑増大を招きます。
調査を進める中で、Proxmox上でCephをネイティブに動かすHCI構成が、今の私にとっての「銀の弾丸」であることに気づきました。
- 25GbEという逆張り:
- メモリやディスクが高騰する中、実は25GbEアダプターは驚くほど安価に流通しています。ここをケチらず25GbEを選択したことで、Cephの同期トラフィックを余裕を持って捌き、オールNVMeに頼らずとも十分なI/Oを確保する道が見えました。
- 1ノード300万円への削減:
- S2Dの呪縛から解き放たれ、OSSをベースにパーツ選定を見直すことで、性能を維持したまま1ノードあたりのコストを大幅に削減。これなら戦える、と確信しました。
4. 最終的な設計思想：モノリス救済PaaS
最終的に辿り着いたのは、 「巨大なモノリスをそのまま包み込み、最新の技術で武装させるPaaS」 です。
- タイムマシンリカバリの標準実装:
- 「運用者が最も怖いのはデータの消失と不整合」。1～5分おきにスナップショットを取得し、管理画面から「20分前の状態にアプリとDBを丸ごと戻す」機能。これは、私が現場で何度も「あればよかった」と切望した機能です。
- Cloudflare Tunnel による要塞化:
- グローバルIPという枯渇リソースを節約しつつ、外部からの直接攻撃を物理的に遮断する。クライアント証明書認証を組み合わせ、安価ながら軍事レベルのセキュリティを提供します。
今後の課題：.NET Core への架け橋
.Net Framework を直接動かすことは諦めましたが、それは「古いものをそのままにする」ことへの決別でもあります。
今後は、.Net Framework から .NET Core への移行をいかにシームレスにサポートするか。この「移行の痛み」を和らげるツール群をPaaSの一部として提供することが、私の次の戦場です。
おわりに
これから少しずつ開発環境で今回の構成を検証していきます。サービスインを応援して頂けると嬉しいです。