Microsoft Azureの大規模障害
2019/5/3 4:43 AM JSTごろ、Azure内のDNSの障害を起点として、全世界のコンピューティング、ストレージ、AAD、データベース、などなど広範にサービス停止が発生したそうです。
Microsoft used its Azure Support Twitter account to send this message a short time ago: "Engineers have identified the underlying root cause as DNS resolution issues affecting network connectivity with impact to Compute, Storage, AAD, and Database services.
"Mitigation steps are being applied, and we are starting to see signs of recovery."
（日本語訳）
Microsoftは、Azure Support Twitterアカウントを使用してこのメッセージを少し前に送信しました。
「エンジニアは、根本的な根本原因を、コンピューティング、ストレージ、AAD、データベースサービスへの影響でネットワーク接続に影響するDNS解決の問題として特定しました。
「緩和策が適用されており、回復の兆しが見え始めています。」
ちなみに、最新のツイートにて、「根本原因はDNSの誤った委任」にあるとあります。プライマリーサーバーを計画停止したときに、想定していないサーバーへ引き継がれたように読めます。
⚠️Engineers have identified the underlying root cause as an incorrect name server delegation issue. Mitigation has been applied, and most services have recovered, with the exception of a small subset of services who may still experience some impact. https://t.co/Dw19fIoS5H
— Azure Support (@AzureSupport) 2019年5月2日
エンジニアは、根本的な原因を誤ったネームサーバー委任の問題として特定しました。軽減策が適用され、ほとんどのサービスが回復しましたが、一部のサービスが影響を受ける可能性がある場合を除きます。
感想
基本情報処理試験のときに勉強しました。複数のモジュールはできるだけ独立し、結合させないほうが安全性が高い、と。
インフラを仕事にしていると、一見こういったソフトウェア開発の理論は関係なさそうですが根っこは一緒なのがわかります。
具体的に言えば、今回のAzure障害にて、なぜDNSの設定が間違っていたら全世界のリージョンのネットワークがいっぺんに停止するのか。また、DNSとネットワークをなぜ結び付けたのか。
これは根本的な設計の問題で、結合させなければ起きえなかった問題だと思います。
例えば以下のような設計はいかがでしょうか。
・リージョンごとにDNSサーバーを分割し、同時障害とならないようにする。
・ネットワークインフラストラクチャーにはDNSサーバーを用いずIPアドレスでの実装とする。
・ネットワークインフラストラクチャーと各サービスを分割し、同時サービス障害を避ける。
・・などと今さら言っても遅いのです。もうサービスは動いているのですから。結局のところサービスを開始してから、「ああ設計時にもっとモジュール間の独立性を高めておけば良かった・・」というようになるので、クラウドサービスはリニューアルする場合があります。
私が知っている範囲だと、NTT CommunicationsのEnterprise Cloud、またOracleのGen2 Cloud。この2種類は完全に作り直しました。
AWSやAzureの弱みは、バージョン1にてシェアを握ってしまったので設計ごとリニューアルできないところです。ただAWSは初期の設計が良かったのか、莫大な設備投資のためなのか、昨今は大きな障害が随分ないなあと感心はしています。
話を戻して、DNSを起因として、ネットワークインフラごと停止し、そこからその上のIaaSやらPaaSやらSaaSやらが全部影響を受けるというのは、結合し過ぎという評価になってしまいます。
建物の話に例えるとわかりやすいのですが、ネットワークインフラは地面のようなものです。その上に建物が乗ります。これはコンピューティング（仮想OS）ですね。そしてデータベースやOffice 365、ADのようなサービスが運用されますが、これは建物の中にあるコンビニや病院、住居などに例えられます。
一つの地面の上に大きな建物、例えばタワー型マンションを建てて高層構造にすると、経済的ですよね。狭い面積にたくさんの部屋と店舗や住居が収納できます。
しかし、この設計だと、地面、例えば災害などが起きると建物や店舗・住居などがいっぺんに災害を受けます。経済性を取ると、異常時の被害が拡大してしまうのです。
ですから、私はインフラ設計を行う時は、できるだけサービスごとに結合度を減らすようにしています。同じインフラサービス上に複数のお客様を収納しない。ロードバランサーを複数サービスで共有しない。ネットワークも分割する。なにしろ結合させないことを念頭に設計します。
人間、構築するときはインフラを過信しがちです。インフラサービスの売り文句は堅牢、耐障害性ですからうのみにしてしまうのです。そこに結合度の高い設計を施してしまうと、何か起こったときに取り返しがつかなくなるのです。
例えばタワー型マンションのうち、店舗と住宅を別の土地に分けようとしても、建ててからでは遅すぎるのです。更地の時にどれだけ「できるだけ結合しない」ことを想像できるかがポイントだと思います。
特に今回のような同時障害は、サポートチームの機能が麻痺します。障害の単位が小規模で独立していれば、サポートのリソースを振り向けることができます。しかし同時であるとたくさんのお客様に同時に反応しなければならず、結果として「何か問題が起こっているのにサポートとつながらない」という状態になってしまいます。
まとめ
インフラは設計時こそ大事、作ってからではできることが限られる。Azureですらこの原則を守れず、大規模障害を発生させてしまっています。インフラエンジニアの我々は、これを教訓とし例えばマルチクラウドを検討するなど、できるだけ結合させず同時障害を避けるような価値観を持つ必要があると思います。一つのサービスに依存するのは危険です。
ビジネスの安定はインフラサービスの局所化が肝、です。
