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

View Slide

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

View Slide

4
リンクアンドモチベーションについて
327億円（2022年12月時点）
（2022年12月時点）
11社

View Slide

5
プロダクト紹介
働きがいあふれる社会へ

View Slide

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

View Slide

7
Generative AIを内包した機能
2023年3月7日リリース 2023年4月7日リリース

View Slide

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

View Slide

© Link and Motivation Group
9
2023/09/29 SRE NEXT 2023
アジェンダ
▷マルチプロダクトの運用の現状
▷マルチプロダクトにおける課題
▷標準化された世界とは？
▷標準化を進める上で大事なこと
▷標準化の効果
▷まとめ

View Slide

10
2023/09/29 SRE NEXT 2023
アジェンダ
▷まとめ

View Slide

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

View Slide

12
4つのプロダクトから成る、複数のチーム
社員約80名＋パートナーさん約20名＋ SRE 4名

View Slide

13
2023/09/29 SRE NEXT 2023
アジェンダ
▷まとめ

View Slide

14
課題その１

View Slide

15
【課題】運用工数が線形にスケールする
プロダクトA プロダクトB プロダクトC
運用
運用
運用
プロダクトA
の運用してるよ
Bの...
Cの運用は特殊で
大変だなぁ...

View Slide

16
【課題】運用工数が線形にスケールする
プロダクトD
運用
運用
運用
時間
運用
運用
運用
プロダクトが増えれば
運用も増えるのは
当たり前さ...
プロダクトE プロダクトF

View Slide

17
課題その２

View Slide

18
【課題】チーム・組織間の流動性を阻害する
運用
運用
運用
誰が代わりに C の
運用を見れるの？
異動・退職
プロダクトD
運用
運用
運用
プロダクトE プロダクトF

View Slide

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

View Slide

20
課題その３

View Slide

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

View Slide

22
課題を解決するには？

View Slide

23
解決方法
カスタマイズではなく
標準化された世界へ

View Slide

24
2023/09/29 SRE NEXT 2023
アジェンダ
▷まとめ

View Slide

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

View Slide

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

View Slide

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

View Slide

28
標準化された結果
▷アーキテクチャが同じであれば、全プロダクトのCI/CDとIaCが共通化できる
プロダクトB
ECS on
Fargate
全プロダクト共通CI/CD
ECS on
Fargate
ECS on
Fargate
共通IaC(Terraform)

View Slide

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

View Slide

30
標準化を進めるうえでの
課題と解決策

View Slide

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

View Slide

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

View Slide

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

View Slide

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

View Slide

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

View Slide

36
結果
▷３ヶ月という短い期間で新たな作業の時間を20％増やすことに成功

View Slide

37
結果
▷３ヶ月という短い期間で新たな作業の時間を20％増やすことに成功
スイッチングコストを減らし、
新たな作業に集中できる時間を確保することが重要

View Slide

38
2023/09/29 SRE NEXT 2023
アジェンダ
▷まとめ

View Slide

39
標準化を進める上で大事なこと
責任範囲の明確化

View Slide

40
アプリケーション層
Dockerfile
Dockerfile
プロダクト差分を吸収する層
Dockerfile
変更管理
変更管理
アプリ
開発者 A
プロダクトA
共通化層
terraform-modules
プロダクトB プロダクトC
terraform
-stacks-C
terraform
-stacks-B
terraform
-stacks-A
運用者
(SRE, etc…)
mod参照
mod参照
mod参照

View Slide

41
変更管理
共通化層
terraform-modules
terraform
-stacks-C
terraform
-stacks-B
terraform
-stacks-A
運用者
(SRE, etc…)
mod参照
mod参照
mod参照
Dockerfile
Dockerfile
Dockerfile
アプリ
開発者 A
Dockerfileよりも上、アプリケーションのランタイム
は各プロダクトの開発チームの領域
変更管理

View Slide

42
Dockerfile
Dockerfile
Dockerfile
変更管理
アプリ
開発者 A
terraform
-stacks-C
terraform
-stacks-B
terraform
-stacks-A
mod参照
mod参照
mod参照
変更管理
共通化層
terraform-modules
運用者
(SRE, etc…)
プロダクト間で標準となるインフラリソースはSREの領域

View Slide

43
Dockerfile
Dockerfile
Dockerfile
変更管理
変更管理
プロダクトA
共通化層
terraform-modules
mod参照
mod参照
mod参照
アプリ
開発者 A
terraform
-stacks-C
terraform
-stacks-B
terraform
-stacks-A
運用者
(SRE, etc…)
プロダクト差分を吸収する層はチーム状況に応じて変更。
※理想はアプリ側で責任を持つ形

View Slide

44
標準化を進める上で大事なこと
抽象化と制約

View Slide

45
プロダクトA
共通化層
terraform-modules
terraform
-stacks-C
terraform
-stacks-B
terraform
-stacks-A
mod参照
mod参照
mod参照
terraform apply
AWS リソース
AWS リソース AWS リソース
反映
反映
反映
module の呼び出しと
プロダクト依存の定義
全プロダクトで
共通の基盤コード
抽象化と制約

View Slide

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

View Slide

47
抽象化と制約
プロダクトごとに可変になる要素をmoduleのパラメータとする
共通化層
terraform-modules
terraform
-stacks-C
terraform
-stacks-B
terraform
-stacks-A
mod参照
mod参照
パラメータ
● ECS task定義
● 最大 CPU (cgroup)
● Auto scale 台数
● etc…

View Slide

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

View Slide

49
Module 参照
terraform-stacks-A
terraform-
modules
terraform-stacks-C
terraform-stacks-B
それぞれ別々の Github リポジトリに。
Terraform リポジトリ・ディレクトリ構造

View Slide

50
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

View Slide

51
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ごとの変数を定義
- 性能環境
- 自動テスト用
- 〇〇チーム用

View Slide

52
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
【モジュール呼び出しを定義】
プロダクト固有、環境ごとの変数を定義した上で
共通モジュールを呼び出す。
※ここでリソース定義はしない

View Slide

53
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

View Slide

54
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
リポジトリ分割とモジュール化によって責任と制約を表す

View Slide

55
2023/09/29 SRE NEXT 2023
アジェンダ
▷まとめ

View Slide

56
【効果①】運用工数が最小化
運用
運用
運用
プロダクトは増えても
標準化された運用だから
簡単だ
▷担当するプロダクトが増えても、運用コストがスケールしない
SRE SRE SRE
いなくていいいなくていい

View Slide

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

View Slide

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

View Slide

59
2023/09/29 SRE NEXT 2023
アジェンダ
▷まとめ

View Slide

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

View Slide

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

View Slide

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

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

リンクアンドモチベーション

More Decks by リンクアンドモチベーション

Other Decks in Technology

Featured

Transcript