SRE本発表会

トラーナSREチームでSRE本輪読会を終えたので、内容のまとめを社内で発表しました

Transcript

1. SRE本発表会 2022/09/21(水) トラーナSREチーム
2. サービス管理へのシステム管理者のアプローチ 開発(dev)と運用(ops)を分離し、サービス管理をシステム管理者が行う旧来型のアプローチ opsはシステム運用の増加に伴い、線形に人員を増加させる必要がある devとopsの目標は基本的に対立関係にある(e.g. 新機能ローンチ vs 安定運用)
3. サービス管理へのGoogleのアプローチ: サイトリライアビ リティエンジニアリング 「SREとは、ソフトウェアエンジニアに運用チームの設計を依頼したときにでき上がるもので す」 これまで運用チームが手作業で行ってきたことをエンジニアがソフトウェアによる自動化で 対処する これにより、サービスの成長に伴うシステム運用の増加に対してSREの人数は比例しない
4. SREの信条 1. エンジニアリングへの継続的な注力の保証 運用作業は業務の50%まで 2. サービスのSLOを下回ることなく、変更の速度の最大化を追求する エラーバジェットの活用 3. モニタリング 人間はアクションを行わなければならないときにのみ通知を受けるようになってい るべき
5. SREの信条(続き) 4. 緊急対応 MTTRの短縮のために自動化する 5. 変更管理 自動化によって「全身的なロールアウトの実装」「高速かつ正確な問題の検出」 「問題が生じた際の安全なロールバック」を実現することがベストプラクティス 6. 需要の予測とキャパシティプランニング 7. プロビジョニング 8. 効率とパフォーマンス
6. SREの観点から見たGoogleのプロダクション環境 Googleのコンピュートリソースの殆どは、Googleが設計したデータセンター群にある 独自の電源系、冷却系、ネットワーク、およびデータセンター内で統一されたコンピュート ハードウェアを持つ 数十台のマシンが1つのラックに配置 複数のラックが1列に並ぶ 1つないし複数の列は1つのクラスタを構成する 通常は、1つのデータセンターの建物は複数のクラスタを格納する 近くに配置されたデータセンターのビルディング群はキャンパスを構成する データセンター群はGoogleの地球規模のバックボーンネットワークで相互接続されている
7. リスクの受容 過渡の信頼性はコストに跳ね返る サービスを十分信頼できるものにするための努力をするが、必要以上の信頼性を求めない
8. サービスリスクの計測 多くのサービスでは、計画外の停止時間に注目する 可用性 = 稼働時間 / (稼働時間 + 停止時間) Googleではグローバルにサービスを展開しているので世界中のどこかのトラフィックが死ん でもどこかは生きている → リクエスト成功率に注目する 可用性 = 成功したリクエスト数 / 総リクエスト数
9. サービスのリスク許容度 安全性が極めて重要なシステムの場合と、そうでない大半の場合ではリスク許容度が大きく 異なる
10. エラーバジェットの活用 プロダクト開発チームとSREチームは異なるメトリクスのもと評価される 2つのチームに共通のインセンティブを与える仕組みがエラーバジェット エラーバジェットは、1つの四半期内でサービスの信頼性がどの程度損なわれても許容できる かを示す エラーバジェットが減ってきたらリリースの速度を下げる リリースの速度を上げたい場合はSLOを緩めてイノベーションを加速させることもできる
11. サービスレベル サービスを適切に管理するには、重要な振る舞いがどれか、その振る舞いの計測と評価の方 法はどうすればいいかを理解しなければいけない ユーザーに対するサービスレベルを定義することで、サービスが健全であるかどうかを確認 できるようになる
12. SLI(Service Level Indicators) サービスレベル指標の略で、慎重に定義された計測量のこと たとえば、リクエストのレイテンシや、エラー率、スループットなどがSLIになり得る サービスによって重要な指標はことなるため慎重に定義する必要がある
13. SLO(Service Level Objectives) サービスレベル目標の略で、SLIで計測される値の数値目標のこと たとえば、リクエストのレイテンシは100ms以下と設定した場合、SLIがそれを達成するよう に努力しなければいけない
14. SLA(Service Level Agreements) サービスレベルアグリーメントの略で、ユーザーとの間で結ぶ契約のこと SLAの中に含まれるSLOが満たされなかった場合の規定であり、主に金銭的な補償などがあ る たとえば、AWSのS3だと特定の稼働率を下回った場合にクレジットが受けられるとSLAが定 められている https://aws.amazon.com/jp/s3/sla/
15. SLOは常に満たさなくてもよい SLOを常に満たすことは現実的でなく、デプロイメントの頻度を落としてしまったり、保守 コストが高くなったりする エラーバジェットを用意してSLOともうまく付き合うことが大事 場合によってはSLOを緩めてデプロイメントの頻度を上げるといった選択も取れる
16. なぜSLOが必要なのか SLOは技術的側面から決めるものでなく、プロダクトやビジネスの事情、ユーザーの関心事 が反映されるべき SREやプロダクト開発者の仕事の優先順位を決める上で主要な要因になり、SLOを満たすよ うに開発することでサービスの健全性を保つことができる
17. トイルを撲滅したい トイルは直訳で「労苦」などといった意味を持つ SREは運用作業をするよりもエンジニアリングで解決する
18. トイルとは トイルは単にやりたくない・つまらない仕事ではない 以下に当てはまればトイルの可能性がある 手作業である 繰り返される 自動化できる 戦術的である(割り込み対応など) 長期的な価値をもたない サービスの成長に対して比例する
19. トイルの例 温かみのある手作業での定期的なDBバックアップ ローカルからの手動デプロイ 重要性の低いモニタリングアラートの確認 トイルでない ミーティングやゴールの設定、評価（オーバーヘッド） アラートの設定を整理する（長期的な価値がある）
20. なぜトイルを撲滅しなければならないのか トイルの性質上（サービスの成長に比例する）、あっという間に全員の時間がトイルで埋め 尽くされる可能性がある トイルばかりやっていると従来の運用チームと代わりなくなってしまう トイルの対応でなくエンジニアリングすることでSREの規模はサービスのサイズに比例しなく なり効率的に管理できるようになる キャリアの停滞や生産性の低下、不満の発生につながる
21. 自動化の価値 一貫性 手作業による間違いや見逃しを排除できる 高速な修正 平均修復時間（MTTR）が短縮される 時間の節約 その自動化されたものを利用する全員に効果が及ぶ
22. Google SRE にとっての自動化の価値 プロダクトやサービスは地球規模、自動化なしでは管理できない そのため、自動化のためのシステムを自前で構築してきた 短期的にはコストがかかるが、Google にとっての自動化領域は複雑であるため、プロダクト のスタック全体をコントロールできることが長期的には大きなメリットになる
23. 自動化の進化 自動化以前 フェイルオーバーが手動で行われる状態 外部でメンテナンスされるシステム固有の自動化 SRE がフェイルオーバーのスクリプトを持っている状態 外部でメンテナンスされる汎用の自動化 誰でも使える「汎用フェイルオーバー」スクリプトに、SRE がデータベースのサポ ートを追加した状態 内部でメンテナンスされるシステム固有の自動化 データベース自身にフェイルオーバーのスクリプトが同梱されてリリースされた状 態 システムが自動化を必要としない データベースが問題を検出し、人間の介入なしに自動的にフェイルオーバーを行う 状態
24. 単純さ ソフトウェアを単純にすることは、信頼性を持たせるための前提条件 本当に実現したいこととそれを最も簡単に行う方法を明確化する 想定外の複雑さを取り除く/生じさせない努力を継続的に行うべき 定期的な不要コードの削除 最小限の API モジュラー性 複数変更をまとめたリリースよりも単一の変更をリリース
25. サービスの健全性の階層構造 システムがサービスとして機能するための低レベルのものから高レベルのものまで階層化し て表すことができる 引用元: https://sre.google/sre-book/part-III-practices/
26. サービスの健全性の階層構造 アプリケーションエンジニアには馴染みのあるテストより下には3階層も存在する テストを全く書かずにプロダクションリリースできますか？ ポストモーテムやインシデントレスポンス、モニタリングが十分でないというのはそういう ことである
27. ポストモーテムの文化: 失敗からの学び ポストモーテムを書くことの主な目的 インシデントがドキュメント化されること 影響を及ぼしたすべての根本原因(群)が十分に理解されること 再発の可能性や影響を削減するための効果的な予防策が確実に導入されるようにするこ と
28. ポストモーテムを書くべきかの判断 ユーザーに影響が及んだダウンタイムやデグレーションが一定のしきい値を超えた場合 種類のいかんを問わず、データの損失が生じた場合 オンコールエンジニアの介入が必要だった場合(リリースのロールバック、トラフィック のルート調整など) 解決までの時間が一定のしきい値を超えた場合 モニタリングの障害(これは通常、人ででインシデントが発見されることになる)
29. ベストプラクティス: 非難を避け、建設的であり続けること ポストモーテムから非難を取り除けば、人々は自身を持って怖がらずに問題をエスカレーシ ョンさせるようになる 非難的な雰囲気はインシデントや問題を隠蔽する文化を醸成する危険性をはらんでいる
30. ベストプラクティス: ポストモーテムをレビューされないままにはしな い レビューされていないポストモーテムは、存在しなかったも同然 完成した下書きが確実にレビューされるようにするため、ポストモーテムのための定期的な レビューセッションを推奨
31. ベストプラクティス: 正しいことを行った人には目に見える報酬を 2014年のあるTGIFの事例 徹底したテストを行ったにもかかわらず、予想外のやり取りによって重要なサービスが4分間 ダウンした 担当のSREがロールバックを念頭においていたために、もっと長期間に渡る大規模サービスダ ウンを避けられた このSREは素早い冷静なインシデントへの対処について報奨と喝采を得た
32. ベストプラクティス: ポストモーテムの効果に対するフィードバックを 求める Googleでは、ポストモーテムのプロセス自体も改善しようとしている ポストモーテムを書くことでトイルが増えすぎていないか 自分のチームから他のチームに推薦できるベストプラクティスにはどんなものがあるか 開発してほしいツールにはどんなものがあるか
33. SRE内でのソフトウェアエンジニアリングの重要性 Googleのプロダクション環境は極めて大規模なので、サードパーティのツールが適応できな い コンシューマからは見ることのない多くのプロダクトをSREが開発している SREチームの人数を増やさずにサービスを成長させるため、プロダクション環境の日々の運用 を効率化する必要がある SREはエンジニアであり、コーディングのスキルを磨く機会もキャリア上必要
34. 他の業界からの教訓 多くの業界で、業界なりのポストモーテム的なことが行われている 製造業や化学業界の事例 重大な問題が実際に起こらなかった場合も、その可能性への「ニアミス」が注意深 く調査される イギリスのCHIRP(航空及び海運業のための秘密報告プログラム)では、秘密裏に報 告できる場所があり、ニアミスに関するレポートと分析が定期的にニュースレター で公開されるようにしている ライフセーバーの事例 重大なインシデントが発生した場合はチーム全体で端から端まで検証され、議論さ れる 将来の同様なインシデントに自信を持って対処できるようトレーニングが組まれる
35. 他の業界の自動化への取り組み 業界ごとに自動化への対応は様々 アメリカ原子力海軍の事例 潜水艦のバルブの操作は自動化しない 自動化やコンピュータはあまりに高速に動作するため、大規模で回復不能なミスが 発生しうる レーシック手術の事例 術前の眼屈折検査にて、手入力データの正常性チェックのコンピュータ化 バリデー ションができるようになった 患者の虹彩の写真を患者の虹彩と一致することをチェックして患者の取り違えがな くなった
36. 構造化された合理的判断 SREチームは構造的で合理的な方法によって判断を下すことを重要視している 判断の基準は事後に正当化されるのではなく、事前に合意されていること 判断の材料が明確であること 推定に過ぎないことはその旨がはっきり示されていること 感覚、直感、あるいは同席している最上級の社員の意見に基づく判断よりも、データに 基づく判断を優先すること サービスのユーザーの最善の利益を根底に置くこと 入手できるデータに基づいて物事を進める方法を導き出せること
37. まとめ SREはシステムの規模や速度が何倍になろうとも、エンジニアリングによって信頼性を保つ 飛行機の例 100年前にはエンジンが1つの飛行機に積荷の袋がいくつかとパイロットが1人、多くて2人だ った 現代では数百人の乗客に数トンの積荷、信頼性のある冗長化されたシステムが搭載されてい る しかし、パイロットは依然として2人である このようにSREチームはコンパクトさを保ちつつ、エンジニアリングによって信頼性や可用 性、パフォーマンス、モニタリング...などを解決していくのである