パンデミックがクラウドコンピューティングの災害復旧について教えてくれること

クラウド コンピューティングは、オンデマンドのインフラストラクチャと「無制限」の規模で予期しない状況に対応する機会を多くの企業に提供します。しかし、実際の災害状況では、「無限の規模」の物理的な実現可能性が現れ始めます。

[[331898]]

プラットフォーム アーキテクトは、2020 年 3 月に HDInsight クラスター (Microsoft が提供するマネージド Hadoop 製品) を私の運用環境にデプロイすることを承認したと述べました。彼は待望の Azure ベースのデータ プラットフォームの次のフェーズを開始している最中に、DevOps リーダーから電話を受けました。そのリーダーは、「新しい運用クラスターに構成エラーがあり、デプロイできません。クラスターをスケーリングできません。十分なノードを取得できません。クォータは十分ですが、クラスターをスケーリングするのに十分なノードがありません」と言いました。

結局、Microsoft Azure 北欧地域のデータセンターの容量がいっぱいになっている状況だったことが判明しました。 Microsoft は、他のすべてのクラウド プロバイダーと同様に、物理インフラストラクチャを過剰にプロビジョニングします。つまり、顧客が一度にすべての容量を消費して予期しない状況に陥ることはないとわかっているため、顧客に仮想マシンと CPU コアの割り当てを提供することができます。

欧州諸国は感染拡大が続いているため渡航禁止令を発令しており、企業は全従業員に在宅勤務を義務付けるなど迅速に対応する必要がある。渡航禁止令が発令されてからわずか数日後、IT 部門は VDI とコラボレーション ツールに対する前例のない需要の急増に対処する必要があり、クラウドに大きく依存するようになりました。結局のところ、それがクラウド コンピューティングの目的なのです。

クラウドベースの Windows 10 リモート ワーク ソリューションである Microsoft Windows Virtual Desktop は、IT 部門がリモート デスクトップ ソリューションの導入を熱望していることから、非常にタイムリーなタイミングで最近一般提供が開始されました。 Microsoft Teams は、スケーラブルでシームレスなコラボレーションおよびテレビ会議ソリューションを提供しますが、すべての会議が突然オンラインになり、どこかに物理的なインフラストラクチャを用意して対応する必要がありました。

その結果、Azure データセンターのコンピューティングに対する需要が急増し、すべての顧客のニーズに対応できなくなりました。新しいリソースを展開できないことに加えて、仮想マシンが夜間にシャットダウンされ、スケジュールどおりに起動されると、朝に再び起動できないなど、既存のリソースの起動に問題を抱えているお客様もいました。

アナリストは、この特定の顧客を担当する Microsoft アカウント チームと話をしたところ、同社の容量管理チームが状況を認識しており、医療および緊急サービスの顧客向けの容量を優先していると述べました。アナリストらがハードウェアの発注が増えているのに、サプライチェーンが納期に影響を及ぼしていることを知ったとき、状況は暗いように見えた。

幸いなことに、アカウント マネージャーは毎日の容量管理会議で顧客を代表し、必要な容量の根拠を説明することができました。 Microsoft はまた、20,000 個の vCPU の作業または内部ワークロードを Azure Nordic データセンターから移動するように指示され、1 週間後に HDInsight クラスターを正常に展開しました。

アナリストは現在、万が一地域的な停止が発生した場合に 1 つの Azure リージョン内でサービスをフェールオーバーすることをベースとした、別のクライアント向けの災害復旧 (DR) 戦略に取り組んでいます。これは、Microsoft 独自のアーキテクチャ推奨事項に基づいた標準パターンです。ただし、Azure リージョン全体がダウンした場合、残りの Azure リージョンのリソースに対する需要も急増することになります。災害復旧テストで達成できる復旧時間目標 (RTO) は、容量の制約により、実際のインシデントでは達成できない可能性があります。

Azure の災害復旧戦略を設計する場合、アナリストは次のことを推奨します。

• リソースの可用性を確保するためにクォータに依存することはできませんが、セカンダリ リージョンでクォータを増やす必要があります。
• フェイルオーバーが発生した場合に容量の問題について話し合うために、Microsoft 容量管理チームと話し合う準備をしてください。
• Microsoft のアカウント チームを活用することで、フェイルオーバーが発生した場合に容量を保護し、顧客への影響と企業としての Microsoft の評判への影響に基づいてケースを構築できます。
• クラウド プロバイダーへのフェイルオーバーが発生した場合、復旧時間目標 (RTO) は優れたレベルになることを理解してください。最終的にはインフラストラクチャを所有していないため、クラウド プロバイダーがニーズを満たせない可能性があります。
• 顧客が AWS、Google Cloud Platform、その他のクラウド環境、さらにはオンプレミスにフェイルオーバーできるようにするマルチクラウド アプローチを検討してください。