9月15日のAzure障害について

RCA(根本原因分析)などが出てるので記録的な感じで。

今回の障害は主にAzureが参照しているDNSでサービス低下が複数リージョンにて起こりました。(今PreviewのAzure DNSという名前のサービスとは別です)

概要については先に挙げた記事を読めばよいかと思います。ひらたくいうとネットワークデバイスのソフトウェアのバグでDNSクエリがスパイクして(Azure内外から)名前解決できない=つながらなくなっちゃったという感じです。以下は個人的な蛇足です。

原文(2016年9月19日0:00現在)

本当はパーマリンクがあればいいんですけど、現状ないので引用として載せておきます。基本的にAzure Status Historyに詳細が随時更新されていくようなスタンスのようです。

Network Infrastructure in Multiple Regions and Impacted Dependent Services

Services impacted: Azure SQL Database, SQL Data Warehouse (DW), HDInsight, App Service \ Web Apps, Service Bus, Redis Cache, Azure Backup, Visual Studio Team Services, Azure RemoteApp, Azure Media Services, Azure Search, Application Insights, IoT Hub, Azure Log Analytics, Azure Automation and Data Movement

Summary of impact: Starting at 11:18 UTC on 15th September 2016, customers may have experienced degraded service availability for multiple Azure services listed in “Impacted Services” above. The issue was triggered by a spike in network traffic that was not handled properly by the network management policy due to a network device bug. This resulted in incorrect identification of legitimate DNS requests as malformed, including requests from Azure services to resolve the DNS names of any internal endpoint or external endpoint to Azure from within Azure. The mitigation was to roll out a configuration change to override the incorrect device behavior. The mitigation was confirmed as effective by 13:00 UTC, all impacted Azure services that had a dependency on the recursive DNS recovered at this time, except Azure SQL Database and SQL Data Warehouse (DW) in Central US region, and HDInsight and Media Services in Central US that have a dependency on Azure SQL Database.
The subsequent impact on Azure SQL Database and DW services in Central US region were triggered due to receiving a large number of incoming requests simultaneously to re-establish connections after the recursive DNS issue had been mitigated. Most of Azure SQL Database services were able to handle large number of requests from our customers quickly enough to seamlessly process and Azure SQL Database customers would have seen recovery except Central US region. Unfortunately, Azure SQL Databases in Central US region were overwhelmed by requests that came in higher rate than expected and resulted in availability impact to Azure SQL Database service in Central US region. Azure SQL Database service team was engaged promptly and identified a higher rate of sending requests that prevented Azure SQL Database services from recovery. The team controlled the amount of requests to Azure SQL Database service to be able to handle seamlessly, confirmed all requests were processed normally by 17:15 UTC. Affected HDInsight and Media Services in Central US region were fully recovered shortly after.

Customer sla impact: Customers may have experienced degraded service availability for multiple Azure services listed in “Impacted Services” above when connecting to resources or services that have a dependency on the recursive DNS services. We estimated that the availability of Azure SQL Database and DW, and HDInsight and Media Services that are dependent on these was reduced by approximately 60% due to the impact of the recursive DNS issue. After the recursive DNS issue was mitigated, a subset of our customers using Azure SQL Database and DW resources in Central US region, services that have a dependency on Azure SQL Database and DW in Central US region may have continued experiencing the impact.

Workaround: No workaround was available during the initial impact period from 11:18 UTC to 13:00 UTC. For customers who were impacted by the subsequent outage on Azure SQL Database and DW in Central US region, if customers configured active geo-replication, the downtime would have been minimized by performing a failover to a geo-secondary which would be loss of less than 5 seconds of transactions. Please visit https://azure.microsoft.com/en-us/documentation/articles/sql-database-business-continuity/ for more information on these capabilities.

Affected sub regions: All Regions

Root cause: The root cause of the initial impact was a software bug in a class of network device used in multiple regions which incorrectly handled a spike in network traffic. This resulted in incorrect identification of legitimate DNS requests as malformed, including requests from Azure services to resolve the DNS names of any internal endpoint or external endpoint to Azure from within Azure.
The root cause of the subsequent Azure SQL Database issue in Central US region was triggered by a large amount of requests before Azure SQL Database service was fully recovered to process those requests, which resulted in availability impact to Azure SQL Database service in Central US region.
Azure SQL Database and DW and its customers make extensive use of DNS. This is because the connection path to Azure SQL Database and DW requires 2 DNS lookups. All Azure SQL database and DW connection requests are initially handled by an Azure hosted service called the control ring. This is the IP address referenced by the DNS record .database.windows.net. The control ring tracks which Azure hosted service currently hosts the database/datawarehouse requested, and returns the DNS name of that service to the client in the form …worker.database.windows.net. The client then performs a DNS lookup to connect to that location. For some customers (those connecting from outside Azure), the control plane proxies the entire connection, and thus performs the DNS lookup itself. Internal connections to databases and datawarehouses, for instance to perform service management operations and geo-replicate transactions, act as clients to other databases and datawarehouses and thus go through the same 2 lookups. We estimate that during the outage, DNS lookups failed at approximately 75% rate, for Azure SQL Database and DW this meant approximately 6% of connections succeeded on first try.

Next steps: 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, and in this case, it includes (but is not limited to):
1) Azure Network Infrastructure: The network device bug fix released in all regions once testing and validation are completed [Status – in progress]
2) Azure Network Infrastructure: Improve alerting to detect an inability of DNS services quicker to minimize the time to resolve [Status – in progress]
3) Azure Network Infrastructure: Set new configurations to bypass the network devise bug [Status – Completed]
4) Azure SQL Database/Data Warehouse: Reduce dependency on DNS by increasing TTL for most records maintained by Azure SQL Database and DW (Instance and server names change rarely, this occurs only on service management operations, therefore the low TTL is unnecessary) [Status – in progress]
5) Improve resiliency options for our customers to be able to minimize downtime. This includes Azure services that have a dependency on the DNS services used by Azure services [Status – in review]
In addition, we continue working on the following remediation actions that were identified during Azure SQL Database and DW incident on September 12th. We are committed to completing these items as soon as possible to help avoid any further interruption. We again apologize for any impact you may have experienced due to this issue.
1) Run multiple active/active control rings to avoid single point of failure in a region. [Status – in progress]
2) Document additional control ring IPs and later provide an easy to manage IP tagging mechanism in the future using Azure Network security groups. [Status – in progress]
3) Automate health detection of full control ring health and failover to standby. After item#1 this becomes move of traffic to the healthy rings. [Status – in progress]
4) Evaluate enhancements to Quality-of-Service traffic management scenarios [Status – in progress]

Provide feedback: Please help us improve the Azure customer communications experience by taking our survey:https://survey.microsoft.com/159741

意訳(という名の機械翻訳)

対象

複数リージョン及び影響を受ける従属サービス内でのネットワークインフラストラクチャ

影響を受けるサービス

Azure SQL Database, SQL Data Warehouse (DW), HDInsight, App Service \ Web Apps, Service Bus, Redis Cache, Azure Backup, Visual Studio Team Services, Azure RemoteApp, Azure Media Services, Azure Search, Application Insights, IoT Hub, Azure Log Analytics, Azure Automation and Data Movement

影響の概要

2016年9月15日11時18分(日本時間2016年9月15日20時18分)、上記の影響を受けるサービスにリストアップされている複数のAzureのサービスにて可用性の劣化を顧客が感じました。この問題はネットワークデバイスのバグによってネットワーク管理ポリシーによって適切に処理されなかったネットワークトラフィックがスパイクすることで引き起こされました。
これはAzure内からのAzureの任意の内部エントリポイントと外部エントリポイントのAzureサービスのDNS名の解決要求(リクエスト)が不正なリクエストとして識別された結果です。
被害抑止としては不正なデバイスの挙動を上書きするために構成の変更をロールアウトすることでした。被害抑止は(UTCで)13時に有効と確認され、再帰的なDNSへの依存関係を持っていた全ての影響を受けるAzureサービスのうち米国中央リージョンのSQL Database、SQL Data Warehaouseと中央アメリカリージョンのSQL Databaseへ依存していたHDInsight、Media Servicesを除いてこの時点で復旧しました。

2次的な影響として米国中央リージョンにおけるSQL DatabaseとSQL Data Warehouseは再帰的なDNSクエリの問題が復旧した際の大量の再接続要求を受けたことが原因で引き起こされました。
米国中央リージョンのを除いたAzure SQL Databaseサービスのほとんどは回復が見込まれ顧客からの大量の要求を十分に素早く処理できました。
残念ながら米国中央リージョンのSQL Databaseは中央アメリカリージョンのSQL Databaseサービスの可用性に影響を与える、想定をこえる高いレートで来た要求に圧倒されました。Azure SQL DatabaseサービスチームはSQL Databaseの復旧における大量の送信要求を予防するために速やかに対応しました。チームがSQL Databaseサービスへの要求量を制御することで17時15分(UTC)にはすべての要求が正常に処理されたことを確認しました。影響された米国中央リージョンのHDInsight、Media Servicesも直後に復旧しました。

顧客のSLAへの影響

お客様は再帰的なDNS問題に依存している、列挙されている複数の影響を受けたサービスへの可用性の低下を受けた可能性があります。Microsoftは再帰的なDNS問題の影響でAzure SQL DatabaseとData Warehouseおよびこれらに依存しているHDinsight、Media Servicesの可用性が60%減少したと推定しています。また再帰的なDNS問題が復旧した後の米国中央リージョンでのSQL DatabaseとData Warehouseに依存しているサービスのサブセットはさらに影響を受けている可能性があります。

回避方法/ワークアラウンド

11時18分(UTC)から13時(UTC)の間、初期の障害期間中に回避作はありませんでした。お客様へは米国中央リージョンにおけるSQL DatabaseとData Warehouseの2次障害についてはアクティブGeoレプリケーションを設定しフェイルオーバーを実施することでダウンタイムが5秒未満で影響を最小化することができたでしょう。これらの機能の詳細については  https://azure.microsoft.com/en-us/documentation/articles/sql-database-business-continuity/ を参照ください。

影響を受けたリージョン

全てのリージョン

根本的な原因

最初の障害の根本的な原因は、ネットワークトラフィックのスパイクを担当する複数のリージョンで使用されているネットワークデバイスのクラスのソフトウェアバグでした。この結果、Azure内からのAzureの任意の内部エントリポイントと外部エントリポイントのAzureサービスのDNS名の解決要求(リクエスト)が不正なリクエストとして識別されました。
2次的な影響の根本的な原因は米国中央リージョンにおけるSQL DatabaseとSQL Data Warehouseの再帰的なDNSクエリの問題が復旧した際の大量の再接続要求を受けたことによって引き起こされました。

Azure SQL DatabaseとSQL Data Warehouseとその顧客はDNSを広範囲に使用します。SQL DatabaseとData Warehouseは2回のDNSルックアップを接続するパスの中で行うからです。すべてのAzure SQL DatabaseとData Warehouseの接続要求は最初にAzure Hosted Serviceがコントロールリングと呼んでいる部分が処理します。それはDNSレコード ___.database.windows.net の正引きです。コントロールリングは要求されたDNS名のAzure Hosted Service上で現在ホストされているDatabase/DataWarehouseのDNS名( ____.worker.database.windows.net)をトラックし、クライアントへ返します。次にクライアントは返されたサーバーに接続するためにDNSルックアップを実行します。一部の顧客(Azure外から接続したもの)については制御プレーンは全体の接続をプロキシし、DNSルックアップそのものを実行します。SQL Database/Data Warehouseへの内部接続、例えばサービス管理操作やgeoレプリケーションのトランザクションを実行するインスタンスなどは、他のDatabaseやData Warehouseに対してクライアントと同じように振る舞い、同様に2回DNSルックアップを行います。Microsoft(私たち)は停電時、DNSルックアップは75%の確率で失敗すると推定しており、これはSQL Database/Data Warehouseへの接続の約6%が最初の試行で成功したことを意味します。

次のステップ (2016年9月19日1:00現在のステータス)

Microsoft(私たち)心から影響を受けたお客様へお詫び致します。我々は継続的にこのような障害が今後発生しないようにMicrosoft Azure Platformと業務プロセスを改善するための下記の措置を(これらに限定はされません)講じております。

  1. Azure ネットワークインフラストラクチャ:  テストと検証を完了し、全てのリージョンでネットワークデバイスのバグ修正をリリースする [ステータス: 進行中]
  2. Azure ネットワークインフラストラクチャ: DNSサービスに問題があった際により迅速に、解決にするために要する時間を最小限にするためにアラートを改善 [ステータス: 進行中]
  3. Azure ネットワークインフラストラクチャ: ネットワークデバイスのバグを回避するための新しい構成を設定する [ステータス: 完了]
  4. Azure SQL Database/Data Warehouse: ほとんどのDNSレコードのTTLを増やしてAzure SQL DatabaseとData WarehouseのDNSへの依存を減らす(インスタンスとサーバー名の変更はサービス管理操作で行われ、ほとんど変更されない為、短いTTLが不要のため) [ステータス: 進行中]
  5. ダウンタイムを最小限に抑えることができるように顧客向けの回復オプションを向上させる。これはAzureサービスが使用しているDNSサービスへ依存しているAzureサービスを含みます。 [ステータス: レビュー中]

加えて、我々(Microsoft)は9月12日(UTC)のSQL DatabaseとData Warehouseに起こったインシデントに対する改善アクションを続けます。我々は任意のさらなる中継を避けるために、できるだけ早く下記の項目を完了することにコミットしています。私たちはもう一度、皆さまがこの障害で得た可能性のある影響についてお詫び申し上げます。

  1. リージョン内の単一障害点(SPOF)を回避するために複数のアクティブ/アクティブ制御リングを実行します。 [ステータス: 進行中]
  2. 追加のコントロールリングのIPアドレスを文書化し、Azureネットワークセキュリティグループの機能で管理されたIPアドレスのタグとして簡単に管理できる機能を提供します。 [ステータス: 進行中]
  3. コントロールリングのスタンバイへフェールオーバーや状態監視を自動化します。 項目1の後、これは健全なリングへのトラフィック移動となります。 [ステータス: 進行中]
  4. トラフィック管理シナリオのサービス品質(QoS)の強化を評価します。 [ステータス: 進行中]

フィードバックの提供

今回の障害について、何かフィードバックしたいことがあればフィードバック用フォームからお願いします。 https://survey.microsoft.com/159741 (例えばRCAへのパーマリンクがほしいとか)

※原因から察するに、Azureが提供しているFQDNに依存しなかった部分は影響を受けなかったか限定的だったと思われます。例えばSQL Databaseを使用しないカスタムドメイン名を設定したWeb Appsとか。まぁネットワークインフラにまつわる部分なので(利用者側での)対策が難しいところではありますが、何かうまいこと考えたいですね。

広告

コメントを残す

以下に詳細を記入するか、アイコンをクリックしてログインしてください。

WordPress.com ロゴ

WordPress.com アカウントを使ってコメントしています。 ログアウト / 変更 )

Twitter 画像

Twitter アカウントを使ってコメントしています。 ログアウト / 変更 )

Facebook の写真

Facebook アカウントを使ってコメントしています。 ログアウト / 変更 )

Google+ フォト

Google+ アカウントを使ってコメントしています。 ログアウト / 変更 )

%s と連携中