Github.comは、API、認証、Github.comのウェブサイトなど多くの重要なサービスのバックボーンとしてMySQLを使用している。Githubのエンジニアリングチームは、以前のDNSとVIPベースの設定をOrchestrator、Consul、Github Load Balancerに基づく設定に置き換え、スプリットブレインとDNSキャッシュの問題を回避した。
Githubはさまざまなサービスやタスクのために複数のMySQLクラスタを実行する。そのため、それらを高可用にすることが不可欠である。 Githubのインフラストラクチャは、15台のクラスタ、150台のプロダクションサーバ、15TBのMySQLテーブルで構成される複数のデータセンターに分散している。各MySQLクラスタには、書き込み要求に応答する単一のマスタと、マスタのレプリカで、読み取り要求に応答する複数のスレーブで構成される。マスターノードは単一障害点であり、マスタがなければ、書き込みは完全に失敗する。この設定のHA要件には、障害の自動検出、スレーブノードのマスターへの自動プロモーション、新しいマスターノードからクライアントアプリケーションへの自動通知が含まれる。
Githubのエンジニアリングチームは、長年にわたってHAのためのいくつかの戦略を採用しており、徐々に組織全体の統一に向かっている。これはMySQLに限定されないため、HAソリューションの要件には、データセンター間の可用性とスプリット・ブレーク防止が含まれている。MySQLマスターディスカバリーには、さまざまな方法がある。以前は、GithubはMySQLマスタノードの検出にDNSと仮想IPアドレス（VIP）を利用していた。クライアントアプリケーションは固定ホスト名に接続し、仮想IP（VIP）にDNSによって解決される。VIPを使用すると、異なるホストにトラフィックをルーティングし、単一のホストに拘束することなくモビリティを提供できる。VIPは常に現在のマスターノードによって所有される。しかし、スプリットブレイン状況を含むフェールオーバーイベント中に、VIPの取得および解放プロセスに潜在的な問題があった。これが起こると、2つの異なるホストが同じVIPを持つことができ、トラフィックを間違ったホストにルーティングする可能性がある。さらに、異なるデータセンターにあるマスターノードを扱うためには、DNSを変更しなければならず、クライアントのDNSキャッシュのために伝播に時間がかかる可能性がある。
Githubの最新のセットアップには、Orchestratorツールキット、サービスディスカバリのためのConsul、Github Load Balancerが含まれている。このアーキテクチャでは、クライアントアプリケーションが名前でDNSのマスターIPをルックアップすると、それはAnycastで解決される。Anycastを使用する利点は、すべてのデータセンターで同じIPアドレスに名前が解決されても、そのIPへのクライアントトラフィックは最も近いマスターにルーティングされることである。最も近いマスターは、同じデータセンターに配置されているマスターである。このルーティングは、現在アクティブなMySQLマスターバックエンドを知っているGLBによって処理される。
画像提供: https://githubengineering.com/mysql-high-availability-at-github/
Orchestratorは、Githubのエンジニアリングオープンソースプロジェクトでもあり、マスタ障害の検出とフェールオーバープロセスを行う。レプリカを含むすべてのMySQLノードから引き出された集合的な知識を利用して、マスターの状態に関する決定を下す。書き込みマスターに障害が発生すると、Orchestratorリーダーノードは障害を検出し、フェールオーバープロセスを開始して新しいMySQLマスターを選択する。残りのOrchestratorクラスタノードはこの変更を認識し、ローカルのConsulデーモンを新しいマスター詳細で更新する。Consulは、Hashicorpが提供するサービス発見ツールである。Consulは、マスターノードをキーと値のペアとして保存して追跡する。Consulはデータセンター間で分散モードで実行できるが、Githubの場合、各Consulクラスターはデータセンターレベルで独立している。GLBは、Consulテンプレートを使って、フェールオーバーイベントでマスターステータスの変更通知を受ける。Consulテンプレートは、Consulクラスターを照会してGLB状態を更新する。そして、トラフィックを新しいマスターにルーティングする。
この記事では、Githubの上級インフラストラクチャエンジニアであるShlomi Noach氏は、新しいセットアップではほとんどの場合、最大停止時間が「10～13秒」であると述べている。そして、スプリットブレイン、またはフェールオーバー時のConsulの停止につながる、データセンターの隔離にような、より多くの作業が必要なシナリオがいくつかあと述べている。Githubの新しい設定は、ネットワーキングに基づく従来の技術から、プロキシとサービス発見に基づくものへ移行している。これはVIPベースのものを完全に置き換えているが、Border Gateway Protocol（BGP）を使用した別のアプローチを採用する方が簡単かどうかという議論がある。
Rate this Article
- Editor Review
- Chief Editor Action