読者です 読者をやめる 読者になる 読者になる

感想:Site Reliability Engineering

Site Reliability Engineeringを読んだので、感想と個人的な各章のサマリ(備忘メモ)です。

shop.oreilly.com
Google - Site Reliability Engineering

なお私はソーシャルゲーム会社のインフラエンジニアで、CM対策などを含めた大規模インフラの経験はありますが、ビッグデータ的な分散処理基盤はあまり経験していません。

[感想]

SLO大事

SLO(Service Level Objectivesの略。稼働時間や遅延などのサービスの健全性を示す指標に対する目標値)の策定と自動化を進めて、インフラの雑務(toil)を削減することが大事だなと思いました。

「Error Budget」の概念に注目されている本ですが、「Error Budget」に基づいた運用をする/しないに関わらず、SLOを策定して自動化を進めることがSREチームのスタート地点になるのかなと思いました。
SLOを定めることで、サービスにとっての障害が何かを定義できて、作業スコープを明確にできます。その上で自動化を進めると、作業時間の短縮ができ、「Error Budget」に基づいたチーム運営もできるようになり、またインフラエンジニアの燃え尽きも防げるという主張は、その通りだなと思いました。

Error Budgetについて

私は賛否両方あると考えています。エンジニアの観点では賛成で、サービスの運用者としては悩ましいと感じました。

「Error Budget」としてクォーター毎にSLOを下回ってよい時間を定義しておき、「Error Budget」が残っているうちはアグレッシブなリリースをしたり、障害対応をon-call担当に任せて非on-call担当のエンジニアが開発に専念できるのは、エンジニアとしてはとても仕事がしやすいなと思いました。

一方でサービスの責任者から見ると、インフラは動いていてナンボなので、イノベーションのために多少のSLO違反は許容してというのは心理的に受け入れづらそう。極論すると、必死に盛り上げているサービスが、アグレッシブなリリースで水を差されたら、企画している人たちは嫌だろうなと。
そうしたデメリットをイノベーションが上回ると説得できればよいけど・・。「Error Budget」を低めに設定するとあまり意味がないので、まだいい落としどころが自分の中でついていないです。*1


[各章サマリ]

本を買わなくていいじゃん!とならない範囲で書きます。
「Chapter 1 : Introduction」もインパクトありましたが、「Chapter 21 : Handling Overload」と「Chapter 26 : Data Integrity: What You Read Is What You Wrote」が私のこれまでの業務・興味との重なりが大きく、特に面白かったです。

Chapter 1 : Introduction

SREとは?Error Budgetとは?という内容。

Chapter 2 : The Production Environment at Google, from the Viewpoint of an SRE

Googleのシステム構成について。Borgやストレージスタック、SpannerやChubbyなどの概要。

Chapter 3 : Embracing Risk

稼働率100%を目指すと超高コストになるので、コストやサービスの内容(売上や人命に関わるとかの特性など)を踏まえて、妥当なSLOを策定しようという話。

Chapter 4 : Service Level Objectives

SLOやSLIなどの用語説明と、いい感じのSLOの運用方針について。

Chapter 5 : Eliminating Toil

タイトルそのまま

Chapter 6 : Monitoring Distributed Systems

Googleの監視システムの思想について。

Chapter 7 : The Evolution of Automation at Google

Googleの自動化の変遷。

Chapter 8 : Release Engineering

Googleのコードのデプロイと、設定変更の本番反映についてちょっと具体的な話。

Chapter 9 : Simplicity

コードはシンプルなほうがいいとのこと。

Chapter 10 : Practical Alerting from Time-Series Data

Googleがどのように監視用のデータを時系列で作成・保持し、アラートを飛ばしていたかの詳細。
現監視システムでなく、過去に10年使っていたborgmonについての話。

Chapter 11 : Being On-Call

Googleが障害対応担当をどうローテーションしているかについて。
かなりエンジニアの燃え尽き(burn out)に気を配っている感じ。

Chapter 12 : Effective Troubleshooting

Googleの障害解析のアプローチについて。
全体的には普通のアプローチだけど、根本原因の追究が徹底的なのと、解決が自動化 or ツール化なのがGoogleらしい気がしました。

Chapter 13 : Emergency Response

Googleで起きた障害とその対応のケーススタディ

Chapter 14 : Managing Incidents

障害対応時の役割分担について。
Googleは簡単な障害は自動復旧の仕組みがあるので、人手が必要な大規模/複雑な障害の時の話。

Chapter 15 : Postmortem Culture: Learning from Failure

Postmortem(障害報告書)とは何か、どう運用しているかの話。
postmortem自体は、google以外の会社でも結構よく聞きます。

Chapter 16 : Tracking Outages

Googleが使っている障害管理システムのご紹介。

Chapter 17 : Testing for Reliability

Googleが実践しているテストの話。

Chapter 18 : Software Engineering in SRE

Auxonというキャパシティプランニングツールの構築を例にした、SREのソフトウェア開発について。
新ツールをどう社内で普及させるかという泥臭い話もあり。

Chapter 19 : Load Balancing at the Frontend

Google流のDNS Load Balancingの話。

Chapter 20 : Load Balancing in the Datacenter

GoogleのDC内のロードバランサについての話。
Googleはユーザのリクエストを、Chapter19のDNSで地理的に最適なDCに割り振ってから、本ChapterのとおりDC内でL7レイヤの振る舞いをするLBで負荷分散しているそうです。

Chapter 21 : Handling Overload

高負荷時の望ましい振る舞いと、その実装について。
個人的にあまり考えてこなかった内容なので、とても勉強になった章でした。

Chapter 22 : Addressing Cascading Failures

障害の連鎖をどう防ぐかという話。Chapter21から繋がっている内容で、具体的な対策もあり。

Chapter 23 : Managing Critical State: Distributed Consensus for Reliability

分散合意システムでどう信頼性を担保するかという話・・と思いますが、この分野の経験が足りなくてうまく読めなかった章です。

Chapter 24 : Distributed Periodic Scheduling with Cron

Googleの超大規模・分散システムでcron的な処理をどうやって実現しているかの話。

Chapter 25 : Data Processing Pipelines

GoogleはWorkFlowというツールを作って、いい具合にデータ処理を並列処理しているとのこと。あまりこの賞は深読みしなかったので違うかも・・

Chapter 26 : Data Integrity: What You Read Is What You Wrote

バックアップ/リストアの話と、データ不整合の対策について。
優秀なエンジニア達が、多くのコストをかけて、本気でデータ保全を検討して実装した内容が書いてある章で、すごく学びが多かったです。

Chapter 27 : Reliable Product Launches at Scale

Launch Coordination Engineering(LCE)という、サービスローンチを専門にしたエンジニアの紹介。

Chapter 28 : Accelerating SREs to On-Call and Beyond

新しくSREに加わったメンバーをOn-Callを担当できるまで育てるプロセス。

Chapter 29 : Dealing with Interrupts

SREチームはサービス横断的な組織で、また障害対応を受け持っているため、作業の割り込みが増えがちなので、それをどう処理するかという話。個人的には作業の割り込みは苦にならないけど、チームで苦手にしている人が多かったので、うまく配慮できるようになりたい。

Chapter 30 : Embedding an SRE to Recover from Operational Overload

運用負荷が高まっているチームにはSREを1名派遣して、根本原因を取り除いて立て直すhow to気味な章。
SRE的な仕事が根付いていないチームを、SRE文化に変えていくときにも参照できそうな内容。

Chapter 31 : Communication and Collaboration in SRE

SREとプロダクトチーム、または複数拠点に分散しているSREチーム同士が、どのように連携すると良いかのGoogleケーススタディとベストプラクティス。

Chapter 32 : The Evolving SRE Engagement Model

SREがどうプロダクトに貢献するかという話。プロダクトのリリース後にチームに参加するパターン、開発中に参加するパターンを経て、フレームワークを提供するパターンに変遷してきたとのこと。

Chapter 33 : Lessons Learned from Other Industries

医療や軍隊、ライフガードなど別産業から、参考にしたアイデア集。
Chapter 26の実装の背景にもなっていそうで、読み物としても面白い。

Chapter 34 : Conclusion

全体のまとめ。

以上です。
英語版を買ったものの、積読しているうちに英語版が無償公開され、日本語版まで発行されそうになったので、焦って読みました。

*1:私がソシャゲというコンテンツの力が大きい業界のエンジニアで、接続エラーで離脱したユーザはインフラのイノベーションでは帰ってこないと思えるため、こうした考えになっているのかもしれない。