WePayのエンジニアリングチームが，HAProxy，Consul，Orchestratorで構築された新しい高可用性MySQLクラスタについて語っている。ダウンタイムを30分から40～60秒に短縮することで，それまでのアーキテクチャを改善している。
WePayではメインRDBMSとしてMySQLが使用されており、複数のクラスタを運用してさまざまなサービスを提供している。同社のアプリケーションアーキテクチャはマスタ-レプリカモデルに基づくもので，書き込みはマスタに，分析クエリを含む読み出しはレプリカに対して行われる。マスタに障害が発生した場合には，新たなマスタが選択されて，そのIDがレプリカと書き込みクライアントに伝達される仕組みだ。ファイルオーバ発生時の合計ダウンタイムには，これらのアクティビティがすべて含まれている。チームは，MySQLクラスタのダウンタイムを30分から40～60秒に短縮するとともに，シングルゾーン障害に耐性を持つアーキテクチャをGoogle Cloud内に構築した。記事の執筆者で，WePayのサイト信頼性エンジニアであるAkshath Patkar氏は，新たなアーキテクチャでは"フェールオーバタスクを単純化し，より小さなチャンクに分割した"，と説明している。
以前のアーキテクチャではマスタフェールオーバにMHAを使用していたが，新しいものでは，Githubが開発したオープンソースツールのOrchestratorを採用している。いずれのアーキテクチャでもHAProxy – TCP/HTTPロードバランサ – が重要な役割を担うが，その使い方が異なっている。一般的な設定では，HAProxyはバックエンドのサーバ"プール"にリクエストを分散する。以前のアーキテクチャでは，MHAとHAProxyのパッチバージョンを使用して，プール設定の動的な変更を処理していた。HAProxy自体のフェールオーバについては，Google Routesを使用して，障害のあったものとは別の正常なHAProxyインスタンスに，クライアントのトラフィックをルーティングしていた。この構成ではHAProxyが単一障害点であり，Google Cloudにネットワーク上の問題があってルートを即時に変更できない場合には，問題はさらに複雑になっていた。最小ダウンタイムは30分程度だった。これに加えて，レプリケーションラグをpt-heartbeat – レプリケーションの遅延を測定するツール – で測定していたため，MHAサーバとレプリカの時間のずれが計算誤差につながる可能性があったのだが，NTPを使用しても時間のずれが防止できず，その理由も不明だった。
新しいアーキテクチャでは，Githubのエンジニアリングチームが開発し，同社のデータセンタで使用されているオープンソースツールのOrchestratorを採用している。Orchestratorは，現在のマスタの障害を検出すると，新たなマスタを選択する。GithubでもWePayと同じように，OrchestratorとConsulを連携して使用しており，ローカルのConsulデーモンが新たなマスタの詳細をそれ自身で更新する。WaPayでは，Consulデーモンの更新に，現在のマスタとレプリカに関する情報を保持するconsul-templateを使用している。以前のアーキテクチャとは異なり，新たなアーキテクチャでは，HAProxyを2つのレイヤで動作させている。ひとつのインスタンスは個々のアプリケーションと共に，そのKubernetesデプロイメントのローカルプロセスまたはサイドカーとして動作しており，アプリケーションはこのローカルHAProxyを使用してMySQLに接続する。リモートとローカルのHAProxyインスタンスは別のゾーンで動作し，それによってスプリットブレインの発生を回避している。リモートHAProxyインスタンスは現在のトポロジを理解しており，ローカルインスタンスはリモートインスタンスに接続することで最新のマスタ情報を取得する。
このアプローチで計画的(メンテナンス)および非計画的ダウンタイムのいずれも処理可能だが，方法にいくつかの違いがある。レプリケーションラグの計算方法も変更され，pt-heartbeatは各レプリカ上で動作してマスタに行を挿入し，その行を確認するようになった。