Mission and Alliance for SRE in 40 (or more) minutes

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

View Slide

SREしてますか！

View Slide

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

View Slide

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

View Slide

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

View Slide

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

View Slide

1. SREと「信頼性」

View Slide

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

View Slide

「信頼性（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

View Slide

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

View Slide

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

View Slide

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

View Slide

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

View Slide

本当にユーザーは時間に厳しくなったか？
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

View Slide

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

View Slide

「速いは正義」という時代
「赤の女王」仮説
● 開発速度 ≒ 変化する/変化に対応する速度
● 処理性能(レスポンスタイム)の速さ
資本主義は「赤の女王」である – アゴラ
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
“ここではだね、
同じ場所にとどまるだけで、
もう必死で走らなきゃいけないんだよ”
ルイス・キャロル “鏡の国のアリス”

View Slide

参考：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

View Slide

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

View Slide

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

View Slide

ヒント : 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

View Slide

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

View Slide

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

View Slide

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

View Slide

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

View Slide

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

View Slide

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

View Slide

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

View Slide

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

View Slide

余録：「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 = 悲歌、哀歌）
SREであることを自覚するのは…… (抜粋)
・最初の質問として「それをどのように計測していますか」が口をついて出る時
・自分の個人ブログが複数のAWSリージョン障害にも耐えられる時
・決まりきった運用作業を自動化するという根拠でロボット掃除機の購入を
　正当化する時
・利用している電力会社のSLOがどのようなものか気になる時

View Slide

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

View Slide

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

View Slide

2. SREのミッション

View Slide

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

View Slide

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

View Slide

35
SREの手法のでよくふれられるところ

View Slide

36
ここに注目

View Slide

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

View Slide

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

View Slide

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

View Slide

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

View Slide

3. SREの始め方

View Slide

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

View Slide

いろいろな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/

View Slide

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

View Slide

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

View Slide

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

View Slide

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で大切でないはずがありません

View Slide

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

View Slide

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

View Slide

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

View Slide

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

View Slide

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

View Slide

可用性の維持と計測

View Slide

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

View Slide

エラー予算（エラーバジェット）という考え方
● サイトを変化させるために利用できる「予算」
○ リリースによる計画停止、見込み不具合
○ 発生した障害の回復に必要とした時間（自動・手動）
● 設定したウィンドウ(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

View Slide

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

View Slide

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

View Slide

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

View Slide

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

View Slide

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

View Slide

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

View Slide

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

View Slide

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

View Slide

監視ではだめなんですか？
“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

View Slide

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

View Slide

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

View Slide

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

View Slide

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

View Slide

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

View Slide

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

View Slide

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

View Slide

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

View Slide

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

View Slide

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

View Slide

Gremlin　　とAWS FIS
Gremlin
カオスエンジニアリングの先駆者
AWS FIS(Fault Injection Simulator)
W-A「信頼性の柱」
○ 創業者のコルトンCEOは元Netﬂix
（その前はAWS）
○ カオスエンジニアリングはNetﬂixが発祥
（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インフラに対する障害注入実験が可能

View Slide

コストコントロール

View Slide

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

View Slide

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

View Slide

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

View Slide

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

View Slide

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

View Slide

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

View Slide

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

View Slide

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

View Slide

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

View Slide

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

View Slide

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

View Slide

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

View Slide

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

View Slide

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

View Slide

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

View Slide

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

View Slide

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

View Slide

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

View Slide

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

View Slide

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

View Slide

Appendix

View Slide

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

View Slide

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-eﬀectiveness/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

View Slide

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/

View Slide

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

View Slide

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

View Slide

セッション後は、チャット欄の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

View Slide

View Slide

Mission and Alliance for SRE in 40 (or more) minutes

Mission and Alliance for SRE in 40 (or more) minutes

Seigo Watanabe

More Decks by Seigo Watanabe

Featured

Transcript