今回は、Googleの自動化の実例を扱います。
また、その解決にどのような取り組みをしていったのかについても見ていきます。
Googleの自動化の歴史②
クラスタインストラクチャSREチームは、数か月ごとに採用を行っている状況がありました。
新人がクラスタ内部にサービスを立ち上げることは、サービス内部に触れることになるため、自然とトレーニングになると思われていました。
クラスタを使えるようにするためのステップは、以下のようなステップで行われていました。
1. データセンターののビルディングに、電源と冷却機構を整える。
2. コアスイッチをインストールして設定し、バックボーンに接続する。
3. 最初のサーバーラックをいくつかインストールする。
4. DNSやインストールなどの基本サービスを設定し、続いてロックサービス、ストレージ、コンピューティングの設定をする。
5. 残りのマシンのラックを設置する。
6. ユーザーが使うサービスリソースを割り当て、ユーザーのチームがサービスをセットアップできるようにする。1
当時のストレージやコンピュートのサブシステムは、開発が行われており、毎週のように新しいフラグやコンポーネント、最適化が行われていました。
サービスの中には100以上のさまざまなコンポーネントサブシステムを持つものがあり、それぞれが網目のように依存関係を持っていました。
1つのサブシステムの設定に失敗したりすれば、それはサービス障害を仕込むようなものでした。
初期の自動化はクラスタの素早い提供に焦点を当てており、パッケージの配布やサービスの初期化をSSHをうまく使って解決していました。
このような型にはまらない方法は、初めは上手くいきましたが、技術的負債を残すことになりました。
Prodtestでの不整合の検出
先のような状況において、クラスタを設定するために使われていたシェルスクリプトは、変更を行う人数やクラスタ数の観点からスケーラビリティを持っていませんでした。
そして、以下のような懸念点がありました。
- サービスの依存対象が全て利用可能で、適切に設定されているか。
- すべての設定とパッケージは、他の動作環境と一貫しているか。
- 例外的な設定はすべて意図的なものであることを確認できたか。1
GoogleはProdtestによって、この問題を解決しました。
これによって、実際のサービスをユニットテストできるようになりました。Prodtestは、pythonのユニットテストのフレームワークの拡張です。チームのクラスタ名を指定すると、そのクラスタ内のチームのサービスを検証できるようになります。
これにより、サービスが適切に設定されているか、あるいはされていないかを素早く知ることができるようになりました。また、予想外の設定ミスによって、遅延が生じた場合、その原因となったバグを登録できます。それにより、素早く問題の検出を行えるようになりました。
この取り組みのおかげで、プロジェクト管理者は、クラスタがライブ状態になる時期を予測できるようになり、実際に提供中になるまでに6週間以上かかる理由を理解できるようになりました。
そして、SREにシニア管理者からミッションが与えられました。
「3か月以内に、5つのクラスタが同日にネットワークの準備完了状態になる。そのクラスタを1週間以内にたちあげてほしい」1
まとめ
- Googleの初期のSREは、サービスの設定をシェルで行っており、そのせいで設定のばらつきが生じることがあった。
- 設定のばらつきをProdtestを導入することで検知できるようにした。
- そのため、管理者はどの程度作業が進んでいるかを知ることができるようになった。
雑記
書籍の記述が若干エモい。苦労したんだろうなあ。
参考文献
- Betsy Seyerほか SRE サイトリライアビリティエンジニアリング オライリー 77-79