Upgrade to Pro — share decks privately, control downloads, hide ads and more …

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

ktykogm
November 19, 2021
3.2k

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

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

ktykogm

November 19, 2021
Tweet

Transcript

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

    View full-size slide

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

    View full-size slide

  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

    View full-size slide

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

    View full-size slide

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

    View full-size slide

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

    View full-size slide

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

    View full-size slide

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

    View full-size slide

  9. 9
    サービスと組織の拡大を支えるEmbedded SREs
    SLO設計と運用の勘所

    View full-size slide

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

    View full-size slide

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

    View full-size slide

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

    View full-size slide

  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%

    View full-size slide

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

    View full-size slide

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

    View full-size slide

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

    View full-size slide

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

    View full-size slide

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

    View full-size slide

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

    View full-size slide

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

    View full-size slide

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

    View full-size slide

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

    View full-size slide

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

    View full-size slide

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

    View full-size slide

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

    View full-size slide

  26. 26
    サービスと組織の拡大を支えるEmbedded SREs
    MicroservicesとSREの
    関係

    View full-size slide

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

    View full-size slide

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

    View full-size slide

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

    View full-size slide

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

    View full-size slide

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

    View full-size slide

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

    View full-size slide

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

    View full-size slide

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

    View full-size slide

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

    View full-size slide

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

    View full-size slide

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

    View full-size slide

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

    View full-size slide

  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あたりからそれについて言及されています。

    View full-size slide

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

    View full-size slide

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

    View full-size slide

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

    View full-size slide

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

    View full-size slide

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

    View full-size slide

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

    View full-size slide

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

    View full-size slide

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

    View full-size slide

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

    View full-size slide

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

    View full-size slide

  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に移行すれば、そのまま課題計測ダッシュボードに使えそう)

    View full-size slide

  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

    View full-size slide

  52. 52
    サービスと組織の拡大を支えるEmbedded SREs
    メルカリSREの実情

    View full-size slide

  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的なチームも存
    在しています。

    View full-size slide

  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に戻る

    View full-size slide

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

    View full-size slide

  56. 56
    サービスと組織の拡大を支えるEmbedded SREs
    Embedded SREsを導入
    して何を得て何を失うか

    View full-size slide

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

    View full-size slide

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

    View full-size slide

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

    View full-size slide

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

    View full-size slide

  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

    View full-size slide