インフィニティソリューションズ株式会社ブログ

欧州Windows Azureの障害の真因は…やってもうた!!

7月26日、欧州でWindows Azureの障害が発生。2時間以上にわたってサービスがストップする事態が発生した。マイクロソフトはその真因分析の結果をブログで明らかにしている。
AllThingsDの「Microsoft Explains Last Week’s Azure Outage: Whoops!(マイクロソフトが先週のAzure障害を説明:しまった!)

‘In a blog post summarizing Microsoft’s root-cause analysis of the incident, Mike Neil, general manager for Windows Azure, writes that someone forgot to adjust a safety-valve setting in the networking gear.’

「Windows AzureのジェネラルマネージャMike Neil氏が、ブログポストで、障害の真因分析をまとめており、そこで、ある者がネットワーク装置のセーフティバルブの設定調整を忘れた、と記している。」

MSDN Blogs

‘Just before everything happened, the company had just added a bunch of new capacity. The safety-valve mechanisms on the networking equipment, which usually guard against the possibility of a cascading failure brought on by unusual spikes in the number of connections, hadn’t had their limit setting adjusted upward. So when the new capacity was brought online, the safety valves hit their limits, and did what they were set to do: Generate network-management messages to administrators. The resulting surge in traffic brought on by those messages triggered other bugs, and pushed the CPU usage of some of the machines in the cluster to 100 percent.’

「事態が発生する直前、同社は相当量のキャパシティ追加を行った。ネットワーク装置のセーフティバルブ機構は、通常接続数の異常急増による連鎖障害を防ぐためのものであるが、その制限値を上方修正していなかった。従って、キャパシティ追加がオンラインになると、セーフティバルブは閾値に達し、期待されている通りの動作を行った。ネットワーク管理メッセージ群を生成し、管理者に通知することだ。このメッセージ群の結果もたらされたトラフィック増加が、他のバグを引き起こし、クラスター内のいくつかのマシンのCPU使用率が100%に達してしまったというものだ。」

— 6月のAmazonの障害は、サーキットブレーカーの設定値が余りに低かったため、通電したとたんにブレーカーが切れたことが原因であったが、なんだかWindows Azureも同じような原因にみえる。ただマイクロソフトの真因分析は、発生した事象をシステム内で遡っているだけであって、何故そのような設定になったのか、正しい設定がなされたことを確認するチェック機構はあったのか、なかったのか、など、もっと突っ込んでいかないと真因分析にならない。明らかにされていないだけかもしれないが、これで真因分析だといわれると、早い話が誰かがミスった、以降ミスらないように注意します、になっちゃうぞ。