前回は、Googleの自動化の2つ目の実例を扱いました。
Prodtestを拡張し、修正スクリプトを実装することで対応しましたが、現実の世界の変化には対応しきれませんでした。そこへきっかけはセキュリティ要件でしたが、Admin Serverからのサーバーへの変更の仕組みを取り入れることにより、自動化の仕組みからRPCが送られるようになりました。
今回は自動化の問題を考える上でたどり着いたもう一つの事例であるクラスタ管理システムの歴史を見ていきます。
Borg：ウェルハウススケールコンピュータの誕生
初期のころのGoogleクラスタは、一般的な小さなネットワークと同じように設置されていました。特定の目的のためのさまざまな設定がなされたマシン群がラックに収められていました。プロダクション環境が成長していくにつれて、複数のクラスタが立ち上がりました。そして、さまざまなドメイン（クラスタ名）が加わっていきました。その際、それぞれのマシンが受け持つことを記述するファイルが必要になり、そのファイル内でゆるい命名方針でマシンがグルーピングされました。この記述ファイルと並列SSH相当のツールを使うことで、例えばすべての検索マシンを同時に再起動するということができるようになりました。
そして、自動化の開発が始まりました。処理の自動化は、サービス管理やサービスが動作しているマシンの追跡、ログメッセージのパースなどシンプルなものでした。最終的に自動化の仕組みはマシンの状態を追跡するデータベースへと変化するとともに洗練されたモニタリングツールを取り込みました。
このような融合型の自動化の仕組みが備わるとサービスの除去、サーバーの修理への配送、修理から戻ったマシンへの設定のリストアなどが自動で管理できるようになりました。
この自動化は有益ですが、システムが物理マシンに堅く結びついてしまっていました。
そこで誕生したのがBorgです。Borgによって、以前のようにホスト/ポート/ジョブの割り当てという方法からマシン群の集合をリソースプールとして扱うようになりました。
Borgの出現により、数千台のマシンが日々設置され、壊れ、修理に送られるものの、SREがそれに関して作業することは無くなりました。初期のクラスタ管理の自動化からシステム自体を自律的なものへと変化させました。
地球規模のコンピュータにおいて、一定のサイズを超えると大量の障害が発生することが日常になります。そうなれば、運用するには自己修復が必要不可欠になります。
システムが手動、自動、自律と進化するにつれて、自己検査の能力がなければ生き残れなくなります。
基本的機能としての信頼性
システムが成長するごとにやがて、自律的なものである必要が出てくることは、わかりましたが、しかし、同時に高度に自動化されたシステムによる弊害も指摘されています。
それは、自動化による人間が直接システムを扱う機会がなくなっていくことです。そして、自動化の仕組みに問題が生じたとき、人間にはうまく扱うことができなくなっています。
また、大規模に自動化を行ったことにより、問題が生じたときの影響範囲が大きくなることも考えられます。
しかし、多くのシステムにおいて、その規模に関係なく、自律的なシステムを求めるべきであるという主張もあります。その為、信頼性はオプションではなく、基本的な機能となります。
今後の学習でその理由について、見ていこうと思います。
##まとめ
- システムの進化は、手動、自動、自律
- 自律的なシステムにも問題が生じる。しかし、自律的なシステムを目指すべき。
参考文献
- Betsy Seyerほか SRE サイトリライアビリティエンジニアリング オライリー 86-89