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. 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
  2. 19 SLO バーンレートアラート で起きる問題の回避方法 • Botを作ってトラフィックを生成してお茶を濁す • サービスを組み合わせてそれを重大なイベントとして計測するようにSLOの対象 を切り替える •

    サービスとインフラに対する変更 ◦ 例: Exponential backoff retry, fallback • SLOの引き下げ • ウィンドウの拡大 SLOバーンレートアラートおすすめです。
  3. 20 SLO設計と運用の勘所まとめ • CUJを軸に設計する • SLI/SLOに重要度の段階を設ける • アラートはSLOベースにする ◦ SLOバーンレートアラートが良い

    ▪ とくに複数のウィンドウと複数のバーンレートで設定するのが推奨 ▪ 低トラフィックのリクエスト監視には要注意
  4. 22 何故Microservicesなのか • サービスの急拡大に開発が追いつけるよ うにするため? • Two Pizza (約8名規模)の小さな独立 チームを多数編成し、効率良く開発させる

    ため? • リリース頻度を上げるため? • デプロイに対する恐怖を減らしたい? • 「一つのことを上手くやる」ため? • コミュニケーションコストを下げるため? • 構成管理負担を減らすため? • 対障害性を高めるため? • 新しいテクノロジースタックを採用し続け ていくため? • サービスごとにDBを分割させるため? • 開発者が運用もするため? • 採用に繋げたいため? • スキルを高めるため?
  5. 23 何故Microservicesなのか 2011年5月、Microservices という言葉が無い時代にこれら一部の課題解決のため のアーキテクチャが議論され始め、2012年のJavaのカンファレンスで James Lewis 氏が具体的な事例を発表したとMicroservices 提唱者の Martin

    Fowler 氏のブ ログに 書かれています。 そのスライドの中には「短期間でサービスの急拡大の依頼をされた際に従来のやり 方ではとても厳しいため採用した」というような内容で書かれています。(私個人の意 訳です)
  6. 25 Microservicesは万能ではない CAUTION! 万能ではなく目的特化型です。 トレードオフで例えば欠点もあるので、不必要に採用しないほうが良いです。 • テストが難しくなる • サービス間連携が慎重になる •

    分散トランザクションが必要になる • 運用難易度が上がる しかし、年数が経つにつれて成熟しているものもあり、その欠点は小さくなっていっている傾 向にあります。 • デプロイが複雑になる • 運用コストが上がる • オーバーヘッドが増加
  7. 31 サイロは自然で必然的でもある また、SRE {wook}book instigator のNiall Murphy氏も SREcon21 にて、この ようなことを言っています。

    縦割りのサイロに横串を入れるのは難しい。Googleでも他のところでもサイロがな いということではありません。どこにでもあります。(意訳) 10:24付近
  8. 34 Microservicesの本質は何か すなわち「疎結合」は、「サイロを上手に結合させる」ことと同義 • サイロ != 悪 • 悪い ◦

    サイロが分断したまま ◦ 問題が顕在化できない • 良い ◦ サイロで効率化を図る ◦ サイロで安全性を保つ
  9. 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あたりからそれについて言及されています。
  10. 40 参考: Google SREの組織 • Google SREの体制を整理 ◦ プロダクトごとにSREチームが存在する ◦

    大陸ごとにチームが別れていて24時間オンコール体制 ◦ グループ化されたレポート階層がある
  11. 48 どのようにMovable Embedded SREsを行うか 横断的なSREチームが存在するケースで考えてみます。 1. 1-2名が数ヶ月間SREチームから抜けることが可能な状態か考察し、候補メン バーを選出します 2. 候補メンバーのスキルセットを把握します

    3. Embedded 先のサービス候補を出します 4. サービス開発チーム側に期間限定でSREサポート参加の提案をします 5. 合意が得られれば Embedded の開始です (上記はメルカリの実情ではありません。それはこのあと説明します)
  12. 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に移行すれば、そのまま課題計測ダッシュボードに使えそう)
  13. 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
  14. 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的なチームも存 在しています。
  15. 54 メルカリにおけるMovable Embedded SREs 1. Embedded SREs用のインセプションデッキを作成 2. SREs の参加が必要な開発チームを見つける

    3. インセプションデッキを使って開発チームにSREサポートを提案 4. 開発チームに期間限定で参加する 5. SREに必要なことは全てやる(伝えていくことも重要な使命) 6. 各種EcosystemやToolの導入などを行う 7. そのチームに合った新しいことにチャレンジする 8. Goalを決め抜ける 9. 1Qくらい空ける 10. 1に戻る
  16. 55 SRE が上手く行っていることをどうやって知るのか 我々が当初考えた候補は次のとおりです。 • 課題チケット管理システムで集計する(例: SP) • 課題目標やOKRの達成度で見る しかし、ベロシティ

    = SRE満足度とは限らないので、我々は満足度を計測するために 次のことを実施しました。 • チームに参加して最初の4半期が過ぎた時にサーベイ • チームを抜ける時にサーベイ • 360度評価でも評価を確認
  17. 57 Embedded SREsを導入して何が得られるか • SREの普及状況の把握 • 外からは見えない問題を見つける ◦ SRE課題の発見 ◦

    DX課題の発見 個人的に感じたメリット: • 現在行われているサービス開発の知識を直接得られる ◦ スキルアップにもつながる ◦ 部分的にコンフォートゾーンからの脱却にもなる
  18. 59 Embedded SREs として、苦労や失敗したこと • 最初は認知負荷が高い ◦ ドメイン知識を含めてサービス開発知識もある程度は必要 • マルチアーキテクチャー且つ移行中の場合に起きること

    ◦ Monolith環境向けとの並行作業 ◦ 大きなインシデントが発生するとそちらに時間を取られる ◦ ドメイン/開発知識 + マルチアーキテクチャー + システム移行によりさらに認 知負荷が高まる • サービス開発者にわかりやすい説明を行う準備が不足していた
  19. 60 まとめ • SREは開発組織全体で実践していく • SLOはCUJを軸に考える • Microservicesの数が増えればサイロも増える ◦ サイロ自体は悪くないが、分断が強いと悪い

    • サイロの本質を理解する ◦ 必要であればEmbedded SREsを採用する • SREsが足りないならMovable Embedded SREs という方法もある • 苦労よりも得られるもののほうが大きい (+トイルは減らす事が出来ます)
  20. 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