技術選定は やり直せる前提で設計する

Transcript

1. Developers Summit 2026 Summer 技術選定は やり直せる前提で設計する mNi Cloud が Facade パターンで得た柔軟性 株式会社フォーセシステム / mNi Cloud 開発チーム
2. 今日の論点 技術選定は当たるか外れるかではなく、選び直せるか 2 / 32 主張 採用時のベストな OSS も、運用・要件・組織の変化で置き換えたくなることがある。 mNi Cloud では、Kube-OVN への直接依存が移行の妨げになった バックエンドをリファクタリングし、サービスの窓口と内部実装を分けた その結果、ユーザ向け API を変えずに内部実装を移行できる状態になった
3. mNi Cloud の位置づけ Kubernetes をベースにした国産クラウドプロダクト 3 / 32 背景 VMware の値上げや円安を背景に、国内で扱い やすいクラウド基盤を作る。 提供形態 パブリック、プライベート、OSS 版を視野に入 れて開発している。 mNi Cloud VM / Container / VPC / Storage / VPN / Auth Kubernetes ベースとなる実行・制御基盤
4. mNi Cloud が提供する 6 領域 ユーザから見る単位と、内部で動く実装は一致しない 4 / 32 VM 仮想マシン Container コンテナ実行 VPC 仮想ネットワーク Storage ブロックストレージ VPN 拠点・端末接続 Auth 認証・権限 この発表では、特に VPC の失敗と移行を軸に、6 領域共通の設計を話します。
5. 最初の判断: OSS を直接使う 立ち上げ期は、最短で動かすことを優先した 5 / 32 要件 VPC を提供 調査 既存 OSS を探す 採用 Kube-OVN 実装 直接呼ぶ 立ち上げ期の判断としては自然だった ネットワーク機能を一から作るより、既存 OSS に乗る方が早い ただし「後で置き換える」前提はコードに入っていなかった
6. VPC の初期実装: Kube-OVN Kubernetes 上で VPC 相当のネットワークを作る OSS 6 / 32 採用した理由 Kubernetes 上で仮想ネットワークを作るための機能がそ ろっていた。 当時の価値 mNi Cloud の VPC 機能を早く形にできた。 VPC Service mNi Cloud 側のサービス Kube-OVN VPC の内部実装
7. 直接依存が生んだ前提 VPC サービスのコードが、Kube-OVN の都合を知っている状態 7 / 32 VPC API ユーザ向け VPC Service 作成・削除・状態管理 Kube-OVN OSS のリソース サービスコードが OSS のリソース構造を前提にする 削除や状態確認のロジックも OSS 側の挙動に引っ張られる 置き換える場合、単に依存ライブラリを変えるだけでは済まない
8. 運用で顕在化した問題 公表済みの開発ブログにある、VPC まわりの課題 8 / 32 リソース残留 削除したはずの VPC / Subnet 関連リソースが内部に残る 外部接続用 IP EIP 相当の挙動が安定しない ブラックボックス化 OVS まわりの状態が追いにくく、障害調査が難しい 問題の本質は、OSS が悪いことではなく、置き換えの余地を設計していなかったこと。
9. リソース残留と EIP 不安定で起きること ユーザ操作としては終わったはずなのに、内部状態と外部接続を信用しきれなくなる 9 / 32 削除したはずの VPC / Subnet が残る 画面や API 上は消したつもりでも、内部に関連リソースが残る。 EIP 相当の挙動が安定しない 外から入るための入口が、期待した状態で維持されない。 同じ VPC / Subnet を作り直すときに、残骸との衝突 を疑う必要がある ユーザの操作履歴と、Kubernetes 内部の状態が一致 しない 削除処理が完了したと言い切る前に、内部確認と清 掃が必要になる デモや本番利用で「外からつながるはず」が揺らぐ 切り替えや復旧のたびに、疎通確認を厚くする必要 がある 原因が VPC 設定なのか、EIP なのか、内部実装なのか 切り分けに時間がかかる クラウド基盤で一番困るのは、「消したはず」「つながるはず」を運用者が信用できなくなることです。
10. 剥がせなかった理由 依存が 1 箇所ではなく、作成・削除・状態管理に散っていた 10 / 32 VPC Service 作成 削除 EIP 状態確認 Kube-OVN 内部実装 依存が散るほど、置き換えは「局所修正」ではなく「再設計」になります。
11. 2024 年のバックエンド刷新 2024 年 5 月から 10 月にかけて、バックエンドを大きく作り直した 11 / 32 問題整理 運用課題 境界設計 窓口を定義 実装分離 内側へ閉じる 移行準備 差し替え可能 単なる修正ではなく、依存の向きを変えるためのリファクタリング ユーザ向け API と内部実装を同じものとして扱わない 各サービスが内部 OSS の詳細を外へ漏らさない構造に寄せた
12. Developers Summit 2026 Summer 設計方針 ユーザ向けの窓口と、内部で動く実装を分ける 12 / 32
13. Facade パターンとして整理する 外から使う窓口を固定し、内部の複雑さを隠す 13 / 32 利用する側 API / Controller Facade mNi の窓口 実装 OSS / 自前 利用側は Facade だけを見る 内部の OSS や自前実装は Facade の内側に閉じ込める 差し替えは Facade の内側で完結させる
14. VPC サービスの二段構成 VPC の概念を mNi 側で定義し、実装は内側に置く 14 / 32 ユーザ向け API VPC / Subnet / Route / External IP VPC Service Facade mNi Cloud としての VPC 操作を受ける窓口 Kube-OVN Adapter 既存実装 mNi Network Adapter 移行先の自前実装
15. Before: Kube-OVN に直結 移行したいときに、サービス側の変更範囲が広がる 15 / 32 VPC Service 作成・削除・状態管理 Kube-OVN OSS の構造・挙動 依存が強いほど、Kube-OVN を剥がす作業が VPC Service 全体に広がる。 OSS のリソース名・状態・失敗パターンをサービス側が知っている 移行と障害対応のたびにサービス側の知識が増える 結果として、サービス境界が曖昧になる
16. After: 実装を内側へ閉じ込める サービス側は mNi の VPC 操作だけを扱う 16 / 32 VPC API ユーザ向け Facade mNi の窓口 Kube-OVN 既存実装 自前基盤 移行先 利用側は Facade だけを呼ぶ Kube-OVN 固有の処理は Adapter の内側に寄せる 新旧実装を同じ窓口の下に置ける
17. 移行: Kube-OVN から自前基盤へ eBPF + BGP の自前ネットワーク基盤へ段階的に移行中 17 / 32 既存 Kube-OVN 共存 新旧 Adapter 検証 一部経路 切替 自前基盤 一気に入れ替えるのではなく、Facade の内側で段階的に進める 問題があれば旧実装へ戻せる余地を残す ユーザが触る API は変えない
18. 変えなかったもの: ユーザ向け API 内部の移行を、利用者の変更作業にしない 18 / 32 固定する境界 ユーザが作る VPC / Subnet / External IP の操作体系は変えない。 変えてよい内側 Kube-OVN か自前基盤か、どのリソースで実現するかは Facade の内側で変える。 「技術選定をやり直す」と「ユーザに移行作業をさせる」を分離する。
19. 変えたもの: 内部実装の責務 OSS 固有の事情を、mNi のサービス境界から押し出す 19 / 32 作成 VPC の作成要求を受ける Kube-OVN / 自前基盤の具体リソースを作る 削除 ユーザから見た削除を受ける 残留確認・再試行・清掃を行う 状態確認 mNi の状態へ正規化する 実装ごとの状態差分を吸収する Facade は、mNi としての意味に正規化する場所です。
20. Developers Summit 2026 Summer 6 領域への展開 VPC だけでなく、全サービスで同じ境界を引く 20 / 32
21. 6 領域の窓口と内部実装 ユーザが見るサービス名と、内部で使う実装を分けて扱う 21 / 32 領域 mNi の窓口 内部実装 VM VM Service KubeVirt Container Container Service Kubernetes 標準 VPC VPC Service Kube-OVN -> 自前ネットワーク基盤 Storage Storage Service Kubernetes 標準 VPN VPN Service 自前の VPN 連携層 Auth Auth Service Keycloak -> 自前実装
22. VM: KubeVirt を内部実装にする ユーザは mNi VM を使い、内部では KubeVirt を利用する 22 / 32 mNi VM API ユーザ向け VM Service 窓口 KubeVirt 内部実装 KubeVirt のリソース構造をユーザ向け API へ漏らさない VM 作成・起動・停止・削除を mNi の操作として定義する 将来の実装変更時も、ユーザの操作体系を固定できる
23. Container / Storage: Kubernetes 標準を隠す 標準機能でも、サービス境界を作る意味はある 23 / 32 Container Service Kubernetes の Pod / Deployment などを、mNi のコンテナ操作 へ正規化する。 Storage Service Kubernetes のストレージ機能を、mNi のブロックストレージ 操作へ正規化する。 標準機能に乗る場合でも、mNi としての API は別に定義する Kubernetes の都合ではなく、クラウドサービスとしての都合を窓口に置く 内部の実装差分はサービス側で吸収する
24. VPN: 連携層を別プロジェクトに切り出す OSS がない部分も、サービス内に抱え込まない 24 / 32 VPN Service mNi の窓口 VPN 連携層 別プロジェクト VPN 実装 内部 「OSS がないからサービス内に書く」ではなく、実装層を分ける VPN Service はユーザ向けの操作と状態管理に集中する 連携層は独立して開発・検証・差し替えできる
25. Auth: Keycloak 依存から自前実装へ 認証も、外部実装の都合をサービス境界から切り離す 25 / 32 Before Keycloak 前提 Auth Service mNi の窓口 After 自前実装 認証のユーザ体験と、内部の認証基盤を分けて考える 内部実装の移行を、利用側の API 変更にしない VPC で得た設計方針を認証にも適用する
26. 開発チームへの効き方 サービスの外側と内側を、別々に進められる 26 / 32 サービス側 ユーザ向け API、状態遷移、エラー表現を設計する。 実装側 OSS / 自前基盤のリソース作成、監視、再試行、清掃を担当 する。 レビュー観点が分かれる 実装を変えても、サービス側の仕様レビューを毎回やり直さなくてよい 新旧実装を並行して検証しやすい
27. 障害調査への効き方 実装ごとの状態を、mNi の状態へ正規化して扱う 27 / 32 Kube-OVN 状態 旧実装の見え方 mNi 状態 正規化 自前基盤状態 新実装の見え方 どの実装でも、ユーザに見せる状態は mNi の状態として扱う 実装固有の調査項目は Adapter 側に閉じる 障害対応の手順も、実装単位で整理しやすくなる
28. 「あとで分ける」が失敗する理由 運用に入ると、境界を引く余裕は減っていく 28 / 32 初期実装 直接呼ぶ 機能追加 依存が増える 運用 例外が増える 移行 剥がせない 最初に楽をした場所ほど、あとで重要な経路になる 障害対応の知識が、境界のないコードへ積み上がる 分けるなら、最初から薄くても境界を置く方が安い
29. 境界を引く判断基準 すべてを抽象化するのではなく、変わり得る場所を見極める 29 / 32 外部 OSS への依存か プロダクトの都合だけでは制御できない 運用で状態管理が必要か 作成・削除・再試行・清掃がある ユーザ API と実装都合が違うか その違いを吸収する層が必要 将来の置き換え候補があるか 今は未定でも、境界だけ先に置く
30. 境界を厚くしすぎない Facade は万能な抽象化ではなく、変更点を閉じ込めるための境界 30 / 32 やりすぎ 全機能を抽象化しようとして、実装の表現力を失う。 狙い 外へ漏らすと困る都合だけを、Facade の内側へ閉じる。 最初は薄い境界でよい 運用で変化しやすい処理から Adapter 側へ寄せる 抽象化のための抽象化にしない
31. 事業貢献としての技術選定 選び直せる設計は、プロダクトの継続性に効く 31 / 32 採用時の価値 OSS を使うことで、立ち上げを早くする。 運用時の価値 問題が見えたら、ユーザ影響を抑えて実装を変える。 成長時の価値 自前実装を育てながら、既存ユーザへの提供を止めない。
32. Developers Summit 2026 Summer まとめ 技術選定は、運用に入ると変わることがある 変わる可能性がある場所には、ユーザ向け API と内部実装の境界を置く Facade パターンは、選び直し可能性をプロダクトへ組み込むための設計だった 株式会社フォーセシステム / mNi Cloud 開発チーム