40分+で分かった気になる SREのミッションとゆかいなSaaSの仲間たち - Mission and Alliance for SRE in 40 (or more) minutes - クラスメソッド株式会社 アライアンス統括部テックG 渡辺聖剛 2021.10.07

SREしてますか！

アジェンダ 1. SREとは・サイトの信頼性とは 2. SREのミッション 3. SREの始め方 4. SREが駆使するツール ○ 可用性の維持と計測 ○ コストコントロール ○ コアバリューへのシフト 5. まとめ 3

お断り ● 本セッションでは基本を抑えつつ、 各現場で独自に展開頂くためのヒントをご紹介します ● 参加者全員の前提をそろえるために、 基本的なところから周辺事情まで、幅広く扱います ● 少 々 駆け足となりますが、 疑問点・不明点はお気軽にお尋ねください 4

注意：最近(ここ半年程)何回か似た話をしてます 一部、話やスライドの重複がありますが、 そこは何卒ご容赦ください（新しい話もします！） https://dev.classmethod.jp/news/210609-sre-webinar/ https://dev.classmethod.jp/news/gremlin-sre-webinar/ 5 20分+で分かった気になるSREと「速度の時代」 30分で分かった気になるSREとカオスエンジニアリング

自己紹介 6 渡辺聖剛 ( Seigo Watanabe ) ● クラスメソッド株式会社 アライアンス統括部テックG ● 運用/分析/モニタリング ● 前職までは いわゆるインフラエンジニア ● 好きな AWS サービス ○ ACM, Route 53 ○ Amazon CloudWatch https://dev.classmethod.jp/author/watanabe-seigo/

1. SREと「信頼性」

8 SRE = サイト信頼性エンジニアリング S R E Site サイト Reliability 信頼性 Engineering 技術 (or Engineer)

「信頼性（Reliability）」とは？ ”正確さ(accuracy)・誠実さ(honesty)・実績(achievement) などにより、確信をもって頼りにされる・頼られる能力” 利用者から「ここなら大丈夫だ」と思ってもらえること(性質) ブランドといっても良い 9 the ability to be relied on or depended on, as for accuracy, honesty, or achievement. Reliability | Definition of Reliability at Dictionary.com https://www.dictionary.com/browse/reliability

利用者(ユーザー)から信頼を得るには？ ● 使いたいと思ったときにいつも使える ● 使っていてイライラしない ○ 欲しい機能がある、得られる内容が正確 ○ 直感的にすぐ使える、画面遷移などで待たされない ● 不具合が放置されない、すばやく修正される ● 情報漏洩等のクリティカルな事故がない、もしあっても 正しく誠実に対応される ● 素敵な新機能が定期的に実装される ● それらが継続して行われている 10 などなど...

つまり... どちらか片方だけではダメ！ ● 究極に安定したシステム → 枯れた「塩漬け」システム ○ 新機能は一切追加されない、不具合も放置されたまま ○ 周囲の変化に取り残される ● 究極に開発が進むシステム → 永遠の「アルファ版」 ○ いつ止まっても文句は言えない ○ そのうち完成する、という期待感があるうちは… 11 素早い実装・修正 《開発》 安定したシステム 《運用》

ところで：ちょっと気になる 12

余談 13 ほんとうに 世間の要求性能・速度は加速しているのか？

本当にユーザーは時間に厳しくなったか？ 2012/11 : “3秒を過ぎると57％のユーザーが訪問を諦める” 2021/05 : 「LCPは2.5秒以内がGOOD」 ● LCP (Largest Contentful Paint) : ビューポート内に表示される最も大きいコンテンツのレンダリング時間 概ね「3秒ルール」は変わってない...？ The Cost of Poor Web Performance - SmartBear https://smartbear.com/blog/the-cost-of-poor-web-performance-infographic/ Google Developers Japan: Core Web Vitals によるビジネス インパクト https://developers-jp.googleblog.com/2021/05/core-web-vitals.html 14

HTTPページの平均サイズの推移(‘10/11 → ‘21/09) Total Kilobytes - HTTP Archive: State of the Web https://httparchive.org/reports/state-of-the-web#bytesTotal ❖ デスクトップ向けで 約4.7倍、モバイル 向けは10倍+ ❖ 何倍もリッチになっ たコンテンツを、 以前と変わらない時 間内に届けないとな らない Webサイトに求められ る処理性能(bps)は、 確実に高くなっている 15

「速いは正義」という時代 「赤の女王」仮説 ● 開発速度 ≒ 変化する/変化に対応する速度 ● 処理性能(レスポンスタイム)の速さ 資本主義は「赤の女王」である – アゴラ https://agora-web.jp/archives/516141.html 鏡の国のアリス Through the Looking Glass: And What Alice Found There: Japanese https://www.genpaku.org/alice02/alice02j.html 16 “ここではだね、 同じ場所にとどまるだけで、 もう必死で走らなきゃいけないんだよ” ルイス・キャロル “鏡の国のアリス”

参考：2020年の「変化」by Zoom ● 1日あたりのミーティング参加者数が 4ヶ月で30倍（1,000万 → 3億、‘19/12〜’20/04） ● 2020/04〜2020/12まで90回以上のリリース ● (おそらく)日本国内での 利用ユーザー数の推移 2020年を振り返って - Zoom Blog https://blog.zoom.us/ja/2020%E5%B9%B4%E3%82%92%E6%8C%AF%E3%82%8A%E8%BF%94%E3%81%A3%E3%81%A6/ Zoom Releases By Date – Zoom Help Center https://support.zoom.us/hc/en-us/sections/360008531132-Zoom-Releases-By-Date?page=1#articles Zoom、GoogleMeetなどオンライン会議ツールの利用実態を調査 - マナミナ https://manamina.valuesccg.com/articles/1439 17

つまり : SREとは SRE = サイト信頼性 (Reliability) エンジニアリング 高いレベルでサイトの信頼性を維持するために 開発速度とサイトの安定性の両方をバランスさせるための技術 （あるいは、その役割を担ったエンジニア） ● 安定しないサイトは信頼されない ● 過剰な安定性は開発速度Down　(やっぱり信頼されない) ● 開発(機能実装)最優先のサイトはなかなか安定できない 18

...とはいえ 実際にはどうすれば？

ヒント : Ben Treynor Sloss 曰く Google Cloud Day: Digital ‘21 セッション「SREの基本と組織への導入」資料より https://dev.classmethod.jp/articles/202105-report-gcd21-d3-infra-01/ 20 ・現Google副社長 ・2003年に入社しSRE部門やデータセンター部門その他を率いる ・SRE本の執筆者のひとり https://www.linkedin.com/in/benjamin-treynor-sloss-207120

ソフトウェアエンジニアに運用設計を依頼すると いったい何が起きるんだ...?

モダンなソフトウェアエンジニアを取り巻く2つの要素 22 DevOps 「永遠の未完成」をささえる技術 Cloud技術 (X-as-a-Service) 設備・性能・コストの柔軟化・最適化 両者とも、「システム開発」を加速させるために誕生・進化してきた ○ 開発と運用の密接な連携、迅速な方針決定 ○ 短いリリース間隔、継続した開発 (CI/CD) ○ 心理安全性が高く保たれた組織文化がベース ○ ソフトウェアで定義されたインフラストラクチャ ○ APIによる高度かつ柔軟なコントロール ○ リソースの調達・破棄が短時間で完了 Cloud技術が成熟してさらに重要に DevOps側の要求に適応した進化 ChatOps, GitOps, Infrastructure-as-Code サービスの全レイヤをAPIコントロール サーバーレス, マイクロサービス, 可搬コンテナ アプリレイヤとインフラレイヤの明確な分離 この2つが SRE の土台となる

つまり : SREとは DevOpsとCloud技術が先鋭化したなかで生みだされた概念 ● DevOpsを安定かつ高速に回転させるために、 ● Cloud技術をはじめ様々なツールを駆使することで、 ● 信頼性を適切に維持・コントロールする技術 / 役割 ➢ リリースしても・不具合が生じても止まらないシステム ➢ 不具合があればすぐ対処・修正できる運用・開発体制 ➢ 異常発生を素早く検出、自動的に対処 ➢ 手戻り・ブロックの少ない俊敏な開発サイクル 23

言い換えると 「ソフトウェアエンジニアに運用設計を 依頼すると起きること」とは... ● 開発現場で行われた「DevOps化」が 運用の現場に適用されること ○ 情報伝達の効率化、手作業領域の極小化・定型作業の自動化 ○ 運用手順のリファクタリングと パフォーマンスチューニング・最適化 24 ※当時 (2010年前後〜) のGoogleの基本戦略 　「最高のソフトウェア開発者に(高給払って)オンコール対応させて、 　彼ら自身が嫌にならない環境を爆速で開発してもらおう」

でもそれ、 Googleさんだからできる事ですよね...

よく言われます(ました？) ● 特に最初の翻訳本が出た2017年頃 (正直、ぼくも思いました) ○ オンコール業務を工数50%以下？ SLOにエラーバジェット？ 上層部にそんなの理解されないし... ○ 運用自動化しても使われない、 作ったひとにメンテナンスが集中 するだけで楽にならない... 結果、単に「インフラエンジニア2.0」 「品質管理2.0」的に扱われる事例多数 O'Reilly Japan - SRE サイトリライアビリティエンジニアリング https://www.oreilly.co.jp/books/9784873117911/ 26 (※要出典)

その後「実践SRE」的な本もでました (2018年) ● いろいろな規模/形態の組織で 実践されています ○ Googleモデル ○ Pure SRE ○ Embedded SRE ○ SREロール　etc. ● 国内事例もいろいろ載ってます 少しずつ国内事例も増えてきつつ、 本来のSREもじわじわと浸透... O'Reilly Japan - サイトリライアビリティワークブック https://www.oreilly.co.jp/books/9784873119137/ 27

更に：SREについての最強のまとめ本もでました 訳　：渡邉了介氏 監訳：山口能迪氏 2021/09 SREの導入など技術論のみならず、 DevOpsとの比較、アンチパターン、 周辺領域、組織論から雇用、採用、 評価からメンバーのヘルスケアまで、 あらゆる項目を網羅した究極の一冊 O'Reilly Japan - SREの探求 https://www.oreilly.co.jp/books/9784873119618/ 28 NEW

余録：「SREの探求」目次 29 本書への推薦の言葉 監訳者まえがき はじめに 第I部　SREの導入 1章　SREにおけるコンテキストとコントロール 2章　サイトリライアビリティエンジニアの面接 3章　なるほど、SREチームを作りたいのですね 4章　インシデントのメトリクスを用いたSREの大規模な改善 5章　サードパーティとの協力を円滑に進める重要性 6章　専任SREチームなしでSREの原則を適用する方法 7章　SREのいないSRE：Spotifyのケーススタディ 8章　大企業におけるSREの導入 9章　25ページでシステム管理者からSREへ 10章　大企業でSRE導入の道を開く方法 11章　DevOpsの幅広い実践現場で活用されているSREのパターン 12章　DevOpsとSRE：コミュニティからの声 13章　Facebookにおけるプロダクションエンジニアリング 第II部　SREの周辺領域 14章　初めにカオスありき 15章　信頼性とプライバシーが交わるところ 16章　データベースリライアビリティエンジニアリング 17章　データ耐久性のエンジニアリング 18章　SREのための機械学習入門 第III部　SREのベストプラクティスと技術 19章　ドキュメント作成業務の改善：エンジニアリングワークフローへのドキュメンテーションの統合 20章　アクティブなティーチングとラーニング 21章　サービスレベル目標の技法と科学 22章　成功の文化としてのSRE 23章　SREのアンチパターン 24章　イミュータブルなインフラストラクチャとSRE 25章　スクリプタブルロードバランサー 26章　サービスメッシュはマイクロサービスの世話人か 第IV部　SREの人間的側面 27章　SREにおける心理的安全性 28章　SREの認知的作業 29章　燃え尽きを超えて 30章　オンコール反対論 31章　複雑なシステムのためのエレジー 32章　運用と社会運動が交わるところ 33章　まとめ コラム　SREであることを自覚するのは…… 4章　インシデントのメトリクスを用いたSREの大規模な改善 6章　専任SREチームなしでSREの原則を適用する方法 12章　DevOpsとSRE：コミュニティからの声 19章　ドキュメント作成業務の改善： エンジニアリングワークフローへのドキュメンテーションの統合 22章　成功の文化としてのSRE 23章　SREのアンチパターン 27章　SREにおける心理的安全性 29章　燃え尽きを超えて 30章　オンコール反対論 31章　複雑なシステムのためのエレジー（elegy = 悲歌、哀歌） https://www.oreilly.co.jp/books/9784873119618/ SREであることを自覚するのは…… (抜粋) ・最初の質問として「それをどのように計測していますか」が口をついて出る時 ・自分の個人ブログが複数のAWSリージョン障害にも耐えられる時 ・決まりきった運用作業を自動化するという根拠でロボット掃除機の購入を 　正当化する時 ・利用している電力会社のSLOがどのようなものか気になる時

これらの本を読むと... SREの仕事は非常に多岐に渡り、 高度な技量と聖人のような精神力が必要に思えますが... ● あくまで事例です ● SRE (Engineering) の全てをこなせるひとでないと SRE (Engineer) になれない、というわけではありません！ ● 適用組織に対しても同様です 出来るところだけCherry-Pickして 出来るところから始めていきましょう！ 30

31 ここまでのポイント SREとは、以下を「サイト運用」に活用すること ● DevOpsのノウハウ ● Cloud技術・インフラ その目的は、以下を実現すること ● 安定したサービス提供・運営 ● 素早い開発・リリース 3冊の本はおすすめ、特に3冊目

2. SREのミッション

33 ミッション = 果たすべきこと 安定な運用と開発 → 究極に目指す場所 DevOpsとCloud技術 → 目の前にある手法 「目指す場所」にたどり着くために、 「目の前にある手法」を使って、 SREは何をすればいいのか。。。 https://pxhere.com/en/photo/930678

34 SREの原則 SRE本の章タイトルから読み取ると... ● リスクを許容しコントロールする (エラーバジェット) ● サービスレベル目標 (SLO) ● トイルの撲滅 ● モニタリング・可観測性(オブザーバビリティ) ● 自動化 - 手作業の不確かさとオーバーヘッドの除去 ● 品質の高いリリース（リリースエンジニアリング） ● 単純さ = シンプルに保つ Part II. Principles - Google - Site Reliability Engineering https://sre.google/sre-book/part-II-principles/

35 SREの手法のでよくふれられるところ SRE本の章タイトルから読み取ると... ● リスクを許容しコントロールする (エラーバジェット) ● サービスレベル目標 (SLO) ● トイルの撲滅 ● モニタリング・可観測性(オブザーバビリティ) ● 自動化 - 手作業の不確かさとオーバーヘッドの除去 ● 品質の高いリリース（リリースエンジニアリング） ● 単純さ = シンプルに保つ Part II. Principles - Google - Site Reliability Engineering https://sre.google/sre-book/part-II-principles/

36 ここに注目 SRE本の章タイトルから読み取ると... ● リスクを許容しコントロールする (エラーバジェット) ● サービスレベル目標 (SLO) ● トイルの撲滅 ● モニタリング・可観測性(オブザーバビリティ) ● 自動化 - 手作業の不確かさとオーバーヘッドの除去 ● 品質の高いリリース（リリースエンジニアリング） ● 単純さ = シンプルに保つ Part II. Principles - Google - Site Reliability Engineering https://sre.google/sre-book/part-II-principles/

37 トイル(Toil) = 価値を生まない作業 ● プロダクションサービスに関係 ● 自動化が可能なのに手作業で行われている ● 長期的な価値をもたない・価値を生み出さない こういうものを「トイル（toil = 労苦）」と定義 “トイルとは、プロダクションサービスを動作させることに 関係する作業で、手作業で繰り返し行われ、自動化することが 可能であり、戦術的で長期的な価値を持たず、作業量がサービ スの成長に比例するといった傾向を持つものです。” Betsy Beyer “SRE サイトリライアビリティエンジニアリング”

38 トイルの撲滅は結果であり動機である トイルの撲滅 = 運用のリファクタリング ● DevOpsで「ベストプラクティス」といわれることを 運用に対しても行う ● 運用の改変に伴うリスク = エラーバジェットで吸収 ○ エラーバジェットの計測にはSLI/SLO ○ きちんと計測するために可観測性(オブザーバビリティ) ● もちろんDevOpsもきっちり回す ○ = リリースエンジニアリング・シンプルさ ○ SREとDevOpsはずぶずぶの関係(語弊) 　トイル撲滅のためにあらゆる手段手法を駆使　

トイルの撲滅、といったものの... トイルは「最小化」を目標にする ● 「無くす」ではない ○ 無理に無くしたことで非効率になる場合もある ● Google : トイルに費やす時間を 50% 以下にする ○ 残りの時間でコードを書く ○ 書かれたコードでトイルを減らす トイルが多すぎるとメンバーが疲弊することも... “チームの仕事の流れにあまりに多くのトイルを組み込んでしまう と、それはチーム内の最高のエンジニアに対し、もっと報われる 仕事を他のところで探すようにすすめているようなものです。” Betsy Beyer “SRE サイトリライアビリティエンジニアリング” 39

40 ここまでのまとめ ● SREのミッション = トイルの撲滅 ● SREは「信頼されるサイト」のために、 あえてトイルの山に飛び込みそれを減らすことを ミッションとしている ● トイルを減らすための道具がたくさんある ○ エラーバジェット、SLI/SLO、可観測性... ● SREのヘルスケアも忘れずに！ ○ トイルの撲滅はSREのミッションだが、 サービスの運用はチームの仕事です！ ○ SREは専務しわ寄せられ役ではない、との共通認識を あとお給料も上げてあげてください

3. SREの始め方

42 SREの守備範囲 守備範囲 = 「サイト (Site)」 ● 「システム (System)」ではない（内包している） ○ 狭義でいえばサイト = システムでも誤りではない ● インフラから開発体制、サービスまで含む ○ ユーザーが使っているのは「サービス」 ○ サーバー1台、プログラム1本を意識して使っていない サービス(プロジェクト)全てがSREの守備範囲の「候補」 ※必ずしもそうあるべき、というものはない

いろいろなSREのかたち Pure SRE (Google Model) ... SRE専門チーム Embedded SRE ... 各開発チームに所属するSRE (役割としての) SRE ... 各開発チームのメンバーが SREとして働く・兼務する 43 ※(もちろん)混在事例も多数 SRE-iously: Defining the Principles, Habits, and Practices of Site Reliability Engineering https://www.slideshare.net/newrelic/sreiously-defining-the-principles-habits-and-practices-of-site-reliability-engineering-112178269 The Many Shapes of Site Reliability Engineering | by Rob Cummings | Slalom Build | Medium https://medium.com/slalom-build/the-many-shapes-of-site-reliability-engineering-468359866517 開発チームとともに歩む SREチームが成し遂げたいこと | メルカリエンジニアリング https://engineering.mercari.com/blog/entry/20210129-embedded-sre/

答えはひとつじゃない ● 全体を統括する部署でもいいし、 各チームに埋め込まれてもいい ● 開発者でもいいし運用担当でもいいし、 単なる助言役でもいい 既に、SREと呼ばれないままSRE的な役割を担っている メンバーがいるのでは？ ● そのようなひとを正しく評価し後押しすることも、 広義の「SRE」です 44

忘れてはならないこと あくまで「エンジニアリング」 ● 理論に裏打ちされていないうちは、技術ではない ● 根性論・精神論は意味をなさない（トイルを増やすだけ） SREの仕事は「強制」ではない ● 提案の押しつけはトイルの増加を招きかねない ● 「銀の弾丸はない」 ○ その提案が現場にあうかどうかはケースバイケース ○ 最初はある程度の権威付け・強制力を持たせたほうが スムーズに行くケースも...？ ● チームが自律できるようにガードレールを設置 45

忘れてはならないこと (cont.) SREには「発言力」を持たせることが重要 ● SRE・現場・上層部の相互理解・信頼が大切 ○ 開発・運用・ビジネスがワンチームであること ● SRE自身にも「説得スキル」が必要 ○ チーム内で目的意識を共有させる技術 理想 : お互いの信頼の元で提案し、試しに採用する ● 良ければ永続化、合わないなら見直し ○ クラウド・SaaSは試行がしやすい ● 組織内の「心理的安全性」が重要 参考 : Google re:Work - ガイド: 「効果的なチームとは何か」を知る https://rework.withgoogle.com/jp/guides/understanding-team-effectiveness/steps/introduction/ 46

47 思い出して欲しいのが SRE = サイト運用の現場にDevOpsを持ち込むこと DevOpsのCALMSモデル ● Culture ● Automation ● Lean (IT) ● Masurement ● Sharing ※「SREの探求」にはDevOpsとSREを比較する章があります Download our diagram CALMS Model of DevOps | DevOpsGroup https://www.devopsgroup.com/insights/resources/diagrams/all/calms-model-of-devops/ DevOpsでも組織文化が重要 SREで大切でないはずがありません

SREにとって重要な能力 ● ソフトウェアエンジニアとしての能力 ○ コードを読む・書く能力 ● 全レイヤの知識 ○ アプリケーション ○ OS・ネットワーク ○ コスト・ビジネス感覚 ● コミュニケーション能力・リーダーシップスキル ● そのサービスの最適化への情熱 ※全てを備えた人材はそうそういない！ 　という前提に立つことが出発点です 48

4. SREが駆使するツール ❏ 可用性の維持と計測 ❏ コストコントロール ❏ コアバリューへのシフト

(要は) 実際どうやるの？

SREのお仕事 = サイトの信頼性の維持 ● サイト全体の計測 ● 信頼性が維持されていることを確認 ● 信頼性を下げそうなこと（トイル）をつぶす ○ システムの安定性 ■ 運用環境の最適化・リファクタリング ● 自動化 ● ドキュメントやランブックの整備 ■ オンコール対応 ● 信頼性に直結したフィードバックが手に入る ○ 開発速度 ■ リリースサイクルのコントロール ■ リリース環境のチューニング ● コードは自分で(も)書く 道具(ツール) ・SLI / SLO ・エラーバジェット ・Cloud技術 ・OpEx ・言語・SaaS 51

キーワード ● 可用性の維持と計測 ○ SLI / SLO / エラーバジェット ○ 可観測性(Observability)と監視(Monitoring) ● コストコントロール ● コアバリューへの内製能力のシフト 以下は話しません ● 自動化・DevOpsそのもの ● 組織的・人事的な話 ● 上にあげた項目の細かな内容 52

可用性の維持と計測

「信頼性の保たれている状態」とは？ ユーザーの信頼に応えられている状態 二律背反の命題 100%ではなく、「ここまでなら OK 」というポイントを 見極める必要がある ➡ エラーバジェットを使ってコントロール 54

エラー予算（エラーバジェット）という考え方 ● サイトを変化させるために利用できる「予算」 ○ リリースによる計画停止、見込み不具合 ○ 発生した障害の回復に必要とした時間（自動・手動） ● 設定したウィンドウ(ex: 直近30日)内で「達成率」を計測 (現在の達成率) - (目標とする達成率) ex) 現在 99.95%、目標 99.90% 　　→ エラーバジェット 0.05% Google Cloud Day: Digital ‘21 セッション「SREの基本と組織への導入」資料より https://dev.classmethod.jp/articles/202105-report-gcd21-d3-infra-01/ 55

「達成率」？ SREでは SLI・SLO という考え方をします。 SLI Service Level Indicator 何をもって「正常」を定義するか / 何を使えば測れるか ex) Webサイトのレスポンス速度、ステータス、応答コード、 総有効アクセス数における理想的なレスポンスの割合 SLO Service Level Objective SLIがどうであった時に「正常」と見なすのか SLIと1対1で設定、部内での目標値（達成が目的ではない） SLA Service Level Agreement 顧客との約束 端的には返金基準 56 エラーバジェット = SLO 違反となるまでに許容できる時間やエラーの量

SLIは利用者目線で設定する ● 例1 : CUJ（クリティカルユーザージャニー）から検討 ○ 「利用者がこのシステムを利用して成し遂げたいことは?」 ● 例2 : 故障モード（failure mode）・FMEA ○ 「どのような状態になったら『異常』となるのか？」 利用者からすれば、 CPU利用率が100%だろうがWebサーバが1台落ちてようが、 目的が達成できるなら「故障ではない」し、その逆も真 SLO の定義 | Cloud アーキテクチャ センター | Google Cloud https://cloud.google.com/architecture/defining-SLOs?hl=ja [レポート] 行き先は火星？木星？　移住計画用マイクロサービスを AWS サービスで構築・管理する | DevelopersIO https://dev.classmethod.jp/articles/201912-report-reinvent-2019-ent308/ FMEA(故障モード影響解析 )とは？評価法や実際の流れを解説 | 金属加工の見積りサイト Mitsuri（ミツリ） https://mitsu-ri.net/articles/fmea_toha 57

サービスにあった適切なSLI/SLOを ● 過剰品質はコストに反映、結局は顧客のためにならない ● 大事なことは、利用者の信頼を落とさないこと “SRE では 100% の信頼性は期待されていません。 失敗は予測済みで、許容されます。” “99% の信頼性を持つスマートフォンを使っているユーザーには、 サービスの信頼性が 99.99% の場合と、99.999% の場合との 違いは分からない” Betsy Beyer “SRE サイトリライアビリティエンジニアリング” 58 SRE とは https://www.redhat.com/ja/topics/devops/what-is-sre

59 参考) ドミナント・ロジック 2005年頃から ● グッズ・ドミナント・ロジック ○ 提供される「モノ」に価値を置く ○ モノが壊れていたら価値が提供できない = 暗黙の可用性100% ● サービス・ドミナント・ロジック ○ 提供される「サービス」「体験」に価値を置く ○ モノだけでなく、提供形態やトータルの「居心地」が重要 目指すところはこの考え方に近い サービス・ドミナント・ロジック：先進企業事例に見る「価値づくり」の世界観 | 価値共創が生み出す競争優位の源泉｜ DIAMOND ハーバード・ビジネス・レビュー https://www.dhbr.net/articles/-/2698

参考) Everything fails all the time 全てのものはいつかは壊れる、という前提に立って、 壊れたときの影響を最小にする設計と運用を行うことで、 真に「壊れない」システムを構築する 60

SLO・エラーバジェットはあくまで目安・目標値 エラーバジェットが... ● ひっ迫 = 新規リリースを一時ストップし調整 ● 超過　 = 原因の確認と改善（コード、運用） ● 下回る = 過度・過剰に余裕をもっていないか見直し ○ より多くのリリースを実施、挑戦的な機能の実装 ○ バジェットを減らす方向にSLOの数値を調整 継続して計測し全体計画に反映させる 達成することが目的ではありません❗ 61 信頼性 UP❗

3 Pillars of Observability 可観測性（オブザーバビリティ / Observability） 「システムを総合的・多角的にモニタし継続して分析する」 そのための機能(性質)をシステムが備えていること Metric CPU%, Mem Usage, Traffic, Counter Log 高コンテキスト アプリ/インフラログ Trace 複数箇所からの関連 するデータを連結 Blackbox 外部/インフラスト ラクチャからの計測 Whitebox アプリ内部の計測 データ・APM Frontend 合成(Synthetic)監視 RealUser Monitoring 可視化 グラフ化, 分類, 図示 ダッシュボード 分析 相関, 推移・傾向予測, ふるまい検出, Severity 通知(Action) 通知(アラート/on-call), 自動処理(failover/recovery) 62 4 Golden Signals Latency, Errors, Saturation, Traffic 3 Dimmensions Functionally, Availability, Speed

監視（Monitoring）と可観測性（Observability） ● 監視 ... 観測地点で異常が発見されたら通知 → 対処 ● 可観測性 ... 定常状態をひろく観測、備える https://flic.kr/p/hRLTUV https://stocksnap.io/photo/senior-running-KVQQJKRXZW 監視 Monitoring 可観測性 Observability 63 ・比較的少数の計測 　(痛み、気分、体温) ・異常(閾値超え)を検知 　し病院へ ・病院で検査 　(血圧、心拍数 ...) ・検査結果に基づいて 　対処 　(薬の処方 etc.) ・多数の計測ポイント 　(歩数、心拍数 ...) ・日常的に状態をモニタ ・過去との比較 ・比較から未来予測 ・異常を起こさないよう 　先手の対策 　(継続した体調管理)

監視ではだめなんですか？ “Monitoring means that you already know what is important. 何が重要でどうなったら異常 なのか、既に分かっている 場合にのみ監視は有効だ” —— Dr. Werner Vogels. [レポート] オペレーション、監視 (Monitoring)、可観測性(Observability)… AmazonのCTOは　 AWS re:Invent 2020のキーノートでどう語ったか？ キーワードを拾ってみた #reinvent | DevelopersIO　 https://dev.classmethod.jp/articles/202012-report-reinvent-keynote-observability/ 64

つまり？ ● 固定的な閾値設定による異常検知だけでは十分ではない ○ 障害の予測ができない・十分な精度を保てない ○ 個々の閾値を調整し続ける必要がある ● 観測対象が爆発的に増加 → 従来型監視の維持は困難 ○ サーバーレス / コンテナ (Kubernetes) ○ マイクロサービス（疎結合・非同期） ○ 外部APIサービス(SaaS) / マネージドサービス ○ 単一の事象による大量のアラート ● (もちろん) 既知の事象をとらえるためには引き続き必要 ○ 監視ポイントを見直す必要がある https://twitter.com/Werner/status/741673514567143424 65

監視と可観測性の使い分け (真に)起きてはまずい事象 　監視し即対応アラート Root Cause調査、 周辺事象、 将来予測 　可観測性(オブザーバビリティ)を高め継続してデータを収集 　予測された事象に対して警告通知 66

監視 + 可観測性のイメージ LB CDN Application DB Storage DNS Network Backend Synthetics Log VM / コンテナ APM インフラストラクチャ Infrastructure 可観測性 Observability 可視化 分析 通知(Act.) Code Repo CI/CD JS RUM 67 Integration 監視 Monitoring 既知の事象 起こってはならない事象

【PR】弊社があつかう監視・可観測性プロダクト 68 見やすく直感的なダッシュボード 純国産・日本語フル対応 簡単な導入と豊富な拡張性・URL外形監視 クラウドインフラ向けインテグレーション 定番の可観測性プラットフォーム 強力なAPM インフラから合成監視、RUM、Log 広い無料枠と開始しやすい価格体系 https://classmethod.jp/partner/mackerel/ https://classmethod.jp/partner/newrelic/

ところで、 69 可観測性といっしょに カオスエンジニアリングは いかがですか？

カオスエンジニアリングとは Chaos Engineering 特定の環境(システム)に意図的に異常を発生させることで、 その環境がどのような反応をするかを継続的に検証する(実験) ● 監視システムは意図した通りに検知したか？ ● 自動復旧システムは意図した通りに機能したか？ ● マニュアル通りの対処で想定内に復旧したか？ ● ユーザー(利用者)への影響は想定の範囲内に収まったか？ ● 想定していない不具合の引き金にならなかったか？ 70

カオスエンジニアリングはSREを補強する ● サイトの信頼性(Reliability)を高く維持するために、 SREはあらゆる事象を想定して対処しなくてはならない ● とはいえ、いわゆる「カバレッジ100%」は実質不可能 ○ 開発の機動性も落としてしまう ● よく聞く言葉「やってみないとわからない」 ● 実際に「やってみる」ことで、 意図しない事象の発生をとらえたり、 意図しない事象が発生しないことを確認する 71

カオスエンジニアリングの始め方 1. 「定常状態」を定義 ○ ex) フロントエンドのリクエスト応答時間(p99)は 500ms 2. 定常に対する仮説 ○ プロセスが1つ落ちても、応答時間は影響がないか、 あるいは 1s 以内に正常値にもどるはずだ 3. 実験を行う(障害のシミュレート) ○ カオスエンジニアリングツールなどを利用 4. 実験により得られたデータを元に仮説を検証 フィードバック 5分で学ぶ: カオスエンジニアリングの説明書 - New Relic公式ブログ https://blog.newrelic.co.jp/engineering/chaos-engineering-explained/ 72 データを得るためには 可観測性が備わってないとダメ

監視 + 可観測性 + カオス実験 LB CDN Application DB Storage DNS Network Backend カオスエンジニアリング Synthetics Log VM / コンテナ APM インフラストラクチャ Infrastructure 可観測性 Observability 可視化 分析 通知(Act.) Code Repo CI/CD JS RUM 73 Integration 監視 Monitoring 既知の事象 起こってはならない事象

【PR】カオスエンジニアリングを実現するツール AWS Fault Injection Simulator 74

Gremlin　　とAWS FIS Gremlin カオスエンジニアリングの先駆者 AWS FIS(Fault Injection Simulator) W-A「信頼性の柱」 ○ 創業者のコルトンCEOは元Netflix （その前はAWS） ○ カオスエンジニアリングはNetflixが発祥 （2012年にChaos MonkeyをOSS化） ○ 広い適用範囲と無料枠 ○ AWS re:Invent 2020にて発表 2021/03より提供開始 ○ Well-Architected Framework「信頼性の柱」に おいて、可観測性や継続化(CI/CDとの組合せ)が 語られている カオスエンジニアリングツール「 Gremlin」 | クラスメソッドのパートナー https://classmethod.jp/partner/gremlin/ ついにAWSがマネージドなカオスエンジニアリングサービスを発表したぞ #reinvent | DevelopersIO https://dev.classmethod.jp/articles/coming-soon-fault-injection-simulator/ 75 多種多様な障害パターンを網羅 AWS環境に特化・高い親和性 特にアプリケーション側に強み サーバーレスやオンプレ・マルチクラウドに AWS Systems Manager等のサービスと統合 AWSインフラに対する障害注入実験が可能

コストコントロール

コストの最適化もSREの仕事 適正運営のためにはコストは価格に反映せざるを得ない ➡ 過剰にコストをかけることも顧客のためにならない ● 余剰コストの削減 ○ きめ細かな余剰リソースのコントロール ○ AutoScaling・サーバーレス・自動化の促進 ○ 「価値を生まない手作業(トイル)」の削減 ● 過剰な内製をやめて適切にアウトソーシング ○ マネージドサービスやSaaSの利活用 ○ 開発リソースはコアバリューに集中 → 真の「内製化」 77

CapEx -> OpEx ● CapEx (Capital Expenditure) ... 設備投資 ○ 資産として購入(オンプレミス)、専門の人員の確保 ○ 長期的な予測が必要 ○ ゼロにはできない ● OpEx (Operating Expense) ... 運用経費 ○ サービス利用（クラウドインフラ、SaaS） ○ 短いスパンで負荷・需要と利用費を合致させることが可能 ○ 継続した監視とコントロールが必要 企業活動における CAPEXとOPEXの定義 | クラウドERP実践ポータル https://www.clouderp.jp/blog/what-is-capex-opex クラウド費用の最適化 : 成功し続けるための諸原則 | Google Cloud Blog https://cloud.google.com/blog/ja/products/gcp/cost-managementprinciples-of-cloud-cost-optimization 78

79 CapExが悪者、というわけではない ● 同じ期間で同じ内容なら、一般的にCapExのほうが安い ○ 長期利用によるコスト圧縮が効く ○ AWSでいうところの RI や SP の活用はコスト削減の定石 ● OpExの強みは「キメの細かなコントロール」 ○ 負荷に応じて柔軟に増やし、減らす ○ 無駄に起動したままに しない ○ Auto Scalingに例えるなら EC2よりFargate/Lambda という議論に似ている AWS re:Invent 2019 - Dr. Werner Vogels による基調講演 | AWS (日本語字幕) - YouTube https://www.youtube.com/watch?v=NKW-q7FE2rc

80 SRE視点からみたコストコントロール 長期的視点から、要所を押さえた CapEx の利用 柔軟なコントロールを効かせるための OpEx の活用 ● 可観測性によりリソース利用の傾向を把握 ● コストを最適化：必要なところに振り分ける ○ どんなインフラが最適か？ ○ コードに無駄はないか？ ○ ひとを雇うのとSaaSを活用するのとどちらが得か？ etc...

コアバリューへの内製能力のシフト

想像してみて下さい 仮に、貴方が何か素敵なサービスを作るとなったとき 82 Awesome Service

インフラ！ 想像してみて下さい (cont.) 動かすためのインフラも用意する必要がありますが、 この部分は、今はだいぶ楽になりました（選択肢的な意味で） ● パブリッククラウド ● FaaS・サーバーレス コンテナ・k8s 83 Awesome Service

想像してみて下さい (cont.) でも、考えなくてはならないものは他にもいっぱいあります これらを作り込まないとサービスインできない ...? 84 Awesome Service 認証 管理統制 コンプライアンス モニタリング ログ管理 セキュリティ 通知 メール SMS サポート コミュニケーション BI データ分析 コード リポジトリ テスト CI/CD プロビジョ ニング コンテンツ 再生 課金 ログイン

そもそも：何がやりたかったんだっけ？ 提供したい【コアバリュー】は、素敵なサービス！ できる限りそこに注力したい… 85 認証 管理統制 コンプライアンス モニタリング ログ管理 セキュリティ 通知 メール SMS サポート コミュニケーション BI データ分析 コード リポジトリ テスト CI/CD プロビジョ ニング コンテンツ 再生 課金 ログイン Awesome Service Core Value!

そこで : 現状の(弊社が考える)最適解 内製すべき「コアバリュー」はきっちりと 内製 する それ以外は SaaS でカバー！ 86 認証 管理統制 コンプライアンス モニタリング ログ管理 セキュリティ 通知 メール SMS サポート コミュニケーション BI データ分析 コード リポジトリ テスト CI/CD プロビジョ ニング コンテンツ 再生 課金 ログイン Awesome Service Software-as-a-Service SaaS! Core Value!

87 極端な話 コンピューターの歴史は 「汎用部品の共通化・アウトソース」の歴史 設置場所 マシンルーム → データセンター インフラストラクチャ オンプレミス → クラウドインフラ OS ハードウェア付属(!) → 汎用OS (→ OSS) ミドルウェア パッケージ (→ OSS) → マネージドサービス 開発言語 専用(!) → 汎用言語 特定機能 作り込み → ライブラリ → モジュール → SaaS Webフレームワーク 内製 → 汎用

クラウドマネージドサービス パブリッククラウド各社はインフラ (IaaS) だけでなく 各種分野向けのマネージド(管理された)サービス群を展開 ● データベース（RDBMS, NoSQL, GraphQL, 時系列DB ...) ● データ分析基盤・DWH・可視化 ● 機械学習(ML)・AIサービス（自然言語処理, 機械翻訳 ...） ● 認証基盤・セキュリティ ● 運用・環境管理統制・コストマネジメント　等々 クラウドベンダーによってラインナップに特色があります AWS の製品・サービス一覧 | クラウドなら AWS https://aws.amazon.com/jp/products/ 88

SaaS - Software as a Service ● 必要な機能を素早く組み込む「ショートカット」 ○ 一昔前のライブラリやパーツ、ミドルウェア、 フレームワークのような位置づけ ○ クラウドインフラの「マネージドサービス」もその一種 ● いわば「最新鋭の安定した機能と専属の運用チームの 両方を、従量課金で利用する仕組み」 “SaaS を使えば数分で動く仕組みが手に入り、しかも 始めたタイミングからドキュメントなども手に入ります。” Mike Julian “入門　監視” 89

SREっぽい事例：水曜どうでしょう祭 ● 開発期間と必要とする機能・セキュリティのバランス ● 内製リソースはコアバリューに注力 ● 有料配信サービスの準備がほぼ 1ヶ月 で整う 90 HTB北海道テレビ放送｜水曜どうでしょう祭ライブ配信の技術支援｜クラスメソッドの事例 https://classmethod.jp/cases/htb/ 認証：Auth0 課金：Stripe 動画再生：THEOplayer サーバーレスアーキテクチャ

SaaSに対する懸念と注意 ● 効果測定 ○ 開発コスト + 運用コスト（時間、工数） ○ 開発チームが本当に開発したいことに注力できる価値 ○ 本当に価格と見合っているか？を実測する ● 過度に避けるのは開発速度を落とす ○ 「ロックインを避ける」は永遠の課題 ○ OS、言語 ... 避けられないロックインもある ● どこをオフロードすることが最適かの判断 ○ その製品のコアバリューを自分たちで持ち、 その周辺をSaaSでカバーする 適用されるSLAや規約、法律にも適切な注意を❗ 91

【PR】弊社で取り扱いのあるSaaS (一部) 92 お気軽に ご相談ください！ https://classmethod.jp/partner/

5. まとめ：(改めて) SREとは

94 (改めて) SREとは ● DevOpsとCloud技術が先鋭化したなかで生みだされた概念 ○ DevOpsを安定かつ高速に回転させるために、 ○ Cloud技術をはじめ様々なツールを駆使することで、 ○ 信頼性を適切に維持・コントロールする技術 / 役割 ● DevOpsの原則を運用の現場に適用したもの ○ 運用のリファクタリング ● その守備範囲は「サイト」=サービス提供に関わる全て ● そのミッションは「トイルの撲滅」 ● そのために独自の様々な手段手法を駆使する

まとめ SREの一番の目的 : 開発・リリースのペースを高く保ちつつ信頼性を維持すること ● SLI/SLOはユーザー目線でシンプルに設定を ● 速度は正義：速度アップのためのツールを効果的に使おう ○ DevOps、Cloud技術 (XaaS) 、CI/CD ○ 可観測性（Observability） ○ カオスエンジニアリング ○ SaaS 基本となる考え方や要素技術は汎用的 できるところから組み入れていきましょう！ 95

SREを成功させるには “短距離ではなくマラソンである” “Remember: it's a marathon, not a sprint” SRE を成功させるには、まず計画を立てることが大事 | Google Cloud Blog https://cloud.google.com/blog/ja/products/gcp/sre-success-starts-with-getting-leadership-on-board 96

Appendix

98 書籍（O'Reilly Japan） ➢ SRE サイトリライアビリティエンジニアリング ○ https://www.oreilly.co.jp/books/9784873117911/ ○ https://sre.google/sre-book/table-of-contents/ ➢ サイトリライアビリティワークブック ○ https://www.oreilly.co.jp/books/9784873119137/ ○ https://sre.google/workbook/table-of-contents/ ➢ SREの探求 ○ https://www.oreilly.co.jp/books/9784873119618/ ➢ 入門 監視 ○ https://www.oreilly.co.jp/books/9784873118642/

99 SRE ➢ SRE とは (RedHat) ○ https://www.redhat.com/ja/topics/devops/what-is-sre ➢ Site Reliability Engineeringとは。 ○ https://www.nic.ad.jp/ja/materials/iw/2017/proceedings/s15/s15-fujisaki.pdf ➢ 開発チームとともに歩むSREチームが成し遂げたいこと ○ https://engineering.mercari.com/blog/entry/20210129-embedded-sre/ ➢ Google re:Work - ガイド: 「効果的なチームとは何か」を知る ○ https://rework.withgoogle.com/jp/guides/understanding-team-effectiveness/steps/introduction/ ➢ SRE を成功させるには、まず計画を立てることが大事 | Google Cloud Blog ○ https://cloud.google.com/blog/ja/products/gcp/sre-success-starts-with-getting-leadership-on-board ➢ [レポート] SREの基本と組織への導入 | DevelopersIO ○ https://dev.classmethod.jp/articles/202105-report-gcd21-d3-infra-01/ ➢ SRE Gaps「理論と実践からSREを再考する」 - YouTube ○ https://www.youtube.com/watch?v=CEn3e8JxgtY ➢ SLAに関する7つの誤解とは、Uptime.comが解説：ダウンタイムはゼロにはならない - ＠IT ○ https://www.atmarkit.co.jp/ait/articles/2102/26/news117.html ➢ SLI, SLOとカオスエンジニアリング、そしてオブザーバビリティ SRE Lounge #12 - Speaker Deck ○ https://speakerdeck.com/katzchang/sli-slotokaosuenziniaringu-sositeobuzababiritei-sre-lounge-number-12

100 SRE (cont.) ➢ クラウド費用の最適化: 成功し続けるための諸原則 | Google Cloud Blog ○ https://cloud.google.com/blog/ja/products/gcp/cost-managementprinciples-of-cloud-cost-optimization ➢ SLO の定義 | Cloud アーキテクチャ センター ○ https://cloud.google.com/architecture/defining-SLOs ➢ Download our diagram CALMS Model of DevOps | DevOpsGroup ○ https://www.devopsgroup.com/insights/resources/diagrams/all/calms-model-of-devops/ ➢ 初めてのポストモーテム - Platinum Data Blog by BrainPad ○ https://blog.brainpad.co.jp/entry/2020/09/30/141837 ➢ SRE-iously: Defining the Principles, Habits, and Practices of Site Reliability Engineering ○ https://www.slideshare.net/newrelic/sreiously-defining-the-principles-habits-and-practices-of-site-reliability-e ngineering-112178269 ➢ The Many Shapes of Site Reliability Engineering ○ https://medium.com/slalom-build/the-many-shapes-of-site-reliability-engineering-468359866517 ➢ Incident Metrics in SRE - Google - Site Reliability Engineering ○ https://sre.google/resources/practices-and-processes/incident-metrics-in-sre/

101 可観測性・カオスエンジニアリング ➢ オブザーバビリティ（可観測性）がなぜ必要だと考えるのか - YAMAGUCHI::weblog ○ https://ymotongpoo.hatenablog.com/entry/2019/03/25/084500 ➢ New Relicを使って、アプリAPIの応答速度を10倍早くしました - GA technologies GROUP Tech Blog ○ https://tech.ga-tech.co.jp/entry/2019/09/new-relic-helps-to-improve-renosy-app ➢ カオスエンジニアリングの原則 ○ https://principlesofchaos.org/ja/ ➢ 5分で学ぶ: カオスエンジニアリングの説明書 - New Relic公式ブログ ○ https://blog.newrelic.co.jp/engineering/chaos-engineering-explained/ ➢ カオスエンジニアリングの過去と今(前編) ○ https://zenn.dev/hodagi/articles/3ce6ccdb00538c ➢ カオスエンジニアリングの過去と今(後編) ○ https://zenn.dev/hodagi/articles/abf6a20186f24a ➢ The Four Golden Signals - Google - Site Reliability Engineering ○ https://sre.google/sre-book/monitoring-distributed-systems/#xref_monitoring_golden-signals

102 事例・参考 ➢ 突撃！隣のDevOps 【リブセンス編】 | DevelopersIO ○ https://dev.classmethod.jp/articles/devops-livesense/ ➢ HTB北海道テレビ放送｜水曜どうでしょう祭ライブ配信の技術支援｜クラスメソッドの事例 ○ https://classmethod.jp/cases/htb/ ➢ FMEA(故障モード影響解析)とは？評価法や実際の流れを解説 | 金属加工の見積りサイトMitsuri（ミ ツリ） ○ https://mitsu-ri.net/articles/fmea_toha ➢ 【CEDEC 2021】『NieR Re[in]carnation』における負荷試験の効果的な運用方法とは　技術・チー ムの両面から実践内容を紹介 | gamebiz ○ https://gamebiz.jp/news/333021 ➢ サービス・ドミナント・ロジック：先進企業事例に見る「価値づくり」の世界観 | 価値共創が生み出 す競争優位の源泉(1/2)｜DIAMOND ハーバード・ビジネス・レビュー ○ https://www.dhbr.net/articles/-/2698 ➢ [レポート] AmazonのCTOはAWS re:Invent 2020のキーノートでどう語ったか？ | DevelopersIO ○ https://dev.classmethod.jp/articles/202012-report-reinvent-keynote-observability/ ➢ 企業活動におけるCAPEXとOPEXの定義 | クラウドERP実践ポータル ○ https://www.clouderp.jp/blog/what-is-capex-opex ➢ 鏡の国のアリス Through the Looking Glass: Japanese ○ https://www.genpaku.org/alice02/alice02j.html

セッション後は、チャット欄のURL、または下記QRコードより アンケートへのご協力をお願いいたします。 SNS投稿にはこちらをお使いください：#devio2021 https://forms.gle/sp41fP9i9AzjZbmr5 15:20-16:05 40分+で分かった気になる SREのミッションとゆかいなSaaSの仲間たち Mission and Alliance for SRE in 40 (or more) minutes 」 Q&A Q&A

No content