ナレッジワークの成長を加速する Platform Engineering 戦略

@ Google Cloud Innovators Live Japan
急成長企業のエンジニアに聞く！スタートアップにおける Platform Engineering のリアル

https://cloudonair.withgoogle.com/events/innovators-live-jp?tab=cloudnative&expand=module:cloudnative_20240910

Transcript

1. ナレッジワークの成長を加速する Platform Engineering 戦略 株式会社ナレッジワーク / Shogo Watanabe / Platform & SRE Group Manager
2. 01 03 02 04 ナレッジワークの成長と課題 Platform 戦略 1 : ミドルウェア Platform 戦略 2 : 自律分散プラットフォーム 自己紹介 05 まとめと今後の展望
3. 自己紹介
4. 自己紹介 株式会社ナレッジワーク Platform & SRE Group Manager 2023 年に株式会社ナレッジワークに入社し、 認証基盤の刷新や自律分散アーキテクチャへの移行を担当。 現在はプレイングマネージャーとして Platform Engineering や SRE 領域をリード。 Shogo Watanabe @nownabe
5. 創業日 　2020 年 4 月 1 日 代表者 　麻野 耕司 資本金 　61.3 億円（資本準備金等含む） 事業内容 　ナレッジワークの開発・提供 主な株主 　グロービス・キャピタル・パートナーズ、DNX Ventures、WiL 　Salesforce Ventures、One Capital、ANRI、XTech、 　ユーザベース、フォースタートアップス、Sansan
6. できる喜びが巡る日々を届ける Deliver the joy of enablement 「昨日できなかった仕事が今日できるようになった」 「今日うまく進められなかった仕事も明日はうまくできるかもしれない」 そんな想いで働ければ、仕事に希望が持てるはずです。 しかし、世の中の多くの人が「上司に恵まれない」「職場に恵まれない」 「会社の仕組みに恵まれない」などの理由で、 「努力しても成長できない」「努力しても成果が出ない」つまりは 「努力しても報われない」という環境で仕事をしています。 私たちは『イネーブルメント』を実現するプロダクトを提供することで 世の中の人たちが仕事にできるようになることを支援し、 働く喜びが巡る日々を届けます。
7. セールスイネーブルメントクラウド「ナレッジワーク」 みんなが売れる営業になる セールスイネーブルメントクラウド
8. ナレッジワークの成長と課題
9. 社員数は倍々で増加 エンジニア
10. 導入実績
11. 2023 年 11 月 シリーズ B 調達で一気に加速 https://prtimes.jp/main/html/rd/p/000000035.000063428.html
12. ナレッジワークが目指すマルチ プロダクト 高速な新プロダクトの立ち上げ はじめから高品質な新プロダクト 一貫性があるユーザー体験の提供
13. 一貫した体験で はじめから高品質な 10 プロダクト 身近な例
14. マルチ プロダクトを実現するための Platform Engineering 戦略 高速な新プロダクトの立ち上げ はじめから高品質な新プロダクト 一貫性があるユーザー体験の提供 自律分散プラットフォーム ミドルウェア Platform Engineering 戦略
15. Platform 戦略 1 ミドルウェア
16. マルチプロダクトを実現するための Platform Engineering 戦略 高速な新プロダクトの立ち上げ はじめから高品質な新プロダクト 一貫性があるユーザー体験の提供 自律分散プラットフォーム ミドルウェア Platform Engineering 戦略
17. ミドルウェア？ ナレッジワーク プロダクト全体のコアとなるデータや機能をホストするサービス ミドルウェア プロダクト A プロダクト B プロダクト C
18. ナレッジワーク (セールス イネーブルメント) ミドルウェアを中心にマルチプロダクトを展開 ミドルウェア プロダクト A プロダクト B プロダクト C 新プロダクト 新プロダクト プロダクト D • 一般的な共通機能だけではなく次のような特徴を持つ ◦ ナレッジワークのビジネスドメインに特化 ◦ 一貫性があり高品質なプロダクト機能を提供 ◦ 将来に渡る高速なプロダクトの立ち上げを実現
19. ナレッジワークのミドルウェア ミドルウェア プロダクト A プロダクト B プロダクト C 認証・認可 ナレッジ (営業資料など) ディレクトリ (ユーザー ID など) ID 連携 監査ログ ナレッジ管理・連携 通知 タスクキュー 新プロダクト 新プロダクト プロダクト D
20. 高速な立ち上げ、高品質なプロダクト、一貫性のある体験を ミドルウェアで実現 高速な新プロダクトの立ち上げ はじめから高品質な新プロダクト 一貫性があるユーザー体験の提供 自律分散プラットフォーム ミドルウェア
21. Platform 戦略 2 自律分散プラットフォーム
22. マルチプロダクトを実現するための Platform Engineering 戦略 高速な新プロダクトの立ち上げ はじめから高品質な新プロダクト 一貫性があるユーザー体験の提供 自律分散プラットフォーム ミドルウェア Platform Engineering 戦略
23. 自律分散プラットフォーム？ 自律分散プラットフォーム いわゆるマイクロサービス アーキテクチャ セルフサービス プラットフォーム = +
24. マルチ プロダクト化における技術的懸念 モノリス • 創業期はリーズナブルな選択 • 成長期で課題が顕在化 ◦ 開発速度の低下 ◦ 開発品質の低下 ◦ 開発体験の低下
25. 単一プロダクトからマルチ プロダクトへ モノリスから自律分散アーキテクチャへ モノリス プロダクト マルチ プロダクト ナレッジワーク ミドルウェア プロダクト A プロダクト B プロダクト C プロダクト D 新規開発 ナレッジワーク オプション機能 B オプション機能 C
26. 「マイクロサービス」ではなく 「できるだけ大きい自律サービス」を目指す • ビジネス ドメインの境界 = プロダクトの境界を見極めて最小限のサービス分割 ◦ 将来の分割に備えてサービス内はモジュラーモノリスで実装 • プロダクト単位でみるとモノリス → 認知負荷が低い • プラットフォーム的には分散サービス数の抑制 → 運用コストが低い プロダクト A サービス プロダクト A 開発チーム プロダクト B 開発チーム プロダクト C 開発チーム モジュール モジュール プロダクト B サービス モジュール モジュール プロダクト C サービス モジュール モジュール
27. Cloud Run を中心としたサーバーレスの採用 • 開発・運用ともに認知負荷を軽減 • Cloud Run 選定理由 ◦ Kubernetes がなくても要件を十分満たす ◦ できるだけ大きい自律サービスが実現可能 ◦ ゼロスケールによるインフラコストの削減 ◦ シンプルでわかりやすい ◦ 運用コストの削減 ◦ Cloud Run の将来性 • その他も基本はマネージド サービスを活用 ◦ Cloud SQL、Cloud Storage、Pub/Sub、Cloud Tasks、など
28. プロダクト C プロダクト B プロダクト A 自律分散アーキテクチャ概要 LB Cloud Load Balancing product A backend Cloud Run product A frontend Cloud Run product B backend Cloud Run product B frontend Cloud Run product C backend Cloud Run product C frontend Cloud Run frontend Vercel backend Cloud Run モノリス 自律分散アーキテクチャ
29. 自律分散アーキテクチャ詳細 (プロダクト ) プロダクト A gateway Cloud Run LB Cloud Load Balancing database Cloud SQL job queue Cloud Tasks backend Cloud Run worker Cloud Run frontend Cloud Run プロダクト B プロダクト C プロダクトは基本的に同じ構成
30. 自律分散アーキテクチャ詳細 (ミドルウェア ) ミドルウェア α gateway Cloud Run LB Cloud Load Balancing database Cloud SQL job queue Cloud Tasks backend Cloud Run worker Cloud Run frontend Cloud Run ミドルウェア β ミドルウェアはより複雑な構成 gateway Cloud Run frontend Cloud Run auth Cloud Run backend Cloud Run ID management Identity Platform database Cloud SQL event queue Pub/Sub file storage Cloud Storage
31. Layered-service アーキテクチャの採用 ミドルウェア • サービス間の依存関係の制約 ◦ プロダクトはミドルウェアに依存可能 ◦ プロダクト間の依存禁止 ◦ ミドルウェア内はさらにレイヤーを定義 • 保守性の向上 ◦ サービス間依存による認知負荷を軽減 • 再利用性の向上 ◦ 共通データ・機能をミドルウェアに集約 プロダクト ミドルウェア α Cloud Run ミドルウェア β Cloud Run プロダクト A Cloud Run プロダクト B Cloud Run ︙
32. 自律分散アーキテクチャを支えるセルフサービス プラットフォーム • 各プロダクト開発チームの自律性を保ちつつ、認知負荷を最小化 ◦ セルフサービスとして提供 ◦ 適切な抽象化・隠蔽 プロダクト テンプレート gateway Cloud Run database Cloud SQL job queue Cloud Tasks backend Cloud Run worker Cloud Run frontend Cloud Run ミドルウェア SDK Observability アラート CI/CD Terraform Readiness Checklist
33. 各プロダクト開発チームの最高パフォーマンスを 自律分散プラットフォームで実現 高速な新プロダクトの立ち上げ はじめから高品質な新プロダクト 一貫性があるユーザー体験の提供 自律分散プラットフォーム ミドルウェア Platform Engineering 戦略
34. まとめと今後の展望
35. マルチ プロダクトを実現するための Platform Engineering 戦略 高速な新プロダクトの立ち上げ はじめから高品質な新プロダクト 一貫性があるユーザー体験の提供 自律分散プラットフォーム ミドルウェア Platform Engineering 戦略
36. 高速な立ち上げ、高品質なプロダクト、一貫性のある体験を ミドルウェアで実現 ミドルウェア プロダクト A プロダクト B プロダクト C 認証・認可 ナレッジ (営業資料など) ディレクトリ (ユーザー ID など) ID 連携 監査ログ ナレッジ管理・連携 通知 タスクキュー 新プロダクト 新プロダクト プロダクト D
37. 各プロダクト開発チームの最高パフォーマンスを 自律分散プラットフォームで実現 プロダクト A gateway Cloud Run LB Cloud Load Balancing database Cloud SQL job queue Cloud Tasks backend Cloud Run worker Cloud Run frontend Cloud Run プロダクト B プロダクト C
38. まだまだ始まったばかり • 今はまだ Platform Engineering を本格的に始める準備段階 • モノリス解体もまだ終わりきっていない • やりたいことはたくさんある ◦ セルフサービス化の推進 ◦ ミドルウェア as a Service の推進 ◦ 開発ポータルの提供 ◦ ゴールデンパスの整備 ◦ よりよい抽象 ◦ モノレポ整備
39. WE ARE HIRING!! ナレッジワークはエンジニア大大大募集中です プロダクト開発 / プラットフォーム開発 バックエンド / フロントエンド / SRE / QA セキュリティ / データ / AI https://kwork.studio/recruit-engineer まずはカジュアルに質問・相談も大歓迎！ → @nownabe まで
40. Thank you. Proprietary + Confidential