あけましておめでとうございます。
中途三年目の堀越です。
システムを保守・運用したり、可用性を担保しながら機能追加や新規開発を進めるのは簡単なことではないですよね？
課題として認識はしているものの具体的な対策を打てずにいましたが、
SRE というワードを耳にしてざっと調べたところ解決の糸口になりそうな気がしました。
とはいえ、雰囲気でやりたくないなあという思いもあったので読書会を開催する運びとなりました。
教材は、オライリー出版の「SRE サイトリライアビリティエンジニアリング (Googleの信頼性を支えるエンジニアリングチーム)」です。
ちょうど第1部を読み終えたタイミングですので軽く振り返ろうかなという内容となります。
では、はじめていきます。
はじめに *1
ソフトウェアエンジニアリングと子供を持つことの共通点
ソフトウェアエンジニアリングと子供を持つこととの間には、誕生の前の労苦も苦痛で大変だが、誕生の後の労苦の方が努力の大部分を占めるものだという共通点がある。
システム誕生前の段階では議論に時間を多く費やすものの、
トータルコストの40~90%はシステム誕生後に生じるものと推定される。
サイトリライアビリティエンジニアリングと呼ばれる分野
ソフトウェアエンジニアリングが設計と構築に焦点を当てるならば、
そもそもの始まりからデプロイと運用・改善、そして最終的に迎える平穏な撤去に至るシステムのライフサイクル全体に焦点を当てる分野がサイトリライアビリティエンジニアリング。
サイトリライアビリティエンジニアリング(SRE)とは何なのか？
SREは誰なのか？
SREはエンジニアである。
例えばどんなことをするのか？
- あるときは普通にソフトウェア開発をする。
- あるときはバックアップやロードバランスのような付加的なソフトウェアを再利用できるように構築する。
- あるときは既存のソリューションを新たな課題に適応する方法を見いだす。
SREはシステムの信頼性に焦点を置く
信頼性とは？
システムが求められる機能を、定められた条件下で、定められた期間に渡り、障害を起こすことなく実行する確率。
SRE提唱者の考え。
- 信頼性こそがあらゆるプロダクトの基本機能である。
- 誰も使えないシステムは、有益なものではありえない。
SREはシステムのスケーラビリティ、信頼性、効率性を向上させるために、設計と運用の改善方法を見つけることに集中する。
システムが十分な信頼性を持ったなら、機能追加や新プロダクトの構築に注力する。
DevOps との違い
SREは信頼性に焦点をおいている点において DevOps とは一線を画する。
加えて、運用の必要性を取り除くことを強く指向する。*2
小規模な組織におけるSRE
信頼性を早期に考慮する
信頼性の考慮は早ければ早いほど良い。小規模な組織には緊急性のある多くの懸念事項があり、早期に負担の軽い信頼性への取り組みを始めておく価値は十分にある。
これは新たな取組みを後回しにするより、既存の取り組みを拡張する方が負担が低くなることから。
信頼性の改善
どのような規模の組織においてもSREの仕事をしている人はすでに存在する。公式にその仕事を認知してもらうことや、そういった人々が行っていることを促進する、すなわち報酬を与えることは信頼性改善のきっかけになる。
SREどのような人々か？
一つのものの見方と、もう一つのものの見方の境目に立っている人々であり、世界最期の錬金術師と呼ばれたニュートンのような人々である。
1章 イントロダクション
1.1 サービス管理へのシステム管理者のアプローチ
従来のシステム管理者すなわち、シスアドを配置するアプローチに関して。
シスアドの役割
既存のソフトウェアコンポーネントのを組み合わせてデプロイしサービスを作る。
サービスを運用し、変更やイベントの発生のたび対処する。
シスアドの副作用
- システムが複雑化、トラフィックが増大するたびイベントや更新も増加することになり、シスアドチームも巨大化する。
- プロダクト開発者と求められるスキルセットが異なるので、「dev」、「ops」という別々のチームにわけられる。
シスアド適用のメリデメ
| メリット | デメリット |
|---|---|
| 業界で馴染みのあるパラダイムなので参考事例が多い。 | サービスの成長や、トラフィックの増大にはチームを大きくするしかない。 |
| 関連する能力を持つ人員を広く集められる。 | dev, ops それぞれのチームは異なる用語で対話し、リスクや安定性についても異なる想定をする。 |
| 既存のインテグレーションツールを利用してシスアドチームが熟練してなくても車輪の再発明を防ぐことができる。 | dev, ops、チーム同士の衝突を生む。 |
1.2 サービス管理への Google のアプローチ: サイトリライアビリティエンジニアリング
チームの構成
- チームメンバーにはソフトウェアエンジニアを積極的に採用する。
- 50~60% は Google の標準的なエンジニア。
- 残りの 50~40% はGoogle のソフトウェアエンジニアの必要条件をほぼ満たしていることに加えてSREにとって有益でありながらほとんどのソフトウェアエンジニアが持っていないような一連の技術スキルを持っているエンジニア。
作業内容
- シスアドとは異なり、ソフトウェアエンジニアにサービスを運用させる。
- 従来であればシスアドが手作業で行っていたであろう作業を遂行するシステムを構築する。
SREチームというアプローチの結果
手作業で行っていたタスクにすぐ飽きてしまい、それまで手作業で行っていたことを、たとえそれが複雑なものであっても、代替ソフトウェアを書くのスキルを持つエンジニア達のチームができあがった。
したがってSREは、運用チームが行ってきたことをソフトウェアの専門性をもつエンジニアが行い、手動管理を自動化するソフトウェアを設計し実装する能力を持ち、それをいとわないことにより成り立つ。
制約事項
チケット、オンコール、手作業といったいわゆる 「運用」業務の合計を50%以下 にするように、上限を設定。
なぜそうするのか???
- SREチームがサービスを安定稼働させるための 開発作業 の時間を十分に確保するため。
- これにより、シスアド戦略のように運用負荷拡大に対するアプローチに人材を増やす選択を回避できる。
このルールはどのように実行されるか
- SREがどのように時間を使っているかを計測する。
- 開発作業が50%以下となっていた場合は負担の一部を差戻したり、人の追加するなどして対応する。
SREのメリット
- システムの稼働、メンテナンス、改善に必要となる開発者の人数が、システムのサイズに比例して増えることがないため人的リソースを削減できる。
- プロダクト開発チームとSREチーム間の移動が容易なことで開発者のスキル改善に繋がる。
SREの課題
組織としてSREというアプローチを採用すること自体が課題となる。
なぜSREをやることが難しいのか???
- コーディングスキルとシステム構築力の両面で高いスキルが要求されるので採用の対象者が少なくなる。
- 目新しい概念なので業界内で情報が少ない。
- マネージメント層からの強力なサポートを要する。*3
1.3 SREの信条
SREチームは、サービスの可用性、レイテンシ、パフォーマンス、効率性、変更管理、モニタリング、緊急対応、キャパシティプランニングに責任を負う。Google は SREチームがどのような環境*4とやり取りすべきか業務の規範を明文化した。
以下は、Google の SRE の中核的な信条についての説明となる。
1.3.1 エンジニアリングへの継続的な注力の保証
運用作業を50%に制限するということは？
運用作業にかける時間に対し50%という制限を設け、残りの時間をコーディングスキルを使うプロジェクトの作業にあてることが求められる。
運用作業量をモニタリングして、超過した分をプロダクト開発チームへ差し戻す。この差し戻しは運用負荷が50%以下になったら終了する。
この取り組みは手作業の介入を必要としないシステム開発へ開発者を導く効果的なフィードバックとなる。
組織全体がこの仕組みを理解し、プロジェクトに過大な運用負荷を生じさせないという目標を支持することで、この取組みをうまく運用できる。
運用作業に注力する時間の目安
8時間から12時間の一度のオンコールシフトの間に受け取るイベントは平均して最大2つ。
これにより、下記のような作業時間を確保できる。
- イベントを素早く正確に処理する。
- クリーンアップと通常のサービスへのリストアを行う。
- ポストモーテムへの取り組みを行う。*5
2つ以上のイベントを受け取る場合はどうなるのか
- 問題を完全に調査できない。
- イベントから学び取ることができなくなる。
- スイッチングコストによる疲労が生まれる。
逆に、1つ未満のイベントしか受け取らない場合は時間の無駄になっていしまう。
1.3.2 サービスのSLOを下回ることなく、変更の速度の最大化を追求する
エラーバジェットの導入
プロダクト開発チームとSREチームは、イノベーションの速度とプロダクトの安定性という観点で対立する傾向にあるが、エラーバジェットはこの対立を解消する。
100%の信頼性を目標とすることは間違っている
100%の信頼性を目標とすることは適切ではない。なぜなら、100%と99.999%の可用性の違いは誰にも指摘できないからである。
ユーザーとシステムの間には別のシステム(ラップトップ、WiFi、ISP、電力網、etc...)が数多く存在しそれらをシステムの総体とすれば99.999%よりはるかに低くなる。
最後の0.001%を高めるためには莫大なコストがかかるのに対し、ユーザーには何らのメリットをもたらさない。
正しい信頼性の目標とは？
以下のことを考慮するべき。
- プロダクトの利用方法を踏まえて考えたとき、ユーザーが満足する可用性のレベルはどの程度か
- プロダクトの可用性に満足できなかったユーザーにとって、どのような代替策があるか
- 可用性のレベルを変更したとして、ユーザーのプロダクトの利用の仕方に何が起こるか？
エラーバジェットを設定する
システムの可用性のターゲットを明確にすることでエラーバジェットを設定できる。エラーバジェットはその可用性のターゲットを1から引いたものになる。
つまり、システムの可用性が99.99%ということは、0.01%は利用できないということであり、利用できないことが許容される%0.01がエラーバジェットとなる。
エラーバジェットの活用
エラーバジェットをローンチに関わるリスクを取るために使い、機能を早くローンチできるのが理想。
ローリングアップデートやカナリアリリースなどの手法により、エラーバジェットを節約するための、素早いローンチに向けた最適化が行える。
1.3.3 モニタリング
モニタリングはサービスの所有者がシステムの健全性と可用性を追跡するための主要な手段のひとつ。したがってその方針は、十分に検討して構築する必要がある。
これまで一般的だったモニタリングのアプローチ
特定の値や条件を監視し、閾値を超えたり条件が満たされた場合に、メールのアラートを発するというようなもので、これは効果的なソリューションではない。
人間がメールを読み、何らかのアクションの必要性を判断しなければならないシステムは、根本的に欠点をかかえている。
アラートのどの部分をとっても人間の解釈が必要であってはならない。ソフトウェアが解釈を行い、人間はアクションを行わなければならないときにのみ通知を受け取るようになっているべき。
効果的なモニタリング
効果的なモニタリングの出力には、３つの種類がある。
| 名前 | 説明 |
|---|---|
| アラート | 人間が即座にアクションを起こして対応し、状況を改善しなければならないことが生じている、あるいは生じていることをしらせる。 |
| チケット | 人間がアクションを起こさなければならないことを知らせる。 |
| ロギング | この情報を人間が見る必要はないもの、診断もしくはフォレンジックのために記録されるもの。ログは何かが起きない限り、誰かが読むことは期待されていない。 |
1.3.4 緊急対応
平均故障時間(MTTF)*6と平均修復時間(MTTR)*7
信頼性は、平均故障時間と、平均修復時間との関数である。緊急対応の効率を評価する上で、最も関係のあるメトリクスは対応チームがシステムを健全な状態に戻すのに用した時間、すなわちMTTRである。
手順書を用意しておくことの重要性
障害修復に人間が関わらなければならない場合は、ベストプラクティスを事前に十分に考えておき、手順書に記載しておく。
手順書に記載しておくことにより、即興で対応を行った場合と比較してMTTRに 3倍 の改善が見られた。
Google SRE は手順書を使って「不運の輪」、すなわち防災訓練のように障害対応の練習を行う。
1.3.5 変更管理
SREは、障害の70%が動作中のシステムの変更によって生じていることを発見した。この領域におけるベストプラクティスは自動化によって実現することである。
- 漸進的なロールアウトの実装。
- 高速かつ正確な問題の検知。
- 問題が生じた際の安全なロールバック。
この3つで1組のプラクティスは、下記のメリットがある。
- 不備のある変更にさらされるユーザーや、運用の総数を効率的に最小化。
- 繰り返しの多いタスクに対する疲労、慣れ/軽視、不注意の回避。
- リリースの速度と安全性が共に高まる。
1.3.6 需要の予測とキャパシティプランニング
キャパシティプランニングとは
予想されている未来の需要に対して、必要な可用性を提供できる十分なキャパシティと冗長性を保証すること。
キャパシティプランニングで考慮すべきこと
- 自然な成長
- 顧客によるプロダクトの採用と利用から自然に生じるもの。
- 突発的な成長
- 機能ローンチ、マーケティングキャンペーン。
- あるいはその他のビジネス的な変更といった出来事によって生じるもの。
キャパシティプランニングのステップ
キャパシティは可用性にとって極めて重要なので、SREチームはキャパシティプランニングを担当し、プロビジョニングにも関わる。
1.3.7 プロビジョニング
プロビジョニングとは
変更管理とキャパシティプランニングの双方の組み合わせ。
プロビジョニングの原則
正確かつ素早くかつ必要な場合にのみ行うべきである。さもないと必要なときに必要なキャパシティが活用できなくなる。したがってプロビジョニングには細心の注意を払わなければならない。
1.3.8 効率とパフォーマンス
サービス効率性の3要素
- 需要(負荷)
- キャパシティ
- ソフトウェアの効率性
負荷が上がり続けるとシステムの速度は低下し、最終的には反応を返さなくなる。
これは速度が無限に低下した状態とも捉えることもできる。
SREは特定のレスポンス速度のキャパシティのターゲットを満たすようプロビジョニングを行うので、サービスのパフォーマンスに強い関心を持つ。
サービスのパフォーマンスを改善するためにモニタリングと改修に努めなければならず、そのためキャパシティを追加して効率性を改善する。
1.4 始まりの終わり
SREはこれまでの業界のベストプラクティスとは大きく離脱している。
もともとの動機は「ソフトウェアエンジニアなんだから、繰り返しの作業なんかはこうやって片付けたい」という発想だったものの、今はそれ以上のもの、すなわち一連の指針、プラクティス、動機付け、そしてソフトウェアエンジニアリングという領域の中の注力分野となった。
以降で、SREについて詳細に見ていく...。
（今回はここまで）
終わりに
いい感じにまとめてシュッとさせたかったのですが重要な文献が多く、蓋を開けてみるとに写経に近い感じになってしまいました。
さすがにこの粒度で書き続けるのはちょっと厳しいので、SLO・SLI・SLA、エラーバジェット、ポストモーテムなど重要なトピックにフォーカスして書けたら良いのかなと思いました。
ブログを書いている間に読書会も回数を重ね、すでに4章に突入しました。社内での関心度も高いので引き続き継続していきます。
では、また。
*1:SRE本の「はじめに」を指します。
*2:インフラストラクチャをコードとして捉える点は DevOps と共通している。
*3:エラーバジェットの消費状況から四半期の残りの期間はリリースをやめるなどの強い判断が必要な場合など。
*4:この環境には実働環境のみならず、プロダクト開発チーム、テスティングチーム、ユーザーなども含まれる。
*5:いわゆる障害報告書。
*6:平均故障時間: mean time to failure = MTTF
*7:平均修復時間: mean time to repair = MTTR
*8:キャパシティのリソース確保に必要なリードタイムも考慮する。
*9:サーバーやディスクなど。
