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

SRE Lounge #13 での発表資料です。
https://sre-lounge.connpass.com/event/227250/

Transcript

1. 1 サービスと組織の拡大を支えるEmbedded SREs k-oguma(@ktykogm)
2. 2 Twitter ID の付け方を失敗した人。 0gm (@ktykogm) % whoami
3. 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
4. 4 SREの概要 今回伝えたいこと SLO設計と運用の勘所 02 01 Embedded SREs を導入して何を得て何を失うか 04 MicroservicesとSREの関係 03
5. 5 SRE は開発組織全体で取り組むべきことである 今回覚えてほしいことは3つ SLOはCUJを軸に考える サイロの本質を見極めたEmbedded SREs の採 用は合理的である 02 03 01
6. 6 SREの概要 最初に簡単な用語の定義からしておきます。 SREとSREs。 SREはご存知のとおりですが、おさらいを兼ねて後ほど少し説明します。 SREsはSREの専門家、専門的に行うエンジニアを指しています。 SREs are engineers https://sre.google/sre-book/preface/
7. 7 SRE本から抜粋 SREという言葉の提唱者であり、Googleの常時稼働運用担当バイスプレジデントの Ben Treynor Slossは、信頼性こそがあらゆるプロダクトの基本的な機能だと考えて います。誰も使えないシステムは、有益なものではありえません。 セキュリティの場合と同様に、信頼性についても考慮するのは早ければ早いほ ど良いのです。
8. 8 SREとは何か https://dzone.com/articles/site-reliability-engineering-sre-101-with-devops-v SREは運用のソフトウェアアプローチです。アプリケーション開発者が SREを実践してはいけない理由はあり ません。むしろ全エンジニア推奨です。
9. 9 サービスと組織の拡大を支えるEmbedded SREs SLO設計と運用の勘所
10. 10 SLO設計と運用の勘所 CUJを取り入れてください。 CUJとは、Critical User Journey のことで、次のような意味です。 究極的にはSLOの主眼は顧客体験の改善であるべきです。 したがって、SLOはユーザーを中心に置くアクションについて書かれるべきです。 サイトリライアビリティ ワークブックより。
11. 11 SLOはCUJを軸に考える 顧客体験のストーリーを考えます。 ※「商品を探す」、「購入を完了する」など 考えるための材料は、シーケンス図やDesignDoc、ドメインモデル図などあるものを 使ってください。 なければコードから読み解くか、既にdev版でもアプリがあるなら実際に触って確認し てください。 そこからSLI -> SLO と設計を落とし込んでいきます。
12. 12 SLOはCUJを軸に考える CUJを軸に分析すると、重大イベントの計測が足りていないことに気がつく場合があ ります。 またCUJを考えると、重要度の段階付けも出来るようになります。 全てのリクエストの重要度が同等ではないはずです。 比べるとどちらのほうが重要であるかCUJからも見えてきます。
13. 13 SLOはCUJを軸に考える 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%
14. 14 SLOはCUJを軸に考える 不必要なアラートが頻発したり、翌日の日勤時間帯の対応で良いものなのに夜中に 電話が鳴って起こされたりします。 また、逆に重要なリクエストに対するSLOが緩く、問題に気がつくのが遅れます。
15. 15 SLOはCUJを軸に考える 依存関係もCUJから考えます。 依存関係は内部の他のサービスだけではなく、外部サービスなど各種コンポーネント になります。 それらの依存コンポーネントの公開されたSLA、SLOにこちらのSLOを合わせる必要 があります。 それらがユーザージャーニーで求められる基準を下回るSLOの場合は対策を考える 必要が出てきます。
16. 16 SLOに基づくアラート 目標は、「重大なイベント」のアラート通知を受けることです。 逆に重大ではないイベントでも発生するたびにアラート通知が来ていては集中力や 時間を奪われます。 SLOが全て正しく設定できている場合: 「SLO違反」もしくは「エラーバジェットが枯渇しそうな傾向がある」際に通知を飛ばす ようにすれば、それが「重大イベント」のみ通知されることと理論上同等になるはずで す。 いわゆるSLOベース運用です。
17. 17 SLOベース運用におすすめ 基本的には「複数ウィンドウ、複数バーンレート」のアラートが推奨です。 バーンレートはエラーバジェットの燃焼率を計測し、複数のバーンレートと複数のウィ ンドウを重ねることでより精度を上げています。
18. 18 SLO バーンレートアラートの注意点 低トラフィックのサービスだとすぐにバーンレートアラートが来てしまう問題がありま す。 これは、たまにしかリクエストが来ないようなエンドポイントの監視でよく発生します。 例えば、1時間に10リクエストしか受信しない場合、わずか1回でも失敗すると1時間の 中で10% のエラーとなり、それが閾値を上回っていればバーンレートアラートが発生 します。
19. 19 SLO バーンレートアラート で起きる問題の回避方法 • Botを作ってトラフィックを生成してお茶を濁す • サービスを組み合わせてそれを重大なイベントとして計測するようにSLOの対象 を切り替える • サービスとインフラに対する変更 ◦ 例: Exponential backoff retry, fallback • SLOの引き下げ • ウィンドウの拡大 SLOバーンレートアラートおすすめです。
20. 20 SLO設計と運用の勘所まとめ • CUJを軸に設計する • SLI/SLOに重要度の段階を設ける • アラートはSLOベースにする ◦ SLOバーンレートアラートが良い ▪ とくに複数のウィンドウと複数のバーンレートで設定するのが推奨 ▪ 低トラフィックのリクエスト監視には要注意
21. 21 何故Microservicesなのか Embedded SREsの話に移る前にMicroservicesの存在理由も簡単に説明する 必要があります。 最初に紹介しておきますと、だいたいのことは以下に書かれています。 https://microservices.io/patterns/microservices.html では、Microservicesを採用する具体的な理由はなんでしょうか。
22. 22 何故Microservicesなのか • サービスの急拡大に開発が追いつけるよ うにするため？ • Two Pizza (約8名規模）の小さな独立 チームを多数編成し、効率良く開発させる ため？ • リリース頻度を上げるため？ • デプロイに対する恐怖を減らしたい？ • 「一つのことを上手くやる」ため？ • コミュニケーションコストを下げるため？ • 構成管理負担を減らすため？ • 対障害性を高めるため？ • 新しいテクノロジースタックを採用し続け ていくため？ • サービスごとにDBを分割させるため？ • 開発者が運用もするため？ • 採用に繋げたいため？ • スキルを高めるため？
23. 23 何故Microservicesなのか 2011年5月、Microservices という言葉が無い時代にこれら一部の課題解決のため のアーキテクチャが議論され始め、2012年のJavaのカンファレンスで James Lewis 氏が具体的な事例を発表したとMicroservices 提唱者の Martin Fowler 氏のブ ログに 書かれています。 そのスライドの中には「短期間でサービスの急拡大の依頼をされた際に従来のやり 方ではとても厳しいため採用した」というような内容で書かれています。（私個人の意 訳です）
24. 24 何故Microservicesなのか 特に重要な点としては Microservices は組織論でもあることです。 小さなサービスとして多数に分けて（decouple）、そのサービスごとにチームを編成 していく。（逆コンウェイの法則） 何が嬉しいのか: 全ての他のサービスを気にしながら慎重に開発してきたMonolith アーキテクチャか ら脱却が出来る。
25. 25 Microservicesは万能ではない CAUTION! 万能ではなく目的特化型です。 トレードオフで例えば欠点もあるので、不必要に採用しないほうが良いです。 • テストが難しくなる • サービス間連携が慎重になる • 分散トランザクションが必要になる • 運用難易度が上がる しかし、年数が経つにつれて成熟しているものもあり、その欠点は小さくなっていっている傾 向にあります。 • デプロイが複雑になる • 運用コストが上がる • オーバーヘッドが増加
26. 26 サービスと組織の拡大を支えるEmbedded SREs MicroservicesとSREの 関係
27. 27 Microservicesになると、多くの小さな開発チームが作られま す。 Microservices teams 問題が顕在化しにくくなる「サイロ化問題」 多数あるMicroservices開発チーム全てに隠れた信頼性課題を見つけていくのは至難の業
28. 28 そもそも何故チームは小さいほうが有利なのか それは メンバーが増えれば増えるほど生産性が低下する相関関係があり、モチベー ションやチーム内での調整の損失が増えるとされるリンゲルマン効果 やブルックス効 果 の問題を防ぐためです。
29. 29 チームを増やしたらサイロが増えるのは当然では？ ※ ここからは途中までは会社ではなく私個人の見解です。 サイロ自体は悪いものではありません。 Slackがサイロについて書かれた複数の書籍を基に記事を出していて、次のように述 べられています。
30. 30 サイロは悪なのか サイロでの作業は絶対に避けるべきものではない。 サイロでの作業は共同作業よりも自然で、それは部族の考え方です。 サイロを横切るのは不自然な行為です。 専門化が進みサイロ化が進むのは必然的な問題である。 サイロでの作業は共同作業よりも自然です。本当の問題は「サイロが分断」されてし まうことです。（意訳）
31. 31 サイロは自然で必然的でもある また、SRE {wook}book instigator のNiall Murphy氏も SREcon21 にて、この ようなことを言っています。 縦割りのサイロに横串を入れるのは難しい。Googleでも他のところでもサイロがな いということではありません。どこにでもあります。（意訳） 10:24付近
32. 32 チームを増やしたらサイロが増えるのは当然では？ • サイロを横切る行為こそ不自然 • サイロは必然的である 先程説明した、「何故、小さいチームは有利なのか」のリンゲルマン効果やブルックス 効果との関係性があるように見えませんか？
33. 33 Microservicesの本質は何か 見方を変えるとMicroservices は、 「サイロになることをわかった上で上手に利用しようとしている」ように見えます。 Monolith Microservices teams
34. 34 Microservicesの本質は何か すなわち「疎結合」は、「サイロを上手に結合させる」ことと同義 • サイロ != 悪 • 悪い ◦ サイロが分断したまま ◦ 問題が顕在化できない • 良い ◦ サイロで効率化を図る ◦ サイロで安全性を保つ
35. 35 サイロに対し、「見える化」を図るには 「見える化」、問題意識の個人差を無くすためにもSLI/SLOという重要指標がありま す。 しかし「それら全てのSLOsは正しい設計に常になっているか」は外からでは、なかな か分かりません。
36. 36 問題の顕在化率 https://www.xeex.co.jp/shishifunjin/text/201005.html
37. 37 サイロに対し、「見える化」を図るには 「だったらそのサイロに飛び込んで、直接課題を見つけて解決させていってしまうのが 最適である」という解釈も出来るわけです。 それがEmbedded SREsだと私は理解しています。
38. 38 「見える化」以外のEmbedded する理由 「見える化」の他に「SREがCatalyst（触媒）となる」ことが重要です。 SREsは必ずしもインシデントを解決するわけではありませんが、SREのベストプラク ティスがプロセス全体を通して確実に守られるようにするためのCatalyst（触媒）とな ります。 （意訳）
39. 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あたりからそれについて言及されています。
40. 40 参考: Google SREの組織 • Google SREの体制を整理 ◦ プロダクトごとにSREチームが存在する ◦ 大陸ごとにチームが別れていて24時間オンコール体制 ◦ グループ化されたレポート階層がある
41. 41 何故Google SREは Embeddedしないのか ここでは次のようなことが説明されています。 Embeddedしない理由:「信頼性は忘れがち」になるから。 「大きなローンチが控えている場合、簡単に忘れてしまう可能性があります。」「ソフト ウェアのテストと同じようにリリース後へと後回しになったりして、それを繰り返し手遅 れになってから信頼性を軽視していたことに気づくわけです。」（意訳）
42. 42 Google と同じようにEmbeddedしないほうが良いのか AWSでは逆にSREチームが無く、全てEmbedded SREsとなっていると言われて います。 それは開発チームが運用も全て責任を見るOwnershipの考えがあります。 https://youtu.be/vhmmxJdykX4?t=2570
43. 43 Embedded SREs への理解 SREsやSREを実践する側（サービス開発者、マネージャー、CTO）が「なんのために 必要なのか」を理解していて説明できることが重要です。 そして、サービス開発チームへの参加前に理解しておいてもらいたいのはメリットだけ ではありません。 サービス開発チームにとって、デメリットに見える部分もあります。
44. 44 Embedded SREs への理解 Embedded 先のサービス、開発チームが「真っ先に検証や導入ターゲットとなりや すい」、そしてその際は他のチームに比べて一番負担がかかるときはあります。 しかしそれはデメリットだけではないはずです。
45. 45 Embedded SREs の準備 「そんなにSREs沢山いないよ」と思われているかも知れません。 「SREsはスケールしない」、「SREsを増やしたいが無闇に開発者と同じ数だけ増える のはよくない」と以前から度々議論に出ていました。 しかしSREは増加させることが可能です。
46. 46 Embedded SREsでSREを増やす SREは、最初に説明したとおり「誰もが行うことが推奨されるもの」です。 セキュリティやテストと同じく、専門家以外でも開発者のスキルに合わせて対応できる 範囲が広まっていきます。 普及するばするほど、専門家はより専門的な活動に集中できるように。 各サービス開発チームでSREの自走レベルが上がればSREsが少なくても会社全体 のサービスの信頼性を上げることが可能です。
47. 47 少人数でEmbedded SREsを始めるコツ 「渡り鳥のように開発チームを移っていくスタイル」を採用することで、社内全体の SREを底上げしていくことが可能となります。 残念ながらこのスタイルは正式な名前がまだ無いようです。 便宜上、この資料では「Movable Embedded SREs (可動組み込みSREs)」としま す。
48. 48 どのようにMovable Embedded SREsを行うか 横断的なSREチームが存在するケースで考えてみます。 1. 1-2名が数ヶ月間SREチームから抜けることが可能な状態か考察し、候補メン バーを選出します 2. 候補メンバーのスキルセットを把握します 3. Embedded 先のサービス候補を出します 4. サービス開発チーム側に期間限定でSREサポート参加の提案をします 5. 合意が得られれば Embedded の開始です （上記はメルカリの実情ではありません。それはこのあと説明します）
49. 49 SREの課題が多くあるサービス開発チームの見つけ方 見つける方法としては次のようなものが考えられます。 優先順は次のとおりになると考えています。 「信頼性に関わる重大な問題が溜まっている」 > 「サービスの重要度」 > 「計測結果」 > 「サーベイ」 要するに明確な問題を基準にした isssue drivenを最優先に考えています。
50. 50 SREの課題が多くあるサービス開発チームの見つけ方 1. 信頼性に関わる重大な問題が溜まっているサービスを探す a. 案: 問題管理（ITIL, 恒久対策タスク）からSeverity Levelの高い未解決タスク数を計測する 2. サービスの重要度から探す 3. 計測結果から探す a. SLO違反数 b. バーンレートアラート数 c. Error budgetの低下 d. インシデント発生数 e. デプロイ数 f. お客様からの問い合わせ数 g. 性能低下傾向やエラー数を見る h. etc 4. サーベイで見つける 画像は現在作成中のDatadog「SRE課題計測」ダッシュボード (試せていないけど、インシデントとPostmortemの管理をDatadogに移行すれば、そのまま課題計測ダッシュボードに使えそう）
51. 51 SREの課題が多くあるサービス開発チームの見つけ方 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
52. 52 サービスと組織の拡大を支えるEmbedded SREs メルカリSREの実情
53. 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的なチームも存 在しています。
54. 54 メルカリにおけるMovable Embedded SREs 1. Embedded SREs用のインセプションデッキを作成 2. SREs の参加が必要な開発チームを見つける 3. インセプションデッキを使って開発チームにSREサポートを提案 4. 開発チームに期間限定で参加する 5. SREに必要なことは全てやる（伝えていくことも重要な使命） 6. 各種EcosystemやToolの導入などを行う 7. そのチームに合った新しいことにチャレンジする 8. Goalを決め抜ける 9. 1Qくらい空ける 10. 1に戻る
55. 55 SRE が上手く行っていることをどうやって知るのか 我々が当初考えた候補は次のとおりです。 • 課題チケット管理システムで集計する（例: SP） • 課題目標やOKRの達成度で見る しかし、ベロシティ = SRE満足度とは限らないので、我々は満足度を計測するために 次のことを実施しました。 • チームに参加して最初の4半期が過ぎた時にサーベイ • チームを抜ける時にサーベイ • 360度評価でも評価を確認
56. 56 サービスと組織の拡大を支えるEmbedded SREs Embedded SREsを導入 して何を得て何を失うか
57. 57 Embedded SREsを導入して何が得られるか • SREの普及状況の把握 • 外からは見えない問題を見つける ◦ SRE課題の発見 ◦ DX課題の発見 個人的に感じたメリット: • 現在行われているサービス開発の知識を直接得られる ◦ スキルアップにもつながる ◦ 部分的にコンフォートゾーンからの脱却にもなる
58. 58 Embedded SREs を導入して何を失ったか SREsが裁量で行える範囲は減りました。（サービス開発チームへの参加になったた め） それと失ったのは時間。※これはメルカリの特別な事情もあります。Hybrid型 + 引き継ぎタスクが残っているからと いう理由が大きいです。でも調整可能なことが多い メルカリSREチーム（現2チーム）内の連携は大分減りました。（毎日やりとりするメン バーは直属のSREs以外です）※ただし、問題は発生していません
59. 59 Embedded SREs として、苦労や失敗したこと • 最初は認知負荷が高い ◦ ドメイン知識を含めてサービス開発知識もある程度は必要 • マルチアーキテクチャー且つ移行中の場合に起きること ◦ Monolith環境向けとの並行作業 ◦ 大きなインシデントが発生するとそちらに時間を取られる ◦ ドメイン/開発知識 + マルチアーキテクチャー + システム移行によりさらに認 知負荷が高まる • サービス開発者にわかりやすい説明を行う準備が不足していた
60. 60 まとめ • SREは開発組織全体で実践していく • SLOはCUJを軸に考える • Microservicesの数が増えればサイロも増える ◦ サイロ自体は悪くないが、分断が強いと悪い • サイロの本質を理解する ◦ 必要であればEmbedded SREsを採用する • SREsが足りないならMovable Embedded SREs という方法もある • 苦労よりも得られるもののほうが大きい （+トイルは減らす事が出来ます）
61. 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