無印吉澤

Site Reliability Engineering（SRE）、ソフトウェア開発、クラウドコンピューティングなどについて、吉澤が調べたり試したことを書いていくブログです。

SRE NEXT 2020 の個人的おすすめセッション動画

SRE NEXT SRE Microservices SLO
f:id:muziyoshiz:20200127000336p:plain:w640

SRE NEXT 2020 のセッション動画が公開されました！

SRE NEXT 2020 の参加者には、2/23(日)に「SRE NEXT 2020 参加者特典のご案内(セッション動画限定公開)」という Subject のメールが届いていると思います。

このメールに書かれている YouTube の URL から、全セッションの動画を見ることができます！

いい機会なので、今回は SRE NEXT 2020 のセッションのなかから、個人的に動画を見ることをおすすめしたいものをご紹介します。これらの動画は3月中旬以降に一般公開される予定ですので、SRE NEXT に参加されていなかった方はひとまずプレゼン資料を読んでお待ちください 🙇

※2020-03-16追記
動画の一般公開が始まりましたので、この記事にも、セッション動画へのリンクを追加しました。

今回のおすすめの基準

有志の方がまとめてくださった 【SRE Next 2020】発表資料まとめ - Qiita から辿って、プレゼン資料を一通りすべて読みました。

そして、そのなかで自分が特に参考にしたいと思った（＝僕の現状にマッチした）セッションの動画を 1.5 倍速で再生して見まくりました。今回は、その中で特に参考になったものをおすすめとしてご紹介します。ちなみに、全員見ていそうな基調講演やパネルディスカッションは除外しました。

今回ご紹介していないセッションについても、どれも濃い内容でしたので、一通りスライドを読んで、興味のあるキーワードを含むセッションの動画を見てみることをおすすめします。

※2020-03-16追記
SRE NEXT 公式サイトのタイムテーブルにも、各セッションのスライドと動画が表示されるようになりました。スライドを見るなら、いまはこちらから見たほうが楽です。神アプデ！

sre-next.dev

SRE 入門

[A7] サイト信頼性エンジニアリングの原則

ymotongpoo.hatenablog.com

SRE NEXT サイト内の紹介文

Google の山口さんによる講演。SRE が守るべき基本的なセオリーを1つずつ取り上げて解説されている講演で、SRE 入門としておすすめです。特にポストモーテムの重要性を詳しく解説しています。

スライドは公開されていないのですが、上記のブログ記事でその内容が詳しく紹介されています。

メルカリのマイクロサービスの事例

個人的に、メルカリのマイクロサービス化は先進的な事例として以前から注目しています。今回も非常に勉強になりました。

メルカリの SRE は、マイクロサービスの基盤を担当する Microservices Platform チームと、サービス開発者と協働する SRE チームに分かれているのですが、SRE NEXT 2020 ではそれぞれのチームの方による発表がありました。

[B7] SRE Practices in Mercari Microservices

SRE NEXT サイト内の紹介文

Microservices Platform チームのテックリードの deeeet さんによる講演。

Microservices Platform チームの活動でどういうことを工夫しているかを、SLI/SLO, On-call, Toil という3つの観点から紹介されていました。個人的にはこちらが今回のベストセッションでした！

以下は内容のメモです。

  • そもそもなぜメルカリがマイクロサービス化を進めているか
    • Successful Software Developmentの三角形
      • マイクロサービス化によって可能になることをシンプルな図で表しているもの
      • ArchitectureがOrganizationを可能にし、このArchitectureとOrganizationが、Processを可能にする
        • 実現したいのはProcess＝Continuous delivery/deployment
      • マイクロサービスはその技術だけじゃなく、どういう組織を作るかということが重要
    • SRE と Platform Team の違いを KPI から説明
      • SRE は、SLI/SLO を KPI として追ってる
      • Platform Team は、deploy/developer/day など、開発効率の指標を KPI として追ってる
    • 2つの信頼性
      • Reliabilities for platform → 講演前半の話
      • Reliabilities for microservices → 講演後半の話
  • SLI/SLOを導入するにあたって重要だと考えている点
    • 適切なプロジェクトマネジメントが行われているかどうか。プロダクトバックログ、スプリント、といったフローに沿って開発しているかどうか
      • 好き勝手に各自が開発していたら、SLI/SLOは機能しない
    • プロダクトバックログの優先度を決める基準の一つとしてSLI/SLOが使われてこそ意味がある
  • SLI/SLO
    • SLO Document
    • ここで重要なのは Approver(s) と Revisit date
      • Approver(s): SLOを満たせなかったときに、実際に開発を止める判断をできる人
      • Revisit date: SLI/SLO を更新する日。定義した時点で Revisit dateを決めて、Google Calendarに登録してしまう
    • SLI specification と implementationを分けて書くのも良いプラクティス
      • エンジニアだと how を先に考えがちだが、what を先に考えるべき
    • このドキュメントを GitHub に置いて、GitHub のプルリクで更新
    • SLO Documentの具体例：Spinnaker（Platformチームが、社内のエンジニアに提供するサービス）
      • マイクロサービスのデプロイの基盤として使っている
      • Spinnaker に対する SLO を設定している
        • パイプラインの成功率、パイプラインの実行時間
    • SLI/SLO の revisit meeting
      • 社内の Slack に対するエゴサーチと、開発者に対する Google Form でのアンケート
      • SRE Workbook の SLO Decision Matrix に従って SLO を更新している
  • On-call
    • オンコールを誰がするかは、マイクロサービスによってどういう組織に作っていきたいかによる
    • メルカリでは、運用を含めたソフトウェアサイクルを自分たちで回せる、クロスファンクショナルなチームを作っていくこと。だからサービスチームがオンコール対応する
      • 100個くらいあるマイクロサービスを運用チームが見るのは現実的に不可能
    • k8s のネームスペースを、サービス用と、基盤用で分けている。そこを責任分界点にしている
    • アラートの設定基準
      • RED でアラート、USE で調査
      • Actionable Alert＝Alert 1個につき、必ずPlaybookを1個用意する
        • コンポーネントのPlaybookもGitHubで管理している
  • Toil
    • 自分たちはあまりToilという単語を使っていなくて、外部要因で発生するタスクのことをReactive Taskと呼んでいる
      • Toilもその1つとして扱っている
      • サービスが成長し続ける限り、reactive taskはゼロにはならない、ということを念頭に置くのが大事
    • PlatformチームがReactive Tasksへの向き合い方をどう変化させてきたか？
  • マイクロサービスのreliabilityのために僕らが取り組んでいること
    • Platformチームがベストプラクティスを提供し、サービスチーム自身がソフトウェアサイクルを回せるようになってもらう（self-service）
    • 2つのベストプラクティス：Design Doc, Production Readiness Check
      • マイクロサービスの開発前にDesign Docを書いてもらう（テンプレートを提供している）
      • 本番運用のために、アプリケーションが満たすべきことをチェックリスト（Production Readiness Check）で確認
        • Production Readiness Checkは、GitHubのissue templateとして準備している
        • サービスチームはリリース前にissueを作り、それを自分たちでチェックして、そのレビューをSREなどに依頼できるようになっている

[C1] 絶え間なく変化するメルカリ・メルペイにおけるSREの組織と成長

SRE NEXT サイト内の紹介文

前半はメルカリの SRE チームの EM を担当されている渋谷さん、後半はメルペイの SRE の EM を担当されている高木さんによる講演。ちなみに、渋谷さんは SRE NEXT 2020 のコアスタッフとして Web サイトなどを担当してくれました。

前半の講演のなかで、SRE チームのこれまでの組織体制と、今年の1月に行われた SRE チームの編成のマイナーアップデートについてご紹介されていました。僕は前半の組織体制の話について、興味深く聞きました。

以下は前半の内容のメモです。

  • メルカリ・メルペイそれぞれのチーム体制
    • SREチームとMicroservices Platformチームの住み分け
    • SREもマイクロサービス化に貢献している→chocon（チョコン）というプロクシを開発
  • メルカリのマイクロサービス移行の進捗 (2019年冬) - Mercari Engineering Blog
  • いままではSREが本番環境を支えるいわば「門番」だった
    • 門番モデルではSREチームがボトルネックになるリスクがある
    • マイクロサービス化により開発チームのスケーラビリティが上がっていくのに追従していけるよう、SREチームの体制もアップデートしたいと考えた
  • 今月（2020年1月）から、SREチームの編成をマイナーアップデートした
    • SRE Core：DatastoreやMail/SMS deliveryなどの共通基盤を担う
    • SRE Edge：クライアントから直接リクエストを受ける部分に近いCDN、ロードバランサ、ゲートウェイなどを担う
    • SRE Advocacy：マイクロサービス開発チームの一員として、信頼性向上やオペレーションを担う

負荷テスト

[B2] 計画的に負荷リスクを排除するためのキャパシティプランニング

SRE NEXT サイト内の紹介文

タップル誕生の SRE の赤野さんによる講演。

負荷試験の実行環境を、バックエンドエンジニアなら誰でも作れるようにセルフサービス化しています。さらに、その負荷試験の結果を施策の導入可否にまで影響させているとのこと。ここまで実現しているのは本当にすごい！

以下は内容のメモです。

  • タップルSREが負荷的な観点でのセキュアベースになるための取り組み
  • 定期的に負荷試験を実施できる環境づくり
    • 負荷試験用のAWSアカウントを別に用意
      • できるだけ本番環境に影響が出ない、という安心感を得るため
      • LocustクラスタをFargateで稼働
      • バックエンドエンジニアなら誰でも負荷試験環境を構築できるようにスクリプトを整備
    • 限界値を把握するためのロードテスト、スパイクテスト
      • いくつかのテストの種類
      • ECSタスク数ごとのスパイク限界値を測定→予定されたスパイクアクセスに対応できるか確認したいため
      • 性能劣化をチェックするテスト→SREは実施前のテスト計画のレビューと、テスト結果のレビューのみしている
    • SREが決めたSLOはあったが、UXを考慮したSLOではなかった
    • レイテンシSLOを決めるにあたって、API遅延体感チェック会を実施
      • SLOを満たさない場合はリリースしないようにしたい、という目的でこの会を開催した
      • 「全体リクエストのレイテンシのp90が223ms以下で、1ヶ月のうち99%以上稼働」に決定
      • 現在もこのSLOで運用している
  • 施策開発フローに負荷レビューを組み込む
    • 施策のロードマップを立てた段階で、SREが、負荷の観点から実現可能かをチェック
    • すべての施策についてはレビューしきれないので、「DAU増加」か「カードのフリック数の増加」を狙いとした施策のみレビューしている
    • レビューに必要な情報はプランナーに提出してもらっている
    • PUSHについてはレビュー結果をもとに、ECSタスク数や、PUSHを分割する・しないを判断する

障害対応

[A3] freee のエンジニアは障害から何を学び、どう改善しているのか？

SRE NEXT サイト内の紹介文

freee の SRE 坂井さんによる講演。過去に発生した障害をきっかけに、障害対応フローをどのように整備したかを解説してくださいました。自分たちの障害対応フローを見直すうえで、とても参考になりそうです。

以下は内容のメモです。

  • 今日のゴール
    • 障害対応に課題を感じている人が、改善のための第一歩を踏み出そうと思えるようになること
  • freeeのプロダクトは、お金や人に関する情報を扱うものが多い
    • 会計freeeは電子決済等代行業に当たる
    • 2019年に上場し、以前にも増して、障害に対してよりシビアな対応が求められる
  • 障害をゼロにすることは難しい
    • 障害を受け入れながらも、安定したプロダクト、という相反するものを目指す
  • 自分が入社した頃（2016年）から、障害対応フローがどう変わってきたか
    • 徐々にポストモーテムを書くようになるが、フォーマットや情報の粒度、書く場所もバラバラ → 障害対応の学びが属人的
    • SOC1取得に向けた準備を始めた2018年に、準備の一環で障害対応フローが策定された（レベル1〜5の障害定義など）
    • 2018年10月（月末）に起きた障害で全サービス停止
    • 障害から得られた組織としての学び
      • 障害対応フローのブラッシュアップ（初動対応、役割、社内外コミュニケーション）
      • 障害対応エリアの設置（物理的に集まれるエリア「ブリッジ」）
      • 初動の省力化（チャットボットでのドキュメント検索、ポストモーテムの自動作成、関係者への通知の自動化）
  • 振り返りのためのいろいろな取り組み
    • freeeの開発文化「失敗して攻めよう」
    • 失敗.js
    • 割れ窓を改善し隊
    • alertを振り返り隊（今年から始めた新しい取り組みで、成果が出るかはこれから）
  • まとめ
    • 自分たちの組織やプロダクトに合った障害対応フローを作る
    • 大きな障害は学びの宝庫
    • 障害からの学びが属人的にならないように工夫する

SLI/SLO

[C4] SLO Review

SRE NEXT サイト内の紹介文

Quipper の SRE であり、SRE NEXT 2020 のコアスタッフでもあった chaspy さんの講演。

2019年に Quipper 社内で SLO をどうやって徐々に導入していったか、という事例紹介です。内容ももちろん勉強になるんですが、chaspy さんはとにかく話がうまくて、聞いてて面白いです。

以下は内容のメモ。

  • 最近受講した：Coursera の Site Reliability Engineering: Measuring and Managing Reliability コース
  • エラーバジェット導入に向けて、SLO導入をどういうステップを踏んで実現したか
    • エラーバジェット導入は今後の課題
  • reliabilityとagilityのバランスを取るためのツールがSLO
    • マイクロサービスに取り組むなら必須のツール
    • 依存先のサービスの信頼性を、依存元が超えることはできない
  • Quipperでのケーススタディ
    • いろいろなツールでメトリクスを取り、すべてをDataDogに送っている
      • Synthetics Clients：Pingdom
      • Frontend：Centry
      • Load Balancer：Nginx, envoy
      • Application：New Relic
    • 今年のSREチームの目標：Self-Contained
      • 開発チームが自分たち自身のみでプロダクト開発を完結できること、を目指している
      • そのための支援をSREチームがしていく
      • すでに提供している：Design Doc、Production Readiness Check、インフラ管理の移譲（Terraform）
      • その延長でSLI/SLOにも取り組んでいる
    • 2019年に行った取り組み
      • Define the Ownership
        • 多拠点に複数の開発チーム。各マイクロサービスに誰がオーナーシップを持つのかの定義から
        • Design Docでステークホルダーを明確化（Design DocはSREがレビューする）
        • オーナーを決める文化が根付いてきたので、この活動はおすすめ
      • SLO review by myself
        • まずは自分（chaspyさん自身）でやってみた
        • 誰でもできる方法
          • 週1でSlackにリマインダを飛ばして、その時点でのSLIをDataDog上で確認し、GitHub Issueに記録する
        • Availability Table、どれくらいの稼働率が良いのかの肌感を得た（99.9%くらいが良さそう）
        • SLO reviewや、ペアプロやユニットテストのような「良い習慣」なのではないかと気づいた
      • SLO review with Devs
        • 開発者からいろいろ要望が出てきて対応した
          • Dos detector（Rate limitting）がSLIのノイズになる
          • マイクロサービスで同じドメイン名を共有している（パスは違う）場合に、ログにパスを付与
      • Set Error Budget Policy
        • 今年の4月くらいからエラーバジェットを決めて、エグゼクティブと合意してやっていけたらと思ってる
  • SLO導入に向けておすすめするポイント
    • 最初のSLIはSREが設定したほうがいい。プロダクトに詳しいのは開発者だが、今取れる情報についてはSREのほうが詳しい
      • AvailabilityやLatencyなど、当然見ると思われるものを最初に設定しておけばよかったと反省している
    • SLI/SLOの設定もコードしたほうが良い（Terraform）
    • 少ない時間で成果を出すことを意識する
      • ドキュメントを最初から書いておけば楽だったと思う
      • 15チームにそれぞれ説明して、徐々に導入していった

開発者と SRE

[C6] Designing fault-tolerant microservices with SRE and circuit breaker centric architecture

SRE NEXT サイト内の紹介文

Cookpad の海外チームの SRE を担当している渡辺さんによる講演。

この講演での話題は、新しい技術スタック（機械学習関係）を採用した、試作的なプロダクトを導入するケースです。その試作的なプロダクトがメインのサービスに与える影響の範囲を限定しつつ、どうやって試作を行うチームの生産性を損なわないようにしたか、という事例紹介でした。

マイクロサービスの特徴がうまくマッチした事例として、こういうケースがあるのか！と参考になりました。

以下は内容のメモです。

  • Cookpad Global（Cookpad のグローバルサービス）
    • 23 backend developers
    • 5 SREs
  • Search-v2, ML APIs：新規機能、実験的な機能
    • これを入れていくときのアプローチについての講演
    • 特殊な状況での事例紹介
  • 独立性の高いチームと、既存のチームの間での衝突を少なくするために、circuit breaker、SLOを導入している
  • technology stackをcookpadでは制限している
    • しかし、新しい機能では、rails以外の言語を使う必要が出てきた
  • 24/7サポートには8人のエンジニアが欲しい。いろいろな本で8人と書かれている
  • 関係者の間での調整のためにdesign documentを書く
  • それにプラスアルファで、目的別の対策
  • Delegation and resource isolationも必要
    • AWSアカウントを分離して、VPC peering
    • 自分たちが使う技術の範囲は自分たちで運用する（SREが管理するのではなく、MLのdevelopersが管理する）
  • circuit breaker
    • Traefik
    • SLOに応じて設定。そのSLOはDesign Docで調整
  • 開発者がSLOを決めるのは難しい。だからSREがavailability classを提供している
    • availability classを定義し、それぞれのサービスの目標値を決める。それをcircuit breakerの設定に反映させる
  • PrometheusとAlertmanagerのコンフィグはJsonnetで書いている
    • よく使う設定はSREがライブラリ化してる
  • Search-v2についてはオンコール対応不要にした
    • 動かないときはSearch-v1にフォールバックするようにした
  • Bonus Track
    • オンコールローテーションルールは、そのチームのメンバーの好き好きによって決めるべきで、組織全体の統一ルールを作るべきではない
    • Cookpadのバックエンドエンジニアは世界中にいるので、1日を午前午後で分けて、営業時間内だけオンコール対応している
    • SREも日本とイギリスで分散しているので、同様にローテーションしている

[D4] 100万回線のIoT通信を支えるソラコムにおけるOpsDevの実践

SRE NEXT サイト内の紹介文

ソラコムの OpsDev エンジニア（DevOps エンジニアの誤記じゃないです）の酒井さんによる講演。開発者が全員で運用し、サポートまで行う現場の事例紹介でした。

以下は内容のメモです。

  • OpsDev Engineer≒SRE
  • 開発と運用の基本原則
    • 開発者：全員がDevOpsを実践。運用もする
    • OpsDevエンジニア（≒SRE）：運用作業の傍ら、運用作業省力化のための開発をする
    • チーム全体で運用に責任を持つ
  • 運用しやすいシステムを作るための基本的な原則
    • Horizontal Scalability：小さいサーバを横に並べることでスケールアウトできる設計
    • Built-in Resilience：障害を前提とした設計、障害が起きたシステムを単独でプロセス再起動できる設計
  • サポートプライマリ制度：サポート・運用タスクについてはエンジニアが交代制で対応する
    • お客様と直接コミュニケーションすることで改善点に気づける、モチベーションが上がる、自身の問い合わせスキルが上がる
  • 一部のエンジニアは嫌がるのでは？トレードオフがあるのでは？
    • ソラコムのリーダーシップステートメントで、上記のような行動を推奨
      • リーダーシップステートメントに沿って行動することで評価も上がる
    • サポート・運用タスクのタスクコントロールを工夫
  • インシデント対応
    • なにか怪しいことがあったら #andon チャンネルで報告。間違った報告でも責めない
    • チャットボットで障害対応をサポート（障害報告書のひな型作成など）
    • ポストモーテム：2週間のイテレーションの最後に関係者全員で andon 振り返り

ちなみに、過去に SRE Lounge #8 で酒井さんの講演を聞いたことがあって、その時の内容を以下の記事にまとめています。SRE NEXT の講演に含まれていない内容もありますので、興味が湧いた方はこちらもどうぞ。

muziyoshiz.hatenablog.com