2週に1度のビッグバンリリースをデイリーリリース化するまでの苦悩 ~急成長するスタートアップのリアルな裏側~
by
KNOWLEDGE WORK / 株式会社ナレッジワーク
Link
Embed
Share
Beginning
This slide
Copy link URL
Copy link URL
Copy iframe embed code
Copy iframe embed code
Copy javascript embed code
Copy javascript embed code
Share
Tweet
Share
Tweet
Slide 1
Slide 1 text
2週に1度のビッグバンリリースを デイリーリリース化するまでの苦悩 mado / Knowledge Work
Slide 2
Slide 2 text
© Knowledge Work Inc. ⾃⼰紹介 株式会社ナレッジワーク SRE / Scrum Master 樋⼝ 直⼈ (mado) 経歴 パチプロ / パチスロライター / パチスロエンジニア ビズリーチ: テックリード - Scala, AWS ナレッジワーク: 1⼈⽬SRE - Go, Google Cloud 趣味 まどマギのパチスロ (4⽉の新台マギアレコードが楽しみ) ウルトラマラソン / スパルタンレース サウナ
Slide 3
Slide 3 text
© Knowledge Work Inc. 皆さんのリリース頻度はどのくらいでしょうか? 3 Elite オンデマンド (複数回 / ⽇) High 1回 / 1⽇ ~ 1週 Medium 1回 / 1週 ~ 1⽉ Low 1回 / 1⽉ ~ パフォーマンス デプロイ頻度
Slide 4
Slide 4 text
© Knowledge Work Inc. ローンチ直後のナレッジワーク 4 DORAのパフォーマンス指標において Lowレベル Elite オンデマンド (複数回 / ⽇) High 1回 / 1⽇ ~ 1週 Medium 1回 / 1週 ~ 1⽉ Low 1回 / 1月 ~ パフォーマンス デプロイ頻度
Slide 5
Slide 5 text
© Knowledge Work Inc. 今⽇のお話 5 ビッグバンリリースを解体して⾼頻度リリース化を⽬指すお話 ナレッジワーク モノリス 🚀 Server Server Server Server Server Server Server Server 🚀 🌅 🚀 🌆 🚀 🏙 🚀 🌃 🚀 🏙 🚀 🌆 🚀 🏙 🚀 🌅
Slide 6
Slide 6 text
© Knowledge Work Inc. Key Takeaways 6 • スタートアップでも低頻度デプロイの許容はマズい • 低頻度デプロイを改善した時の苦労ポイント
Slide 7
Slide 7 text
© Knowledge Work Inc. Agenda 目次 1. 会社/事業紹介 2. マルチプロダクトへの転換 3. リリースの課題 4. リリース改善の道のり 5. 現状と効果 6. 今後の展望 7
Slide 8
Slide 8 text
1. 会社‧事業紹介
Slide 9
Slide 9 text
© Knowledge Work Inc. Profile 会社概要 9 創業⽇ 2020年4⽉1⽇ 代表者 ⿇野 耕司 資本⾦ 61.3億円(資本準備⾦等含む) 事業内容 ナレッジワークの開発‧提供 主な株主 グロービス‧キャピタル‧パートナーズ、DNX Ventures、WiL One Capital、ANRI、XTech、Salesforce Ventures ユーザベース、フォースタートアップス、Sansan
Slide 10
Slide 10 text
© Knowledge Work Inc. ナレッジワークのミッション 10 できる喜びが巡る⽇々を届ける Deliver the joy of enablement 「昨⽇できなかった仕事が今⽇できるようになった」 「今⽇うまく進められなかった仕事も明⽇はうまくできるかもしれない」 そんな想いで働ければ、仕事に希望が持てるはずです。 しかし、世の中の多くの⼈が「上司に恵まれない」「職場に恵まれない」 「会社の仕組みに恵まれない」などの理由で、 「努⼒しても成⻑できない」「努⼒しても成果が出ない」つまりは 「努⼒しても報われない」という環境で仕事をしています。 私たちは『イネーブルメント』を実現するプロダクトを提供することで 世の中の⼈たちが仕事にできるようになることを⽀援し、 働く喜びが巡る⽇々を届けます。 我々はイネーブルメントの会社です
Slide 11
Slide 11 text
© Knowledge Work Inc. イネーブルメントの4つの提供価値 11 「ナレッジ」「ラーニング」「ワーク」「ピープル」 の4つの領域が必要になります 成果視点 (業務視点) 能⼒視点 (⼈材視点) できるよう になる (Canの最⼤化) ワーク 領域 ナレッジ 領域 ピープル 領域 ラーニング 領域 やるべきこと が分かる (MUSTの明確化) ワーク領域 業務プロセスの最適化 ナレッジ領域 コンテンツやノウハウの展開 ピープル領域 スキルの可視化 ラーニング領域 学習プログラムの提供
Slide 12
Slide 12 text
© Knowledge Work Inc. 事業展開 12 課題の⼤きい営業職種にまずフォーカスし 隣接した職種への展開に向けて製品開発を進めていきます ナレッジ領域 営業 ‧‧‧ ‧‧‧ ‧‧‧ ワーク領域 ラーニング領域 ピープル領域
Slide 13
Slide 13 text
© Knowledge Work Inc. 製品紹介 13 みんなが売れる営業になる セールスイネーブルメントクラウド セールスイネーブルメントクラウド「ナレッジワーク」を提供しています
Slide 14
Slide 14 text
© Knowledge Work Inc. マルチプロダクトへ 14
Slide 15
Slide 15 text
2. マルチプロダクトへの転換
Slide 16
Slide 16 text
© Knowledge Work Inc. マルチプロダクト戦略は⼤きく2種類 16 ナレッジワークのビジネスではコンパウンド戦略が最適と判断 ⾃律的な独⽴プロダクト 共通基盤を整え全体最適を⽬指す プロダクトA 基盤A プロダクトB 基盤B 共通基盤 プロダクトA プロダクトB プロダクトごとの⾃由度は⾼いが 複利が⽣まれ⾟い 少ない⼈数で最⼤効率を⽬指せる SaaS界隈ではコンパウンド戦略と呼ばれる
Slide 17
Slide 17 text
© Knowledge Work Inc. 共通基盤不⾜ 17 しかし、 当時はコンパウンド戦略を遂⾏できる共通基盤が不⾜
Slide 18
Slide 18 text
© Knowledge Work Inc. コンパウンド戦略を進められる体制へ 18 当時はSREやPlatform Engineer不在だったが 2022: SRE⼊社 2023: Platform Engineer⼊社 2024: SRE⼊社 徐々に⼈材が揃ってきて、コンパウンド戦略を進められる体制に
Slide 19
Slide 19 text
マルチプロダクト化のbefore/after
Slide 20
Slide 20 text
© Knowledge Work Inc. リリースフロー before 20 prd環境のリリースまで最⼤5週間かかる ブランチ 環境 master qa stg prd 2週間 2週間 1週間 dev 環境 qa 環境 prd 環境 stg 環境 🌃 🌃 🌅
Slide 21
Slide 21 text
© Knowledge Work Inc. リリースフロー after 21 ⾼頻度でデプロイできるフローに ブランチ 環境 master dev 環境 qa 環境 prd 環境 stg 環境 promote promote IssueOps
Slide 22
Slide 22 text
© Knowledge Work Inc. システムアーキテクチャ before/after 22 モノリス 自律分散アーキテクチャ モノリスから⾃律分散アーキテクチャへ プロダクトA プロダクトB プロダクトC LB Cloud Load Balancing backend A Cloud Run backend Cloud Run backend B Cloud Run frontend B Cloud Run frontend A Cloud Run backend C Cloud Run frontend C Cloud Run Frontend Vercel
Slide 23
Slide 23 text
© Knowledge Work Inc. なぜ改善してきたのか 23 before/afterに⾄った経緯と ⾄るまでの苦労を以下にまとめます
Slide 24
Slide 24 text
3. リリースの課題
Slide 25
Slide 25 text
© Knowledge Work Inc. デプロイ頻度が少ない 25 DORAのパフォーマンス指標においてLowレベル Elite オンデマンド (複数回 / ⽇) High 1回 / 1⽇ ~ 1週 Medium 1回 / 1週 ~ 1⽉ Low 1回 / 1⽉ ~ パフォーマンス デプロイ頻度
Slide 26
Slide 26 text
© Knowledge Work Inc. デプロイ頻度が低いことによる問題 26 デプロイ頻度の低さはビジネス競争⼒を弱めます 機能開発のフィードバックループが遅い インシデントが起きやすい 原因が特定し⾟い 開発 企画 顧客の声 slow…
Slide 27
Slide 27 text
© Knowledge Work Inc. 深夜デプロイ時にやることが多く消耗 27 トイルや深夜作業による消耗はバーンアウトの原因となります やることがとにかく多い 深夜作業で消耗
Slide 28
Slide 28 text
© Knowledge Work Inc. devとopsのサイロ化 28 dev (開発チーム) ops (SRE) 開発と運⽤でフィードバックサイクルによる改善が回らない 運⽤を無視した開発が横⾏してしまう
Slide 29
Slide 29 text
© Knowledge Work Inc. hotfixリリースが⼤変 29 prd ブランチ prd 環境 hotfix時のトラブルが多い hotfixパッチ 変更リードタイムが長いためコンフリクトが発生しやすい 原因となるサービスの特定が大変 サービスごとにデプロイ方法が異なっていて職人芸が必要 リリース時に各所への調整が必要
Slide 30
Slide 30 text
⾼頻度リリース化する上での課題
Slide 31
Slide 31 text
© Knowledge Work Inc. モノリス 31 リリースタイミングの調整が難しい プロダクトB プロダクトA プロダクトC プロダクトD モノリスは頻繁なリリースが難しい オーナーが不明瞭 X月X日にリリースしたい QAが間に合わないから無理
Slide 32
Slide 32 text
© Knowledge Work Inc. 機能リリースのタイミングのズレ 32 toB SaaSとしてCSの⼿厚いサポートがあるため 頻繁な機能リリースが難しい 頻繁にprd環境にリリースしたい リリース前にstg環境でじっくり触りたい CS Dev
Slide 33
Slide 33 text
© Knowledge Work Inc. 品質保証 33 dev 環境 qa 環境 prd 環境 stg 環境 2週間かけてきたQA期間をどう短縮するか 2週間 2週間 1週間
Slide 34
Slide 34 text
4. リリース改善の道のり
Slide 35
Slide 35 text
© Knowledge Work Inc. ⾼頻度デプロイのために 35 ⾼頻度デプロイのためには まずプロダクトごとにサービスを分割し デプロイの独⽴性担保が必要
Slide 36
Slide 36 text
© Knowledge Work Inc. サービスの分割のために 36 全プロダクトを巻き込むため 全社横断的なプロジェクト化が必要
Slide 37
Slide 37 text
© Knowledge Work Inc. プロジェクト化 37 ● 全社巻き込みのためプロジェクト発⾜ ● ゴールは2つ ○ モノリスから⾃⽴分散アーキテクチャへの移⾏ ○ 低頻度ビッグバンデプロイから⾼頻度スモールデプロイへの移⾏ ● CTOやPrincipal Engineer、PdMなどを巻き込み ● プロジェクト名は Project Bamboo ○ ⽵を割ったような美しいサービス分割 ○ 地下茎 (Platform) による驚異的な繁殖⼒と成⻑スピード 印象に残るようにイメージ画像も作成 全社プロジェクト開始
Slide 38
Slide 38 text
© Knowledge Work Inc. モノリスの解体 38 モノリス ⾃律分散アーキテクチャ プロダクトごとに独⽴してデプロイできるように分割 プロダクトは量産できるようにテンプレート化 プロダクトA プロダクトB プロダクトC LB Cloud Load Balancing backend A Cloud Run backend Cloud Run backend B Cloud Run frontend B Cloud Run frontend A Cloud Run backend C Cloud Run frontend C Cloud Run Frontend Vercel
Slide 39
Slide 39 text
© Knowledge Work Inc. デプロイとリリースの分離 デプロイ時に全機能リリース デプロイ時に全機能リリース 39 全機能を機能フラグ管理 機能フラグONはPdMが任意のタイミングで実施 機能リリースのタイミングのズレを解消 デプロイとリリースを明確に分離することで 頻繁なデプロイと任意のタイミングでの機能リリースを実現 デプロイ & リリース デプロイ リリース PdM Eng
Slide 40
Slide 40 text
© Knowledge Work Inc. 40 サービスの品質保証 qa example worker example backend example gateway e2e 実施 stg example worker example backend example gateway e2e 実施 prd example worker example backend example gateway 🎉 e2eテストを強化 e2eテストが通ると次の環境へデプロイされる Cloud Deploy Delivery pipeline
Slide 41
Slide 41 text
デプロイ時のオペレーション分離
Slide 42
Slide 42 text
© Knowledge Work Inc. デプロイとterraform applyの分離 デプロイ時にterraform apply アプリケーションデプロイ時に terraform apply 42 terraform applyを分離 デプロイとterraform applyを分離 デプロイとterraform applyを分離 デプロイ & terraform apply デプロイ terraform apply terraform apply terraform apply
Slide 43
Slide 43 text
© Knowledge Work Inc. デプロイとterraform applyを分離 43 細かい単位で都度prd環境までapplyする運⽤へ master tf/qa tf/stg tf/prd Pull request → Approve → atlantis apply Pull request → Approve (SRE) → atlantis apply Pull request → Approve (SRE) → atlantis apply
Slide 44
Slide 44 text
© Knowledge Work Inc. デプロイとDB migrationの分離 デプロイ時にDB migration アプリケーションデプロイ時に DB migration 44 DB migrationを分離 デプロイとDB migrationの分離 デプロイとDB migrationを分離 デプロイ & DB migration デプロイ DB migration DB migration DB migration
Slide 45
Slide 45 text
© Knowledge Work Inc. デプロイとDB migrationの分離 45 毎⽇深夜にstg/prdへDB migrationする運⽤へ master db-migration/qa db-migration/stg db-migration/prd qa 実行 stg 実行 prd 実行 🌃 🌃 ● 各ブランチへのマージをトリガーに Cloud Build 起動 ○ Cloud Build で sql-migrate を実⾏ ● stg/prd への実⾏は深夜メンテナンスウィンドウに実 ⾏ ○ Pull request を Approve だけしておく ○ GitHub Workflow で⾃動マージ
Slide 46
Slide 46 text
移⾏期間中に起きること
Slide 47
Slide 47 text
© Knowledge Work Inc. 社内各所から⾊々と懐疑的な声 47 ⻑らく続いたビックバンリリースの⽂化は根強い ⼤きな変更は何かあると槍⽟にあげられる 後方互換性を意識したダウンタイムのない開発は大変 ... 機能開発のスピードが落ちたのでは ... 移行に伴うインシデントが増えた ...
Slide 48
Slide 48 text
© Knowledge Work Inc. 48 やりきる実⾏⼒ 完了後 移⾏中 ビジョンを語り続けて実⾏していく必要がある 戦略と実⾏どちらも⼤事 プロダクト開発チームの時間 新規構築のコストダウン 量産化できる基盤 Platform プロダクト プロダクト プロダクト
Slide 49
Slide 49 text
5. 現状と効果
Slide 50
Slide 50 text
© Knowledge Work Inc. 50 完全分割まであと⼀歩 ナレッジワーク モノリス 2022 2025 🚀 Server Server Server Server Server Server Server Server 🚀 🌅 🚀 🌆 🚀 🏙 🚀 🌃 🚀 🏙 🚀 🌆 🚀 🏙 🚀 🌅 一部サービスで 高頻度デプロイを開始
Slide 51
Slide 51 text
© Knowledge Work Inc. オーナーシップの明確化 51 各プロダクトチームが⾃律的に開発‧運⽤‧デプロイできる体制に プロダクトA SRE Platform プロダクトB プロダクトC
Slide 52
Slide 52 text
© Knowledge Work Inc. オンデマンドにサッとデプロイ 52 サービスごとにprd環境まで⾼頻度デプロイ可能に hotfixも正規ルートで安全にデプロイ ブランチ 環境 master dev 環境 qa 環境 prd 環境 stg 環境 promote promote IssueOps
Slide 53
Slide 53 text
6. 今後の展望
Slide 54
Slide 54 text
© Knowledge Work Inc. まだまだやりたいことはたくさん 54 • 全サービスの分割&⾼頻度デプロイ(あと少し!) • DB分割 • 環境の削減 • Platform Enginneringの推進(テンプレート化、モジュール化) • 開発ポータル作成 理想のプラットフォームへ
Slide 55
Slide 55 text
© Knowledge Work Inc. SRE as a Service 55 各プロダクト開発チームが 信頼性の⾼いプロダクトを効率よく開発できるPlatformを開発していきます プロダクトA Platform SRE Platform プロダクトB プロダクトC
Slide 56
Slide 56 text
© Knowledge Work Inc. Platform & SRE Group 56 樋⼝ 直⼈ ex-ビズリーチ SRE Google Cloud 資格9冠 ギャンブラー 渡邊 尚吾 ex-Google Group Manager Google Cloud Champion Innovator 愛⽝家 SRE k8sとGitHub Actions のスペシャリスト 世界⼀周トラベラー 村岡 宏是 ex-10X 本⽇全員会場に来ています ブースに遊びに来て気軽に話しかけてください
Slide 57
Slide 57 text
© Knowledge Work Inc. WE ARE HIRING! 57 SRE & Platform Engineer 募集中! 新規プロダクトをガンガン⽴ち上げられる 最⾼のプラットフォームを開発していきます! イネーブルメントに興味ある⽅ お声がけください!
Slide 58
Slide 58 text
No content