SRE、開発、QAが協業して挑んだリリースプロセス改革@SRE Kaigi 2025

SRE Kaigi 2025
https://2025.srekaigi.net/

Transcript

1. 2025/01/26 SRE Kaigi 2025 株式会社ニーリー 宮後 啓介 @miya10kei NEALLE SRE、開発、QAが協業して挑んだ リリースプロセス改革 1
2. 2023年にニーリーにジョイン SREとしてサービスの信頼性やアジリティ向上の施策を実施。 最近はSRE業務のかたわら生成AIを用いた業務改善をしています。 以前は、SIerで業務システムのスクラッチ開発、Web系企業でメー ルサービスやフリマサービスなど複数のサービス開発やSRE業務を 担当。 2 自己紹介 @miya10kei 株式会社ニーリー プラットフォーム開発G SREチーム リーダー Keisuke Miyaushiro 宮後 啓介
3. 3 プロダクト紹介
4. 複数のチームユニット 4 プロダクト開発組織の紹介 ※ 2024年12月時点 Nealle プロダクト統括本部 Growth/BizDev PdM エンジニア QA デザイン 5名 SRE Platform Success Engineering Architecture Design エンジニア エンジニア エンジニア エンジニア デザイン 2名 6名 4名 1名 全チームユニット合計 PdM エンジニア QA デザイン 3名 32名 7名 5名 ・ ・ ・ Nealle全体の従業員数 約 200名 開発組織の従業員数 約 65名 ※ 業務委託/兼務を含む
5. 目次 1｜抱えていた課題 2｜取り組み 3｜現在の課題と今後の取り組み 4｜まとめ 5
6. 目次 1｜抱えていた課題 2｜取り組み 3｜現在の課題と今後の取り組み 4｜まとめ 6
7. 7 1｜抱えていた課題 デプロイ頻度の低さ 変更障害率の高さ
8. 8 1｜抱えていた課題 ~ デプロイ頻度 ~ 月に2〜5回ほどの頻度でしかデプロイできていない状態🥲
9. 9 1｜抱えていた課題 ~ 変更障害率 ~ デプロイすると40%は障害が発生していた状態🥲
10. 10 プロダクトをグロースさせていく上で 高頻度に安定したリリースをしていくことは重要！ 1｜抱えていた課題
11. 開発から運用まで含めたリリースプロセスの改革に着手！ 11 1｜抱えていた課題
12. 目次 1｜抱えていた課題 2｜取り組み 3｜現在の課題と今後の取り組み 4｜まとめ 12
13. 13 2｜取り組み 開発 テスト リリース 運用 Feature環境の導入 開発DB複製の自動化 テストでの 本番データ利用 ゼロダウンタイム リリースの実現 DBマイグレーション のリハーサル リリーストグルの運用改善 パラレルテスト の導入
14. 14 2｜取り組み 〜 ゼロダウンタイムリリースの実現 〜 開発 テスト リリース 運用 Feature環境の導入 開発DB複製の自動化 テストでの 本番データ利用 ゼロダウンタイム リリースの実現 DBマイグレーション のリハーサル リリーストグルの運用改善 パラレルテスト の導入
15. ▪ 課題 • 全てのリリースがダウンタイムを伴うものになっていた ◦ 頻度高くリリースができない ◦ 深夜作業となり負担が大きい ▪ 取り組み • ゼロダウンタイムでのリリースを実現するために次の取り組みを実施し、ダウン タイムリリースとゼロダウンタイムリリースを選択できるようにした ◦ ゼロダウンタイムでリリースすための条件を整理 ◦ ゼロダウンタイムリリースの仕組みの構築 15 2｜取り組み 〜 ゼロダウンタイムリリースの実現 〜
16. ▪ ゼロダウンタイムでリリースするための条件を整理 • アプリケーション間の後方互換性が担保できていること • DBマイグレーションが伴わないこと ◦ ※ DBマイグレーションのリハーサルをおこなうことで一部緩和 16 2｜取り組み 〜 ゼロダウンタイムリリースの実現 〜
17. ▪ ゼロダウンタイムリリースの仕組みの構築 ▼ 既存のダウンタイムリリース 　developブランチに変更を溜め込み、リリースタイミングでstaging/masterブランチ に反映 17 2｜取り組み 〜 ゼロダウンタイムリリースの実現 〜
18. ▪ ゼロダウンタイムリリースの仕組みの構築 ▼ ゼロダウンタイムリリース 　stagingブランチに変更を溜め込むことでダウンタイムリリースと開発ラインを分離 18 2｜取り組み 〜 ゼロダウンタイムリリースの実現 〜
19. 19 2｜取り組み 〜 DBマイグレーションのリハーサル 〜 開発 テスト リリース 運用 Feature環境の導入 開発DB複製の自動化 テストでの 本番データ利用 ゼロダウンタイム リリースの実現 DBマイグレーション のリハーサル リリーストグルの運用改善 パラレルテスト の導入
20. ▪ 課題 • DBマイグレーションが必要なリリースが全てダウンタイムリリースとなっていた ◦ テーブルやレコードロックによるアプリケーションへの影響を気にしていた ▪ 取り組み • 事前に本番データを用いてDBマイグレーションを実行する仕組みを構築し、ロッ ク時間の短いマイグレーションはゼロダウンタイムでのリリースを許容するよう にした 20 2｜取り組み 〜 DBマイグレーションのリハーサル 〜
21. GitHub ActionsのWFから本番データに対してDBマイグレーションを実行できる仕組み を構築 21 2｜取り組み 〜 DBマイグレーションのリハーサル 〜
22. テーブル毎のロック時間をSlackに通知し、ゼロダウンタイムでのリリースが可能かを 判断 22 2｜取り組み 〜 DBマイグレーションのリハーサル 〜
23. 23 2｜取り組み 〜 Feature環境の導入 〜 開発 テスト リリース 運用 Feature環境の導入 開発DB複製の自動化 テストでの 本番データ利用 ゼロダウンタイム リリースの実現 DBマイグレーション のリハーサル リリーストグルの運用改善 パラレルテスト の導入
24. ▪ 課題 • 開発環境へのマージ前に開発中のアプリケーションを複数人で同時に触ることが できない • クラウド環境でしか確認できない事象の検証に手間がかかる ▪ 取り組み • Feature環境（＝Pull Requestの単位で作成可能な専用環境）を作成する仕組みを 構築し、案件単位で並行開発しやすい環境を整備 24 2｜取り組み 〜 Feature環境の導入 〜
25. 25 2｜取り組み 〜 Feature環境の導入 〜 Pull Requestへのラベル付与をトリガーに専用のFeature環境を構築 • 21時に自動削除することでコストを削減
26. Feature環境についての詳細はテックブログに載っているので是非ご覧ください！ 26 2｜取り組み 〜 Feature環境の導入 〜 https://nealle-dev.hatenablog.com/entry/2024/12/20/01 https://nealle-dev.hatenablog.com/entry/2024/04/01/120409
27. 27 GitHub ActionsをトリガーにSlackで操作者に通知したい場合、Slackのマイキーワード にGitHubのユーザ名を登録することで簡単に通知することができます！ ※ SlackのGitHubアプリでは多数の通知が届いてしまいノイズになってました💦 Tips｜GitHub ActionsからSlack通知をするとき
28. 28 2｜取り組み 〜 開発DB複製の自動化 〜 開発 テスト リリース 運用 Feature環境の導入 開発DB複製の自動化 テストでの 本番データ利用 ゼロダウンタイム リリースの実現 DBマイグレーション のリハーサル リリーストグルの運用改善 パラレルテスト の導入
29. ▪ 課題 • Feature環境はDBを開発環境と共有しており、スキーマやデータの更新が全体に 影響していた • 手動で開発環境のDBを複製していたが、設定や削除漏れなどが発生していた ◦ なにより手間がかかっていた、、、 ▪ 取り組み • 開発DBの複製を自動化し、Feature環境と同様にPull Request単位で専用のDBを 利用可能にした 29 2｜取り組み 〜 開発DB複製の自動化 〜
30. 30 2｜取り組み 〜 開発DB複製の自動化 〜 Pull Requestへのラベル付与をトリガーに開発環境のDBを複製する • 21時に自動停止、9時に自動起動することでコスト削減 • Pull Requestのマージとクローズタイミングで自動削除し消し忘れ防止
31. 31 2｜取り組み 開発 テスト リリース 運用 Feature環境の導入 開発DB複製の自動化 テストでの 本番データ利用 ゼロダウンタイム リリースの実現 DBマイグレーション のリハーサル リリーストグルの運用改善 パラレルテスト の導入
32. ▪ 課題 • 複雑な機能のテストデータの準備に時間がかかる ◦ 抜け漏れなども発生し、リリース後に不具合が発覚してしまう ◦ 本番データをそのままテストに利用するとデータ漏えいのリスクがある ▪ 取り組み • テストに本番データを安全に利用できるように次の仕組みを構築 ◦ データの自動マスキング ◦ 外部との通信を遮断 ※ マスキングと通信遮断の2段階の防止策を設けることでデータ漏洩のリスク低減 32 2｜取り組み - テストでの本番データ利用-
33. ▪ データの自動マスキング Pull Requestへのラベル付与をトリガーに本番DBを複製し、自動でマスキング実施 33 2｜取り組み - テストでの本番データ利用-
34. ▪ 外部との通信を遮断 Network Firewallを用いて外部通信を制限することで、意図しないデータ転送を抑制 • Feature環境と同様にPRに特定ラベルを付与することで自動で構築される 34 2｜取り組み - テストでの本番データ利用-
35. 35 2｜取り組み 〜 パラレルテストの導入〜 開発 テスト リリース 運用 Feature環境の導入 開発DB複製の自動化 テストでの 本番データ利用 ゼロダウンタイム リリースの実現 DBマイグレーション のリハーサル リリーストグルの運用改善 パラレルテスト の導入
36. ▪ 課題 • 開発者によるスクリプトテストとQAによる探索的テストをシリアルにおこなっ ていたことでリリースまでのサイクルタイム増加の一つの要因となっていた ▪ 取り組み • Feature環境を利用し、パラレルテスト(＝開発者によるスクリプトテストとQAに よる探索的テストの並列実施）をおこなうプロセスに変更 ◦ テストがパラレルになることでサイクルタイムを短縮できる ◦ Pull Requestの段階でQAからバグのフィードバックを得られる ※ パラレルテストは弊社の造語です 36 2｜取り組み 〜 パラレルテストの導入〜
37. 37 2｜取り組み 〜 パラレルテストの導入〜
38. 38 2｜取り組み ~ リリーストグルの運用改善 ~ 開発 テスト リリース 運用 Feature環境の導入 開発DB複製の自動化 テストでの 本番データ利用 ゼロダウンタイム リリースの実現 DBマイグレーション のリハーサル リリーストグルの運用改善 パラレルテスト の導入
39. ▪ リリーストグル フィーチャーフラグの一種。コードのデプロイと機能リリースをフラグのOFF/ONで 分離することでブランチワークの複雑化の回避とリードタイムの短縮を図る。 ▪ 課題 • 各環境（開発、ステージング、本番）のトグルの設定値を横断的に確認できない • 不要になったトグルの削除ができておらず、コードが複雑化してしまっている • ローカル環境への各環境のトグル状態の取り込みが大変、、、 ▪ 取り組み • 横断的にトグルの状態を確認できるダッシュボードの整備 • 不要になったトグルを通知する仕組みを構築 • 特定環境のトグル状態を取り込むスクリプトを作成 39 2｜取り組み ~ リリーストグルの運用改善 ~
40. ▪ 横断的にトグルの状態を確認できるダッシュボードの整備 40 2｜取り組み ~ リリーストグルの運用改善 ~
41. ▪ 横断的にトグルの状態を確認できるダッシュボードの整備 41 2｜取り組み ~ リリーストグルの運用改善 ~
42. ▪ 不要になったトグルを通知する仕組みを構築 一定期間更新のないトグルの数が一定数を超えた場合に、開発者にSlack通知すること で削除忘れを防止 42 2｜取り組み ~ リリーストグルの運用改善 ~
43. ▪ 特定環境のトグル状態を取り込むスクリプトを作成 43 2｜取り組み ~ リリーストグルの運用改善 ~
44. 44 2｜取り組み 開発 テスト リリース 運用 Feature環境の導入 開発DB複製の自動化 テストでの 本番データ利用 ゼロダウンタイム リリースの実現 DBマイグレーション のリハーサル リリーストグルの運用改善 パラレルテスト の導入
45. 毎日複数回リリースできる状態まで大きく改善 ！ 45 2｜取り組み - デプロイ頻度改善の効果 -
46. 10%程度まで低減することができ大きく改善！ 46 2｜取り組み - 変更障害率改善の効果 -
47. 目次 1｜抱えていた課題 2｜取り組み 3｜現在の課題と今後の取り組み 4｜まとめ 47
48. 48 3｜現在の課題と今後の取り組み ▪ 課題 1. リリースの相乗り待ちが発生してしまっている ◦ stagingブランチに変更を溜めてからリリースしているため、複数チームの 変更がリリース可能な状態になるのを待つ必要がある 2. 開発プロセスにおける開発者の負担が大きい ◦ 案件Doc作成、実装、テスト設計・実施、リリースなど多くの作業を担って いる
49. 49 3｜現在の課題と今後の取り組み ▪ 今後の取り組み 1. リリースの相乗り待ちが発生してしまっている →　トランクベース開発に移行し、直接maserブランチへマージ／リリースして いくことで相乗り待ちをなくしていく 2. 開発プロセスにおいて開発者の負担が大きい →　テスト設計、スクリプトテストの実施をQAが担うことで開発者の負担の低 減を図る
50. 目次 1｜抱えていた課題 2｜取り組み 3｜現在の課題と今後の取り組み 4｜まとめ 50
51. • 高頻度で安定したリリースを実現するまでの課題と取り組みを紹介 • リリースに至るまでのプロセス全体を見て、課題を解決していくことが大きな効 果につながった • そのためにも、SRE、開発、QAといったプロセスに関わる複数のチームが協業 して取り組むことが重要 51 4｜まとめ
52. ニーリー採用情報など
53. Thank you 53