遅くなりましたが、1/25にSRE NEXT 2020というイベントに参加をしてきました。
そもそも最近までは「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
- https://github.com/kazeburo/chocon
- さくらインターネットの石狩データセンターと東京間のレイテンシを減らすために、SREチームが開発
- 半分近い開発チームはマイクロサービスの開発に関わっていて、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通知をきっかけに大量アクセスが発生
- サービスの復旧に時間がかかった
- キャパシティプランニングのゴール
- 継続的なシステムキャパシティの把握
- 負荷レビューの手順と実施フローの整備
- 継続的なシステムキャパシティの把握
- 負荷レビューの手順と実施フローの整備
- 施策単位でのレビューフロー
- 施策の一覧をSREが負荷的に問題ないかをチェック
- 施策段階では具体的な情報が少ないので、経験則や体感的なものによる
- 担当エンジニアによる負荷レビュー
- 施策の担当エンジニアが実施
- 手順
- レビューに必要な情報をプランナーに聞く
- 施策の概要
- 施策の想定効果
- 担当エンジニアが増加するアクセス数の想定を出す
- 負荷試験結果と付き合わせる
- ここで定期的な実施が聞いてくるのかなーと思う
- レビューに必要な情報をプランナーに聞く
- すべての施策で負荷レビューするのはコストがかかるので特定の施策のみ
- 施策の一覧をSREが負荷的に問題ないかをチェック
- push通知の設定レビュー
- 施策単位でのレビューフロー
- これらを行ってきた結果
- push通知や施策のリリースでSLOに違反するようなスローダウンが減った
- エンジニア主導での気軽な負荷試験の実施
freee のエンジニアは障害から何を学び、どう改善しているのか？
https://speakerdeck.com/manabusakai/what-do-freee-engineers-learn-and-improve-from-failures
- 障害対応に課題を感じている人が改善のための第一歩を踏み出せそうと思えるようになること
- freeeの特徴
- お金や人に関する情報が多い
- 上場をした
- 障害へのシビアな対応が求められる
- ただし新しい価値を生み出す上で障害は避けられないもの
- 障害にどう立ち向かってきたか
- 2017年ごろまではフォーマットもバラバラで障害対策の学びも属人化していた
- 2018年に「SOC1」取得に向けた準備の一貫で、障害対応フローが作成
- 障害の影響度に応じてレベルを定義 -障害判断のブレがなくなった
- 2018/10/31の障害
- https://tech.nikkeibp.co.jp/atcl/nxt/mag/nc/18/020600011/040800029/
- オペレーションミスのため
- データ保護を優先するためにサービス停止の決断
- 月末に2時間半停止（freeeは月末・月初に最も利用される）
- この障害をもとに対応を改善
- 対応の明瞭化
- 「SOC1」取得に向けて整備した障害対応フローをブラッシュアップ
- 障害発生時の対応について、「すべて」をまとめたドキュメントを用意
- 初動対応
- 障害対応における役割
- 指揮を取る人や意思決定者は手を動かさない
- 社内外のコミュニケーション
- 障害対応エリアを設置
- ディスプレイがある物理的なスペースを用意
- 情報を集約して作業のお見合いなどを防ぐ
- 初動の省略化
- Slackのbotで障害対応のドキュメントが出るように
- ポストモーテムの自動作成
- GASでの社内に連絡すべき人への告知の自動化
- 対応の明瞭化
- 障害の学びを広める
- freeeの開発文化には失敗から学ぶ文化が根付いていた
- 失敗.js
- 障害の学びを開発組織全体に共有する場
- 犯人探しや責任追及の場ではない
- 障害がなかった月は寿司
- 割れ窓を改善し隊
- 小さな問題が大きくなる前に改善する有志の活動
- 3ヶ月で33個の問題があがり、20個が解消が済み
- はてなの取り組みを参考にした
- alertを振り返り隊
- 直近1週間のalertを振り返りノウハウを共有
- 障害対応の属人化を防ぐ
SLO Review
https://speakerdeck.com/chaspy/slo-review
- SLI / SLOを定めることは重要
- ただし最初は完璧ではない
- Quipperでのケーススタディ
- Define the Ownership
- 日本と海外にチームがあり、それぞれのチームでオーナを決める
- SLO review by myself
- 最初は一人でやった
- Slackにリマインダーをセットし、GitHubに記録
- DatadogのダッシュボードでSLOをモニタリング
- Availability Table
- https://landing.google.com/sre/sre-book/chapters/availability-table/
- システムの可用性の割合によって、許可されるダウンタイムを表すものっぽい
- 最初は99.9% / per weekで開始
- SLO review with Devs
- Set Error Budget Policy
- まだ
- Define the Ownership
- こんなSLIを定めたほうがいいというデフォルトセットを用意しておく
- SLIの設定はコード化しておく
- 開発者が簡単に変えられるようにするため
急成長するPairsと共に変化・成長し続けてきたエウレカのSRE戦略
https://speakerdeck.com/kaneshin/how-to-keep-growing-sre-team-at-eureka
- 2012-2015年
- サービスの性質上、DB負荷が高い
- 専任のインフラエンジニアがいない
- 2015-2017
- インフラチームが発足
- PHP→Goへの書き換え
- テーブル設計の見直し
- リリース回数を増やせた
- 2017-2020
- インフラチームからSERチームにリネーム
- SREチームのビジョンの整備が追いついていないという課題がありそれを明瞭化した
- 技術的な話として以下のスライドの紹介
Designing fault-tolerant microservices with SRE and circuit breaker centric architecture
- Cookpadのグローバルチームでの話
- Cookpadのレシピ検索の改善として、「Serch v2」と「ML API」を開発
- この開発チームを「Serch / MLチーム」として、SREとしてどのように改善したのかといった構成の話
- 最初はMLの研究者と開発者とバックエンドエンジニアがコラボして作業をしていた
- 解決するためのSREチームの具体的な取り組み
- すべての課題に対してDesign Docsを書く
- Serch / MLチームの技術選択
- AWSアカウントやリソースを分けて、本体側に影響出ないようにしてチーム内で自走するようにする
- 本体側が停止しないようなマイクロサービスの導入
- オンコールからの開放
- サーキットブレーカーで切断したあとに自動的に古いプロダクトに戻すことで、手動での対応を不要にしているっぽい
- 実験的な内容のリリース
- リクエストパスごとに、新旧のプロダクトを切り替える
サイト信頼性エンジニアリングの原則
- SREの何たるが全然分かってない自分にとっては、エラーバジェットなどの説明や具体例も一緒に話してくれたのは非常に分かりやすかったです。
- スライドは公開されてないですが、登壇した@ymotongpooさんのブログ記事があったので、こちらをメモ代わりに貼っておきます。
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
- CI高速化
- 本体APIはPerlでのモノリスなアプリ
- アプリケーション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年〜
- Stretcherを開発
- https://github.com/fujiwara/stretcher
- デプロイの配布物をS3に置くようにして、各ホストでStretcherコマンドでS3から取得して展開するようにした
- オートスケールで起動したホストもS3から取得して展開
- rsyncの3-4分から、1分程度に短縮
- 2010年〜
- エラー検知
- デプロイはエラーがないことを確認してからでないと完了にならない
- ログから問題を検出する仕組み
- NorikraでログにSQLクエリを投げれるようにした
- https://norikra.github.io/
- 特定のクエリにマッチしたエラーがあると通知が来る
- ログ検知を適切なwindowsで実行する
- エラーが大量発生しても1分に1回だけ通知する（通知が膨大に来ないようにするため）
- ロールバック
- 誰でもデプロイできる仕組み
- これまでは特定の担当者がデプロイをしていたが、コードを書いた人がデプロイできるようにする
- Rundeckを使った
- https://www.rundeck.com/open-source
- デプロイに必要なコマンドを叩くためのWeb UIとして使用
- デプロイ履歴の管理にghch
- https://github.com/Songmu/ghch
- Gitの履歴からChangeLogを自動生成できる
- デプロイんい含まれるPRを取得して、Googleカレンダーに記録する
- Slackbotによるデプロイの管理
- テストが通ってなかったり時間外のデプロイを行おとすると警告する
- コンテナ移行後のデプロイ
- ecspresso
- https://github.com/kayac/ecspresso
- ECSデプロイツール
- ecspresso
