GCPでOrchestratorによるフェイルオーバーを検証してみた

WRITER: shimada
このエントリーをはてなブックマークに追加

はじめに

こんちには。

サムザップでSREチームに所属しており、主にパブリッククラウドなどを使用する業務に携わっている島田です。本記事ではOrchestratorというツールを導入検証してみたので、その特徴などを解説していきます。

orchestrator

引用: https://github.com/github/orchestrator

Orchestratorとは、MySQLレプリケーショントポロジ管理およびビジュアライゼーションツールです。同様の自動フェイルオーバーツールとしてMHAやmysqlfailoverのようなツールがあります。GitHubのバックエンドとしても使用されているそうです。複雑なレプリケーション構成の管理をしやすくするためのツールで以下のような特徴があります。

  • レプリケーションクラスタの検出と調査
  • 安全なトポロジリファクタリング：トポロジの周りのレプリカの移動
  • 洗練されたトポロジの視覚化
  • レプリケーションの問題の視覚化
  • 直感的なドラッグアンドドロップによるトポロジの変更
  • メンテナンスモードの宣言と実施
  • オペレーションの監査
  • more…

MHA, mysqlfailoverとの比較

もともとサムザップではMHAを使用してサービスを運用していたのですが、下記のようなMHAではない特徴がOrchestratorにはあるのでMHAの代わりとして使用できないか検証してみました。

  • 状態をMysqlに保存する
  • 障害ログを残せる
  • 複数クラスタ監視ができる
  • GTID対応
  • フェイルオーバー後に再セットアップする必要がない
  • 監視サーバにエージェントをインストールする必要がない(アクセス用のユーザを作成)
  • 誤検知が少ない(マスターの状態のみで判断しない)

GTIDの対応はmysql5.7以上を使用するならば欲しかった機能ですね。
また運用上ログを残せたり、手動で再セットアップ不要というのは大きなメリットです。

GCPによるフェイルオーバーの検討

gcpではインスタンスにvipを付与することが出来なかったので、当初はMHA+Haproxy+consul-template構成でフェイルオーバーを構成していました。しかしこの構成では使用するミドルウェアが多いことや、configファイルを書き換えなくてはいけないなど、システムが大変複雑になってしまいます。

しかし最近Alias IPがgceで使えるようになったので上記構成を見直しました。
MHAの代わりにOrchestratorを使用し、mysqlの障害時にAlias IPをつけかえるだけというとてもシンプルな構成です。

gcpによるフェイルオーバー

Orchestratorの設定

では早速orchestratorを試してみましょう!
手順は下記です。

1. mysqlのインストール

省略

2. orchestratorのインストール

Installationページ参照

3. 設定ファイルの記入

/etc/orchestrator.conf.jsonに以下の設定ファイルを作成します。

{
  "Debug": false,
  "EnableSyslog": false,
  "ListenAddress": ":3000",
  "AuthenticationMethod": "",

  "MySQLTopologyUser": "orchestrator_user",
  "MySQLTopologyPassword": "orchestrator_pass",

  "MySQLOrchestratorHost": "127.0.0.1",
  "MySQLOrchestratorPort": 3306,
  "MySQLOrchestratorDatabase": "orchestrator",
  "MySQLOrchestratorUser": "orchestrator_user",
  "MySQLOrchestratorPassword": "orchestrator_pass",

  "RecoveryPeriodBlockSeconds": 3600,
  "RecoveryPollSeconds": 10,
  "RecoverMasterClusterFilters": [
    ".*"
  ],
  "PostMasterFailoverProcesses": [
    "sudo /usr/local/orchestrator/failover.sh {failedHost} {isSuccessful} {successorHost} {slaveHosts} >> /tmp/failover.log"
  ],
  "ApplyMySQLPromotionAfterMasterFailover": true
}

・ MySQLTopologyUser と MySQLTopologyPasswordがクラスター接続用のユーザ設定

・ MySQLOrchestratorUser と MySQLOrchestratorPasswordが情報保存用のユーザ設定

・ RecoveryPeriodBlockSeconds が一度フェイルオーバーが起こったあとに再度フェイルオーバー可能になるまでの時間

・ PostMasterFailoverProcesses にフェイルオーバー時に差し込む処理を記述出来ます

-> 今回はGCPのAliasIPの変更処理を /usr/local/orchestrator/failover.sh に記載しています

詳しくはConfigurationページ参照

4. 起動

省略

5. 監視するmysqlクラスターに接続用ユーザ作成

MySQLTopologyUser と MySQLTopologyPasswordで設定したユーザを監視クラスターのmysqlで作成

mysql> GRANT SUPER, PROCESS, REPLICATION SLAVE, RELOAD ON *.* TO 'orchestrator_user'@'%' IDENTIFIED BY 'orchestrator_pass';
mysql> GRANT SELECT ON mysql.slave_master_info TO 'orchestrator_user'@'%';

6. webからmysqlクラスター登録

http://[orchestrator HOST]:3000/web/discover にアクセスしてクラスターマスターを入力するだけ(Enter host name)

cluster登録

するとレプリしているサーバも自動で検知してくれます。

cluster情報

もちろん複数クラスターを登録・監視することも可能です。

multi cluster

実際にフェイルオーバーを起こしてみる

mysqlのマスターを落とします。
するとマスターサーバはエラーとなり、スレーブだったサーバがマスターに昇格。
すぐにweb画面でもフェイルオーバーが確認出来ます。

dead master

slave 昇格

またログも下記のように残っています。

failover log

まとめ

今回GCPでorchestratorの導入と実際にフェイルオーバーを起こしてみて接続が切り替わるかテストしてみました。導入は自身にmysqlが必要なので少し手間かもしれませんが、mysqlなどはよく使うのでコード化されていて問題ありません。それよりも監視対象にエージェントを入れなくてもよかったり、監視対象がwebで可視化されたり、Logが残ったりとメリットの方が大きいと感じました。フェイルオーバー時の処理も自由に挟み込めるので、環境に合わせて設定することが出来ます。今回はGCPで試しましたが、いろいろな環境に対応することが出来ますね。まだ本番環境には導入していませんが、今後MHAの代わりとして使用していきたいと思います。

shimada
2012年新卒入社のエンジニア。株式会社サムザップのSREチームに所属し、スマホゲームのバックエンドとしてGCPやAWSなどのクラウドプラットフォーム構築を担当。
UnityのFirebase Test Labを利用したUIテスト
次の記事
Data Engineering and Data Analysis Workshop #5 を開催しました！
前の記事