Facebook: 自動で本番環境への再投入を準備してくれるWindex

https://www.facebook.com/notes/facebook-engineering/windex-automation-for-database-provisioning/10151551942243920

1 comment | 0 points | by Jshiike 約4年前


Jshiike 約4年前 | ▲upvoteする | link

Facebook: MySQL Pool Scannerでの徹底した自動化」で紹介したMPSと連携して、サーバを本番環境に再投入する準備をしてくれる自動化システムがWindexです。サーバが修理対象かどうか、資産管理簿上でステータスがどうなってるかも、システマティックに確認してくれるのですね。すごい。世の中には、自分で確認して、エクセルにステータスを記入(もしくはその管理もきちんとできてない。)という会社が多いとは思いますが。。



Windexは、元々は、本番サービスからはずれたサーバのデータをクリーンアップし、OSからMySQLまでを再インストール、そして設定を完了して、新しいスペアとして提供するシステムであった。その後、新規にセットアップされるサーバや、RAMの交換修理のために本番サービスからはずれるサーバなどもカバーするようになった。


1) Windexの役割


Windexにサーバが渡されるフローとしては、


  1. MPSが本番環境のMySQLスレーブサーバの異常を検知。

  2. MPSが、問題あるスレーブをスペアのプールのものと交替させる。

  3. MPSが、問題のあるスレーブがあるサーバを「再構成(re-image)」のステータスに変更。

  4. Windexは定期的にMPSにポーリングして、再構成のステータスのサーバを探す。

  5. Windexは該当のサーバが再投入のための準備作業ができる対象かどうか(ホスト名は有効か?Windexの再構成作業はこのタイプのサーバに適用できるか?本番サービスのMySQLとの関係は残ってないか?資産管理システムデータで「使用中」のステータスになってないか?)を確認する。

  6. Windexが、資産管理システムと修理システムを確認し、メンテナンスのステータスであれば「修理中」のステータスに、そうでなければ「作業キュー」のステータスに変更する。「修理中」のステータスもWindexが定期的に確認し、完了していれば「作業キュー」のステータスに変更される。

  7. 「作業キュー」から次は「構成作業中」のステータスに変更され、自動準備システムで、OSやコアパッケージの再インストールがされる。

  8. 自動準備システムは、健康診断も実施する。問題が発見されると「修理中」のステータスに、合格すれば、準備のジョブが実行される。

  9. Windexは、自動準備システムの作業完了を確認し、「インストール後作業」のステータスに変更する。

  10. 正しいMySQLのパッケージがインストール、設定、初期化されているかどうかを確認するスクリプトが実行され、問題なければ、「インストール確認」のステータスに変更される。

  11. 次に、本番サービス投入に問題ないかを確認するスクリプトを実行し、合格すれば、スペアのプールに追加され、MPSの管轄下に移る。

  12. Windexが「作業完了」のステータスに変更する。

Windexは、基本シナリオとおりに事が進まない事態に備えて、冗長化されたリトライや不合格パターン検知ロジックを備えている。


2) リトライと不合格パターン検知


規定回数のリトライが成功しない場合、「再構成」のステータスが変更なく全ての有効性のチェックに依然合格しているのであれば、Windexは新しいジョブを再度作成する。このパターンが、無限ループに陥らないように、Windexは、ジョブの再作成をサーバごとにカウントし、一定回数を超えると「レビュー要」のステータスに変更する。エンジニアが「レビュー要」のサーバを確認し、原因が解決すれば、また自動化されたフローに戻される。


3) 障害を防ぐ


上記1)のフロー5の確認は自動化のプロセスにおいて重要。


例えば、


スペアのサーバのBIOSを一斉アップグレードしたが、MPSに登録されたリストを更新忘れてたので、BIOSバージョン違いと判定され、「再構成」のステータスになる。


当番のDBアドミニストレータ担当が、スペアのサーバないアラートを受信し、状況確認のうえ、MPSに登録されたBIOSバージョンを更新。


それまでは、間違った判定で、Windexが作業すべきジョブが溜まり続ける。


担当者は、キューに溜まっているサーバは全て上記の登録データ更新漏れが起因していると判断し、全てを「スペア」ステータスに移す。


MPSはスペアプールから本番サービスにサーバを投入するが、その中に本当に障害を抱えたサーバが含まれてしまっている。


このようにシステム障害につながりかねないエッジケースが存在するが、上記1)のフロー11で、本番投入前に最後のチェックをするプロセスがあるので、発生を防ぐことができている。自動化した確認作業を複数入れることは、全体の自動化フローの運営を担保するうえで大切。




ワザノバ TOP100 アクセスランキング [8/25-10/12]



#facebook #自動化 #devops

Back