前回は、Googleの自動化の実例を扱いました。クラスタの状態をProdtestで検証できるようになったSREチームは、システム管理者からクラスタを5日以内に立ち上げてほしいという要望を受けました。SREチームはどのような対応をしたのでしょうか？
不整合の冪等な解消
Prodtestによって、クラスタが準備ができているかどうかを検出することはできます。しかし、この状況を修正するとなると、それぞれのSREチームがいち早くバグが修正されるしかありません。
この状況を解決するために行ったことは、「設定ミスを検出するPythonのユニットテスト」を「設定ミスを修正するPythonコード」に変更するということでした。
設定の検証を行い、テストに失敗した時は修復スクリプトが実行されます。修復に数回失敗した場合は、修復に失敗したとみなして、ユーザーへ通知します。
この時点において、これは自動化技術の頂点のように思われました。
しかし、この試みには大きな落とし穴がありました。
テスト、修正、2回目のテストの間のレイテンシにより、テストがうまくいかないことやすべてのテストが冪等になっているわけではないので、あてにならないテストの後に修正がつづきシステムの状態が不整合になってしまうことがありました。
特化する傾向
自動化のプロセスには、3つの面で差異が生じます。
- 対応への適用。すなわち自動化を正確に行えるか。
- 対応にかかっている時間。プロセス開始後の各ステップの動作の速度。
- 対応の関連度。もしくはこの自動化でカバーされる実際のプロセスの比率。1
このため、まず対応がしやすく、手作業に時間がかかっており、関連度が高いものから対応を始めました。ターンアップの時間を少なくするために、多くのチームは単一の「ターンアップ」チームへどの自動化を実行すべきかを指示しました。
各ターンアップチームは、起動処理中の各ステージの構築をチケットで管理し、割り当て状況を追跡できるようにしました。そして、最終的に適切で、正確で、素早い自動化プロセスが出来上がりました。
しかし、現実世界は日々変化をします。それにより、設定やデータが変化します。自動化の関連度は低くなり、適切でもなくなっていきます。ですが、この問題がターンアップの速度に影響を与えるには、多少の時間がかかりました。
しかし、この時サービスを動作させるチームの責任範囲から自動化のコードのメンテナンスをと実行を外すことで、組織はよくないインセンティブを持つことになりました。
サービスを動作させるチームは、サービスの技術的負債と取り除くことにインセンティブを持たない。自動化の処理を実行しないチームは、自動化しやすいシステムを構築することにインセンティブを持たない。プロダクト管理者は、シンプルさや自動化よりも新しい機能を優先する。
新しい制約
これは、まったく無関係なセキュリティ要件によって、この状況から抜け出すことができました。
この頃、分散された自動化の多くはSSHに依存しており、ほとんどのコマンドの実行にroot権限を必要とするので、セキュリティ的に扱いずらくなっていました。そのためSREが持っていた権限を制約し、作業上の必要最小限にする必要がありました。そこでそれまで使用していたsshdを認証済みでACLを使用するRPCベースのローカル管理デーモン（Admin Server）に置き換えました。これは自動化で必要なローカルでの変更を行う権限を持っています。これにより、監査証跡なしにサーバーへ変更やインストールができなくなりました。ローカル管理デーモンとパッケージリポジトリにはコードレビューが義務づけられていたので、権限の逸脱が起こりづらくなりました。
Admin Serverは、デバックとセキュリティのためにRPCリクエストの送信者、パラメータ、RPCの結果がログに残りました。
サービス思考のクラスタのターンアップ
Admin Serverがサービスチームのワークフローに組み込まれると、SREはシェルスクリプトの作成からACLの下で動作するピアレビューを受けたRPCサーバーの構築へ移りました。
後にサービスを所有するチームがターンアップのプロセスも受け持つ必要があることが広く認識された後、クラスタのターンアップ/ターンダウンのRPCを扱うAdmin Serverの作成も、サービス所有者が受け持つことになりました。（クラスタのターンアップをサービス指向アーキテクチャとしてアプローチする方法とみなした）
各チームはターンアップの自動化に必要なAPIを提供します。クラスタがネットワーク準備完了状態になれば、クラスタのターンアップの一部を担う各Admin Serverへ自動化の仕組みからRPCが送られます。
これにより、低レイテンシで要望を満たし、かつ正確なプロセスができたことになります。
まとめ
セキュリティ要件を満たすことにより、Admin Serverを導入する必要が出ました。
その際に、クラスタのターンアップをSOAとみなすことで、自動化もサービス所有者が担うことになりました。
参考文献
- Betsy Seyerほか SRE サイトリライアビリティエンジニアリング オライリー 84-86