前回は、自動化の価値について、学びました。
今回は、実際にGoogleで行われた自動化の実例を見ていきます。
Googleの自動化の歴史①
Google Adsのプロダクト軍は長きにわたり、データをMySQLデータベースに保存していました。GoogleSREのあるチームがそれを管理する役割を持っていました。2005年から2008年にかけて、システムの重要な部分を自動化し、Adsのデータベースは十分管理されており、最適化とスケーラビリティが簡単に行えるようになるにつれ、システム開発は、次のレベルへ向かうことになりました。
つまり、MySQLをGoogleをBorg（Googleのクラスタスケジュールシステム）へ移行することを行い始めました。
この移行には、以下のようなメリットがあると考えました。
- マシン/レプリカのメンテナンスを完全になくすことができる。Borgは、新しいタスクや壊れたタスクのセットアップ/再起動を自動的に処理できるだろう
- 単一の物理マシンへの複数のMySQLのインスタンスの格納。Borgは、コンテナを使って、マシンのリソースの活用効率を上げることができるだろう。1
2008年の終わりには、検証環境でMySQLインスタンスをBorgにデプロイすることに成功しましたが、問題がありました、それはBorgの運用上の特徴の一つに、タスクが自動的に移動するということがあり、その頻度が週1から2回ありました。この頻度はBorgマスターでは受け入れがたいものでした。なぜなら、この時点ではマスターのフェイルオーバーはインスタンスごとに30から90分かかっていました。共有マシンを使っており、通常のマシンの障害の頻度やカーネルのアップデートによる再起動が必要だったため、数多くのフェイルオーバーが発生することを覚悟しなければなりませんでした。
これは、この時Googleが持っていた可用性などの要件を満たしませんでした。この解決の為に残された選択肢はフェールオーバーを自動化することでした。（実際には、他にも自動化しなければならないものがありましたが）
2009年に「Decider」という自動フェイルオーバーデーモンを完成させました。
このデーモンは、予測されているかどうかに関わら95%のフェイルオーバーを30秒以内に完了させるものでした。これにより、当初目的としていたMySQL on Borg（MoB）を実現し、インフラストラクチャの最適化から障害復旧の最適化を行うようなりました。
しかし、これに伴い、新しいコストも発生しました。すべてのアプリケーションを修正し、より耐障害性の高いロジックを持たせる必要がありました。
ですが、MoBによりチームが日常的に費やすコストの95%を削減することができました。
また、複数のMySQLインスタンスを同じマシン上にスケジューリングできるようになったことにより、ハードウェアの利用率が改善されました。
このように、既存の手作業を自動化するのではなく、プラットフォームの実現に労力をさくことは、とても有意義です。
次回は、さらに難しいトレードオフについて、見ていきます。
##まとめ
- システムの成熟に伴い、自動化のシステムも進化する。
- 手作業の自動化でなく、自動化のプラットフォームを実現することを考える。
参考文献
- Betsy Seyerほか SRE サイトリライアビリティエンジニアリング オライリー 77-79