BT

GithubエンジニアリングがMySQL高可用性のために新しいアーキテクチャを採用

| 作者: Hrishikesh Barua フォローする 16 人のフォロワー , 翻訳者 編集部T _ フォローする 0 人のフォロワー 投稿日 2018年7月23日. 推定読書時間: 4 分 |

原文(投稿日:2018/07/08)へのリンク

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ツールキット、サービスディスカバリのためのConsulGithub 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

Adoption Stage
Style
 
 

この記事に星をつける

おすすめ度
スタイル

こんにちは

コメントするには InfoQアカウントの登録 または が必要です。InfoQ に登録するとさまざまなことができます。

アカウント登録をしてInfoQをお楽しみください。

あなたの意見をお聞かせください。

HTML: a,b,br,blockquote,i,li,pre,u,ul,p

このスレッドのメッセージについてEmailでリプライする
コミュニティコメント

HTML: a,b,br,blockquote,i,li,pre,u,ul,p

このスレッドのメッセージについてEmailでリプライする

HTML: a,b,br,blockquote,i,li,pre,u,ul,p

このスレッドのメッセージについてEmailでリプライする

ディスカッション
BT