使いやすいプラットフォームの作り方 ー LINEヤフーのKubernetes基盤に学ぶ理論と実践

Platform Engineering Kaigi 2025 のセッション
"使いやすいプラットフォームの作り方 ー LINEヤフーのKubernetes基盤に学ぶ理論と実践" の登壇資料
https://www.cnia.io/pek2025/sessions/c55827c1-69de-4c3e-8c7f-499993588b68/

Transcript

1. © LY Corporation LINEヤフー株式会社 Flava Kubernetes Engine プロダクトマネージャー・シニアソフトウェアエンジニア 五反田 正太郎 使いやすいプラットフォームの作り方 LINEヤフーのKubernetes基盤に学ぶ理論と実践 Platform Engineering Kaigi 2025 2025.09.18
2. © LY Corporation 五反田 正太郎 (@sgotand) Senior Software Engineer Flava Kubernetes Engine PdM 2 2021 LINE株式会社入社 Verda Kubernetes Service開発・運用 2023 会社合併 Flava Kubernetes Engine開発開始 2024 Flava Kubernetes Engineリリース 2025 LINEヤフー技術イベントTech-Verse “Flava Kubernetes Engine: 直感的に使える プラットフォームを目指して” Platform Engineering Kaigi 2025 “使いやすいプラットフォームの作り方 LINEヤフーのKubernetes基盤に学ぶ理論と実践”
3. © LY Corporation 3 「使いやすいプラットフォーム」を作るために、その条件・要素を理解しよう 「使いやすいプラットフォーム」とは？
4. © LY Corporation 4 「使いやすいプラットフォーム」を作るために、その条件・要素を理解しよう 「使いやすいプラットフォーム」とは？ それぞれのシナリオにおいて使いやすいプラットフォーム である
5. © LY Corporation 5 本セッションにおけるシナリオの定義 • Who: ユーザーが • Where・When: ある状況・タイミングで • For What・Why:ある目的・理由のために • What・How: 何かを行う・行動する という事象やそれらを組み合わせたもの
6. © LY Corporation 6 よくあるケース：部分的には使いやすい Aさん （入門者） Bさん （運用経験あり） Cさん （熟練者） 機能1 機能2 このケースにおいては • 「入門者のユーザーがプロダクトを検証する」というシナリオでは使いやすい • 「プロダクトに精通したユーザーが機能２を使う」というシナリオでは使いづらい という状態…
7. © LY Corporation 7 「使いやすいプラットフォームの作り方」 プラットフォームにおけるユーザーシナリオを分析し、 それぞれのシナリオにおいて使いやすくなるよう設計・改善する 設計・改善の方向性は Flava Kubernetes Engine: 直感的に使えるプラットフォームを目指して を参照 TL;DR • ユーザーがすべきことがない、または少ない • ユーザーが何をすべきかを簡単に理解できる • ユーザーが理解せずとも事故や問題が発生しない
8. © LY Corporation 8 任意のシナリオにおいて「使いやすい」プロダクト？ そんなものはない • トレードオフが存在する • あるシナリオにおいて最適な設計が 別の設計においては悪い設計となるケースがある • シナリオを網羅しきれず、見落としが発生する • 状況によりシナリオは変化するため そもそも網羅という概念が存在しない • 費用対効果・優先度の観点から改善コストをかけられない
9. © LY Corporation 9 改善の価値・費用対効果を最大化する重要なシナリオのパターン 重要なシナリオの使いやすさを改善する • 重要なユーザーに関わるシナリオ • どのユーザーが重要かは状況により変わる • パイロットユーザーを選定し、優先することも有用 • ”プラットフォームチームは、優先順位と初期パートナーのアプリケーションチー ムを慎重に選択する必要があります。” (出典:CNCFプラットフォームホワイトペーパー) • 適用範囲が広いシナリオ • ユーザーが多い機能に関するシナリオ • 改善例: CLIで短縮フラグの設定 • プラットフォーム (XaaS) において普遍的なシナリオ • 適用範囲が広ければ、改善によりユーザーに提供できる価値が大きくなる • 後から変えることは大変なので早めに一貫した方法を決められると良い ※ CNCFプラットフォームホワイトペーパー: https://tag-app-delivery.cncf.io/ja/wgs/platforms/whitepaper/
10. © LY Corporation 10 プラットフォームに普遍なシナリオ例: パラメーターの設定 オプションで組み合わせ可能。プラットフォームはプロダクト開発をより効率的にする ことを目的としているため、障害となってはいけません。プラットフォームは組み合わ せ可能で、提供される機能の一部のみをプロダクトチームが使用できるようにする必要 があります。 優れたプラットフォームは、ウェブポータル、プロジェクトテンプレート、 セルフサービスAPIなど、その能力やサービスの利用と管理において、一貫 したユーザーエクスペリエンスを提供します CNCFプラットフォームホワイトペーパー より抜粋 「ユーザーがプラットフォームの機能を管理するためにパラメーターを設定する」 というシナリオはプラットフォームエンジニアリングにおいて普遍的に存在
11. © LY Corporation 11 シナリオをさらに細分化し、それぞれ個別に分析する 使いづらさの要因分析：パラメーターの設定の場合 よくありそうなユーザーの声 • どんなパラメーター （機能・設定）があるかわからない • どんな値を設定できるかわからない • それぞれの設定値がどんな意味・効果を持つかわからない • 設定方法が煩雑 「ユーザーがパラメーターを設定する」というシナリオは、以下のようなシナリオに分解される • サブシナリオ1: ユーザーがパラメーターの存在およびその役割を知る • サブシナリオ2: ユーザーがパラメーターと設定できる値の候補・制約を知る • サブシナリオ3: ユーザーが各値をパラメーターに設定する意味を理解する • サブシナリオ4: ユーザーがユーザー自身に必要な設定を適用する
12. © LY Corporation 12 FKEでも採用しているが… アプローチ例: API Schema & Document ※Flava Kubernetes Engine（FKE）はLINEヤフーのクラウドであるFlavaのKubernetes as a Service
13. © LY Corporation 13 例1: KubernetesのNodeに用いるサーバー(VM)のフレーバーの指定 LINEヤフーのKubernetes as a Serviceでの実例 ユーザーはどうやって候補となるフレーバーを把握するか？
14. © LY Corporation 14 FKEにおける設計上の制約・背景事情 • 制約1: UI / CLI / API 全てのユーザーが存在 • 全てのインターフェースに対応できる一貫した方法が必要 • 制約2: API/CLIとUIの開発チームが分離 • 単純な実装とするとデリバリー速度が低下する可能性がある • 制約3: KaaSが他のXaaSに依存 • FKEのパラメーターとして何を設定できるかはFKEが依存しているXaaSにも依存 • XaaS側の変更により、指定可能なオプションが変化するケースがある • 制約4:テナント・スコープごとにオプションを分けたい • グローバルなAPI Schema & Documentでは不十分 • 例: 一部のプロジェクトにだけ GPUインスタンスを許可したい等
15. © LY Corporation 15 Flava Kubernetes Engine (FKE) の場合 制約1: UI / CLI / API 全てのユーザーが存在 FKE API UI CLI ドキュメントで提示？ • 機械はドキュメントを読めない • 例: Terraform Provider • ドキュメント画面に行き確認することが面倒 → “ドキュメントに書く” は最善ではない
16. © LY Corporation 16 Flava Kubernetes Engine (FKE) の場合 制約2: API/CLIとUIの開発チームが分離 FKE API UI CLI FKE team UI team CLIのhelpやUIにハードコードする？ →チームトポロジーの観点で最善ではない • CLI/UIを更新しないと反映できない • CLI: ユーザーが更新してくれない • UI: 他チームとの協業コストで更新速度低下 • APIを利用するユーザに対応できない
17. © LY Corporation 17 Flava Kubernetes Engine (FKE) の場合 制約3: KaaSが他のXaaSに依存 FKE API XaaS API FKE(KaaS)が依存しているXaaSの制約により、 指定可能なオプションは変化する • 物理機材の世代更新によるフレーバー更新 • 一時的な在庫不足によるフレーバーの作成不可 2025/09/18 2025/09/19
18. © LY Corporation 18 Flava Kubernetes Engine (FKE) の場合 制約4: テナント・スコープごとにオプションを分けたい GPUのQuota有 GPUのQuota無 FKE API create GPU nodes create GPU nodes バリデーションで拒否する？ →ユーザーは実際に試してみるまで失敗するかわからない →使いづらい
19. © LY Corporation 19 FKEにおける設計上の制約・背景事情（再掲） • 制約1: UI / CLI / API 全てのユーザーが存在 • 全てのインターフェースに対応できる一貫した方法が必要 • 制約2: API/CLIとUIの開発チームが分離 • 単純な実装とするとデリバリー速度が低下する可能性がある • 制約3: KaaSが他のXaaSに依存 • FKEのパラメーターとして何を設定できるかはFKEが依存しているXaaSにも依存 • XaaS側の変更により、指定可能なオプションが変化するケースがある • 制約4:テナント・スコープごとにオプションを分けたい • グローバルなAPI Schema & Documentでは不十分 • 例: 一部のプロジェクトにだけ GPUインスタンスを許可したい等
20. © LY Corporation 20 FKEにおける解決策：APIで動的にオプションを提示 • APIにロジックを集中 • → API/CLI/UIで一貫性のある体験の提供 • CLIやUIの更新に依存しない • → 更新漏れやデリバリー速度の低下を回避 • 動的なオプション生成 • → XaaS側の変更への追従を実現 • スコープを区切ったオプションの提示 • →柔軟な運用を可能に • フレーバーはproject（テナント）ごとに提示
21. © LY Corporation 21 Flava Kubernetes Engine (FKE) の場合 WebUIでフレーバーを指定するシナリオの実装 FKE API UI ①WebUI上でNodePoolの 操作画面にアクセス ②指定可能なフレーバー 一覧をリクエスト ④WebUI上でNodePoolの フレーバー一覧を表示 ⑤フレーバーを選択＆ NodePoolの作成・更新 ⑥NodePoolの作成・更新 をリクエスト ③指定可能なフレーバー 一覧をリクエスト ユーザー
22. © LY Corporation 22 CLIでフレーバーを指定するシナリオの実装 ①ユーザーがコマンドを試しに実行 ②helpメッセージが表示される ③ユーザーが--flavor-idフラグの存在を知る ④ コマンドでの候補の取得方法を知る ⑤ ’fke spec flavor’ コマンドで候補を取得 ⑥ --flavor-idフラグを指定してNodePoolを操作 ドキュメントなしで操作が完結！
23. © LY Corporation 23 一貫した設計: FKEでのその他パラメーター例 • Flavor • コア数、RAMサイズ、ディスクサイズ等の付加情報も提供 • Kubernetes Version • End of Life等の付加情報も提供 • 作成可能なバージョン・更新先として指定可能なバージョン等も区別 • Availability Zone • VPC Network • CIDR等の付加情報も提供 • … 一部のパラメーターのみでは効果が半減してしまう FKEでは Cluster/NodePool リソースの各種パラメーターについても同様の設計を採用
24. © LY Corporation 24 FKEのパラメーター設定例2: Addonの設定 • FKEでは、k8sへの追加機能・およびそのためのk8s resource/manifestをAddonとして管理している • 例: CNI plugin, CSI plugin, Ingress Controller … • ユーザーはクラスタごとにAddonの設定が可能 • 追加制約:設定可能な項目そのものが動的に変わる • Addonや、パラメーターの追加頻度が高い • 環境・クラスタごとに有効化されているAddonが異なる • 旧KaaS（Verda Kubernetes Service）では、 UI開発が追いつかずCLIのみ対応しているAddon等があり 課題があった
25. © LY Corporation 25 FKEでの解決策：スキーマも動的にAPIで提供する • APIでAddonの一覧を提供 • Addonごとに以下の情報を提供 • Addonの説明 • Addonに関連するリンク • 設定可能なパラメーター • パラメーターの名前 • パラメーターの現在の値 • パラメーターの型 • パラメーターの説明 • 現在は以下の型に対応 • boolean • integer • string • string array
26. © LY Corporation 26 WebUI上でのAddon設定の実装 • WebUIはAPIから動的に各Addonのパネルを生成 • 各パラメーターの説明はtooltipとして表示
27. © LY Corporation 27 CLIでのAddon設定の実装 各Addonごとにキーと値のペアとして パラメーターを操作するインターフェースを提供
28. © LY Corporation 28 パラメーター設定というシナリオにおけるFKEの使いやすさの向上方法 LINEヤフーのKubernetes as a Serviceでの実例まとめ • Cluster・NodePoolの設定 • API Schema & Documentでパラメーターの説明・制約を提示 • 選択式のパラメーターについては、APIで動的にオプションの一覧を提供 • 以下の使いづらさを解消 • 何を設定したら良いかわからないという状況 • ドキュメントを読む手間 • Addonの設定 • Addonのスキーマそのものを動的にAPIで提供 • 提供されたスキーマ・説明をベースに、動的にインターフェース生成 • 以下の点で使いづらさを解消 • 一貫した設定方法により、認知負荷を軽減 • UI上での説明提供により、ドキュメントを読む手間を削減
29. © LY Corporation 29 「普遍的なシナリオに対する解決策」は「開発者にとってのゴールデンパス」 余談1: 開発者にとってのプラットフォーム 開発者全員がシナリオ分析が得意なわけではない 「シナリオを分析し使いやすいプラットフォームを設計する」という手法は個別の機 能ごとに実施するのは難しい 普遍的なシナリオに対する解決策を仕組みとして定義しておくと、 それがプラットフォーム開発者にとってのゴールデンパスとなる。 結果として自然とプラットフォームが使いやすい設計で拡張していく
30. © LY Corporation 30 余談2:「使いづらい」は常に悪…ではない • 「使いやすさ」はユーザーに提供する１つの価値に過ぎない • プロダクト全体で見て提供する価値を高められれば良い • あえて「使いづらくする」こともプロダクトデザインの一環 例 • リスクの大きい機能の利用の為にワークフローや責任者・管理者の承認を要求する • 実装・検証途中の機能を早く提供するために、管理者の権限で先行的に有効化する
31. © LY Corporation 31 余談3: どうやって普遍的なシナリオを見つけるか？ • 巨人の肩に乗る • CNCFプラットフォームホワイトペーパー • ペルソナ・シナリオ法、デザイン思考等のプロダクト設計・要件定義手法 • … • シナリオ＝軸・視点の組み合わせ・掛け算として理解する • p6でのシナリオ分析は「ユーザーの習熟度」と「機能」の２軸の掛け算（直積） • FKEの例では「ユーザーが利用するインターフェース（API/UI/CLI）」の軸も登場 • 異なる軸の組み合わせ、同じ軸の新たなケースの発見で、無数のシナリオが想定可能 • 個々のケースの根底にある軸を把握することで、軸に対して汎化したシナリオに拡張できる
32. © LY Corporation ‒ プラットフォームの使いやすさは、個別のシナリオにおける使いやすさで決まる • ユーザーにとって重要なシナリオ・普遍的なシナリオに存在する課題から改善しよう ‒ プラットフォームに普遍的なシナリオ例：パラメーターの設定 • LINEヤフーのKubernetes as a Service: Flava Kubernetes Engineの場合 • Kubernetes クラスタそのもののパラメーター設定 (Flavor等) • Addonのパラメーター設定 • 解決策例: APIで一貫した形式でスキーマ、候補値、説明、リンクを動的に提供 • シナリオは普遍でも、最適な解決策は状況により変わる ‒ 「使いやすさ」はあくまでユーザーに提供する価値の一つ • 状況によって「使いやすさ」を犠牲にする選択肢も持とう 32 まとめ