半月で2回も起こったAzureの多要素認証ダウン 原因はアップデートしたコードに潜んでいたバグ：Publickey（2/2 ページ）

[新野淳一，Publickey]

対策するはずが“火に油を注ぐ”結果に

　しかし残念ながら、それは火に油を注ぐような結果になったと、次のように報告されています。

The MFA team recently deployed a change to more effectively manage connections to the caching services. Unfortunately, this change introduced more latency and a race-condition in the new connection management code, under heavy load.

（多要素認証チームは、キャッシュサービスへの接続を効率良く行えるような変更を投入した。しかし、負荷の高い状況でのそうした変更は、新たな遅延と競合状態をさらに呼び込むだけだった。）

　これによって、障害はさらに拡大していきますが、この時点でデータセンターのトラフィックパターンの変更、自動回復システムをオフにし、システムの容量追加、トラフィック制限の管理といった対策も行った結果、徐々に多要素認証システムは回復へと向かっていきます。

　その後、障害の原因となった上記3つの要因を把握。それぞれに対処をした結果、システムが回復しました。Microsoftは対策として、次の4つを挙げています。

• アップデートプロセスに対する開発とテスト時の見直し
• 障害の検出と復旧を迅速に行うためのモニタリングサービスの見直し
• データセンターを超えて障害が広がらない仕組みの見直し
• 障害発生時に迅速に検出しダッシュボードへ表示するツールのコミュニケーションプロセスの改善

二度目はDNSのエントリ切れと別のバグが障害を引き起こした

　ところが、この障害から1週間ほど経過した2018年11月27日。多要素認証システムは再び数時間ほどの障害を起こします。

　今度の原因は、多要素認証システム内部で使用しているDNSのエントリが期限切れとなり、多要素認証のフロントエンドとバックエンドの通信ができなくなったことでした。

　この障害が解消されると次の障害が待っていました。フロントエンドとバックエンドの通信が回復したことにより、バックエンドへのトラフィックが急激に増大。すると、前回障害を引き起こしたコンポーネントと同じコンポーネントにまだバグが潜んでおり、それがバックエンドのリソースの枯渇と競合を発生させ、最終的にサーバをフリーズさせてしまいます。

　これに対処するためにサーバリソースの追加投入などを行い、障害からの復帰を行いました。二度の障害に対して、Microsoftは報告の中で、以下のように平身低頭で謝罪しています。

We sincerely apologize for the impact to affected customers. We are continuously taking steps to improve the Microsoft Azure Platform and our processes to help ensure such incidents do not occur in the future.

（障害の影響を受けたお客さまに、私たちは心からおわびいたします。私たちはこうしたインシデントを将来において二度と起こさないように、継続的にMicrosoft Azureプラットフォームおよびプロセスを改善していきます。）

　同社はバックエンドサーバがフリーズしないようにコードを見直すこと、多要素認証のシステムキャパシティーを増大させること、トラフィックのスパイクに対するスロットリング制御の改善、DNSの変更を自動化することなどを対策として挙げています。

　これだけの障害の原因を短時間で発見し、対策する技術力はさすがMicrosoftと思わせる面はあります。しかし、システムにログインできなければ、顧客にとってそのシステムは存在しないのも同然ですから、この二度の障害は、同社にとって非常に深刻な出来事であったことは間違いないでしょう。

　この記事は、新野淳一氏のブログ「Publickey」の記事「マイクロソフト、AzureやOffice 365にログインできなくなる多要素認証の障害を二度も発生。アップデートしたコードにバグが潜り込んでサーバがフリーズ」を許可を得た上で転載、編集しています。