7-TheEvolutionOfAutomationAtGoogle.md

7 The Evolution of Automation at Google

• 自動化(automation)は万能薬ではなく、力の乗算機
• 力の乗算機はそれがない場合と同じ結果になる必要がある
  • 自動化はよく考えて行う必要がある。そうしないと自動化が解決する問題よりも多くの問題が発生する
• ソフトウェアによる自動化はほとんどの場合手動操作よりも優れている。どちらよりも更に優れているのは自律動作するシステムのような、高度な設計
• この章では自動化の価値と時間による自分たちの態度の変遷について記載

The Value of Automation(自動化の価値)

Consistency(一貫性)

• 自動化の明白な動機はスケールすることだが、それ以外にもたくさんの理由がある
• 大学のコンピューティングシステムではユーザアカウント作成やDNSの設定変更などを、手で実施しているが、組織や本人にとって満足のいくものではなかった
• 同じ操作を何度もされるが、一貫した方法では実施されない
• 一貫性の欠如は、見落とし、データ品質の問題、ミス、信頼性の問題に繋がる
• well-scopedな知られた手続きの実行という意味での自動化において、一貫性は自動化の第一の価値である

A Platform

• 設計されてうまく動く自動化システムは拡張可能でたくさんのシステムに適用できるプラットフォームを提供する。利益のためにスピンアウトすることさえある(spin outとは？製品として売りだすとかそういうこと？それとも、廃止すること？)
• 自動化されたシステムは、既に動いているプロセスを深く理解することを可能にするという点で、それ自体で価値がある
• 自動化されていないシステムはコスト的に悪く、また拡張可能でもない。これは、システムの運用に対して税として課される
• プラットフォームはミスを一元化する
• 自動化されておらず人間が実行している場合と異なり、一度コードが修正されれば二度と起きなくなる
• タスクを追加するのも人間にタスク追加を指示するよりも簡単
• 人間が実行する場合と比べて、タスクの性質に応じてより何度も実行したり常に実行させたりが可能になる
• プラットフォームはタスクのメトリクスを出力することができる。プラットフォームという文脈では、タスクの計測が楽になるので、タスクの詳細を知ることができるようになる

Faster Repairs

• 自動化が適切に動けば一般的なシステムの問題に対してのMTTR(mean time to repair)を下げることができる
• MTTRの減少により、問題を防いだりクリーンアップしたりすることに時間を使う必要がなくなり、それによって他のタスクに時間を費やしてベロシティを上げることができる
• 問題の発見がプロダクト・ライフサイクルの後になればなるほど修正コストが高くなるので、動いた瞬間に問題を発見するようなシステムはコストを下げるのに役立つ

Faster Action

• 人間は一般的に機械ほど素早く反応できない
• 例えば、fail overシステムにおいて、人間が"fail overを続けます"ボタンを押す必要はない
  • もちろん自動化が時として事態をより悪くする場合もあるが、それは自動化された手続きが、よく定義されたドメイン上にスコープされるべき理由である

Time Saving

• 時間の節約は、自動化の利点としてよくあげられるが、そんなに明確な話ではない
• エンジニアは自動化にかかるコストとそれを手で行うコストの比較をして、自動化を行うかどうかを迷う
• 一度、いくつかのタスクをカプセル化して自動化すると、他の人はだれでも実行できるようになるというのを見過ごしがちであり、時間の節約はそれを使い得る全ての人に適用される
• 自動化されないと、手作業のために人を雇い、人類の血と汗と涙で機械を管理する必要がある

The Value for Google SRE(Google SREの価値)

• 上記の利点やトレードオフはGoogleにも適用され、Googleは自動化に向けた非常に強いバイアスを持っている
• Googleは世界規模のサービスを提供しており極めて巨大なので、手作業をしている余裕はない
• 一貫性と素早さと信頼性は自動化のトレードオフについての会話を支配している(それらのためにはトレードオフはそんなに問題にならないということだろう)
• Googleにおいて、自動化を支持するもう一つの要因は、第2章で説明した、複雑だが驚くほど均一なプロダクション環境
• Googleはアクセス可能なAPIを持っていなかったり内部のソースコードが存在しなかったりその他プロダクションのオペレーションで完全に制御することを拒むような製品を避ける
• ベンダからAPIを提供されない場合は自分でAPIを構築する
• 特定のタスクのための製品を購入することは短期的には安く済むが、長期的なコスト削減のためのAPIを構築するため、自分たちでソリューションを作り上げることを選択する
• Googleは自動システム管理の自動化のための障害を取り除くことに多くの時間を費やし、またシステム自身が自分を管理するような自動システムを開発してきた
• Googleがそのソースコードをどのように管理しているか(The Motivation for a Monolithic Codebase:)については、SREがさわるシステムのソースコードへ触れることは、また、"own the product in production(プロダクション環境の中のプロダクトを保持する？？？)"へのSREのミッションが、全てのスタックをコントロールできるという理由で圧倒的に簡単だということを意味している
• 現実的には、全てをシステム自身で自動管理できるわけではない
• 全てのコンポーネントを自律管理できるわけではないし、人によって自動化をすすめる能力などの違いがある
• 重要なシステムの中には持続する設計になっていなかったり自動化のためのインターフェースの存在しない迅速なプロトタイプとしてスタートしたものもある(大変そうですね)
• 前の章(アクセス可能なAPIをもってないものを避ける等)では自分たちのポジションに対する過激な発言をしましたが、one that we have been broadly successful at putting into action within the Google context.
• 一般的には、私たちはplatformを作ることを選んだ。もしくは、自分たち自身をplatformを作れるようなポジションにおいているので、我々はplatformを作れるようになってきた
• 私たちは、このplatformベースのアプローチを管理のしやすさとスケーラビリティのために必要だと感じている

The Use Cases for Automation

• 業界では、一般的に自動化という用語は様々な問題を解くためにコードを書くこととなっている
  • そのコードを書くモチベーションや解決策それ自体は全くちがうものなのに
• ここでは、自動化をより広く捉え、自動化をメタソフトウェア(ソフトウェアに従うソフトウェア)として扱う
• 自動化のユースケースの非網羅的リストは以下のとおり
  • ユーザアカウント作成
  • サービスに対するクラスタの投入/外し
  • ソフトウェアやハードウェアのインストール準備/廃止
  • 新しいソフトウェアのデプロイ
  • 設定の変更
  • 特別な設定の変更: 依存の変更

このリストは無限に続く

Google SRE's Use Cases for Automation

• SREの主な親和性はインフラの上を通るデータの質を管理することではなく、インフラを動かすことにある。
• この行は完全に明確ではない。例えば、私たちは、デプロイによってデータの半分が消失することを非常に気にかけているので、粗い違いについて気にかけているが、細かいデータの変更の同等性について書くことはほとんどない
• 従って、自動化はしばしばシステムのライフサイクルの管理であり、データの管理ではないというコンテキスト。例えば、新しいクラスタへのデプロイ。
• この範囲で、SREの自動化努力は他の人や組織がしていることと、別の焦点を持ち別のツールを使う(後で議論する)ことを除けばそんなに離れていない
• Puppet, Chef, cfengine, そしてPerlのような、特定のタスクの自動化の方法を提供する、広く利用可能なツールは、自動化の行為を助けるために提供されるコンポーネントの抽象化のレベルの点で主に異なります。
• Perlのような言語は理論的にシステムにアクセスするAPI全体で自動化の無制限の範囲を提供するPOSIXレベルのアフォーダンスを提供する一方でChefやPuppetはサービスの、より高いレベルでの画期的な抽象化を提供する
• 上記のトレードオフは古典的。より高いレベルの抽象化は管理し、理解するのは簡単だが抽象化の漏れがあった際にシステム的に、繰り返し、失敗し、潜在的に一貫しない状態となる
• 例えば、我々は新しいバイナリをクラスタにpushすることはアトミックである(最終的に古いバージョン化新しいバージョンのどちらかとなる)ことを前提としている
• しかし、我々の世界はもっと複雑であり、クラスタのネットワークが片道だけ失敗しうるし機械は失敗しうるしクラスタ管理システムとの疎通が切れえるなどで、システムが一貫性のない状態となることがある
• 状況に応じて新しいバイナリはstageに乗るがpushされていなかったりpushされてもrestartしなかったりrestartしても確認できなかったりし、ほとんどの場合は最終的に停止して介入を要請する。本当に最悪な自動化は、介入の要請すらしない
• SREはたくさんの自動化についての哲学及び製品を持っている
• 特定の詳細なモデルのない一般的なデプロイツールもあれば非常に抽象的なレベルでサービスを記述する言語もある
  • 後者は前者よりも再利用しやすくより共通のプラットフォームとなる。しかしGoogleの本番環境の複雑さは、前者のアプローチの方が最も扱いやすい選択肢となる

A Hierarchy of Automation Classes

この節の前半部分、全体的に全然意味がわからなかった

• それらの自動化のステップは価値があり、自動化のプラットフォームもそれ自身価値があるが、理想の世界では外部化された自動化は必要ない
• 実際、外部のグルー・ロジックをもつ必要があるシステムの代わりにグルーロジックを全く持たないシステムのほうが良い
• それは内部化がより効果的だからというだけではなく、グルーロジックを最初の場所で必要のないようにデザインされているからである
• それの達成は、グルーロジックのためのユースケースを取得(一般的に、アカウントの追加やシステムのリリース(: turnup)のようなシステムの最初の命令操作)すること及びそれらのユースケースをアプリケーションの中で直接扱う方法を見つけることと関連する
• より詳細な例を出すと、ほとんどのturnup自動化は問題をはらんでいる。なぜならそれらはコアシステムとは分離して保持され、従ってbit rotに苦しめられる。換言すれば、下にあるシステムの変更があっても変更されずにいるなど。
• 最高の注意にもかかわらず、リリースの自動化とコアシステムをより強くつなごうとする試みは優先度が直列化されていないためしばしば失敗する。なぜなら、開発者は全変更の際にテストデプロイを行うことに抵抗するからである
• 第二に、極めて重要だが稀にしか実行されずテストが難しい自動化は少ないフィードバックサイクルによりしばしば特に壊れやすい
• クラスタのフェイルオーバはあまり実施されない自動化の典型的な例です
• 自動化の進展は以下のパスをたどる
  • 自動化なし
    • DBのmasterのフェイルオーバは手で実施される
  • システム固有の、外部管理されている自動化
    • SREは自分のホームディレクトリ内にフェイルオーバスクリプトがあります
  • 一般的な、外部管理されている自動化
    • 皆が使っている一般的なフェイルオーバスクリプトにDBのサポートを追加する
  • システム特有の、内部管理されている自動化
    • DBは自分自身のフェイルオーバスクリプトと共に動く
  • 自動化が不要なシステム
    • DBが自分で問題に気付き、人間の介在なしで自動でフェイルオーバする
• SREは手動のオペレーションを嫌うので、手動のオペレーションが不要なシステムを構築しようとする。しかし、しばしば手動のオペレーションは避けられない
• 加えて、特定のシステムに関連した設定ファイルの領域を通してではなく、製品全体の領域を通しての変更の適用という、自動化の亜種がある
• Googleのような高度に中央集権された環境では、サービス特有ではない変更が大量に行われている
• 例えば、Chubbyのupstreamサーバの変更、BigTable Clientがより信頼性の高いデータアクセスを行うためのフラグの変更、等など
• それらは安全に管理され、必要であればロールバックされる
• 変更量が一定を越えると手動での適用は不可能となる。そしてしばしばそのポイントの前に変更の大部分は自明か基本的なデプロイしては確認する戦略で成功している場合のプロセスのための手動の漏れは無駄である
• それでは、先行するいくつかのポイントを詳細に説明するために、内部ケーススタディを使用してみましょう。
• 最初のケーススタディは、どのように、幾つかの真面目で遠慮のある仕事によって、SREの自称の涅槃(ジョブの外の彼ら自身を自動化する)への到達を管理するかである

Automate Yourself Out of a Job: Automate ALL the Things!

• 2005~6年、広告プロジェクトはデータをMySQLに入れていて、SREが面倒を見ていてslaveの置き換えなどある程度は自動化していたが、次のステップとしてBorgにマイグレートすることにした話
• SREはBorgへのマイグレーションが以下2点のメインの価値を提供すると願っていた
  • machineやreplicaのメンテナンスタスクを完全に消しされる。Borgは新しいタスクや失敗したタスクを自動的に開始/再開の管理をしてくれるので
  • 複数のMySQLを1つの物理マシンに入れることができる。Borgはマシンリソースを効率よく使うように作られているため
• 2008年には、テストとして、MySQLインスタンスをBorgにデプロイすることに成功した
• しかし、Borgでの稼働は重大な別の問題が伴っていた
• Borgの特徴はタスクが自動で動いていくこと
• タスクは週に1~2回動き、この頻度での移動はslaveは耐えられるが、masterは耐えられない
• masterのfailoverは30-90分かかっていた
• カーネルのアップデートのためやその他様々な原因により、MySQL自体には関係のないfailoverが毎週発生した
• この問題は、DBのシャードの数から計算すると、以下を意味した
  • マニュアルのfailoverによって人間の時間を消費し、最高の想定されるケースでも、DBの稼働率はビジネス的にプロダクトが必要としている稼働率よりも低く、99%のuptimeになることが想定された
  • エラーバジェットを満たすため、failoverはdowntime30秒以内に実施される必要があった。人間がfailoverする方法では30秒以内にfailoverする方法はない
• なので、とれる選択肢はfailoverを自動化するしかなかった
• 2009年にはDiciderと名付けられた、手動実行でも自動実行でも95%tileで30秒以内にfailoverする自動failoverデーモンを広告のSREチームは完成させ、それによってBorg上のMySQL(MoB)は現実のものとなった
• failureが避けられないという発想によって、failoverの欠如したインフラから卒業できた。そして、それによって自動化を通して素早く回復することに最適化することができた
• 上記ではだめで、全てのアプリケーションは以前よりもかなり多くの障害処理ロジックを含むように変更しなくてはいけなかった
• MySQLでの開発の世界はのノルマは、MySQLのスタック部分が最も安定したコンポーネントであることが当然であり、BorgへのスイッチはJDBCのようなソフトウェアを、障害の起きやすい環境において、より堅牢にカスタマイズすることを意味したが、MySQL over Borg及びDeciderはそのコストを払う価値があった
• MoBによってチームが日常的に払うopsタスクが95%減った
• failoverは自動化されており、単一DBの障害が人間をpageすることはなくなった
• この新しい自動化の結末は、別の部分のインフラを改善するためにより多くの時間を費やせるようになったことです
• このような改善は連鎖的な効果を発揮する
• 時間を節約すればするほど、より多くの退屈な仕事を最適化し、自動化することができる
• 最終的に、スキーマの変更を自動化し、広告DBの全ての運用タスクの95%を削減できた
• ジョブの外の自分たちを自動化することに成功したといえるかもしれない
• ハードウェア側にも改善が見られた
• MoBへの移行は、複数のMySQLインスタンスを同じマシン上で動かすことも可能であり、それにより大量のリソースが開放され、ハードウェアの6割を開放することができた
• この例は手動作業を置き換えるというよりは、プラットフォーム(この場合は多分Borg)を提供することに力を入れることの知恵を示している
• クラスタインフラストラクチャからくる次の例は、全てを自動化する上でのより困難なトレードオフを示す

Soothing the Pain: Applying Automation to Cluster Turnups(痛みを鎮める。クラスタのturnupに自動化を適用する)

• 10年前、クラスタインフラストラクチャSREチームは数ヶ月に1人新たに雇われていた
• これは、新しいクラスタが構築される頻度とほぼ同じ頻度だった
• なぜなら、新しいクラスタにサービスを動かすと、新しく雇用された人はサービスの内部を知る必要が出る。そのタスクはトレーニングツールとして便利だった
• クラスタが使えるようになるには以下のようなステップがある
  • 1. 電力と温度から、適合するデータセンターを選定する
  • 2. コアスイッチをインストール/設定し、バックボーンに接続する
  • 3. 初期のサーバラックをインストールする
  • 4. DNSとinstallersのような基礎サーバを設定し、その後ロックサービス、ストレージ、コンピューティングを設定する
  • 5. 残りのマシンのラックをデプロイする
  • 6. ユーザ向き合いのサービスリソースを割り当てる。これによってサービスのセットアップが可能になる
• ステップ4, 6は非常に複雑である。DNSは比較的単純である一方、ストレージとコンピュートは当時はまだ開発が活発であり、新しいフラグやコンポーネント、最適化が毎週のように追加されていた
• 100以上の異なるコンポーネントサブシステムを使っているサービスもあった
• あるサブシステムの設定を誤ったり、別のクラスタとは異なるような設定を行ったりすると、顧客に露呈する障害が起き得る
• あるケースでは数ペタバイトのクラスタが12個のdiskで構成されたシステムの最初のディスクをレイテンシの理由で使わない設定がされていた
• 1年後、自動化システムは、マシンの最初のdiskが使われていない場合、そのマシンはストレージが設定されていないと認識するようになった。これにより、安全にマシンを初期化し、セットアップすることができるようになった
• 突然、全てのBigTableのデータが消滅した
• 幸いなことにデータセットの複数のリアルタイムReplicaが存在したが、しかしそのような驚きは歓迎しない
• 自動化は、明示的な"安全"シグナルに頼ることについて慎重である必要がある
• 早期の自動化はクラスタの配備を加速させることに集中していた
• このアプローチは退屈なパッケージ配備や初期化の問題のためにクリエイティブなsshの使い方に頼る傾向があった
• この戦略は最初は良かったが、それらのフリーフォームスクリプトは技術的負債のコレステロールとなった

Detecting Inconsistencies with Prodtest(本番環境でのテストによるによる矛盾の検知)

• クラスタの数が増えるにつれて、手でチューニングされたフラグや設定を必要とするクラスタが出てきた
• 結果として、チームは設定のミスを追いかけるのに非常に多くの時間を費やしていた
• もしGFSのログプロセスの反応をよくするフラグがデフォルトテンプレートから漏れていた場合、たくさんのファイルを持つcellは、負荷がかかった際にメモリが不足する場合があります
• 激高や時間の消費を誘う設定ミスは全ての設定の大規模変更に忍び寄っていました
• クラスタの設定に使用している、クリエイティブだが脆いシェルスクリプトは変更をしようとしている人の数にスケールしないし、ビルドを必要としている非常に多くのクラスタの順列にもスケールしない
• これらのシェルスクリプトは顧客向けのトラフィックを受けて良かったと宣言するための、より重大な関心を解決することを失敗しました。例えば以下のような
  • 全てのサービスの依存は正しく設定されているか
  • 全ての設定とパッケージは他のデプロイと独立しているか
  • チームは全ての設定の例外は望んでいるものだと確認できるか
• prodtestはこれらの問題に対する賢い解決策です
• Pythonのユニットテストフレームワークを実世界のサービスをテストできるように改良した
• これらのユニットテストは依存を持っていて、複数のテストの連続実行を許可し、一つのテストが失敗したら素早く実行を中止する
• Figure 7-1にDNS serviceのprodtestの図がある
• あるチームのprodtestはクラスタ名を必要とし、そのクラスタ内のチームのサービスの正しさを検査できる
• 後でユニットテストとステータスの表を生成する機能も追加された
• この機能によって彼らのサービスが全てのクラスたにおいて正しく設定されているか、もし違った場合はなぜなのかをを素早く確認できるようになった
• 表はfailしたstepをハイライトし、失敗したPythonのunitテストはより詳細なエラーメッセージを出力する
• configのミスが発覚する度にprodtestを分厚くしていくことで素早く問題が発見できるようになっていき、全てのサービスが正常に動いていることを保障できるようになった
• その環境で、ネットワークが使えるようになってからサービスインできるまでだいたい6週刊くらいかかっていたが、突然、"3ヶ月以内に5クラスタがネットワーク使えるようになるからそれから1週間でサービス投入して"という話が来た

Resolving Inconsistencies Idempotently(非一貫性を冪等に解決する)

• 1週間でサービス投入するのは大変すぎる
• prodtestによって素早く問題が発見できるようになったが、1クラスタ毎に数百のバグがある
• Pythonは設定のミスを見つけるのではなく、設定のミスを直せばいい！ということに気付いた
• ユニットテストはどのクラスタのどのテストが失敗しているかを知っているので、各ユニットテストに対応する修正スクリプトを書けば良い
• 各修正が冪等であれば、問題の修正は安全なものになる
• 冪等性により、15分に1度修正スクリプトを動かしてもクラスタのコンフィグにダメージを与える心配がない
  • 後の話を見る感じ、15分に1度実際にテストが走って自動的に修正しているっぽい気配を感じる
• DNSチームのテストが新しいクラスタのDBチームの設定をブロックしている場合、DBにクラスタのクラスタの設定が入るとすぐにDNSチームのテストがDNS設定を修正し、動き始める
• Figure7-2を見るとわかるが、各テストに対応する修正スクリプトが存在し、テストが失敗するとそれに対応するスクリプトが呼ばれる
• TestDnsMonitoringConfigExists が失敗すると FixDnsMonitoringCreateConfig が呼ばれて設定をDBから取得してバージョン管理システムにコミットされる
• その後TestDnsMonitoringConfigExists が再度実行され、成功すれば次のテストに進む。何度も失敗した場合は、修正が失敗したと判断して人間に通知する
• この仕組により、ネットワークが動き始めてマシンがDBに登録されてから1~2週間でサービスインできるようになった
• ただ、この仕組は問題がある。テストと修正の間のレイテンシ(バージョン管理システムにコミットされてからそれが反映されるまでということだと思われる)により、2回目のテストが成功したり失敗したりの脆いテストになる
• 全ての修正が自然にべき等なわけではなく、それにより、修正された後に実施される脆いテストはシステムを非一貫な状態にする

ここで終わっている。次の節でも上記の脆いテストに対する答はなさそう

The Inclination to Specialize(特殊化への傾向？)

自動化プロセスは以下3点に分類される

• 正確さ

  • メンテナンスされており、サービスオーナーによって実行される

• 素早さ

  • サービスオーナーが余暇時間に実行するもしくは新しいエンジニアにアサインする

• 妥当性

  • 実世界の作業がどれだけ自動化でカバーされているか
  • サービスオーナーが実世界の変化を知った際に自動化を修正することができる

• turnupのレイテンシを下げるために、たくさんのサービスを持つチームは一つのturnupチームにどの自動化をすべきか指示していた

• turnupチームはturnupの各ステージを始めるのにチケットを使用していたため、残っているタスクが何か、それらのタスクが誰にアサインされているかを把握することができる

• もし自動化モジュールについての人間の相互作用が同じ部屋の人々の間で起きるのであればクラスタのturnupはより短い時間でできる

• 最終的に有能であり正確でありタイムリーな自動化プロセスを持っていた

• しかしこの状態は長く続かなかった。現実は混沌としており、ソフトウェア、設定ファイル、データ等が日に数千回の変更がシステムに影響を与える

• もっとも自動化のバグの影響を受けるのはもはやドメインエキスパートではなかった。なので自動化は妥当性が少なく(新しいステップは忘れられる)、正確さも少なく(新しいフラグが自動化を失敗させる)なった

• しかし、このクオリティの低下がベロシティにインパクトを与えるまでは時間がかかった

• ユニットテストのような自動化コードのメンテナンスチームが、対象のコードベースと同期していることを常に考えていないと簡単に死ぬようになった

• 現実はどんどん変わっている。DNSチームは新しいコンフィグオプションを作りstorageチームはパッケージ名を変え、ネットワーキングチームは新しいデバイスをサポートした

• 自動化コードをメンテし、実行するチームを独立させることによって、以下のような組織の醜いインセンティブが作られていた

  • turnupの速度を上げることが主目的のチームは、本番でサービスを実行しているサービス所有のチームの技術的負債を削減するインセンティブを持っていない
  • 自動化を進めていないチームは自動化しやすいようにシステムを作るインセンティブがなかった
  • 低いクオリティの自動化によってスケジュールへの影響を受けないプロダクトマネージャーは、常に新規機能を、シンプルさや自動化の上に優先度付けした

• 最も機能的なツールは一般的にそれを使う人によって書かれているものだ

• 同様の議論は、なぜ製品開発チームが本番環境のシステムの少なくともいくつかのオペレーションへの気付きを続けることで利益を得られるのかにも適応できます

• 再度turnupはレイテンシが高く、不正確となっていた

• しかし、関係のないセキュリティの任務はこのトラップから私達を脱出させました

• たくさんの分散した自動化システムはSSHに頼っており、ほとんどのコマンドはROOT権限で実行する必要があるため、セキュリティの観点からは扱いにくかった

• sshdの代わりにauthenticated, ACL-driven, RPC-basedな、"Admin Servers"として知られ、それらのローカルの変更を実施する権限を持つローカルアドミンデーモンに置き換える必要があった

• 結果として、監査なしで何かインストールしたりサーバを変更したりすることは誰もできなくなった

• ローカルアドミンデーモンへの変更やパッケージRepoへの変更はコードレビューを通り、持っている権限以上の操作を行うことは極めて難しくなった

• パッケージをインストールする権限を付与することは同じ場所にあるログを見ることができるようになることを意味しない

• Admin ServerはRPCリクエストでどのパラメータで来たかを記録し、デバッグやセキュリティ監査に使用される

Service-Oriented Cluster-Turnup

• マシン単体用のAdmin Server(Packageのインストールや再起動等を行う)、クラスタレベルのAdmin Server(drainやサービスのturn upを行う)が、共にサービスチームのワークフローに組み込まれた
• SREはホームディレクトリでシェルスクリプトを書くのをやめて、きめの細かいACLと、レビューされたRPC serverを使うようになった
• turnupプロセスはサービスを所有するチームが所有したほうが良いというのが明らかになった後、これはクラスタのturnupをService Oriented Architectureの問題として見る
• サービスの所有者は、クラスタがいつ動作可能になっているかを知っているシステムによって送られるクラスタのturnup/turndown RPCを管理するAdmin Serverを構築する責任を持つ
• 順番に、まだ隠れた実装を自由に変更しながら、それぞれのチームは自動化が必要とするAPIを提供した
• クラスタがnetwork-readyになっったらautomationはRPCをそれぞれのAdmin Serverに送り、Admin Serverはclusterをturnupする
• それにより、レイテンシが少なく正しいプロセスを所持するようになった
• 最も重要なことに、このプロセス、毎年チームやサービスが2倍になり、変化のスピードが早くなっても問題なく動いている
• 先に言ったように、我々のturnup自動化の進化は以下のpathを通った
  • Operatorトリガの手動作業
  • Operatorが書いた、システム特有の自動化
  • 外部でメンテナンスされる一般的な自動化
  • 内部でメンテされる、システム特有の自動化
  • 人間関与が不要な自律システム
• この進化は広く話されているように、成功した一方、Borgのケーススタディは自動化の別の問題を表している

Borg: Birth of the Warehouse-Scale Computer

• Borgの開発の歴史を考えることは、自動化へのGoogleの態度を知るための別の方法である
• MySQL on Borgやクラスタのturnupプロセスのように、クラスタ管理の自動化はまた最終的にどのように自動化を実施すべきかを証明する
• その2例のように、最初の単純な出発から継続的な進化を行いその結果として極めて素晴らしいシステムができる
• Googleのクラスたは最初は他の企業と同様に、小さなネットワークから始まった
• 特定の用途のラックと異質なconfigration
• エンジニアはmasterサーバにログインして管理タスクを実行する
• golden binaryと設定はmasterサーバに存在する
• 1つのプロバイダしか持っていないのでほとんどの命名規則は暗黙にロケーションを推測できるようなものになる
• 製品が成長するに従って複数クラスタを使用し、別のクラスた名が絵の中に出てくる
• 命名規則が弱いので、それぞれのマシンがどのグループに所属して何をしているか記述するファイルが必要になってくる
• この記述ファイルとparallel ssh的なものの組み合わせによって、例えば全ての検索関連のマシンを再起動することができました
• 其の頃、検索がマシンの1台で完了した、クロールはマシンを持てる というチケットを得ることが一般的になった
• 自動化の開発が始まった
• 最初の自動化は以下のようなオペレーションのためのシンプルなPythonスクリプトから成っていた
  • サービス管理: サービスを動かし続ける(segfaultした際のrestart)
  • どの差＾ビスがどのマシン上で動いているかのトラッキング
  • ログメッセージのパース: 各マシンにsshして正規表現で探す
• 自動化は最終的にマシンの状態を管理するDBに変わり、より洗練されたモニタリングツールと一体化した
• 自動化の可能な範囲の和と共に、マシンのライフサイクルのの大半を管理することができるようになってきた
• マシンが壊れたのを検知し、サービスをどけて修理に送り、修理から返ってきたら設定を戻す
• しかし、この自動化は、システムの抽象化が物理マシンに強く縛られていたという事実のために有用さは限られていました
• Googleは、それによってBorgが誕生した新しいアプローチを必要としていました
  • 静的なhost/port/jobのアサインを行うような旧時代のシステムからマシンの集合をリソースの海のように扱うように
• その成功の中心にはクラスタ管理をどのAPIが叩かれるかについてのエンティティとして管理するのではなく、いくつかの中央のコーディネータとする概念の変化だった
• これは効率性、柔軟性、信頼性の余分な次元を遊離させ、以前のマシンの"所有者"モデルとは異なり、Borgはバッチとユーザ向けのタスクを同じマシン上で動作させるようなスケジュールを行う可能性がある
• この機能は、日々の苦労がほとんどなし(その苦労はプロダクションのデプロイの総量には比例しません)に継続的な自動OSアップグレードをもたらしました。
• 現在はマシン状態のわずかなずれが自動的に修正されていきます
• このタイミングで故障とライフサイクルの管理は本質的にSREのOps作業をうまなくなりました
• 日に数千台のマシンがSREの努力の必要なしに生まれ、死に、修理されます
• Ben Treynor Slossの言葉"これはソフトウェアの問題"だというアプローチを採ることで、最初の自動化によってクラスタ管理を自動化とは対象的な自律型のものに変えるための十分な時間を得ることができた
• インフラ管理ドメインに関連するデータ配信、API、ハブアンドスポークアーキテクチャ、古典的な分散システム・ソフトウェア開発に関連したアイデアによってGoogleはゴールにたどり着いた
• 興味深い類推： 単一マシンのケースとクラスタ管理抽象の開発の間にマッピングを作ることができる
• この見方では、別のマシンにreschedulingすることはプロセスが1CPUから別のCPUに移動することに似ている
• これらの用語で考えると、rescheduringは自動化というよりも、システムの内的な機能に見える
• クラスタのturnupも同様に考えられる
  • クラスタのturnupは単純にキャパシティを追加することであり、DiskやRAMをコンピュータに追加することに似ている
• しかし一般的にはシングルノードのコンピュータは多数のコンポーネントが壊れた際に動き続けることを期待されていない。
• The global conputerは、本質的統計的に毎秒大量のエラーが発生することが保証されているため、一度、あるサイズ以上になれば自分自身を修復する機能が必要になる
• これは、手動の運用->自動トリガ->自律化及び自己観察の能力の獲得というヒエラルキーの上昇は生き残るために必要なものだということを意味する

Reliability Is the Fundamental Feature

• もちろん効率的なトラブルシューティングのためには内部の詳細は人間の管理にさらされるべき
• コンピュータ関連以外での自動化のインパクトについての類似の議論(例えば、飛行機の運行や工業のアプリケーション)高度に効果的な自動化の否定的側面についてしばしば指摘する
  • 人間のオペレーターは自動化が進展するにつれてだんだんシステムに直接触る機会がなくなる
  • 予想取り、自動化が失敗した際に、人間はシステムを運用できなくなる
  • 彼らの反応の柔軟性は、経験の欠落と、システムがすべきことが、現実の世界でシステムがしていることを反映しなくなるような彼らのメンタルモデルによって失われる
  • このような状況はシステムが非自律的な時により起き得る。すなわち、自動化が手動作業を置き換えた時、手動作業が常に実行でき、以前行っていた時のように実行可能である場合
  • 悲しいことに、このような状況は時間をかけて最終的にはfalseになる。それらの手動作業は、それらを許可する機能がもはや存在しなくなることによって常に実行可能ではなくなる
  • Googleでも自動化が多くの場合に危険なものになった経験を持つ(see "Automation: Enabling Failure at Scale" on page 85)
  • しかしGoogleの経験では、より多くの自動化や自立的動作以外の選択肢は存在しなかった
• サイズに関係なく、より多くの自立した動作のための強い変数が存在します
• 信頼性は、基本的な機能であり、自律的、弾力的な行動は信頼性を得るための一つの有用な方法です。

Recommendations

• この章の例を読んで、自動化の前にGoogle規模になる必要があると決めるでしょうが、それは以下の2つの理由により真実ではない
• 自動化はただ時間の節約だけではないため、自動化コストに見合う時間の節約かどうかの計算をする場合以上に、自動化を行う価値はある
• しかし高いレバレッジと一緒のこのアプローチは、設計フェーズの中で発生する
• shippingとiterateを高速に行うことは機能を素早く実装することを許可する、稀に回復力の早いシステムを作ることさえある
• 自動化されたオペレーションは十分に巨大なシステムを人を説得できるように改造するのが難しい、しかし、ソフトウェア・エンジニアリングでの標準的なグッドプラクティスはかなり助けてくれるだろう
  • サブシステムへの分割、説明API、副作用の最小化等など

Automation: Enabling Failure at Scale

• Googleは数十の自身の巨大なデータセンターで動いているが、同時にたくさんのサードパーティの施設(colos)のマシンにも依存している
• colsで動いている我々のマシンはより低いユーザのレイテンシのためにほとんどの内向きのコネクションを終端することに使われていたり、自分たち独自のCDNとして使用している
• 任意の時点で、これらのラックはインストールされているか退役されているかである
• これらのプロセスの両方において高度に自動化されている
• 退役の1つのステップはラック内の全てのマシンのディスクの中味を上書きする。これをDiskeraseという
• かつて、Disceraseが失敗したが、それ以外の退役操作は完了した。デバッグのために再度退役プロセスを実施した。その際、自動化プロセスは正しく空っぽであることを検知した
• 不運なことに、空っぽのセットは"全て"という特殊な値を設定されていた。この意味は、全colosのDiskeraseを意味している
• 数分でCDNの全マシンのdiskが消滅し、アクセスを終端させることができなくなった
• しかしCDN以外は動いており、その後数分間、レイテンシが少し上がっただけであった
• 良いキャパシティプランニングのおかげでほとんどのユーザはそれに気付かなかった
• その後、2日かけて影響を受けたcolo racksに再インストールをし、2週間かけて自動化にチェックを追加した
• そして退役処理をべき等にした