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