プロダクトの成長とSREと

プロダクトの成長とSREと
Copyright © 3-shake, Inc. All Rights Reserved.

View Slide

自己紹介
自治体やデータベースマーケティング会社でのインフラ設計 /構築
/運用を主に経験し、2018 年 10 月に 3-Shake に Join。
3-Shake Join 後は Google Cloud / AWS / kubernetes /
ServiceMesh など様々な技術的アプローチを駆使し、
大手からベンチャー等規模を問わず様々な組織に対して
SREのコンサルティングや実践を行っている。
趣味：ボクシング観戦
※ 日曜日の昼間は一人で WOWOW 見ながら一人で熱狂してます ...
手塚卓也 Takuya Tezuka

View Slide

社名
設立日
代表取締役
所在地
人員（2022/1）
資本金
事業内容
株式会社スリーシェイク
2015年1月15日
吉田拓真
本社：東京都新宿区大京町22-1 グランファースト新宿御苑3-4F
110名（正社員：71名、業務委託：21名、アルバイト：18名）
1億円
SREコンサルティング支援事業「Sreake」の運営
セキュリティ診断サービス「Securify」の運営
データ連携プラットフォーム事業「Reckoner」の運営
フリーランスエンジニア紹介プラットフォーム「Relance」の運営
会社概要

View Slide

事業全体像
07
　　 Engineering as a Service
すべてのエンジニア不足を解消する
VALUE
Engineering
as a Service
(EaaS)
Application
Development
IaaS
DevOps / SRE
UIUX / Management
HR（Engineer Hiring）
Data Engineering
Security

View Slide

技術戦略から設計、構築、運用まで
ワンストップ支援する技術支援サービス
Multi Cloud や Cloud Native な先進的技術及び大規模なサービス運用に強みを持つ
エンジニアによる技術支援
ベンダー的な役割ではなく「お客様のチームメンバー」という立ち位置で最新技術の提案から
運用支援までをトータル支援
Sreake SRE Cloud Native 技術支援
運用支援
アセスメント
（パフォーマンス /セキュリティ）
構築/実装
支援
システム設計
技術戦略
コンサルティング

View Slide

SREの組成/
SRE文化の
定着化の為の支援
Sreake SRE 組織構築支援
お客様の組織に
適合した
SREの導入を支援
Enterpriseを中心に様々な業種/業界で
SREを実践してきたナレッジを活かしたSREチームの導入および定着化を支援

View Slide

本日お話する内容
SRE における概念について
Startup やこれから SRE を始める方へ向けて、
SRE 実践にまつわるポイントについて(目線がやや高め)のお話
話すこと
話さないこと
詳細なシステムアーキテクチャなどの実装面のお話

View Slide

SRE の原則と実践の現実
01

View Slide

https://sre.google/sre-book/introduction/
❖ リスクの受容
❖ SLO の定義
❖ 分散システムのモニタリング
❖ Toil の削減
❖ 自動化の推進
❖ 適切なリリースエンジニアリング
❖ シンプルさを保つ
SRE の原則とは
SRE の原則
100% の可用性を目指さず、
SLO を元に適切なリスクマネジメントと
業務ハンドリングを行う。
そのためにリスクの評価、管理、
およびエラーバジェットの使用などを
実施していく。

View Slide

❖ SLO の定義
❖ Toil の削減
SRE の原則とは
SRE の原則
長期的なトレンドの把握や
適切なアラートによる
問題解決の修復等を行うために、
各種のモニタリングやアラート設定を行ってい
く。

View Slide

❖ SLO の定義
❖ Toil の削減
SRE の原則とは
SRE の原則
サービスの成長に比例して拡大する
永続的な価値を提供しない、
ありふれた反復的な運用作業を
自動化して削減していく。

View Slide

❖ SLO の定義
❖ Toil の削減
SRE の原則とは
SRE の原則
多くの障害は人の手が加わることに
よって発生する。
その為、適切な構成管理や
リリースエンジニアリングの仕組みを
構築を行う。

View Slide

❖ SLO の定義
❖ Toil の削減
SRE の原則とは
SRE の原則
「ソフトウェアの簡素化は信頼性の前提であ
る」
システムの俊敏性と安定性のバランスを保つ
ためにシンプルさを保とう

View Slide

原則に基づいて実際に実践しようとすると
...
● Monitoring 実装
○ Metrics
○ Logs
○ Traces
○ Profiles
○ Dumps
● SLI / SLO の定義
○ CUJ設計
○ SLO 計測
○ Error Budget 運用
● 運用体制整備
○ インシデント管理
○ インシデント対応
○ アラート制御の実装
○ Postmortem の実施
● IaC (Infrastructure as Code) 化
○ 構成管理の品質チェック
○ GitOps
● CI/CD 導入
○ デプロイの自動化
○ コード品質・脆弱性の検査
○ DevSecOps
● パフォーマンス分析
○ 分散トレーシング
○ 負荷試験
○ カオスシナリオ試験
● Toil 計測のための仕組み構築
○ Toil 撲滅のための自動化の実装

View Slide

原則に基づいて実際に実践しようとすると
...
○ Metrics
○ Logs
○ Traces
○ Profiles
○ Dumps
○ CUJ設計
○ SLO 計測
○ GitOps
● CI/CD 導入
○ DevSecOps
○ 負荷試験
やることだらけ....

View Slide

よくよく考えると....
3つのそもそも
● そもそも、全世界シェア75%以上の検索エンジンを運用するわけでも、国内月間アクティブユーザー4000万人超えの動画配信
サービスを運用するわけでも、20億人以上が利用しているWorkspaceツールのSaasを運用するわけでもない。
● そもそも、大抵の組織は Google 規模のエンジニア組織なんて作れっこない事を理解しないといけない。というかその必要が無
いのでは？
● そもそも、SRE というのが Google 様が何年もの運用の結果見出したメソッドだということを忘れていないかい？
We are not Googler !!!
~ 私たちは Googler ではありません ~
自分の身体に合うサイズの服選びが重要なのでは？
※ 例えると、中学校入学前の制服を選ぶママの感覚が大事...?

View Slide

SRE 実践の中で何を実現したいのか？
1. 信頼性の測定を元にしたロジックを使って、機能開発と保守の間でそれぞれ
の改善が適切にできるようになっていること
2. データドリブンで適切な意思決定やエンジニアリングができるような組織醸成
及び仕組みづくりを実践すること
時間をかけながらでもこういった事を実現していきたい...

View Slide

Error budgets are the tool SRE uses to balance service reliability with the pace of innovation. Changes are a
major source of instability, representing roughly 70% of our outages, and development work for features
competes with development work for stability. The error budget forms a control mechanism for diverting
attention to stability as needed.
An error budget is 1 minus the SLO of the service. A 99.9% SLO service has a 0.1% error budget. If our service
receives 1,000,000 requests in four weeks, a 99.9% availability SLO gives us a budget of 1,000 errors over that
period.
参照: https://sre.google/workbook/error-budget-policy
エラー予算とは、サービスの信頼性と技術革新のスピードのバランスをとるためにSREが使用するツールです。
変更は不安定さの主な原因であり、障害の約70%を占めています。機能のための開発作業は、安定性のための開発作業と
競合しています。エラーバジェットは、必要に応じて安定性に注意を向けるための制御メカニズムを形成しています。
エラーバジェットは、1 からサービスの SLO を引いたものです。
99.9%SLOのサービスでは、エラーバジェットは0.1%です。私たちのサービスが4週間で1,000,000のリクエストを受け取る場合、
99.9%の可用性SLOは、その期間に1,000のエラーのバジェットを提供することになります。
「エラー予算」を設けて信頼性を制御する

View Slide

信頼性を測定するために重要となる
3つの指標
注力ファクターを「錘」として捉えた時に....
機能開発
信頼性
SLO

View Slide

3つの指標
SLO 達成 = Error 予算が消化されていないケース
※ 例えば、SLO を 99.9% としたとき、月間で障害が0件で稼働率100%を達成
機能開発
信頼性
SLO
達成
Error Budget が消化されていないので、機能開発をどんどん推進していく

View Slide

3つの指標
SLO 未達 = Error 予算が消化されてしまった場合
※ 例えば、SLO を 99.9% としたとき、月間で1時間のダウンタイムが発生...
機能開発
信頼性
SLO
未達
Error Budget を消化。SLO 未達の為、機能開発よりも信頼性を高める活動に注力しましょう

View Slide

3つの指標
SLO 未達 = Error 予算が消化されてしまった場合
※ 例えば、SLO を 99.9% としたとき、月間で1時間のダウンタイムが発生...
機能開発
信頼性
SLO
未達
Error Budget を消化。SLO 未達の為、機能開発よりも信頼性を高める活動に注力しましょう
SLO を元にした運用をすることで
「開発」と「運用改善」にまつわる業務の優先順位の付け方の
ロジックを組み込む事が出来る

View Slide

プロダクトの成長と SRE と
02

View Slide

スリーシェイクの次の根幹となるビジネスを生み出す事業部に
05
すべてのエンジニア不足を解消するためのプロダクトをパラレルで開発
&提供
一気に SRE における全ての実践をすることは不可能。プロダクトの性質やフェーズに応じてやるべきこと
は動的に変化していくはず。
課題・プロダクト検証マーケット検証グロース
PSF
Problem/Solution Fit
PMF
Product Market Fit
GTM
Go To Market
CPF
Customer Problem Fit
IV
Idea Verification
顧客課題検証
New Products

View Slide

Securify（セキュリファイ）とは
25
本格的な脆弱性診断をいつでも手軽に
Securify（セキュリファイ）は自社のプロダクトに対し
て、手軽に、何度でも脆弱性診断の実施を可能にし、
セキュリティレベルを可視化・DevSecOpsへの取り組
みをサポートします。

View Slide

今、実践できているところはせいぜいこんなところ
...
○ Metrics
○ Logs
○ Traces
○ Profiles
○ Dumps
○ CUJ設計
○ SLO 計測
○ GitOps
● CI/CD 導入
○ DevSecOps
○ 負荷試験

View Slide

Securify の具体的な実装
● アーキテクチャ面
○ Firebase を軸とした Serverless 構成で開
発
○ 余分なサーバーを持たずにスピード感の
ある開発と極力運用負荷が減るように設
計
○ 監視については最低限の外形監視やメト
リクス監視は実装する一方で、
SLIの追求
等は後回しに。
○ 一方で Frontend はフロントエンドの監視
ツールを利用してユーザー行動を Tracing
出来るように実装。ユーザーがどういうア
クションで止まっているかを把握できるよう
に。

View Slide

プロダクトのステージと SRE
今、 Securify に対して何が求められているのか？
● 多種多様な種類の脆弱性診断が出来るプロダクトになっていること
● よりストレスがなく、手軽に、簡単に脆弱性診断が出来る機能が充実
していること
~ デリバリー優先の技術選定と運用が今求められている ~
❖ 最低限の信頼性を担保しつつも今の基本戦略は「信頼性 < 機能開発」
❖ 信頼性が高いからと言ってプロダクトが売れる訳ではないが、信頼性がないとプロダクトは
グロースしない(と思っている)ので、成長に合わせてアーキテクチャの切り替えやチーム編
成を組み替えていく必要がある。

View Slide

プロダクトの成長のための SRE 実践の中で大事にしていること
❖ 意図した「足りない」と「技術負債作り上げる」こと
➢ 「全部」を推進するには時間もコストもかかる。何が求められるか整理して濃淡つけ
て対応していこう。
➢ スケールしない構成もオーバーな技術選定もプロダクトの成長の足枷になる。何を捨
てて、何を実現したいかを見つめて技術選定を行う。
❖ 責任境界とコミュニケーション設計を計算して構築
すること
➢ 意識しないでコミュニケーション設計をするとエンジニアリングが上手くいくかは運任
せになってしまう。
➢ 開発と保守の区切り方はほとんどのケースで相応しくはない？

View Slide

現在のプロダクトチームの全体体制
❖ 専任の SRE チームは作らずにチーム内で
SRE Role をもたせて SRE を推進
❖ Reckoner チームはサービスの性質上信頼
性の担保が必要となる為、チーム内でSREの
リソースを十分に確保する
❖ Securify は現状専任のSREリソースを要さな
い為、バックエンドチームでカバー
PDM
Reckoner
PDM
Securify
データ基盤
チーム
Frontチーム
APIチーム SRE
Scannerチーム
Growthチーム
Designチーム
SRE

View Slide

今後のプロダクトチームの全体体制
Sreake SRE
SRE
PDM
Reckoner
PDM
Securify
データ基盤
チーム
Frontチーム
APIチーム
Scannerチーム
Growthチーム
Designチーム
❖ 基本的にはチーム内で SRE Role をもたせ
て SRE を推進
❖ Sreake SRE からのKnowledge提供や緊
急時のフォロー等の支援を受けながらリ
ソース不足を補う
各種Knowledge提供や
緊急時のフォローを推進
SRE SRE

View Slide

責任境界及びコミュニケーション設計を計算して構築すること
❖ 目的は SRE の原則に基づいた実践が出来ていること
➢ 本当に SRE を組織として持たせる必要があるのか？
➢ 中央集権的に SRE チームを作る必要がないケースも往々にしてあるのでは？
❖ チーム分割と役割の明確化のメリットとデメリットを考える必要がある
➢ それしかやらないとなった時のメリットとデメリットを理解したデザインが重要
❖ 優秀な人材は簡単に集まらない事を理解して設計する必要がある
➢ 市況的にもエンジニアの採用は簡単ではない

View Slide

まとめ
04

View Slide

まとめ
❖ 基本的に SRE はやることしかない。 SRE の原則をもう一度見返して今求められているエ
ンジニアリングを判断して SRE の実践を推進していこう
❖ 信頼性が高いからと言ってプロダクトが売れる訳ではない。一方で信頼性がないとプロダ
クトはグロースしない(はず)。
❖ 今の組織やプロダクトのフェーズを常に見つめ直しながら、長い目で SRE を実践していこ
う。

View Slide

Thank you
23

View Slide

本格的な脆弱性診断を
いつでも手軽に
Securify（セキュリファイ）は自社のプロダクトに対して、
何度でも脆弱性診断の実施を可能にし、
セキュリティレベルを可視化・
DevSecOpsへの取り組みを
サポートします。
お問い合わせはこちらから ▶
サービス詳細や料金についてのご質問・ご相談など
お気軽にお問い合わせください
期間限定で無償提供中！

View Slide

8/4(木)19:00-20:15 ONLINE
自
動
化
ツ
｜
ル
今
回
の
テ
｜
マ
は

View Slide

プロダクトの成長とSREと

プロダクトの成長とSREと

TakuyaTezuka

More Decks by TakuyaTezuka

Other Decks in Programming

Featured

Transcript