技術ブログ

Akio Sasaki

Azure R&D at Microsoft, Azure Global

このシリーズではCOVID-19緊急事態の影響を受けたパブリッククラウドサービスのMicrosoft Azureの様々な課題緩和、解決に向けて運用の中で実施した事を数回にわたってついてご紹介します。合わせて過去約90日間でマイクロソフト社内のAzureチームで観測、対処を通して学んだ事を共有していきたいと思います。内容は弊社Azure CTOのMarkが blogにポストしたものをベースにAzureチーム内で業務をおこなっている私自身がこの数か月で得た経験も加味しています。

世界中の人々の生活様式がオンラインへと移行し、仕事、教育、そして日常活動がデジタル化していく中、パブリッククラウドサービスであるMicrosoft Azureを始めとするマイクロソフトクラウドサービスの需要が急減に増加していくことが観測されました。第2回では急変した状況に対して取らせて頂いた対応方針、そしてマイクロソフトインフラ（データをセンターやグローバルネットワーク）が受けた影響と技術的な対応についてご説明します。

急増する需要への対応方法

2020年2月から5月までの数か月間マイクロソフト公式ブログを通じてお伝えしている通り、マイクロソフトではCOVID-19状況下で急増した需要に合わせて供給優先順位を設定させて頂きました。COVID-19対応の最前線に立たれている医療機関、医療従事者の皆様、社会維持に不可欠な政府機関並び緊急事態対応をおこなっている組織を第1優先とさせて頂きました。同時平行して各データセンターに緊急ハードウェア増強を行いました。特に需要不足が顕著な地域には集中的に増強を行いました。

次に物理的なハードウェア増強と組み合わせて近い将来に必要されるだろう更なる追加需要までの予測作業を開始しました。世界中から収集されてきた情報を元に毎日多面的に分析をしながらサプライチェーンを動的に変化させ、一刻も早く先手に転じられるよう対応に当たりました。

Microsoft Azureとして運用されている資源、サービスはお客様に直接Azureサービスとしてご利用頂く以外にもマイクロソフトが提供しているM365、D365など様々クラウドサービスのインフラとしても稼働しています。これらのサービス運用を最適化する事でAzureとしてお客様へ提供できる容量を増加することにも成功しました。非優先的なサービスの余剰処理能力の解放から、比較的稼働率に余力のあるインフラサービスへ退避などあらゆる階層での調整をかけました。またユーザ様のサービス利用に直接関連のない運用維持に関連する演算処理も稼働率の低いデータセンターへ一時的に移動するなどの調整も行いました。結果、この文章を執筆している6月16日現在、需要の逼迫は全世界でほぼ解消されています。

オンライン生活へのシフトによるネットワーク負荷増大とAzure対応

さてここからリモートワーク、リモート教育、さらには生活のオンライン化がAzureネットワーク与えた影響とその対応についてより詳細に解説していこうと思います。

具体的な対応策についてご説明する前にまずAzureのグローバルネットワークについて簡単に触れたいと思います。Azureは全世界で現在61のリージョンを運用しています、Azureのリージョンとは特定地域で集合体として運用されるデータセンター群を指します。日本国内では関東地域に関西地域に2つリージョン(JAPAN EAST, JAPAN WEST)が運用中です。Azureのデータセンター間ネットワークはマイクロソフトが所有している光ファイバーとリース契約しているダークファイバーで構成された閉域網で運用されています。この物理接続は全世界で合計16万マイル以上の光ファイバーと海底ケーブルからなっています。グローバルネットワークには約170ヵ所のエッジサイトという接続ポイントがあり、ここを経由して様々なサービスプロバイダー様やユーザ様の専用線接続がAzureに対して行われています。余談ですが、各データセンター内で設置される光ファイバーは平均100万マイル以上です。

COVID-19の影響で在宅勤務が推奨され、更にその後、各政府がロックダウンを宣言することで推奨が必須へと変化する中、最初に顕著な影響が観測されたのはVPNです。VPNクライアントソフトウェアのダウンロード数が月の終盤から増加傾向になり、4月には平時と比較し700%増加、接続数も94％増加しました。VPNソフトウェアダウンロードの利用帯域はもちろん、VPN接続はインターネットサービスプロバイダーを経由してAzureに常時繋がりますのでAzureネットワーク負荷の定常的な増大となりました。

VPN接続も含むAzureのWAN接続（各エッジサイトでの稼働）の推移をより詳細にみてみましょう。AzureのWAN通信量のピークは従来の40倍まで到達しました。掲載しているグラフの通り、ロックダウンとVPN通信量の相関は明確でイタリアでは3月9日のロックダウンと同時に急激に通信量が増加しているのが確認して頂けると思います。ロックダウン初期からWeb会議、仮想デスクトップ、さらに様々な生活関連サービスへ広がり続け今後更なるネットワーク通信量の増大を予測した我々はネットワークの大幅増強をすることを決定しました。

またWAN通信量とともに大幅に増加したのがDDOS攻撃の件数でした。ネットワーク増強とともにセキュリティ制御処理に必要される容量も合わせて増強もする必要がありました。ネットワーク容量が十分でもセキュリティ検知の負荷によってパフォーマンス低下が発生する状況はなんとしても回避する必要がありました。

増強の対策として新たに12のエッジサイトを追加することでAzure外とのWAN接続回線を帯域面、冗長性、負荷分散面で増強、Azureデータセンター間のネットワーク容量を約25%増強しました。増強プロジェクト開始から2か月で110テラビットの回線増強が完了しました。増強は一度に大きく行わずに段階を追って行いました。Azureの運用思想としてどのような変更においてもサービス継続性への影響、リスクを最小限にするために、区画・地域別に実施し正常動作が確認されてから次の区画・地域へ段階的に実行することになっています（参考情報：Azure SAFE Deployment）。グラフで御覧頂けるように、段階的な増強でも常に需要の先をいけるように対象地域の選定を行っていきました。急速に増加する需要とシステムの保全性を両立するには緻密な計画が不可欠でした。

陸の上と異なり、海底ケーブルのネットワーク経路オプションはかなり限定されています。最も有名な大陸間海底ケーブルの一つであるMareaは米国と欧州のロックダウン後に急激な通信量増加を受けました。安定した通信を大陸間で維持するには別の海底ケーブルであるAECの増強が急務となりました。当時AECは稼働していませんでした。そこで急遽、別地域で導入準備中だったDWDM(高密度波長分割多重 / Dense Wavelength Division Multiplexing)機器を持ってきてAECの両終端に導入設置し稼働を開始しました。多くの人々の力のおかげで僅か6週間で稼働まで漕ぎつけることができました。（DWDMは単一の物理光ファイバー線に16波以上の波長の異なる光信号を多重で伝送し、複数回線を物理的に束ねたのと同様な通信量を実現する通信方式です。）

予測制御によるネットワーク稼働率の平準化

Azure内部ネットワークにはORCASという需要予測、実際に帯域量、無数にある利用可能な物理トポロジ（経路）、障害影響、通信の変動状況を計算して動的に通信経路の割り振りするツールがあります。ネットワーク経路は通常Shortest Path（最も早い＋ホップ数が少ない＋etc＝ネットワークの観点から低コスト）を選択するように自動ルーティングする設計になっています。しかしながら通信量が大幅増加、集中するとせっかくある他の経路が利用されないまま、限られた経路に集中してしまう傾向が出てきてしまう場合があります。またそのほかにも障害や他の要因で通信が滞ると真経路の再計算に時間を要してしまう事もあります。ORCASは予測のプロセスを入れる事でプロアクティブに最適な通信経路を制御することで各経路の平準化と安定的に通信環境の維持を可能にしてくれます。

Azureのサービスには外部からアクセスする際に最適化なAzureリージョンにリクエストを送信するサービスとしてAzure Traffic Managerがあります。Azure Traffic Managerはインターネット初期からあるDNS名前解決の技術を利用して広域での負荷分散、最適リクエスト先へ通信を送るためのサービスです。

COVID-19の影響がはじまって以来、Azure Traffic Managerへの負荷は１月から３月の期間毎月46%増加しました。このトラフィックの大きな割合はユーザ様が毎朝９時にTeamsにログインして各機能を利用するための名前解決リクエストでした。特に顕著なのはキャッシュが消えた月曜日の朝でした。Teamsのサービスは全てAzure上で運用されており、Teamsサーバへのリクエストを最寄りのデータセンターに送信するネットワーク制御にAzure Traffic Managerが利用されていました。当時高負荷状況に陥っていたデータセンターで運用されているTeamsサーバもまた高負荷環境下にいました。そこでTeams運用チームとAzureチームが共同で対応策の検討に入りました。通信速度の許容範囲で比較的稼働率が低いデータセンター内のTeamsサーバへAzure Traffic Managerで一時的に分散を行うことで合意しました。

時差により就業開始時間が異なるので、地域別にログインの集中する時間のみ影響のないリクエストを通常と事なるデータセンター上のTeamsサーバへと負荷分散し、ピーク解消後は通常のサーバへ戻します。この高負荷により影響を受けていたRound Trip Timeは改善され、timeoutなどによる再送コストを解消できるとわかったからです。しかしながらAzure Traffic Managerには時間別に設定変更をする機能が備わっていませんでした。

この問題を補うために合同検討チームはAzure Runbookを使用し、時間ベースでの設定変更を自動化することに成功しました。Azure内部の運用ではよくある事なのですが、単一サービスに新規機能を次々追加開発するのでなく既存Azureサービスを組み合わせて利用する事で機能不足を補います。この手法を使うことで開発期間を短縮、実績あるリリース済サービスを採用することで検証工程を抑制、サービス設計の複雑化を回避するなど多くのメリットがあります。現在は各タイムゾーンの就業開始が入れ替わるタイミングで負荷分散制御を変更しています。

今回ご紹介させて頂いたようにAzureでは無数にあるAzureへの入り口、そしてAzure内部両方の観点からネットワーク増強と最適化を行ってまいりました。

次回はレイヤを上げてTeamsやXBOXなどサービスで起きた需要変化と対応について解説します。