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

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

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

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

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

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

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

SRE の原則と実践の現実 01 Copyright © 3-shake, Inc. All Rights Reserved.

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

Copyright © 3-shake, Inc. All Rights Reserved. https://sre.google/sre-book/introduction/ ❖ リスクの受容 ❖ SLO の定義 ❖ 分散システムのモニタリング ❖ Toil の削減 ❖ 自動化の推進 ❖ 適切なリリースエンジニアリング ❖ シンプルさを保つ SRE の原則とは SRE の原則 長期的なトレンドの把握や 適切なアラートによる 問題解決の修復等を行うために、 各種のモニタリングやアラート設定を行ってい く。

Copyright © 3-shake, Inc. All Rights Reserved. ❖ リスクの受容 ❖ SLO の定義 ❖ 分散システムのモニタリング ❖ Toil の削減 ❖ 自動化の推進 ❖ 適切なリリースエンジニアリング ❖ シンプルさを保つ SRE の原則とは https://sre.google/sre-book/introduction/ SRE の原則 サービスの成長に比例して拡大する 永続的な価値を提供しない、 ありふれた反復的な運用作業を 自動化して削減していく。

Copyright © 3-shake, Inc. All Rights Reserved. https://sre.google/sre-book/introduction/ ❖ リスクの受容 ❖ SLO の定義 ❖ 分散システムのモニタリング ❖ Toil の削減 ❖ 自動化の推進 ❖ 適切なリリースエンジニアリング ❖ シンプルさを保つ SRE の原則とは SRE の原則 多くの障害は人の手が加わることに よって発生する。 その為、適切な構成管理や リリースエンジニアリングの仕組みを 構築を行う。

Copyright © 3-shake, Inc. All Rights Reserved. https://sre.google/sre-book/introduction/ ❖ リスクの受容 ❖ SLO の定義 ❖ 分散システムのモニタリング ❖ Toil の削減 ❖ 自動化の推進 ❖ 適切なリリースエンジニアリング ❖ シンプルさを保つ SRE の原則とは SRE の原則 「ソフトウェアの簡素化は信頼性の前提であ る」 システムの俊敏性と安定性のバランスを保つ ためにシンプルさを保とう

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

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

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

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

Copyright © 3-shake, Inc. All Rights Reserved. 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のエラーのバジェットを提供することになります。 「エラー予算」を設けて信頼性を制御する

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

信頼性を測定するために重要となる 3つの指標 Copyright © 3-shake, Inc. All Rights Reserved. SLO 達成 = Error 予算が消化されていないケース ※ 例えば、SLO を 99.9% としたとき、月間で 障害が0件で稼働率100%を達成 機能開発 信頼性 SLO 達成 Error Budget が消化されていないので、機能開発をどんどん推進していく

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

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

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

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

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

Copyright © 3-shake, Inc. All Rights Reserved. 今、実践できているところはせいぜいこんなところ ... ● Monitoring 実装 ○ Metrics ○ Logs ○ Traces ○ Profiles ○ Dumps ● SLI / SLO の定義 ○ CUJ設計 ○ SLO 計測 ○ Error Budget 運用 ● 運用体制整備 ○ インシデント管理 ○ インシデント対応 ○ アラート制御の実装 ○ Postmortem の実施 ● IaC (Infrastructure as Code) 化 ○ 構成管理の品質チェック ○ GitOps ● CI/CD 導入 ○ デプロイの自動化 ○ コード品質・脆弱性の検査 ○ DevSecOps ● パフォーマンス分析 ○ 分散トレーシング ○ 負荷試験 ○ カオスシナリオ試験 ● Toil 計測のための仕組み構築 ○ Toil 撲滅のための自動化の実装

Copyright © 3-shake, Inc. All Rights Reserved. 今、実践できているところはせいぜいこんなところ ... ● Monitoring 実装 ○ Metrics ○ Logs ○ Traces ○ Profiles ○ Dumps ● SLI / SLO の定義 ○ CUJ設計 ○ SLO 計測 ○ Error Budget 運用 ● 運用体制整備 ○ インシデント管理 ○ インシデント対応 ○ アラート制御の実装 ○ Postmortem の実施 ● IaC (Infrastructure as Code) 化 ○ 構成管理の品質チェック ○ GitOps ● CI/CD 導入 ○ デプロイの自動化 ○ コード品質・脆弱性の検査 ○ DevSecOps ● パフォーマンス分析 ○ 分散トレーシング ○ 負荷試験 ○ カオスシナリオ試験 ● Toil 計測のための仕組み構築 ○ Toil 撲滅のための自動化の実装

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

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

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

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

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

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

まとめ 04 Copyright © 3-shake, Inc. All Rights Reserved.

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

Thank you 23 Copyright © 3-shake, Inc. All Rights Reserved.

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

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