パスワードを忘れた? アカウント作成
13759837 story
スラッシュバック

完全復旧までに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データベースクラスターには一方だけに存在する書き込みが含まれることになる。そのため、安全に東海岸をプライマリーとしてフェイルバックすることが不可能な状態となっていた。

GitHubの対策チームは、データの消失を最低限におさえるため、西海岸に複製されていない東海岸でのMySQLバイナリーログを確保しつつ、東海岸のデータセンターに対するバックアップからの復元作業を開始する。外部のクラウドストレージに保存されたバックアップは数TBにおよび、復元には数時間を要した。復元されたクラスターには西海岸から新しいデータを追加し、東海岸がプライマリーとして復旧したとのこと。

GitHubでは現在、東海岸のログを分析して復元を進めているほか、地域をまたぐプライマリー変更が行われないようOrchestratorの設定を調整するなどの対策を行ったとのことだ。
  • by yatyura (11511) on 2018年11月04日 0時34分 (#3509644)
    に変更するんじゃないかな。
    ここに返信
    • by Anonymous Coward

      GitHubのその辺って複数DBに対応してるんかね?
      確かにSQLServerもLinux対応したしなぁ。
      どっちかというとアプリ書き換えるよりデータ移行のほうが楽な気がする。
      ってことでTFSに置き換えられたら笑うぞw
      (因みにTFSのバックエンドはSQLServerな)

      勿論本気で言ってはいない。

    • by Anonymous Coward

      ついでに基盤もAzureに…いやいま何でやってるか知らんのやけど、それで解決するならそれでもええんちゃう?

    • by Anonymous Coward

      後学のために教えてほしいのですが、今回のような障害に対して SQL Server を採用するとなにかアドバンテージがあるということでしょうか?

      • by Anonymous Coward

        MSがGitHub買収したからのネタだよ。言わせんな、恥ず(ry

  • by Anonymous Coward on 2018年11月03日 17時49分 (#3509505)

    両データセンターのMySQLデータベースクラスターには一方だけに存在する書き込みが含まれることになるってそんな状態を許すOrchestratorってなに?
    二重化したつもりが出来てなかったってこと?

    ここに返信
    • Re:要するに (スコア:2, 参考になる)

      by Anonymous Coward on 2018年11月03日 18時31分 (#3509521)

      別の解説 [atmarkit.co.jp]とそのはてブ [hatena.ne.jp]

      説明と改善策にもあるけど、距離があること、データがデカいことの両方が影響するので、リーダー選出は動作として正しかったがリカバリー策として不十分(になっていた)ということかな?

      ただ綺麗に同期できればいいけど、そこはNGなとこか

      引用
      対策

      GitHubは今回のサービス障害を受け、次のような対策を講じるとしている。

      地理的に離れた2つのデータセンターにまたがってマスターセレクションを行う設定をやめる
      サービスステータス表示の方法を改める。「緑」「黄」「赤」だけでなく、サービスの種類に応じ、より詳細な情報を表示するようにする
      GitHubは障害発生の数週間前から、データセンターを1カ所失っても問題がないように、N+1の新たなサービスデリバリアーキテクチャを構築する取り組みを始めている。この取り組みを加速する
      サービスに関する同社の数々の前提をあらためて検証すべく、自律的に動いていく

      NGなとこはここ?

      また、オーケストレータ―機能は米国東部の接続が復旧しているにもかかわらず、同データセンターのMySQLデータベースインスタンスをスレーブ/リードレプリカとして認識せず、米国西部データセンターで完結したデータベーストポロジーを構成した。

      • by Anonymous Coward

        う~ん、そこは別にNGでもなんでもないのでは。
        アクティブ・アクティブ構成で片方を異常とみなしてもう一方を主に切り変える事象が発生したに過ぎない。
        正常に通信出来るようになったからといって再び戻さなくともデータに異常なんて起きない。普通はね。

        問題は

        米国西部のMySQLが新たなマスターになるまでに複製ができなかった少量のデータが残っていた。

        じゃね?切り替えが期待通り行われていなかったことじゃないか、これ。
        通信が遅いとかって、そもそもRDBのレプリケーションってそんな環境下でも動作するものだと思ってたが。
        mysqlのレプリケーションってそんなダメダメなんか。
        いやレプリケーションでなく切り替えタイミングを誤るオーケストラの問題か。

        今回は43秒の不断が原因というけれど、障害発生したら正常に切り替えられないってこと示してない、これ?
        なんか発表が煙に巻くような内容で嫌。

        • 一貫性が保てないなら、プライマリから外れたなら書き込み禁止になるか、
          ロールバックして不完全な書き込みを無かったことにするか、そうしてほしいかな。

          プライマリの選出でネットワーク遅延が問題になるなら、
          同時に全部落ちた方が復旧は楽そう。
          サービスの継続性は、他で帳尻合わせて。

        • by Anonymous Coward

          遠距離だと同期レプリケーション(全サーバに書き込むまで待つ)なんてやると遅延凄いから
          非同期レプリケーションだと思うけど。
          MySQLだと準同期レプリケーションの方かな?

          • Re:要するに (スコア:3, 参考になる)

            by Anonymous Coward on 2018年11月04日 14時35分 (#3509782)

            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]

            • by Anonymous Coward

              そんな資料あったんですね。ありがとう。
              GitHub規模だとRDBMSの機能範囲でとどめるべきだと思うし妥当ですね。

              #DAO層で同じ処理を複数DBに投げてデータ値のみ同期なんてのはやった事あるのでGitHub規模でやってみたい気はするw
              当時のプロジェクト(SI系)で内容を理解できる人は皆無w

              • by nim (10479) on 2018年11月05日 14時03分 (#3510184)

                > #DAO層で同じ処理を複数DBに投げてデータ値のみ同期なんてのはやった事あるのでGitHub規模でやってみたい気はするw

                グローバル分散環境でそれやると、遅すぎて業務にならなくなったりしない?
                MySQLの準同期レプリケーションだと、スレイブ側に書き込んじゃいかんよな……

    • by Anonymous Coward

      この手の瞬断みたいなケースって結構やっかいじゃない?
      よくあると言ってはなんだが、クラスター障害の原因などを調べると、これに行き着くことが多い。

  • by Anonymous Coward on 2018年11月03日 18時28分 (#3509520)

    なんか少ない印象。ソースばっかりだとそんなモンなのかな。

    ここに返信
  • by Anonymous Coward on 2018年11月05日 9時13分 (#3510066)

    言うようにNetflixがやってるようなカオスエンジニアリングしか手が無いんだろうか。
    運用前に確かめた仕組みと仕掛けが何時までも機能するなんて誰も思ってないが、
    何も起きないから許されてるか、起きても根性でみんな何とかしてるが。

    ここに返信
    • by Anonymous Coward

      確認したときは動いていたという証拠さえあればなんとかなる。

    • by Anonymous Coward

      > カオスエンジニアリングしか手が無いんだろうか。
       
      カオスプログラミングなら実践しているんですが...

    • by Anonymous Coward

      これでMariaDBの信頼性が上がってくれるならありがたい。

typodupeerror

コンピュータは旧約聖書の神に似ている、規則は多く、慈悲は無い -- Joseph Campbell

読み込み中...