OSS依存を 安全に剥がす設計

Transcript

1. 株式会社フォーセシステム / mNi Cloud 開発チーム 1 / 24 Developers Summit 2026 FUKUOKA OSS依存を 安全に剥がす設計 プロダクトに入り込んだOSS固有の都合を、 ユーザ向けAPIから切り離す ユーザ向けAPI サービス境界 Adapter 内部実装
2. Developers Summit 2026 FUKUOKA 株式会社フォーセシステム / mNi Cloud 開発チーム 2 / 24 今日持ち帰ってほしいこと 特定OSSの良し悪しではなく、依存をどこに閉じ込めるか 01 依存を見つける OSS固有の状態・エラー・削除挙動 が、サービスコードに混ざっていな いかを見る 02 境界を置く ユーザ向けAPIの意味と、内部実装 の都合を別の層に分ける 03 移行できる形に戻す 旧実装と新実装を同じ窓口の下に置 き、段階的に切り替える 聞き終えたあと、自分のプロダクトで「境界を置くべき箇所」を見直せる状態を目指します。
3. Developers Summit 2026 FUKUOKA 株式会社フォーセシステム / mNi Cloud 開発チーム 3 / 24 OSSを内部実装として使うとは ユーザにOSSを直接見せず、プロダクト機能の裏側で使う ユーザ プロダクトの画面 / APIを 使う プロダクト機能 ユーザの操作を 作成・削除・状態確認へ 変換する OSS / 内部実装 API / CRD / リソース 状態 / エラー / 実行基盤 例: 認証、ネットワーク、ストレージ、VM、監視、キュー ここで扱うのは、プロダクトの中核機能を既存OSSの上に作るケースです。
4. Developers Summit 2026 FUKUOKA 株式会社フォーセシステム / mNi Cloud 開発チーム 4 / 24 直接依存とは何か OSSを呼ぶこと自体ではなく、OSS側の都合でサービスの振る舞いが決まる ユーザ向けAPI 外側の約束 サービスコード ユーザに見せる意味と OSS固有の前提が混ざる OSS側 状態 / エラー / 削除挙動 リソース名 状態差分 削除完了 再試行 清掃 直接依存とは、OSS固有の前提がプロダクトのAPI・状態・運用判断へ染み出している状態です。
5. Developers Summit 2026 FUKUOKA 株式会社フォーセシステム / mNi Cloud 開発チーム 5 / 24 依存は呼び出し以外にも入り込む importやAPI呼び出しだけを見ても、剥がしにくさは見つらない 作成順序 どのリソースを 先に作るか 削除完了 何をもって 完了とするか 状態変換 内部状態を どう見せるか 失敗解釈 どのエラーを 再試行するか 清掃 残ったものを どう片付けるか 呼び出しだけを差し替えても足りない 内部実装の前提が、削除・状態・運用手順へ残る 前提を閉じる層が必要 プロダクトの意味と、内部実装の都合を分けて扱う
6. Developers Summit 2026 FUKUOKA 株式会社フォーセシステム / mNi Cloud 開発チーム 6 / 24 運用で困るのは「完了」を信用できないこと ユーザ操作と内部状態がずれると、運用者が判断できなくなる ユーザから見える世界 削除した 画面 / APIでは操作が終わった 同じ名前で作り直したい 外部から接続できるはず 内部で確認が必要な世界 関連リソースは残っていないか 経路や割り当ては整合しているか 状態を追えるか 再試行や清掃が必要ではないか 操作結果を宣言できないと、障害調査・復旧・再作成の判断が毎回重くなります。
7. Developers Summit 2026 FUKUOKA 株式会社フォーセシステム / mNi Cloud 開発チーム 7 / 24 事例: mNi Cloud のネットワーク機能 弊クラウドで起こった事象 mNi Cloud Kubernetesを制御基盤にしたクラ ウド基盤。 本発表ではネットワーク機能だけ に絞ります。 ユーザに見せる操作 ネットワークを作る サブネットを作る 外部接続を割り当てる 削除・状態を確認する 内部でやること 既存OSSのリソースを作成し、 状態を読み、失敗時に調査・清掃 する
8. Developers Summit 2026 FUKUOKA 株式会社フォーセシステム / mNi Cloud 開発チーム 8 / 24 当初の内部実装としてKube-OVNを採用した 立ち上げ期に既存OSSを使い、早く機能を形にする 要件 クラウドの ネットワーク機能 調査 既存OSSで 実現できるか 採用 Kube-OVN 実装 サービスから 直接扱う この時点の価値 ネットワーク機能を一から作るより、既存OSSに乗る方が早かった。 後から効いた前提 置き換えの余地を、サービス構造に入れていなかった。
9. Developers Summit 2026 FUKUOKA 株式会社フォーセシステム / mNi Cloud 開発チーム 9 / 24 運用で前提が漏れ出した 削除、外部接続、状態確認、調査手順に内部実装の都合が混ざる リソース残留 削除したはずの関連リソースが内部に 残り、再作成や復旧の判断を難しくす る External IPの揺らぎ 外部から入る入口が期待した状態で維 持されず、疎通確認が重くなる 調査の難しさ OVSまわりの状態を追う必要があり、 原因切り分けに時間がかかる 問題はOSSそのものではなく、内部実装の前提がサービス側へ漏れたことでした。
10. Developers Summit 2026 FUKUOKA 株式会社フォーセシステム / mNi Cloud 開発チーム 10 / 24 剥がせなかった理由 サービスコードが実装のリソース構造・状態に依存しすぎている VPC Service ユーザ向けの意味と Kube-OVN固有の処理が混在 作成 実装の前提を知る 削除 実装の前提を知る 状態確認 実装の前提を知る 外部接続 実装の前提を知る 依存が散るほど、置き換えは局所修正ではなく再設計になります。
11. Developers Summit 2026 FUKUOKA 株式会社フォーセシステム / mNi Cloud 開発チーム 11 / 24 まず分けたもの ユーザ向けAPIの意味と、内部実装の都合を別の層に分ける 固定するもの ユーザが使う操作体系 状態の見え方 エラー表現 完了の意味 境界 外側の意味と 内側の都合を ここで分ける 変えてよいもの 内部リソース 実装ごとの状態 失敗パターン 再試行・清掃手順 「技術選定をやり直す」と「利用者に変更作業をさせる」を分離します。
12. Developers Summit 2026 FUKUOKA 株式会社フォーセシステム / mNi Cloud 開発チーム 12 / 24 Facade / Adapter に責務を寄せる Facadeはプロダクトの意味、Adapterは内部実装の事情を扱う 利用する側 API / Controller Facade ユーザ向けの意味 状態モデル 完了判定 Adapter A 旧実装の差分を吸収 Adapter B 新実装の差分を吸収 作成 意味を受ける 削除 完了を定義 状態 正規化する 内部実装を変えても、Facadeの外側の意味を変えないことが狙いです。
13. Developers Summit 2026 FUKUOKA 株式会社フォーセシステム / mNi Cloud 開発チーム 13 / 24 削除完了をサービスの意味で定義する deleteを投げたことではなく、利用者に完了と言える状態までを扱う 要求 ユーザが削除する Adapter内で確認 関連リソース Subnet 経路 割り当て 再試行・清掃 残留を確認し、 必要なら再試行・清掃する 完了 安全に再作成 できる 避けたい状態 内部リソースが残っているのに、外側だけ削除済みに見える 置きたい境界 残留確認・再試行・清掃をAdapter側に閉じる
14. Developers Summit 2026 FUKUOKA 株式会社フォーセシステム / mNi Cloud 開発チーム 14 / 24 状態をサービスの言葉へ正規化する 内部状態をそのまま外へ出さず、ユーザに見せる状態へ変換する 旧実装の状態 実装固有のReady / Failed リソースごとの状態差分 サービスの状態 利用者に見せる Available / Deleting / Failed といった意味へそろえる 新実装の状態 実装が変わっても 外側の状態モデルは変えない 障害調査では内部状態を見る。ただし、利用者へ返す状態はサービスの言葉にそろえます。
15. Developers Summit 2026 FUKUOKA 株式会社フォーセシステム / mNi Cloud 開発チーム 15 / 24 段階移行できる形にする 旧Adapterと新Adapterを同じ窓口の下に置き、切り替え可能に 旧Adapter Kube-OVN 同じFacade ユーザ向けAPIを固定し、 内側だけ切り替える 新Adapter eBPF + BGP 切替 段階的に 移す 共存 旧実装を残す 検証 一部経路で確認 切替 問題範囲を限定 戻し 旧実装へ戻せる余地
16. Developers Summit 2026 FUKUOKA 株式会社フォーセシステム / mNi Cloud 開発チーム 16 / 24 設計判断は「変わる都合」を探す 事例で見えた問題を、次の設計レビューで見つけられる形に 外へ漏れると困る都合 内部リソース名 状態差分 削除挙動 失敗パターン 境界を置く ユーザ向けの意味と 内部実装の都合を 混ぜない 内側へ閉じる都合 実装固有の操作 再試行 清掃 状態変換 「どのOSSか」ではなく、「どの都合が変わり得るか」を見る。
17. Developers Summit 2026 FUKUOKA 株式会社フォーセシステム / mNi Cloud 開発チーム 17 / 24 境界を置くべきサイン 以下がサービスコードに出てきたら、Adapterへ寄せる候補 1 状態解釈 OSS固有の状態を、サービスコードが読んでいる 2 削除完了 delete後に残留確認や清掃が必要になる 3 再試行 エラーごとの再試行条件を内部実装に合わせている 4 調査手順 障害時に実装固有の確認項目が必要になる 5 API波及 実装変更がユーザ向けAPIに影響しそうになる サインが2つ以上あるなら、薄くても境界を置く価値があります。
18. Developers Summit 2026 FUKUOKA 株式会社フォーセシステム / mNi Cloud 開発チーム 18 / 24 Adapterへ閉じる責務 内部実装の都合で変わる処理は、Adapter側に寄せる リソース作成 実装ごとのAPI / CRD / 呼び出し順序 失敗解釈 再試行すべきエラーと、利用者へ返すエラーの分離 再試行・清掃 残留確認、再実行、補正処理 状態変換 内部状態をサービス状態へ変換 Adapterは抽象化のためではなく、変わる都合を外へ漏らさないために置きます。
19. Developers Summit 2026 FUKUOKA 株式会社フォーセシステム / mNi Cloud 開発チーム 19 / 24 Facadeへ残す責務 ユーザに見せる意味と操作体系は、Facade側で守る Facadeが持つもの ユーザ向けAPI 状態モデル エラー表現 操作体系 完了の意味 Facadeが持たないもの 内部リソース名 実装ごとの状態差分 実装固有の再試行 清掃手順 Facadeは「外側の約束」を固定し、Adapterは「内側の変化」を吸収します。
20. Developers Summit 2026 FUKUOKA 株式会社フォーセシステム / mNi Cloud 開発チーム 20 / 24 抽象化しすぎない すべてを隠すのではなく、外へ漏れると困る都合だけを閉じる やりすぎ 全機能を抽象化しようとして、 実装の表現力を失う Adapterが巨大化し、 何を守る層なのか分からなくなる ちょうどよい境界 ユーザ向けAPIへ漏れると困る都合だけを閉じる 作成・削除・状態・失敗処理から始める 境界は厚さではなく、変化をどこに閉じ込めるかで決めます。
21. Developers Summit 2026 FUKUOKA 株式会社フォーセシステム / mNi Cloud 開発チーム 21 / 24 最初から厚く作らない 立ち上げ期は薄い境界でよく、運用で揺れる処理から寄せる 最初 直接呼ぶが、 窓口だけは分ける 運用 削除・状態・失敗処理の 揺れを見る 整理 揺れる処理を Adapterへ寄せる 移行 新旧実装を 同じ窓口に置く 最初から完全な抽象化を作るのではなく、変更される可能性の高い処理から境界へ寄せる。
22. Developers Summit 2026 FUKUOKA 株式会社フォーセシステム / mNi Cloud 開発チーム 22 / 24 設計レビューで見ること OSS固有の都合が、サービスコードに残っていないかを確認する CHECK 1 ユーザ向けAPIの言葉で説明できるか CHECK 2 内部リソース名をサービスコードが前提にしていないか CHECK 3 削除完了の条件が実装ごとに散っていないか CHECK 4 状態変換が一箇所に集まっているか CHECK 5 戻せる単位と観測点が決まっているか レビューでは「使っているOSS名」よりも、「どの都合が外へ漏れているか」を見ます。
23. Developers Summit 2026 FUKUOKA 株式会社フォーセシステム / mNi Cloud 開発チーム 23 / 24 移行前に確認すること 内部実装を変える前に、固定するものと変えてよいものを分ける 固定するもの ユーザ向けAPI 状態モデル エラー表現 変えてよいもの 内部リソース 作成順序 再試行・清掃 戻せる単位 旧実装を残す範囲 切替条件 ロールバック手順 観測点 成功条件 失敗時のログ 比較する状態 移行計画は「何を変えるか」より先に、「何を変えないか」から決めます。
24. Developers Summit 2026 FUKUOKA 株式会社フォーセシステム / mNi Cloud 開発チーム 24 / 24 まとめ 1 OSS採用は悪くない 速く立ち上げるために、既存OSSを内部実装として使う判断は合理的です。 2 問題は依存の置き場所 OSS固有の状態・削除・エラー処理がサービスコードに混ざると、置き換えが難しくなります。 3 境界が移行可能性を作る ユーザ向けAPIの意味をFacadeに、内部実装の都合をAdapterに閉じ込めます。 内部実装を選び直せる設計は、プロダクトを継続して育てるための余地になります。