パスワードを忘れた? アカウント作成
12674583 story
インターネット

先週発生したGitHubの障害、発端はデータセンターの電源設備トラブル 25

ストーリー by hylom
想定外の連鎖 部門より

1月28日、GitHubで障害が発生しサービスを一時的に利用できない状況となったが、この障害はデータセンターにおける電源設備のトラブルが発端で発生していたそうだ(PublickeyGithub)。

GitHubによると、データセンターでの電源装置の不具合により連鎖的に障害が発生し、GitHub.com全体で致命的な問題が発生することに繋がったという。なお、GitHubは自社でデータセンターを運用しているそうだ。

この議論は賞味期限が切れたので、アーカイブ化されています。 新たにコメントを付けることはできません。
  • by nemui4 (20313) on 2016年02月01日 13時04分 (#2957609) 日記

    DCでの事故原因として電源がよく上げられるけど、改善されない要因ってなんだろう。

    ・電源なんてあって当たり前なので管理がいい加減のまま。
    ・不安なので多重化しててもやっぱりどっかで事故っててきりがない。
    ・実は他に原因があるけど言い訳(スケープゴート)にされやすい。
    ・掃除のオバちゃんが黒幕。

    • Re:弱点 (スコア:2, 参考になる)

      by Anonymous Coward on 2016年02月01日 14時11分 (#2957653)

      電源周りは経年劣化が防げないので、お金と冗長性のトレードオフの結果じゃないでしょうか。
      データセンターの管理者とサービスのプロバイダーが同じで、ユーザーが多少我慢してくれるような所だと、金をケチって時々サービスを落としたほうが得なんだと思います。

      でかい共用のデータセンターだと冗長性の規格があって、電源系統の冗長性や、受電設備-ラックUPS系統の冗長性、サーバーUPSの冗長性から施設の耐震性能に至るまでの要求事項が決められています。
      そして、こういった要求事項を満たしているので、統計的に年間の無電源時間をx時間以内に抑えられるはずだというのをユーザーに保証しています。

      親コメント
      • by Anonymous Coward

        世間ではこの件でギットは信頼性が低いって風潮ですが

        • by Artane. (1042) on 2016年02月01日 18時15分 (#2957805) ホームページ 日記

          分散型のヴァージョン管理システムで、特定サーバの信頼性が云々って、限定的にしか問題にならないのではないかと思うんですけどね。
          最終的には、大本の所との同期が取れたらいいので…

          githubにホスティングやバックアップ機能を完全に依存してれば確かに問題ですが、ユーザが複数いるような場合には、確かに同期を取ればいいだけの話のような(;´Д`)

          それでも不十分となったら、別のサービスで多重化した方がいいでしょうね。(と言うか、前々から一個のサービスでの公開だとこの手の障害ならまだしも、洪水とか爆発事故とか地震とかのもっと壊滅的な物理的障害には脆弱なので複数サービスに登録しようか迷ってはいますが)
          参考:http://www.find-job.net/startup/5-git-hosting [find-job.net]

          --
          --暮らしの中に修行あり。
          blogはじめました。 [hatena.ne.jp]
          親コメント
          • by Anonymous Coward on 2016年02月01日 18時33分 (#2957815)

            「限定的にしか問題にならない」
            のと
            「今回の障害で信頼性に疑問が出てる」
            のは全然別の話

            商用サービスとして売ってるんであれば、
            少なくとも完全に停止するような障害は避けるべきだと思いますよ

            親コメント
            • by Artane. (1042) on 2016年02月01日 21時25分 (#2957893) ホームページ 日記

              WEBサーバとかメールサーバならば確かに間違いじゃないと思うんですよ。
              ファイルサーバにしてもミラーリング周期に追いつかないようなやり取りが頻発するとかならたしかにそうです。

              只、今回はGitですからね。
              元々自分の所と繋がってるノードを複数持てて、一回のpushやpullで同期を取れてしまう上に、大元は自分たちのところにありますからね。
              原則論的には、上記のような無停止性は重要じゃなくて、もう少し長いタイムスパン…数日とか…の停止期間があってもシステム的には何とかできるので。
              問題は、システムが落ちる前の状態で確実にバックアップからリストアできるか。改めてpushした時に、リポジトリの整合性が維持出来てるか。の方じゃないですか。

              どちらかというと、次善の策をきちんと用意しましょうね。と言う話なのでは…年に何回かは落ちる可能性があるという前提で動いたほうがいいプロトコルなのでは…。

              勿論、数百人規模やそれ以上の社内Commiterを(クローズドなプロジェクトとして)同時に捌く為に月何万円?もお金を払って有償サービスを買うような場合は、全く話が変わってくるでしょうけど、それもセカンダリの設定で凌げなくはない。

              --
              --暮らしの中に修行あり。
              blogはじめました。 [hatena.ne.jp]
              親コメント
            • by Anonymous Coward

              GitHub Enterpriseは落ちなかったようですようです
              まあ、そういうことです

        • by Anonymous Coward on 2016年02月01日 19時11分 (#2957836)

          GitHub がどうだかは知りませんが、急成長したサービスだと設備が追いついていない可能性はありますね。
          変に GEEK なノリが残っていたりとか。

          # さすがに、こんなこと [atmarkit.co.jp]は無いと思いますがw

          親コメント
          • by Anonymous Coward
            こんなことってこんなこと [it.srad.jp]かと思ったけどいろんなこんなことがあっていい
        • by Anonymous Coward

          そーなの?
          復帰してからpushするだけやないの?

        • by Anonymous Coward

          AWS CodeCommit
          https://aws.amazon.com/codecommit/ [amazon.com]

        • by Anonymous Coward

          自宅で最近使い始めたばかりなので詳しくは無いけど、中央集権型が良いならgit選ぶ必要無いのでは?
          SubversionやTFS(名前変わってたらゴメン)をSAASなり借りて作りゃいいやん、と思うんだけどなあ。

        • by Anonymous Coward

          むしろGitのおかげで完全なミラーリング、冗長化が簡単にできるのでとても良いなと思っています。

      • by Anonymous Coward

        以前使ってたDCも電源が一番高価だったな。
        起動タイミングのずらし方も電源の負荷を考えての事だったし。

        (DCの高価な装置も設定ミスで停電したときは笑うしかなかった。

    • by Alternating Current (39820) on 2016年02月01日 15時37分 (#2957704)

      AC にすればよい!

      親コメント
    • by Artane. (1042) on 2016年02月01日 21時50分 (#2957906) ホームページ 日記

      コンピュータの電源に使われてるスイッチング電源は、大抵、整流した商用電源をFETのスイッチで制御して定電圧を供給していますが、途中途中に大容量の電解コンデンサやコイル・トランスを挟んで求められる安定度と直流の「きれいさ」(ノイズ輻射や電圧変動の小ささ)を確保している訳です。

      これらの部品は経年劣化するし、温度や負荷が高ければ劣化速度は加速します。
      特に、電解コンデンサには電子部品としては比較的短い寿命がありまして、平均故障間隔 [wikipedia.org]が、少し前だと1,000〜2,000時間@105℃、長くても5,000時間で、最近になっていろいろ改善されたり材質が固体化されたりして、10,000時間@105℃の物が出始めた。
      電源内部が50℃位で動作してると仮定した場合、電解コンデンサの温度依存性の法則 [nteku.com]から、中のコンデンサが2,000時間@105℃の場合、大体90,000時間=10年ちょっとの平均故障間隔となりますが、データセンターのサーバとなると熱的にかなりタイトなので、60℃程度で動作してる部位やリップル電流でもう少し高い温度になってるコンデンサもあるでしょうから、平均して大体5年弱で電源装置が壊れると見たほうがいいでしょう。

      今は、電源に自己診断装置やロギング機能が入っていて、不良を起こしそうな兆候が見られるとアラートを上げるものも出てきてるようですが、自社データセンターで、大半のユーザが無料と言うサービスが、そこまで頻繁に機材を入れ替えてるだろうか。と言う問題があるわけです。

      そんな感じである上に、スイッチング電源の設計が拙かったとか部品が想定外の壊れ方をしたということがあると、電源が短絡モードで故障したり商用電源側に大きな負荷変動を起こすことがある訳ですよ。そうなると、ラック内の他のサーバや他の電源ノードにまで影響が波及していく。これが、今回の問題の構図なんじゃないかと思いますよ。

      --
      --暮らしの中に修行あり。
      blogはじめました。 [hatena.ne.jp]
      親コメント
      • by nemui4 (20313) on 2016年02月02日 0時42分 (#2957962) 日記

        とあるメーカーのWSは、内部管理ツールで電源ユニット毎のファン稼働時間を積算していて一定時間毎に交換アラームあげてきますね。
        保守入ってたら定期的にCEさんがそれのlog見て交換していってる。
        同時に稼働しているはずなのに、並列の電源ユニットの交換タイミングがバラバラなのが不思議だけどわざとそうしてんのかな。

        親コメント
        • by Anonymous Coward

          わざとじゃないですかねえ。同時に同じロットのものを大量に交換した結果
          同じタイミングで大量に故障して焼け野原ってのを防ぎたいのじゃないかと。
          この辺実際運用に携わっている人の話を聞いてみたいです。

      • by Anonymous Coward

        商用電源側の大きな負荷変動が祟ったかもしれないという推測はありえるかもです。
        障害検知をするための負荷変動のトリガーの感度設定ミスとかは過去にどこかでありましたね。
        鈍感で検知できない場合や、敏感すぎて切り替えた直後に異常と誤認識して落ちるとか。

        ところで、大抵のところでは電源装置が故障することは当然の前提で電源系統の冗長性を確保しています。
        それでも落ちたのはどうしてだということですね。
        例えば、実システムでの切り替えテストが不十分だったとか、
        運用していく過程でのシステムの増改築変更により当初の設計想定外となったとか、
        最初からある程度のリスクは覚悟していたとかなんだとか。

        githubの原因はなんだったのか気になります。

    • by acountname (43053) on 2016年02月02日 12時37分 (#2958151) 日記

      稼働中の装置が、実際に正常に切り替わるかどうか試験するわけにもいかんだろうしなあ。

      親コメント
      • by Anonymous Coward

        「失敗するとコワいから切り替えテストができない」ぐらいの信頼性で運用してほしくないなぁ...

    • by Anonymous Coward

      こないだもGMOが電源設備トラブルで長期システムダウンしてましたよね。

      多重化しても多重化を制御する装置がイカれたりするんでしょうか。

  • ちょうどこの障害のタイミングでPackagistに上がってるパッケージを入れることがあって困った。
    目的のリポジトリ(ソース)がGitHub以外に見当たらない場合に困るなあと実感しました。

    --
    ---にょろ~ん
typodupeerror

吾輩はリファレンスである。名前はまだ無い -- perlの中の人

読み込み中...