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

© Link and Motivation Group 2023/09/29 SRE NEXT 2023 マルチプロダクト運用における
SREのあり方リンクアンドモチベーション Developer Productivityユニット SREグループ岸本直樹・篠原昂

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

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

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

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

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

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

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

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

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

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

課題その１

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

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

課題その２

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

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

課題その３

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

課題を解決するには？

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

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

当時の構成 ▷保守工数の増加や流動性低下という課題が起きていた時のアーキテクチャプロダクト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、運用フローがプロダクトの数だけ増える

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

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

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

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

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

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

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

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

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

結果 LeanとDevOpsの時間の分析 SREチームの時間の使い方 ▷３ヶ月という短い期間で新たな作業の時間を20％増やすことに成功

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Other Decks in Technology

Featured

Transcript