マルチプロダクト運用におけるSREのあり方/SRE NEXT 2023-link-and-motivation

Slide 1

Slide 1 text

Slide 2

Slide 2 text

2 © Link and Motivation Group 2023/09/29 SRE NEXT 2023 岸本直樹（@naoki-lmi）株式会社リンクアンドモチベーション Developer Productivityユニット SREグループ ● 2019年新卒入社。2020年からSREとして活動。 ● モチベーションクラウドのECS移設から開発メトリクス向上Pjtで4keysの一つであるデプロイ頻度をMiddleからHighへ、生産性の高い組織へと牽引。 ● モチベーションクラウドシリーズ全体の生産性向上に従事 ● 新規プロダクト立ち上げ自己紹介

Slide 3

Slide 3 text

3 © Link and Motivation Group 2023/09/29 SRE NEXT 2023 篠原昂（@koh-sh）株式会社リンクアンドモチベーション Developer Productivityユニット SREグループ ● 2021年7月株式会社リンクアンドモチベーションに SREとして入社。 ● 新規プロダクトであるストレッチクラウドの立ち上げに従事。 ● 現在はプロダクトや開発組織拡大のためのインフラ改善を主に担当。自己紹介

Slide 4

Slide 4 text

4 © Link and Motivation Group 2023/09/29 SRE NEXT 2023 リンクアンドモチベーションについて 327億円（2022年12月時点）（2022年12月時点） 11社

Slide 5

Slide 5 text

5 © Link and Motivation Group 2023/09/29 SRE NEXT 2023 プロダクト紹介働きがいあふれる社会へ

Slide 6

Slide 6 text

6 © Link and Motivation Group 2023/09/29 SRE NEXT 2023 近い未来に向けた挑戦（with AI）リアルタイム分析 LIVE バイタルやチャット等に基づく即時分析予兆検知・予測・予防 FORECAST 未来の組織改善事前予防 AIアドバイザーデータとセオリーを元に支援 CONSULTANT

Slide 7

Slide 7 text

7 © Link and Motivation Group 2023/09/29 SRE NEXT 2023 Generative AIを内包した機能 2023年3月7日リリース 2023年4月7日リリース

Slide 8

Slide 8 text

導入企業様 ※2023年1月時点実績（https://www.motivation-cloud.com/）

Slide 9

Slide 9 text

Slide 10

Slide 10 text

Slide 11

Slide 11 text

11 © Link and Motivation Group 2023/09/29 SRE NEXT 2023 弊社開発組織の歴史 2018 2019 2022 2023 新規プロダクト開発 2020 SRE チームの誕生弊社の開発組織は誕生して５年目です！

Slide 12

Slide 12 text

12 © Link and Motivation Group 2023/09/29 SRE NEXT 2023 4つのプロダクトから成る、複数のチーム社員約80名＋パートナーさん約20名＋ SRE 4名

Slide 13

Slide 13 text

Slide 14

Slide 14 text

14 © Link and Motivation Group 2023/09/29 SRE NEXT 2023 課題その１

Slide 15

Slide 15 text

15 © Link and Motivation Group 2023/09/29 SRE NEXT 2023 【課題】運用工数が線形にスケールするプロダクトA プロダクトB プロダクトC 運用運用運用プロダクトA の運用してるよ Bの... Cの運用は特殊で大変だなぁ...

Slide 16

Slide 16 text

16 © Link and Motivation Group 2023/09/29 SRE NEXT 2023 【課題】運用工数が線形にスケールするプロダクトD 運用運用運用時間プロダクトA プロダクトB プロダクトC 運用運用運用プロダクトが増えれば運用も増えるのは当たり前さ... プロダクトE プロダクトF

Slide 17

Slide 17 text

17 © Link and Motivation Group 2023/09/29 SRE NEXT 2023 課題その２

Slide 18

Slide 18 text

18 © Link and Motivation Group 2023/09/29 SRE NEXT 2023 【課題】チーム・組織間の流動性を阻害するプロダクトA プロダクトB プロダクトC 運用運用運用誰が代わりに C の運用を見れるの？異動・退職プロダクトD 運用運用運用プロダクトE プロダクトF

Slide 19

Slide 19 text

19 © Link and Motivation Group 2023/09/29 SRE NEXT 2023 【課題】チーム・組織間の流動性を阻害するプロダクトA 開発・運用メニュー (CI・CD) アプリ開発者 A プロダクトB 開発・運用メニュー (CI・CD) アプリ開発者 B アプリ開発者 C アプリ開発者 B チーム間の異動普段の開発や本番のリリースが違って辛い〜💦 フィーチャーチーム化してても、人材流動の阻害原因になる。し辛い 💦

Slide 20

Slide 20 text

20 © Link and Motivation Group 2023/09/29 SRE NEXT 2023 課題その３

Slide 21

Slide 21 text

21 © Link and Motivation Group 2023/09/29 SRE NEXT 2023 【課題】新規プロダクトの立ち上げのボトルネックに... 新規プロダクト立ち上げのために０から設計するため、インフラの立ち上げにも時間がかかるアプリ開発がほぼ終わったのでテスト用の環境がほしいんですけど... インフラ担当 (SRE 等) 0からインフラ構築してるからちょっと遅れてしまいそうリリース日が決まってそれまでに本番環境を準備してほしくて... アプリ開発者

Slide 22

Slide 22 text

22 © Link and Motivation Group 2023/09/29 SRE NEXT 2023 課題を解決するには？

Slide 23

Slide 23 text

23 © Link and Motivation Group 2023/09/29 SRE NEXT 2023 解決方法カスタマイズではなく標準化された世界へ

Slide 24

Slide 24 text

Slide 25

Slide 25 text

25 © Link and Motivation Group 2023/09/29 SRE NEXT 2023 当時の構成 ▷保守工数の増加や流動性低下という課題が起きていた時のアーキテクチャプロダクトB ECS on Fargate プロダクトA プロダクトC ECS on EC2 EB プロダクトA用CI/CD プロダクトB用CI/CD プロダクトC用CI/CD プロダクトA用IaC プロダクトB用IaC 手動作成

Slide 26

Slide 26 text

26 © Link and Motivation Group 2023/09/29 SRE NEXT 2023 当時の構成 ▷保守工数の増加や流動性低下という課題が起きていた時のアーキテクチャプロダクトB ECS on Fargate プロダクトA プロダクトC ECS on EC2 EB プロダクトA用CI/CD プロダクトB用CI/CD プロダクトC用CI/CD プロダクトA用IaC プロダクトB用IaC 手動作成アーキテクチャが異なることで CI/CDやIaC、運用フローがプロダクトの数だけ増える

Slide 27

Slide 27 text

27 © Link and Motivation Group 2023/09/29 SRE NEXT 2023 プロダクト間で標準となるアーキテクチャの検討 ▷なるべくシンプルかつ、各プロダクトの要件に対応しやすい構成やサービスを検討プロダクトB ECS on Fargate 弊社のケースだとシンプル + 運用負荷の低さを鑑みてECS on Fargateを採用プロダクトC ECS on Fargate ECS on Fargate プロダクトA

Slide 28

Slide 28 text

28 © Link and Motivation Group 2023/09/29 SRE NEXT 2023 標準化された結果 ▷アーキテクチャが同じであれば、全プロダクトのCI/CDとIaCが共通化できるプロダクトB ECS on Fargate プロダクトA プロダクトC 全プロダクト共通CI/CD ECS on Fargate ECS on Fargate 共通IaC(Terraform)

Slide 29

Slide 29 text

29 © Link and Motivation Group 2023/09/29 SRE NEXT 2023 標準化された結果 ▷アーキテクチャが同じであれば、全プロダクトのCI/CDとIaCが共通化できるプロダクトB ECS on Fargate プロダクトA プロダクトC 全プロダクト共通CI/CD ECS on Fargate ECS on Fargate 共通IaC(Terraform) 標準化されたアーキテクチャへ刷新することで共通のCI/CDとIaCで運用できる状態を目指す

Slide 30

Slide 30 text

30 © Link and Motivation Group 2023/09/29 SRE NEXT 2023 標準化を進めるうえでの課題と解決策

Slide 31

Slide 31 text

31 © Link and Motivation Group 2023/09/29 SRE NEXT 2023 当時の課題感開発者の環境準備の依頼やミドルウェアアップデート作業の時間で改善活動する時間がない・・・定常業務や差し込みタスクが多くあり、改善活動が思うように進まなかった

Slide 32

Slide 32 text

32 © Link and Motivation Group 2023/09/29 SRE NEXT 2023 現状の活動時間を可視化 ▷活動時間の60%を定常業務と緊急対応に使っているが判明 LeanとDevOpsの時間の分析 SREチームの時間の使い方差し込み作業が多く、スイッチングコストが高い = ローパフォーマー

Slide 33

Slide 33 text

33 © Link and Motivation Group 2023/09/29 SRE NEXT 2023 現状の活動時間を可視化 ▷活動時間の60%を定常業務と緊急対応に使っているが判明 LeanとDevOpsの時間の分析 SREチームの時間の使い方新たな作業割合を50%以上を目標にし、並行作業(スイッチングコスト)を減らす差し込み作業が多く、スイッチングコストが高い = ローパフォーマー

Slide 34

Slide 34 text

34 © Link and Motivation Group 2023/09/29 SRE NEXT 2023 ①Toilの撲滅 ▷(当たり前ですが) まず、Toilを洗い出して撲滅するミドルウェアアップデート自動化 Snapshot RDS スナップショット取得自動化例えば・・・

Slide 35

Slide 35 text

35 © Link and Motivation Group 2023/09/29 SRE NEXT 2023 ②開発者への作業の委譲 ▷SREが実施せずとも、開発者が自律的に実行可能な業務を一部自動化して渡す SREタスクをアプリ開発者と分担することで、SREの工数を確保 ❏ 環境の構築・更新・削除 ❏ 性能テストのための環境構築 ❏ 環境変数の追加 ❏ etc ❏ データベースの作り直し ❏ 一部サービスのアカウント発行・削除アプリ開発者 Before SREに依頼しないと開発できない SREに依頼しなくても開発ができる After アプリ開発者

Slide 36

Slide 36 text

36 © Link and Motivation Group 2023/09/29 SRE NEXT 2023 結果 LeanとDevOpsの時間の分析 SREチームの時間の使い方 ▷３ヶ月という短い期間で新たな作業の時間を20％増やすことに成功

Slide 37

Slide 37 text

37 © Link and Motivation Group 2023/09/29 SRE NEXT 2023 結果 LeanとDevOpsの時間の分析 SREチームの時間の使い方 ▷３ヶ月という短い期間で新たな作業の時間を20％増やすことに成功スイッチングコストを減らし、新たな作業に集中できる時間を確保することが重要

Slide 38

Slide 38 text

Slide 39

Slide 39 text

39 © Link and Motivation Group 2023/09/29 SRE NEXT 2023 標準化を進める上で大事なこと責任範囲の明確化

Slide 40

Slide 40 text

40 © Link and Motivation Group 2023/09/29 SRE NEXT 2023 アプリケーション層 Dockerfile Dockerfile プロダクト差分を吸収する層 Dockerfile 変更管理変更管理アプリ開発者 A プロダクトA 共通化層 terraform-modules プロダクトB プロダクトC terraform -stacks-C terraform -stacks-B terraform -stacks-A 運用者 (SRE, etc…) mod参照 mod参照 mod参照責任範囲の明確化

Slide 41

Slide 41 text

41 © Link and Motivation Group 2023/09/29 SRE NEXT 2023 プロダクト差分を吸収する層変更管理共通化層 terraform-modules terraform -stacks-C terraform -stacks-B terraform -stacks-A 運用者 (SRE, etc…) mod参照 mod参照 mod参照責任範囲の明確化アプリケーション層 Dockerfile Dockerfile Dockerfile アプリ開発者 A プロダクトA プロダクトB プロダクトC Dockerfileよりも上、アプリケーションのランタイムは各プロダクトの開発チームの領域変更管理

Slide 42

Slide 42 text

42 © Link and Motivation Group 2023/09/29 SRE NEXT 2023 アプリケーション層 Dockerfile Dockerfile プロダクト差分を吸収する層 Dockerfile 変更管理アプリ開発者 A プロダクトA プロダクトB プロダクトC terraform -stacks-C terraform -stacks-B terraform -stacks-A mod参照 mod参照 mod参照責任範囲の明確化変更管理共通化層 terraform-modules 運用者 (SRE, etc…) プロダクト間で標準となるインフラリソースはSREの領域

Slide 43

Slide 43 text

43 © Link and Motivation Group 2023/09/29 SRE NEXT 2023 アプリケーション層 Dockerfile Dockerfile Dockerfile 変更管理変更管理プロダクトA 共通化層 terraform-modules プロダクトB プロダクトC mod参照 mod参照 mod参照責任範囲の明確化プロダクト差分を吸収する層アプリ開発者 A terraform -stacks-C terraform -stacks-B terraform -stacks-A 運用者 (SRE, etc…) プロダクト差分を吸収する層はチーム状況に応じて変更。 ※理想はアプリ側で責任を持つ形

Slide 44

Slide 44 text

Slide 45

Slide 45 text

45 © Link and Motivation Group 2023/09/29 SRE NEXT 2023 プロダクトB プロダクトC プロダクトA プロダクト差分を吸収する層共通化層 terraform-modules terraform -stacks-C terraform -stacks-B terraform -stacks-A mod参照 mod参照 mod参照 terraform apply AWS リソース AWS リソース AWS リソース反映反映反映 module の呼び出しとプロダクト依存の定義全プロダクトで共通の基盤コード抽象化と制約

Slide 46

Slide 46 text

46 © Link and Motivation Group 2023/09/29 SRE NEXT 2023 プロダクトB プロダクトC プロダクトA 共通化層 terraform-modules terraform apply AWS リソース AWS リソース AWS リソース反映反映反映 module の呼び出しとプロダクト依存の定義全プロダクトで共通の基盤コード抽象化と制約プロダクト差分を吸収する層 terraform -stacks-C terraform -stacks-B terraform -stacks-A mod参照 mod参照 mod参照各プロダクトはmoduleを呼び出すだけでインフラ構築ができる

Slide 47

Slide 47 text

47 © Link and Motivation Group 2023/09/29 SRE NEXT 2023 抽象化と制約プロダクトごとに可変になる要素をmoduleのパラメータとするプロダクト差分を吸収する層共通化層 terraform-modules terraform -stacks-C terraform -stacks-B terraform -stacks-A mod参照 mod参照パラメータ ● ECS task定義 ● 最大 CPU (cgroup) ● Auto scale 台数 ● etc…

Slide 48

Slide 48 text

48 © Link and Motivation Group 2023/09/29 SRE NEXT 2023 抽象化と制約プロダクトごとに可変になる要素をmoduleのパラメータとするプロダクト差分を吸収する層共通化層 terraform-modules terraform -stacks-C terraform -stacks-B terraform -stacks-A mod参照 mod参照パラメータ ● ECS task定義 ● 最大 CPU (cgroup) ● Auto scale 台数 ● etc… 変数化されていない箇所のカスタマイズは基本的に許容しない

Slide 49

Slide 49 text

49 © Link and Motivation Group 2023/09/29 SRE NEXT 2023 Module 参照 terraform-stacks-A terraform- modules terraform-stacks-C terraform-stacks-B それぞれ別々の Github リポジトリに。 Terraform リポジトリ・ディレクトリ構造

Slide 50

Slide 50 text

50 © Link and Motivation Group 2023/09/29 SRE NEXT 2023 Terraform リポジトリ・ディレクトリ構造 terraform-stacks-XXX stacks XXX.tfvars stages development.tfvars production.tfvars stacks.tf variables.tf terraform-modules modules variables.tf web variables.tf worker MODULES STACKS Github URL Github URL

Slide 51

Slide 51 text

51 © Link and Motivation Group 2023/09/29 SRE NEXT 2023 Terraform リポジトリ・ディレクトリ構造 terraform-stacks-XXX stacks.tf variables.tf terraform-modules modules variables.tf web variables.tf worker MODULES STACKS Github URL Github URL stacks XXX.tfvars stages development.tfvars production.tfvars 【環境ごとのtfvarsを定義】 - stageごとの変数を定義 - development - production - stackごとの変数を定義 - 性能環境 - 自動テスト用 - 〇〇チーム用

Slide 52

Slide 52 text

52 © Link and Motivation Group 2023/09/29 SRE NEXT 2023 Terraform リポジトリ・ディレクトリ構造 terraform-stacks-XXX variables.tf terraform-modules modules variables.tf web variables.tf worker MODULES STACKS Github URL stacks XXX.tfvars stages development.tfvars production.tfvars Github URL stacks.tf 【モジュール呼び出しを定義】プロダクト固有、環境ごとの変数を定義した上で共通モジュールを呼び出す。 ※ここでリソース定義はしない

Slide 53

Slide 53 text

53 © Link and Motivation Group 2023/09/29 SRE NEXT 2023 Terraform リポジトリ・ディレクトリ構造 terraform-stacks-XXX variables.tf terraform-modules modules MODULES STACKS Github URL stacks XXX.tfvars stages development.tfvars production.tfvars Github URL stacks.tf 【実際のAWSリソース定義】 stacksから渡されたパラメータを元に、実際の AWSリソースを構築 - ECS Cluster, Service - ELB - SQS - など variables.tf web variables.tf worker

Slide 54

Slide 54 text

54 © Link and Motivation Group 2023/09/29 SRE NEXT 2023 Terraform リポジトリ・ディレクトリ構造 terraform-stacks-XXX variables.tf terraform-modules modules MODULES STACKS Github URL stacks XXX.tfvars stages development.tfvars production.tfvars Github URL stacks.tf 【実際のAWSリソース定義】 stacksから渡されたパラメータを元に、実際の AWSリソースを構築 - ECS Cluster, Service - ELB - SQS - など variables.tf web variables.tf worker リポジトリ分割とモジュール化によって責任と制約を表す

Slide 55

Slide 55 text

Slide 56

Slide 56 text

56 © Link and Motivation Group 2023/09/29 SRE NEXT 2023 【効果①】運用工数が最小化プロダクトA プロダクトB プロダクトC 運用運用運用プロダクトは増えても標準化された運用だから簡単だ ▷担当するプロダクトが増えても、運用コストがスケールしない SRE SRE SRE いなくていいいなくていい

Slide 57

Slide 57 text

57 © Link and Motivation Group 2023/09/29 SRE NEXT 2023 【効果②】チーム・組織間の流動性がスムーズプロダクトA 開発・運用メニュー (CI・CD) アプリ開発者 A プロダクトB 開発・運用メニュー (CI・CD) アプリ開発者 B アプリ開発者 C アプリ開発者 B チーム間の異動どこでも同じ開発者体験！ ▷開発・リリース運用等、プロセスが同じだと人材流動しやすい。 💡

Slide 58

Slide 58 text

58 © Link and Motivation Group 2023/09/29 SRE NEXT 2023 【効果③】新規プロダクトの立ち上げの初速が上がる標準化されたIaCを使えば、インフラの構築の工数が大幅に削減ローカル開発がほぼ終わったのでテスト用の環境がほしいんですけど... インフラ担当 (SRE 等) 標準化されたIaCがあるからサクッと作っちゃうね！！ CI/CDはこれ使って！！リリース日が決まってそれまでに本番環境を準備してほしくて... アプリ開発者

Slide 59

Slide 59 text

Slide 60

Slide 60 text

60 © Link and Motivation Group 2023/09/29 SRE NEXT 2023 ● マルチプロダクト運用ではカスタマイズによるサイロ化が課題 ● 改善活動に時間を使うには実態の可視化と地道な改善が重要 ● 標準化を進める上で責任と制約の明確化がポイントまとめ

Slide 61

Slide 61 text

61 © Link and Motivation Group 2023/09/29 SRE NEXT 2023 お知らせ ● エンジニアリングマネージャー ● プロダクトマネージャー ● テックリード ● サーバーサイドエンジニア ● フロントエンドエンジニア ● SRE ● データエンジニア ● CRM ● UXデザイナー週１でテックブログ更新しています！まずはカジュアルにお話しましょう！ご連絡お待ちしております！全職種、積極採用中です！