2009/03/01

障害時の自動代替・修復は高度になるほど良い? (Gmail障害と改善方針について思うこと)

先日Gmailに大規模な障害が発生したそうです。
各所でこれについて取り上げていますが、今回はGmailや今回の障害自体の話ではありません。

Googleから2/24にGoogle Appsユーザーに向けてレポートが出されました

Google Apps - Gmail Incident Report February 24, 2009
Additional Details
A few months ago, new software was implemented to optimize data center functionality to make more efficient use of Google's computing resources, as well as to achieve faster system performance for users.
Google's software is designed to allow maintenance work to be done in data centers without affecting users. User traffic thatcould potentially be impacted by a maintenance event is directed towards another instance of the service. On Tuesday, February 24, 2009, an unexpected service disruption occurred during a routine maintenance event in a data center. In this particular case, users were directed towards an alternate data center in preparation for the maintenance tasks, but the new software that optimizes the location of user data had the unexpected side effect of triggering a latent bug in the Gmail code. The bug caused the destination data center to become overloaded when users were directed to it, and which in turn caused multiple downstream overload conditions as user traffic was automatically shifted in response to the failures. Google engineers acted quickly to re-balance load across data centers to restore users' access. This process took some time to complete.
これによると、
  1. 数ヶ月前に、性能改善のために新しい地理的最適化ソフトウェアを導入した。
  2. Googleのソフトウェアはメンテナンス時にもユーザの影響を回避するための他のデータセンタにリダイレクトされて代替される。
  3. メンテナンス時に、新しいソフトウェアによる最適化の思わぬ副作用がGmailの潜在バグを顕在化させた。
  4. Gmailの潜在バグによって代替先のデータセンタが過負荷になった。
  5. これが更に後段の過負荷をもたらした。
    ということのようです。

    2の措置は今回の件とは関係なくずっと以前から行っていたと考えるのがGoogleの環境では自然でしょう。
    1に関しては、「思わぬ副作用」とは行っているものの不良とは言っていません。
    これに対して、3はGmailの潜在バグと明言しており、これを根本的原因と捕らえているようです。

    まとめると、
    「新しい最適化の思わぬ副作用がGmailの潜在不良を顕在化させ、Gmailの不良よる過負荷障害が連鎖的に拡大した。」
    というところでしょうか。

    これを聞いて、2003年北アメリカ大停電を思い出しました。
    被害が拡大した原因には諸説あるものの、有力な説に送電管理システムのダウンにより連鎖反応を起こしたためというのがあります。

    今回のGmailのケースはこれとそっくりではないでしょうか。

    残念ながら、この教訓は今回は生かされなかったようですし、今後も生かされるかどうかが不安です。
    というのも、先述のようにGoogleは根本原因をGmailの不良と捕らえ、さらには、基盤の自己修復機能を高度化することを良しとしているように思えるからです。

    Googleは今回の問題に対する改善策として、
    1. Given the risks associated with maintenance events, we understand that it's a traditional IT practice to limit maintenance events to weekends and evenings. This being said, Google's large distributed global infrastructure makes it impossible to mimic this traditional model because complex maintenance events cannot be completed to fit every user's off-hours. Our goal is therefore to innovate on the technology and process fronts to make our systems as self-healing and self-managing as possible. We feel that we run a very reliable system, but we also believe that there's always room for improvement. To that end, Google engineers work around the clock to make our productionsystems better.
    グローバルなインフラであるGoogleは完全にオフラインの間にメンテナンスすることは不可能、と言うことを理由に、自己修復、自己管理技術を革新するとしています。

    これには賛同しかねます。
    北アメリカ大停電と同様に、今回のGmailの障害も自己修復が障害の連鎖を招き事態を悪化させたのだとしたら、自己修復、自己管理機能を強化することは逆効果かもしれないからです。
    (それに、完全にオフラインは無理だとしても休日にすることはできるはずです。)

    個人の経験から言える、HA(高可用性)システムのあるべき姿は、
    • 自動代替メカニズムはシンプルに
    • 自動代替はそれ自身でどこかに歯止を
    • 緊急手動停止装置も
    というものです。


    今回の報道について、言いたいこともありますが、それは別の機会に。