完全復旧までに24時間を要したGitHubの障害は43秒のネットワーク切断がきっかけだった 21
ストーリー by headless
相談 部門より
相談 部門より
GitHubは10月30日、日本時間10月22日に発生した障害のきっかけが43秒間のネットワーク切断だったことを明らかにした(GitHub Blogの記事、
The Registerの記事、
GeekWireの記事)。
日本時間10月22日7時52分、不調となった100G光ネットワーク機器の定期メンテナンスによる交換が行われた際、プライマリーの米東海岸データセンターと米東海岸ネットワークハブの間で43秒間接続が失われたという。その結果、Orchestratorにより米西海岸データセンターが新たなプライマリーに選出され、書き込みトラフィックが送られはじめる。
しかし、米東海岸データセンターにも西海岸で複製されていない短時間の書き込みがあり、両データセンターのMySQLデータベースクラスターには一方だけに存在する書き込みが含まれることになる。そのため、安全に東海岸をプライマリーとしてフェイルバックすることが不可能な状態となっていた。
日本時間10月22日7時52分、不調となった100G光ネットワーク機器の定期メンテナンスによる交換が行われた際、プライマリーの米東海岸データセンターと米東海岸ネットワークハブの間で43秒間接続が失われたという。その結果、Orchestratorにより米西海岸データセンターが新たなプライマリーに選出され、書き込みトラフィックが送られはじめる。
しかし、米東海岸データセンターにも西海岸で複製されていない短時間の書き込みがあり、両データセンターのMySQLデータベースクラスターには一方だけに存在する書き込みが含まれることになる。そのため、安全に東海岸をプライマリーとしてフェイルバックすることが不可能な状態となっていた。
GitHubの対策チームは、データの消失を最低限におさえるため、西海岸に複製されていない東海岸でのMySQLバイナリーログを確保しつつ、東海岸のデータセンターに対するバックアップからの復元作業を開始する。外部のクラウドストレージに保存されたバックアップは数TBにおよび、復元には数時間を要した。復元されたクラスターには西海岸から新しいデータを追加し、東海岸がプライマリーとして復旧したとのこと。
GitHubでは現在、東海岸のログを分析して復元を進めているほか、地域をまたぐプライマリー変更が行われないようOrchestratorの設定を調整するなどの対策を行ったとのことだ。
SQLServer (スコア:2)
Re: (スコア:0)
GitHubのその辺って複数DBに対応してるんかね？
確かにSQLServerもLinux対応したしなぁ。
どっちかというとアプリ書き換えるよりデータ移行のほうが楽な気がする。
ってことでTFSに置き換えられたら笑うぞw
(因みにTFSのバックエンドはSQLServerな)
勿論本気で言ってはいない。
Re: (スコア:0)
ついでに基盤もAzureに…いやいま何でやってるか知らんのやけど、それで解決するならそれでもええんちゃう？
Re: (スコア:0)
後学のために教えてほしいのですが、今回のような障害に対して SQL Server を採用するとなにかアドバンテージがあるということでしょうか？
Re: (スコア:0)
MSがGitHub買収したからのネタだよ。言わせんな、恥ず(ry
要するに (スコア:0)
両データセンターのMySQLデータベースクラスターには一方だけに存在する書き込みが含まれることになるってそんな状態を許すOrchestratorってなに？
二重化したつもりが出来てなかったってこと？
Re:要するに (スコア:2, 参考になる)
別の解説 [atmarkit.co.jp]とそのはてブ [hatena.ne.jp]
説明と改善策にもあるけど、距離があること、データがデカいことの両方が影響するので、リーダー選出は動作として正しかったがリカバリー策として不十分(になっていた)ということかな?
ただ綺麗に同期できればいいけど、そこはNGなとこか
引用
対策
NGなとこはここ?
Re: (スコア:0)
う～ん、そこは別にNGでもなんでもないのでは。
アクティブ・アクティブ構成で片方を異常とみなしてもう一方を主に切り変える事象が発生したに過ぎない。
正常に通信出来るようになったからといって再び戻さなくともデータに異常なんて起きない。普通はね。
問題は
米国西部のMySQLが新たなマスターになるまでに複製ができなかった少量のデータが残っていた。
じゃね？切り替えが期待通り行われていなかったことじゃないか、これ。
通信が遅いとかって、そもそもRDBのレプリケーションってそんな環境下でも動作するものだと思ってたが。
mysqlのレプリケーションってそんなダメダメなんか。
いやレプリケーションでなく切り替えタイミングを誤るオーケストラの問題か。
今回は43秒の不断が原因というけれど、障害発生したら正常に切り替えられないってこと示してない、これ？
なんか発表が煙に巻くような内容で嫌。
Re:要するに (スコア:2)
一貫性が保てないなら、プライマリから外れたなら書き込み禁止になるか、
ロールバックして不完全な書き込みを無かったことにするか、そうしてほしいかな。
プライマリの選出でネットワーク遅延が問題になるなら、
同時に全部落ちた方が復旧は楽そう。
サービスの継続性は、他で帳尻合わせて。
Re: (スコア:0)
遠距離だと同期レプリケーション（全サーバに書き込むまで待つ）なんてやると遅延凄いから
非同期レプリケーションだと思うけど。
MySQLだと準同期レプリケーションの方かな？
Re:要するに (スコア:3, 参考になる)
Githubによると500msタイムアウトの準同期レプリケーションですね。
この構成ならDCレベルのNetwork partitionが起きたらだめだろうなあ。というかデザインの段階で諦めている様子
> Lossless failover on a complete DC failure is costly and we do not expect it.
https://githubengineering.com/mysql-high-availability-at-github/#semi-... [githubengineering.com]
Re: (スコア:0)
そんな資料あったんですね。ありがとう。
GitHub規模だとRDBMSの機能範囲でとどめるべきだと思うし妥当ですね。
#DAO層で同じ処理を複数DBに投げてデータ値のみ同期なんてのはやった事あるのでGitHub規模でやってみたい気はするｗ
当時のプロジェクト（SI系）で内容を理解できる人は皆無ｗRe:要するに (スコア:2)
> #DAO層で同じ処理を複数DBに投げてデータ値のみ同期なんてのはやった事あるのでGitHub規模でやってみたい気はするｗ
グローバル分散環境でそれやると、遅すぎて業務にならなくなったりしない？
MySQLの準同期レプリケーションだと、スレイブ側に書き込んじゃいかんよな……
Re: (スコア:0)
この手の瞬断みたいなケースって結構やっかいじゃない？
よくあると言ってはなんだが、クラスター障害の原因などを調べると、これに行き着くことが多い。
バックアップは数TBにおよび (スコア:0)
なんか少ない印象。ソースばっかりだとそんなモンなのかな。
Re:バックアップは数TBにおよび (スコア:1)
GitHub が Mysql に保存しているのは Issues やプルリクエストなどのメタデータだけ。
ソースの保存先は別です。
DRだの複数拠点跨る仕組みの定期的な試験 (スコア:0)
言うようにNetflixがやってるようなカオスエンジニアリングしか手が無いんだろうか。
運用前に確かめた仕組みと仕掛けが何時までも機能するなんて誰も思ってないが、
何も起きないから許されてるか、起きても根性でみんな何とかしてるが。
Re: (スコア:0)
確認したときは動いていたという証拠さえあればなんとかなる。
Re: (スコア:0)
> カオスエンジニアリングしか手が無いんだろうか。
カオスプログラミングなら実践しているんですが...
Re: (スコア:0)
これでMariaDBの信頼性が上がってくれるならありがたい。