サービスと組織の拡大を支えるEmbedded SREs

1
サービスと組織の拡大を支えるEmbedded
SREs
k-oguma(@ktykogm)

View Slide

2
Twitter ID の付け方を失敗した人。
0gm (@ktykogm)
% whoami

View Slide

3
% cd ${MS} && pwd
Microservices Platform team
Microservices SRE team
Microservices Dev team Monolith Dev team
Core SRE team
Monolith
Microservice Microservice Microservice
Mercari JP SRE team
Microservices Dev team

View Slide

4
SREの概要
今回伝えたいこと
SLO設計と運用の勘所
02
01
Embedded SREs を導入して何を得て何を失うか
04
MicroservicesとSREの関係
03

View Slide

5
SRE は開発組織全体で取り組むべきことである
今回覚えてほしいことは3つ
SLOはCUJを軸に考える
サイロの本質を見極めたEmbedded SREs の採
用は合理的である
02
03
01

View Slide

6
SREの概要
最初に簡単な用語の定義からしておきます。
SREとSREs。
SREはご存知のとおりですが、おさらいを兼ねて後ほど少し説明します。
SREsはSREの専門家、専門的に行うエンジニアを指しています。
SREs are engineers
https://sre.google/sre-book/preface/

View Slide

7
SRE本から抜粋
SREという言葉の提唱者であり、Googleの常時稼働運用担当バイスプレジデントの
Ben Treynor Slossは、信頼性こそがあらゆるプロダクトの基本的な機能だと考えて
います。誰も使えないシステムは、有益なものではありえません。
セキュリティの場合と同様に、信頼性についても考慮するのは早ければ早いほ
ど良いのです。

View Slide

8
SREとは何か
https://dzone.com/articles/site-reliability-engineering-sre-101-with-devops-v
SREは運用のソフトウェアアプローチです。アプリケーション開発者が SREを実践してはいけない理由はあり
ません。むしろ全エンジニア推奨です。

View Slide

9
サービスと組織の拡大を支えるEmbedded SREs

View Slide

10
CUJを取り入れてください。
CUJとは、Critical User Journey のことで、次のような意味です。
究極的にはSLOの主眼は顧客体験の改善であるべきです。
したがって、SLOはユーザーを中心に置くアクションについて書かれるべきです。
サイトリライアビリティワークブックより。

View Slide

11
顧客体験のストーリーを考えます。
※「商品を探す」、「購入を完了する」など
考えるための材料は、シーケンス図やDesignDoc、ドメインモデル図などあるものを
使ってください。
なければコードから読み解くか、既にdev版でもアプリがあるなら実際に触って確認し
てください。
そこからSLI -> SLO と設計を落とし込んでいきます。

View Slide

12
CUJを軸に分析すると、重大イベントの計測が足りていないことに気がつく場合があ
ります。
またCUJを考えると、重要度の段階付けも出来るようになります。
全てのリクエストの重要度が同等ではないはずです。
比べるとどちらのほうが重要であるかCUJからも見えてきます。

View Slide

13
CUJが考慮されずにSLO 設計された場合、ほとんど（もしくは全て）が同じ閾値にな
るケースがあります。
すると、なにが起きるでしょうか。
gRPC service gRPC method Latency Uptime percentage
Foo Get 50ms 99.99%
Foo Buy 50ms 99.99%
Bar ListItems 50ms 99.99%
Bar ListBoughtItems 50ms 99.99%

View Slide

14
不必要なアラートが頻発したり、翌日の日勤時間帯の対応で良いものなのに夜中に
電話が鳴って起こされたりします。
また、逆に重要なリクエストに対するSLOが緩く、問題に気がつくのが遅れます。

View Slide

15
依存関係もCUJから考えます。
依存関係は内部の他のサービスだけではなく、外部サービスなど各種コンポーネント
になります。
それらの依存コンポーネントの公開されたSLA、SLOにこちらのSLOを合わせる必要
があります。
それらがユーザージャーニーで求められる基準を下回るSLOの場合は対策を考える
必要が出てきます。

View Slide

16
SLOに基づくアラート
目標は、「重大なイベント」のアラート通知を受けることです。
逆に重大ではないイベントでも発生するたびにアラート通知が来ていては集中力や
時間を奪われます。
SLOが全て正しく設定できている場合:
「SLO違反」もしくは「エラーバジェットが枯渇しそうな傾向がある」際に通知を飛ばす
ようにすれば、それが「重大イベント」のみ通知されることと理論上同等になるはずで
す。
いわゆるSLOベース運用です。

View Slide

17
SLOベース運用におすすめ
基本的には「複数ウィンドウ、複数バーンレート」のアラートが推奨です。
バーンレートはエラーバジェットの燃焼率を計測し、複数のバーンレートと複数のウィ
ンドウを重ねることでより精度を上げています。

View Slide

18
SLO バーンレートアラートの注意点
低トラフィックのサービスだとすぐにバーンレートアラートが来てしまう問題がありま
す。
これは、たまにしかリクエストが来ないようなエンドポイントの監視でよく発生します。
例えば、1時間に10リクエストしか受信しない場合、わずか1回でも失敗すると1時間の
中で10% のエラーとなり、それが閾値を上回っていればバーンレートアラートが発生
します。

View Slide

19
SLO バーンレートアラートで起きる問題の回避方法
● Botを作ってトラフィックを生成してお茶を濁す
● サービスを組み合わせてそれを重大なイベントとして計測するようにSLOの対象
を切り替える
● サービスとインフラに対する変更
○ 例: Exponential backoff retry, fallback
● SLOの引き下げ
● ウィンドウの拡大
SLOバーンレートアラートおすすめです。

View Slide

20
SLO設計と運用の勘所まとめ
● CUJを軸に設計する
● SLI/SLOに重要度の段階を設ける
● アラートはSLOベースにする
○ SLOバーンレートアラートが良い
■ とくに複数のウィンドウと複数のバーンレートで設定するのが推奨
■ 低トラフィックのリクエスト監視には要注意

View Slide

21
何故Microservicesなのか
Embedded SREsの話に移る前にMicroservicesの存在理由も簡単に説明する
必要があります。
最初に紹介しておきますと、だいたいのことは以下に書かれています。
https://microservices.io/patterns/microservices.html
では、Microservicesを採用する具体的な理由はなんでしょうか。

View Slide

22
● サービスの急拡大に開発が追いつけるよ
うにするため？
● Two Pizza (約8名規模）の小さな独立
チームを多数編成し、効率良く開発させる
ため？
● リリース頻度を上げるため？
● デプロイに対する恐怖を減らしたい？
● 「一つのことを上手くやる」ため？
● コミュニケーションコストを下げるため？
● 構成管理負担を減らすため？
● 対障害性を高めるため？
● 新しいテクノロジースタックを採用し続け
ていくため？
● サービスごとにDBを分割させるため？
● 開発者が運用もするため？
● 採用に繋げたいため？
● スキルを高めるため？

View Slide

23
2011年5月、Microservices という言葉が無い時代にこれら一部の課題解決のため
のアーキテクチャが議論され始め、2012年のJavaのカンファレンスで James Lewis
氏が具体的な事例を発表したとMicroservices 提唱者の Martin Fowler 氏のブ
ログに書かれています。
そのスライドの中には「短期間でサービスの急拡大の依頼をされた際に従来のやり
方ではとても厳しいため採用した」というような内容で書かれています。（私個人の意
訳です）

View Slide

24
特に重要な点としては Microservices は組織論でもあることです。
小さなサービスとして多数に分けて（decouple）、そのサービスごとにチームを編成
していく。（逆コンウェイの法則）
何が嬉しいのか:
全ての他のサービスを気にしながら慎重に開発してきたMonolith アーキテクチャか
ら脱却が出来る。

View Slide

25
Microservicesは万能ではない
CAUTION! 万能ではなく目的特化型です。
トレードオフで例えば欠点もあるので、不必要に採用しないほうが良いです。
● テストが難しくなる
● サービス間連携が慎重になる
● 分散トランザクションが必要になる
● 運用難易度が上がる
しかし、年数が経つにつれて成熟しているものもあり、その欠点は小さくなっていっている傾
向にあります。
● デプロイが複雑になる
● 運用コストが上がる
● オーバーヘッドが増加

View Slide

26
MicroservicesとSREの
関係

View Slide

27
Microservicesになると、多くの小さな開発チームが作られま
す。
Microservices teams
問題が顕在化しにくくなる「サイロ化問題」
多数あるMicroservices開発チーム全てに隠れた信頼性課題を見つけていくのは至難の業

View Slide

28
そもそも何故チームは小さいほうが有利なのか
それはメンバーが増えれば増えるほど生産性が低下する相関関係があり、モチベー
ションやチーム内での調整の損失が増えるとされるリンゲルマン効果やブルックス効
果の問題を防ぐためです。

View Slide

29
チームを増やしたらサイロが増えるのは当然では？
※ ここからは途中までは会社ではなく私個人の見解です。
サイロ自体は悪いものではありません。
Slackがサイロについて書かれた複数の書籍を基に記事を出していて、次のように述
べられています。

View Slide

30
サイロは悪なのか
サイロでの作業は絶対に避けるべきものではない。
サイロでの作業は共同作業よりも自然で、それは部族の考え方です。
サイロを横切るのは不自然な行為です。
専門化が進みサイロ化が進むのは必然的な問題である。
サイロでの作業は共同作業よりも自然です。本当の問題は「サイロが分断」されてし
まうことです。（意訳）

View Slide

31
サイロは自然で必然的でもある
また、SRE {wook}book instigator のNiall Murphy氏も SREcon21 にて、この
ようなことを言っています。
縦割りのサイロに横串を入れるのは難しい。Googleでも他のところでもサイロがな
いということではありません。どこにでもあります。（意訳）
10:24付近

View Slide

32
チームを増やしたらサイロが増えるのは当然では？
● サイロを横切る行為こそ不自然
● サイロは必然的である
先程説明した、「何故、小さいチームは有利なのか」のリンゲルマン効果やブルックス
効果との関係性があるように見えませんか？

View Slide

33
Microservicesの本質は何か
見方を変えるとMicroservices は、
「サイロになることをわかった上で上手に利用しようとしている」ように見えます。
Monolith
Microservices teams

View Slide

34
Microservicesの本質は何か
すなわち「疎結合」は、「サイロを上手に結合させる」ことと同義
● サイロ != 悪
● 悪い
○ サイロが分断したまま
○ 問題が顕在化できない
● 良い
○ サイロで効率化を図る
○ サイロで安全性を保つ

View Slide

35
サイロに対し、「見える化」を図るには
「見える化」、問題意識の個人差を無くすためにもSLI/SLOという重要指標がありま
す。
しかし「それら全てのSLOsは正しい設計に常になっているか」は外からでは、なかな
か分かりません。

View Slide

36
問題の顕在化率
https://www.xeex.co.jp/shishifunjin/text/201005.html

View Slide

37
サイロに対し、「見える化」を図るには
「だったらそのサイロに飛び込んで、直接課題を見つけて解決させていってしまうのが
最適である」という解釈も出来るわけです。
それがEmbedded SREsだと私は理解しています。

View Slide

38
「見える化」以外のEmbedded する理由
「見える化」の他に「SREがCatalyst（触媒）となる」ことが重要です。
SREsは必ずしもインシデントを解決するわけではありませんが、SREのベストプラク
ティスがプロセス全体を通して確実に守られるようにするためのCatalyst（触媒）とな
ります。（意訳）

View Slide

39
[参考] 逆にEmbedded SREsをしないほうが良いケースはど
のようなときか
例えばGoogle SREではEmbedded SREsは行っていないそうです。
https://youtu.be/DOQqOrHs3VY?t=411
上記のGOTOcon というイベントの How Google SRE and Developers Work Together • Christof
Leng • GOTO 2021 で、6:50あたりからそれについて言及されています。

View Slide

40
参考: Google SREの組織
● Google SREの体制を整理
○ プロダクトごとにSREチームが存在する
○ 大陸ごとにチームが別れていて24時間オンコール体制
○ グループ化されたレポート階層がある

View Slide

41
何故Google SREは Embeddedしないのか
ここでは次のようなことが説明されています。
Embeddedしない理由:「信頼性は忘れがち」になるから。
「大きなローンチが控えている場合、簡単に忘れてしまう可能性があります。」「ソフト
ウェアのテストと同じようにリリース後へと後回しになったりして、それを繰り返し手遅
れになってから信頼性を軽視していたことに気づくわけです。」（意訳）

View Slide

42
Google と同じようにEmbeddedしないほうが良いのか
AWSでは逆にSREチームが無く、全てEmbedded SREsとなっていると言われて
います。
それは開発チームが運用も全て責任を見るOwnershipの考えがあります。
https://youtu.be/vhmmxJdykX4?t=2570

View Slide

43
Embedded SREs への理解
SREsやSREを実践する側（サービス開発者、マネージャー、CTO）が「なんのために
必要なのか」を理解していて説明できることが重要です。
そして、サービス開発チームへの参加前に理解しておいてもらいたいのはメリットだけ
ではありません。
サービス開発チームにとって、デメリットに見える部分もあります。

View Slide

44
Embedded SREs への理解
Embedded 先のサービス、開発チームが「真っ先に検証や導入ターゲットとなりや
すい」、そしてその際は他のチームに比べて一番負担がかかるときはあります。
しかしそれはデメリットだけではないはずです。

View Slide

45
Embedded SREs の準備
「そんなにSREs沢山いないよ」と思われているかも知れません。
「SREsはスケールしない」、「SREsを増やしたいが無闇に開発者と同じ数だけ増える
のはよくない」と以前から度々議論に出ていました。
しかしSREは増加させることが可能です。

View Slide

46
Embedded SREsでSREを増やす
SREは、最初に説明したとおり「誰もが行うことが推奨されるもの」です。
セキュリティやテストと同じく、専門家以外でも開発者のスキルに合わせて対応できる
範囲が広まっていきます。
普及するばするほど、専門家はより専門的な活動に集中できるように。
各サービス開発チームでSREの自走レベルが上がればSREsが少なくても会社全体
のサービスの信頼性を上げることが可能です。

View Slide

47
少人数でEmbedded SREsを始めるコツ
「渡り鳥のように開発チームを移っていくスタイル」を採用することで、社内全体の
SREを底上げしていくことが可能となります。
残念ながらこのスタイルは正式な名前がまだ無いようです。
便宜上、この資料では「Movable Embedded SREs (可動組み込みSREs)」としま
す。

View Slide

48
どのようにMovable Embedded SREsを行うか
横断的なSREチームが存在するケースで考えてみます。
1. 1-2名が数ヶ月間SREチームから抜けることが可能な状態か考察し、候補メン
バーを選出します
2. 候補メンバーのスキルセットを把握します
3. Embedded 先のサービス候補を出します
4. サービス開発チーム側に期間限定でSREサポート参加の提案をします
5. 合意が得られれば Embedded の開始です
（上記はメルカリの実情ではありません。それはこのあと説明します）

View Slide

49
SREの課題が多くあるサービス開発チームの見つけ方
見つける方法としては次のようなものが考えられます。
優先順は次のとおりになると考えています。
「信頼性に関わる重大な問題が溜まっている」 > 「サービスの重要度」 > 「計測結果」
> 「サーベイ」
要するに明確な問題を基準にした isssue drivenを最優先に考えています。

View Slide

50
1. 信頼性に関わる重大な問題が溜まっているサービスを探す
a. 案: 問題管理（ITIL, 恒久対策タスク）からSeverity Levelの高い未解決タスク数を計測する
2. サービスの重要度から探す
3. 計測結果から探す
a. SLO違反数
b. バーンレートアラート数
c. Error budgetの低下
d. インシデント発生数
e. デプロイ数
f. お客様からの問い合わせ数
g. 性能低下傾向やエラー数を見る
h. etc
4. サーベイで見つける
画像は現在作成中のDatadog「SRE課題計測」ダッシュボード
(試せていないけど、インシデントとPostmortemの管理をDatadogに移行すれば、そのまま課題計測ダッシュボードに使えそう）

View Slide

51
1. 信頼性に関わる重大な問題が溜まっているサービスを探す
a. 案: 問題管理（ITIL, 恒久対策タスク）からSeverity Levelの高い未解決タスク数を計測する
2. サービスの重要度から探す
3. 計測結果から探す
a. SLO違反数
b. バーンレートアラート数
c. Error budgetの低下
d. インシデント発生数
e. デプロイ数
f. お客様からの問い合わせ数
g. 性能低下傾向やエラー数を見る
h. etc
4. サーベイで見つける
https://sre.google/workbook/implementing-slos/#dashboards-and-reports

View Slide

52
メルカリSREの実情

View Slide

53
メルカリはEmbedded + SRE team(Like a Base camp)
のHybrid + Movable型
企業 SREsの体制特徴
Google Pure SRE team Siloを理解しているからこそ、いかに SRE
team <-> Dev teamで上手くコミュニケーショ
ンを図るかを含めて SLOを提唱しています。
AWS Embedded SREs 「You Build It, You Run It」を提唱していま
す。
よって、SRE teamは存在していないと明言さ
れています。
Mercari (Hybrid type)
Movable Embedded SREs
+ Base camp
可動型（非固定）でサービス開発に組み込ま
れるSREs 且つBase camp的なチームも存
在しています。

View Slide

54
メルカリにおけるMovable Embedded SREs
1. Embedded SREs用のインセプションデッキを作成
2. SREs の参加が必要な開発チームを見つける
3. インセプションデッキを使って開発チームにSREサポートを提案
4. 開発チームに期間限定で参加する
5. SREに必要なことは全てやる（伝えていくことも重要な使命）
6. 各種EcosystemやToolの導入などを行う
7. そのチームに合った新しいことにチャレンジする
8. Goalを決め抜ける
9. 1Qくらい空ける
10. 1に戻る

View Slide

55
SRE が上手く行っていることをどうやって知るのか
我々が当初考えた候補は次のとおりです。
● 課題チケット管理システムで集計する（例: SP）
● 課題目標やOKRの達成度で見る
しかし、ベロシティ = SRE満足度とは限らないので、我々は満足度を計測するために
次のことを実施しました。
● チームに参加して最初の4半期が過ぎた時にサーベイ
● チームを抜ける時にサーベイ
● 360度評価でも評価を確認

View Slide

56
Embedded SREsを導入
して何を得て何を失うか

View Slide

57
Embedded SREsを導入して何が得られるか
● SREの普及状況の把握
● 外からは見えない問題を見つける
○ SRE課題の発見
○ DX課題の発見
個人的に感じたメリット:
● 現在行われているサービス開発の知識を直接得られる
○ スキルアップにもつながる
○ 部分的にコンフォートゾーンからの脱却にもなる

View Slide

58
Embedded SREs を導入して何を失ったか
SREsが裁量で行える範囲は減りました。（サービス開発チームへの参加になったた
め）
それと失ったのは時間。※これはメルカリの特別な事情もあります。Hybrid型 + 引き継ぎタスクが残っているからと
いう理由が大きいです。でも調整可能なことが多い
メルカリSREチーム（現2チーム）内の連携は大分減りました。（毎日やりとりするメン
バーは直属のSREs以外です）※ただし、問題は発生していません

View Slide

59
Embedded SREs として、苦労や失敗したこと
● 最初は認知負荷が高い
○ ドメイン知識を含めてサービス開発知識もある程度は必要
● マルチアーキテクチャー且つ移行中の場合に起きること
○ Monolith環境向けとの並行作業
○ 大きなインシデントが発生するとそちらに時間を取られる
○ ドメイン/開発知識 + マルチアーキテクチャー + システム移行によりさらに認
知負荷が高まる
● サービス開発者にわかりやすい説明を行う準備が不足していた

View Slide

60
まとめ
● SREは開発組織全体で実践していく
● SLOはCUJを軸に考える
● Microservicesの数が増えればサイロも増える
○ サイロ自体は悪くないが、分断が強いと悪い
● サイロの本質を理解する
○ 必要であればEmbedded SREsを採用する
● SREsが足りないならMovable Embedded SREs という方法もある
● 苦労よりも得られるもののほうが大きい（+トイルは減らす事が出来ます）

View Slide

61
参考
● https://sre.google/books/
● https://cloud.google.com/architecture/defining-SLOs
● https://sre.google/workbook/implementing-slos/
● https://slack.com/intl/ja-jp/blog/collaboration/ways-sidestep-working-in-silos
● https://www.salesforce.com/products/sales-cloud/resources/breaking-the-silo-mentality/
● https://zapier.com/blog/organizational-silos/
● https://www.blameless.com/sre/blameless-sre-journey
● https://martinfowler.com/articles/microservices.html
● http://2012.33degree.org/pdf/JamesLewisMicroServices.pdf
● https://microservices.io/patterns/microservices.html
● https://aws.amazon.com/jp/blogs/news/two-pizza-teams-are-just-the-start-accountability-and-empowerment-are-key-to-high
-performing-agile-organizations-part-1-jp/
● https://www.career-adv.jp/recruit_info/career/275/
● https://www.xeex.co.jp/shishifunjin/text/201005.html
● https://www.blameless.com/sre/blameless-sre-journey
● https://youtu.be/DOQqOrHs3VY
● https://cloud.google.com/blog/products/gcp/consequences-of-slo-violations-cre-life-lessons
● https://youtu.be/vhmmxJdykX4

View Slide

サービスと組織の拡大を支えるEmbedded SREs

サービスと組織の拡大を支えるEmbedded SREs

ktykogm

More Decks by ktykogm

Featured

Transcript