くろもか/kuromokaの日常

しがないWebエンジニアの日記です。

SRE NEXT 2020の参加メモ #srenext

遅くなりましたが、1/25にSRE NEXT 2020というイベントに参加をしてきました。

f:id:kuromoka16:20200129040855j:plain

そもそも最近までは「SRE」という言葉自体あまりよく知らなかったのですが、ここ最近この分野の個人的な関心が高まっていることもあり参加してみました。

簡単なまとめ

同時進行のセッションがあったので全部聞けたわけではないのですが、大まかには次のような話が多かったです。

  • SREの概念的な話
  • SREを実践した技術的な話
  • SREの組織的な話

またどのセッションでもしきりに「SLI / SLO」というワードがよく出てきて、決めた指標を元に各社いろいろなSREの取り組みをしているんだなーという印象でした。

懇親会も参加したのですが、話をした限りではSREという組織やチームの中で働いている人は意外と少なく、自分と同じようなバックエンドエンジニアやインフラエンジニアの方が多かったです。

聞いたセッションのメモ

分散アプリケーションの信頼性観測技術に関する研究

https://speakerdeck.com/yuukit/a-study-of-sre

  • さくらインターネットで研究をされている方の発表
  • SREとはなにか
    • 失敗を前提として信頼性を制御する工夫
    • 信頼性低下のリスクを減らすことで変更速度を上げる
  • 失敗のリスクをへらす工夫
    • 事前予測
      • キャパシティプランニング
      • サブシステムの依存関係の把握
    • 事後の最小化
      • 自動回復(フェイルオーバー)
      • アラート
      • 因果関係の特定
      • インシデントの対応体制
      • 高度なデプロイメント
  • 地理的に分散したアプリケーションの信頼性向上というテーマでの研究
    • 既存アプリケーションへの影響を与えないようにする
    • 目的
      • 時間軸方向での可観測性
      • 空間軸方向での可観測性
      • データの一貫性を保証
    • 具体的な研究内容については、レイヤーが低めの話もあり自分には少し難しかった

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

https://speakerdeck.com/tjun/sre-next-2020

  • メルカリとメルペイそれぞれで、SRE組織をどうやって作ってきたか
  • メルカリ
    • マイクロサービス化を進めている
    • chocon
    • 半分近い開発チームはマイクロサービスの開発に関わっていて、SREとしてもその状況を後押ししたい
    • これまでは本番環境を支える「門番」として信頼性向上に関わってきた
      • 今後のマイクロサービス化に伴い、SREチームがボトルネックになるかもという懸念
      • マイクロサービスの開発チームに対応していきたい
    • 専門性の異なる3つのサブチームに分けた
      • SRE Core
      • SRE Edge
      • SRE Advocacy
        • マイクロサービス開発の一員
  • メルペイ
    • @tjunさんが、2018年に1人目のSREとして入社してから現在までの話
    • 2019年の2月にメルペイがリリースされるまでは、なかなかチームとしては動けなかったようで結構苦労してそう
    • 現在
      • エンジニア組織の生産性や運用負荷を改善したい
      • サービスの信頼性を高める
      • 自分ではなくメンバーにできるだけ任せる
    • 組織やチームの段階によってリーダのやるべきことは変わる
    • 最終的にSREチームを超えて、エンジニア組織の生産性と信頼性を作っていく

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

https://speakerdeck.com/sekino/ji-hua-de-nifu-he-risukuwopai-chu-surutamefalsekiyapasiteipuranningu

  • タップルSREの話
  • 全体的に少し駆け足感はあったので、20分ではなくもう少し長い時間でも聞いてみたい
  • 負荷的な観点でセキュアベースになるための取り組みについて
  • 取り組むことになったきっかけ
    • イベント開始のpush通知をきっかけに大量アクセスが発生
    • サービスの復旧に時間がかかった
  • キャパシティプランニングのゴール
    • 継続的なシステムキャパシティの把握
    • 負荷レビューの手順と実施フローの整備
  • 継続的なシステムキャパシティの把握
    • 定期的な負荷試験環境を構築
      • 本番と同様の試験環境
      • AWSアカウントだけ分けて、スペックとか構成は同じにしているっぽい
      • 誰でも使えるようにスクリプトや手順書を作った
    • 負荷試験の実施フローの整備
      • 定期実施
        • 限界値を把握するためのロードテスト
        • 限界値を把握するためのスパイクテスト
          • 固定したECSタスクにスパイクアクセス
            • オートスケールの設定がスパイクアクセスを想定していない設定のため
        • エンジニア主導での実施
          • 性能劣化をチェックするテスト
    • レイテンシSLOを定める
      • ビジネスサイドとの連携にも使用したい
      • APIが遅い環境を用意し、各リーダやPMに集まってもらって「API遅延体感チェック会」を実施
        • こういうのいいなーと思った(小並感)
      • チェック会を元に具体的なSLOを決定
  • 負荷レビューの手順と実施フローの整備
    • 施策単位でのレビューフロー
      • 施策の一覧をSREが負荷的に問題ないかをチェック
        • 施策段階では具体的な情報が少ないので、経験則や体感的なものによる
      • 担当エンジニアによる負荷レビュー
        • 施策の担当エンジニアが実施
        • 手順
          • レビューに必要な情報をプランナーに聞く
            • 施策の概要
            • 施策の想定効果
          • 担当エンジニアが増加するアクセス数の想定を出す
          • 負荷試験結果と付き合わせる
            • ここで定期的な実施が聞いてくるのかなーと思う
        • すべての施策で負荷レビューするのはコストがかかるので特定の施策のみ
    • push通知の設定レビュー
      • サービスをスローダウンさせないように配信するため
      • SREが配信設定をレビュー
      • 手順
        • レビューに必要な情報をもらう
          • 配信ユーザ数
          • 配信時間帯
          • 流入の期待値
        • 想定流入数を出す
        • 想定流入数から必要なスループットを出す
          • 最初のフリックの操作をほとんどのユーザが行うので、このエンドポイント単位
        • スパイクテストの結果を元に配信スケジュールを決定
          • 必要なECSのタスク数
          • 限界スループットを超えている場合はpushを分割
          • ECSにスケジュールベースのオートスケールの設定
  • これらを行ってきた結果
    • push通知や施策のリリースでSLOに違反するようなスローダウンが減った
    • エンジニア主導での気軽な負荷試験の実施

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

https://speakerdeck.com/manabusakai/what-do-freee-engineers-learn-and-improve-from-failures

  • 障害対応に課題を感じている人が改善のための第一歩を踏み出せそうと思えるようになること
  • freeeの特徴
    • お金や人に関する情報が多い
    • 上場をした
  • 障害へのシビアな対応が求められる
  • ただし新しい価値を生み出す上で障害は避けられないもの
  • 障害にどう立ち向かってきたか
    • 2017年ごろまではフォーマットもバラバラで障害対策の学びも属人化していた
    • 2018年に「SOC1」取得に向けた準備の一貫で、障害対応フローが作成
    • 障害の影響度に応じてレベルを定義 -障害判断のブレがなくなった
    • 2018/10/31の障害
    • この障害をもとに対応を改善
      • 対応の明瞭化
        • 「SOC1」取得に向けて整備した障害対応フローをブラッシュアップ
        • 障害発生時の対応について、「すべて」をまとめたドキュメントを用意
          • 初動対応
          • 障害対応における役割
            • 指揮を取る人や意思決定者は手を動かさない
          • 社内外のコミュニケーション
      • 障害対応エリアを設置
        • ディスプレイがある物理的なスペースを用意
        • 情報を集約して作業のお見合いなどを防ぐ
      • 初動の省略化
        • Slackのbotで障害対応のドキュメントが出るように
        • ポストモーテムの自動作成
        • GASでの社内に連絡すべき人への告知の自動化
  • 障害の学びを広める
    • freeeの開発文化には失敗から学ぶ文化が根付いていた
    • 失敗.js
      • 障害の学びを開発組織全体に共有する場
      • 犯人探しや責任追及の場ではない
      • 障害がなかった月は寿司
    • 割れ窓を改善し隊
    • alertを振り返り隊
      • 直近1週間のalertを振り返りノウハウを共有
      • 障害対応の属人化を防ぐ

SLO Review

https://speakerdeck.com/chaspy/slo-review

  • SLI / SLOを定めることは重要
  • ただし最初は完璧ではない
  • Quipperでのケーススタディ
    • Define the Ownership
      • 日本と海外にチームがあり、それぞれのチームでオーナを決める
    • SLO review by myself
    • SLO review with Devs
      • Dos Detector
        • Dos攻撃対策として503エラーを返していた
        • 設定しているSLIに5xxが含まれているため、攻撃されるとするとすぐに違反になってしまう
        • 代わりに429を返すようにした
      • パスが分からないので送るようにした
      • Envoyでのマイクロサービス間のメトリクスを取得(たしか)
    • Set Error Budget Policy
      • まだ
  • こんなSLIを定めたほうがいいというデフォルトセットを用意しておく
  • SLIの設定はコード化しておく
    • 開発者が簡単に変えられるようにするため

急成長するPairsと共に変化・成長し続けてきたエウレカのSRE戦略

https://speakerdeck.com/kaneshin/how-to-keep-growing-sre-team-at-eureka

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

https://speakerdeck.com/takanabe/sre-next-2020-c6-designing-fault-tolerant-microservices-with-sre-and-circuit-breaker-centric-architecture

  • Cookpadのグローバルチームでの話
  • Cookpadのレシピ検索の改善として、「Serch v2」と「ML API」を開発
    • この開発チームを「Serch / MLチーム」として、SREとしてどのように改善したのかといった構成の話
  • 最初はMLの研究者と開発者とバックエンドエンジニアがコラボして作業をしていた
    • うまくいかず…
    • 理想と現実のギャップ
      • 技術
        • 新しいプロダクトはpythonk8sを使う予定でいた
        • チームごとに使う技術がバラバラになってしまうのはよくないと考えている
        • ただ機械学習pythonを柄う
      • サービスレベル
        • 実験的な内容をプロダクトに入れたことによるエラーの発生
      • オンボーディングなしで簡単なプロセスで、リリースをできるようにしたい
  • 解決するためのSREチームの具体的な取り組み
  • すべての課題に対してDesign Docsを書く
  • Serch / MLチームの技術選択
    • AWSアカウントやリソースを分けて、本体側に影響出ないようにしてチーム内で自走するようにする
  • 本体側が停止しないようなマイクロサービスの導入
    • サーキットブレーカーを導入
      • サービスが不安定なときにすぐに本体側と切り離せる仕組み
      • 設定したしきい値を超えたとき、マイクロサーヒスへのリクエストを遮断(503を返す)
      • ヘルスチェックの結果をもとに元に戻す
    • TraefikというGo製のツールを使っている
    • サーキットブレーカーのしきい値をどうやって決める?
      • SLOをもとにする
      • なにをSLOにするかは難しいのである程度のプリセットを用意しているらしい
    • しきい値を超えたらサーキットブレーカーによって、リクエストが遮断されるコンセンサスをチームと取る
  • オンコールからの開放
    • サーキットブレーカーで切断したあとに自動的に古いプロダクトに戻すことで、手動での対応を不要にしているっぽい
  • 実験的な内容のリリース
    • リクエストパスごとに、新旧のプロダクトを切り替える

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

  • SREの何たるが全然分かってない自分にとっては、エラーバジェットなどの説明や具体例も一緒に話してくれたのは非常に分かりやすかったです。
  • スライドは公開されてないですが、登壇した@ymotongpooさんのブログ記事があったので、こちらをメモ代わりに貼っておきます。

ymotongpoo.hatenablog.com

Webサービスを1日10回デプロイするための取り組み

https://speakerdeck.com/fujiwara3/sre-next-2020

  • 内容はタイトルの通り
    • こういう闇を改善していく話は聞いてて面白い
  • Lobiのサービスでの取り組み
  • 1日10回デプロイしたい
    • 以下すべてをデプロイと定義
      • サーバサイド
      • フロントエンド
      • EC2のプロビジョニング(Chef)
      • AWSの構成変更(Terraform)
    • 修正や機能追加や削除はすぐにデプロイしたい
    • 常にデプロイしていればデプロイが怖くなくなる
  • 1日に何時間使えるか
    • 営業時間内(9時間)
    • 営業時間外や休日の前の午後は基本的にデプロイしないようにしている
      • 夜のピークタイムに問題が発生
      • 夜間バッチで問題が発生
      • ユーザからの問い合わせが休日に増える
  • 7時間で10回デプロイするには
    • 1回のデプロイに使える時間は30分以下
    • 1回1回のデプロイの高速化
    • 専任の担当者を作らずだれでもデプロイできるようにする
    • いつなにがデプロイされたかを記録する
  • 以下のデプロイの要素を早くする
    • CI
      • テストが通ってないものはリリースできない
    • ビルド / 配付
    • エラー検知
    • ロールバック
  • CI高速化
    • 本体APIPerlでのモノリスなアプリ
    • アプリケーション26万行 + テスト26万行
    • 実際にMySQLやRedisを起動してテストをしている
    • 何も考えずにテストを実行すると日が暮れるとか…
    • 並列化を行い10分で終わるようにした
      • 10分だとpushをしても他の人のテスト待ちで10分以上掛かる
      • ローカルで修正箇所だけテストをするようにしたりしたが、pushして全部をテストするとこけたりしていた
      • 緊急対応時にもどかしい
    • Jenkins → Circle CIにして、コンテナの並列化をした
      • 10分から3分になった
      • PRを作ってから説明を書いているうちに、CIが終わるようになった
    • Circle CIのイメージはus-east-1に置くようにして、Circle CIの実行環境と物理的に近くなるようにするとよい
  • ファイル配付の高速化
    • 2010年〜
      • EC2のデプロイサーバから各ホストでgit pull
    • 2013年〜
      • デプロイサーバから各ホストにrsync
      • 10並列でrsyncしても終わるまで3-4分
      • この方法だとオートスケールへの対応がやりにくい
    • Stretcherを開発
      • https://github.com/fujiwara/stretcher
      • デプロイの配布物をS3に置くようにして、各ホストでStretcherコマンドでS3から取得して展開するようにした
      • オートスケールで起動したホストもS3から取得して展開
    • rsyncの3-4分から、1分程度に短縮
  • エラー検知
    • デプロイはエラーがないことを確認してからでないと完了にならない
    • ログから問題を検出する仕組み
    • NorikraでログにSQLクエリを投げれるようにした
    • ログ検知を適切なwindowsで実行する
      • エラーが大量発生しても1分に1回だけ通知する(通知が膨大に来ないようにするため)
  • ロールバック
    • デプロイして問題が発生したらすぐに戻したい
    • いままでのフロー
      • リバートのPR作成、レビュー
        • 間違ったコミットをリバートしていないか
      • リリースブランチにマージ
        • CIの待ち
      • デプロイしなおし
    • どう急いでも5分以上かかっていた
    • Stretcherでロールバック
      • デプロイ前の直前の成果物がS3に残っている
      • 直前のURLを指定すればロールバック完了
    • 30秒でロールバックが完了するようになり、人間が介入しないのでミスしないようになった
  • 誰でもデプロイできる仕組み
    • これまでは特定の担当者がデプロイをしていたが、コードを書いた人がデプロイできるようにする
    • Rundeckを使った
    • デプロイ履歴の管理にghch
    • Slackbotによるデプロイの管理
      • テストが通ってなかったり時間外のデプロイを行おとすると警告する
  • コンテナ移行後のデプロイ