Facebook: MySQL Pool Scannerでの徹底した自動化

https://www.facebook.com/notes/facebook-engineering/under-the-hood-mysql-pool-scanner-mps/10151750529723920

1 comment | 0 points | by Jshiike 3年以上前


Jshiike 3年以上前 | ▲upvoteする | link

Facebookがエンジニアブログで、MySQLの運用を自動化している事例を紹介しています。このレベルまでくると、意思をもった大規模なロボット群みたいで、すごいですね。前半はマスタ/スレーブの基本的な自動化の話ですが、後半ではオペレーションの自動化ロジックをどのように自動化して増やすかという手法まで言及してます。



FacebookのMySQL DBクラスタは、2つの大陸にまたがる複数のデータセンタにある数千台のサーバで構成されている。通常、DBアドミンが担当するルーティーンワークは、MySQL Pool Scanner (MPS) で自動化されている。


1) DBノードを詳しく見てみる


各サーバには、いくつかのMySQLインスタンス(portを待ち受けする独自のデータセットをもったMySQLプロセス)がある。


全てのデータセットは数千のシャードに分割され、各インスタンスが複数のシャードを保管している。例えば、ユーザプロファイルが作成されれば、シャードにアサインされ、各シャードが数千人分のデータを保持する。[参考図]


異なるデータセンタ間でインスタンスのコピーを保持し合うことで、高可用性とパフォーマンスを実現している。


この仕組みは、シンプルなマスタ/スレーブの複製で実現している。全てのインスタンスはレプリカのセットの一部。レプリカには一つのマスタと複数のスレーブが存在する。[参考図] マスタに対して書き込みがされ、スレーブはマスタから更新データを受け取る。データの読み取りは、マスタもしくはスレーブのいずれかで対応する。


サーバは複数のインスタンスをもつので、一つのサーバに、マスタインスタンスと他のマスタのスレーブインスタンスがる場合も起きる。[参考図]


MPSは二つの重要な機能をもつ。一つは、サーバのコピーおよび交換。[スレーブの役割をもつサーバの交換の参考図] 二つ目は、新しいサーバのマスタへの昇格。 [参考図] いずれも完全に自動化され、人手を介することなく、1日数十万回実行できる


2) ホストの管理


MPSは、全てのDBホストの現在のステータスとメタデータをもつレポジトリと連動するようにできている。レポジトリへの記録はDBサーバ自身がやるので、MPSは複雑なアプリサーバのインストールなどする必要がない。MPSはステータスデータをもたず、レポジトリに依存している。


新しいサーバが投入されると、そのサーバでローカルエージェントが働きはじめ、


  • どこにいて、何のハードウェアで、どのソフトウェアバージョンなのか情報収集する。

  • アクティブなクラスタに投入されたのか?ディスクは大丈夫か?フラッシュカードは問題ないか?などの問題の優先付けをする。

  • サーバは登録されていて、最新情報が中央のレポジトリに更新されているかどうか確認する。

  • 稼働をはじめると、記録のない新しいサーバであれば、最初の”reimage (再構成) “のステータスになり、MPSの傘下のサーバになる。

  • 数分ごとに中央のレポジトリにチェックインし、データ保持や稼働状況の情報が同期される。

主なインスタンスのステータスは、


  • Production: 本番サービスのトラッフィクをさばいている。

  • Spare: 他のインスタンスをコピーされることができるか、何か他のタスクがアサインされている。

  • Spare allocated: 他のインスタンスからコピー中。

  • Spare deallocated: 本番サービスからはずれ、数分間だけ、待機 & クリーンアップされている状態。

  • Drained: インスタンスが利用されてなく、テストもしくはデータセンタのメンテ用に使われる。このステータスからはずれるには、マニュアル操作が必要。

  • Reimage: 再構成もしくは修理中のステータス。DB準備自動化のためのシステムWindexの管轄下に入る。

[ステータス変更の相関関係の参考図]


この相関図はコピーやメンテのみを前提とした基本的なもので、ステータスの変更には他にも多くのパターンがありえる。しかし、そのパターンを全てコーディングするのは手間が大変。そこで、タグのような働きをする「Problem」を導入した。サーバ内のインスタンスの全てが同じ「Problem」をもつと、そのサーバが「problem」をもつと見なされる仕組みである。MPSは特定の問題に対処するパターンをつくるために、(ステータス、problem) - (アクション、ステータス) というの構成の「Problem」データを確認する。


例として、


  • (Production、スペース少) - (交換、Spare deallocated): スペースの少ない本番に投入されたインスタンスを、違うサーバに移す。

  • (Spare deallocate、古いカーネル) - (移動、reimage): このステータスにあるインスタンスは本番投入されてない状態なので、再構成する。

  • (Production、マスタが限定稼働のロケーションにある) - (昇格、Production): このマスタを適切なロケーションに昇格させて、引き続き本番サービスに投入する。

3) サーバの不具合対処とオペレーションの自動化


大きなデータセンタでは1日数千台のサーバが落ちる。MPSが自動化で対応しているパターンは、


  • 壊れたスレーブインスタンスが検知され、交換されるまで無効にする。

  • 壊れたマスタインスタンスがはずされ、レプリカが役割を代行、その裏で壊れたマスタは交換される。

  • データが増えてスペースが枯渇しそうなインスタンスは、スペースに余裕のあるサーバに移される。

一般的なオペレーションでMPSが対応しているのは、


  • ラックを本番サービスからはずす。どれほどの数があっても、ほぼ24時間で対応完了する。

  • カーネルのアップグレードなど、再構成を数千台のサーバに対して並列処理する。MPSが対象サーバをWindexに送る。

  • 新しいプロジェクト、もしくはテスト用にスペアのインスタンスを用意する。「テスト用にサーバ200台用意。」も問題なくできる。

  • 新しいデータセンタにFacebookのデータ全体を並列処理でコピーする。



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



#facebook #mysql #自動化 #devops

Back