"小規模で一般的なハードウェア障害のほかに、Azure で見られるサービスの信頼性に関する問題を引き起こしている主な原因は何でしょうか? 変更です。クラウドの価値提案の 1 つは、継続的な改善です。つまり、新しい機能を提供するとともに、セキュリティと信頼性を強化します。しかし、プラットフォームは継続的に進化しているため、変更は避けられません。このことは、長い時間をかけてテストを行い、何かをデプロイしたら変更しないようにするといった既製品や従来の IT アプローチにはない、品質と安定性を確保するためのまったく異なるアプローチが必要であることを意味します。この投稿は、Azure の信頼性がお客様のミッション クリティカルなワークロードを確実にサポートできるように Microsoft が行っている取り組みについての分析情報をお伝えするために私が開始した、7 月のブログ投稿の 5 番目の記事です。本日は、Microsoft の安全なデプロイ プラクティスについて説明します。これは、すべてのコードと構成の更新が明確に定義された段階を経て行われることで、お客様に届く前に不具合やバグを検出し、それが初期段階を過ぎている場合はできるだけ影響が少なくなるようにする、変更の自動化を管理するための方法です。 Microsoft のコンピューティング エンジニアリング チームの Cristina del Amo Casado がこの投稿を執筆しました。彼女が Microsoft の安全なデプロイ イニシアティブを促進してきたことがその理由です。" - Mark Russinovich (CTO、Azure)

---

 

IT システムをオンプレミスで実行している場合、最高の機能のハードウェアを用意し、サーバールームをロックアップして鍵を捨て去ることで、完璧な可用性を確保しようとするかもしれません。ソフトウェアの面では、IT 部門は従来、変更は可能な限り避けようとしてきました。つまり、OS やアプリケーション、またはその両方について、その重要度が高すぎるために更新プログラムの適用を回避し、そしてユーザーからの変更要求を退けてきました。すべての人がシステムの周囲で足踏みをしている状態の、この "誰にとっても好ましくない" アプローチにより、システムの継続的な改善は妨げられ、また時として、システムが重大すぎてパッチを定期的に適用することができないと判断されることもあり、それがセキュリティ侵害につながります。Mark が上記で述べたように、このアプローチは、Azure などのハイパースケール パブリック クラウドでの変更およびリリース管理には適していません。変更は避けられないものですが、同時に利点をもたらします。たとえば、サービスの更新プログラムや改善をデプロイする必要がある場合、またセキュリティ上の脆弱性が発生した場合に迅速に行動するというコミットメントがある場合などです。変更を単に回避することはできないため、Microsoft、Microsoft のお客様、Microsoft のパートナーの皆様は、変更が予想されていることを理解する必要があります。そして、それに備えて計画を立てます。Microsoft は引き続き、更新が可能な限り透過的に実行されるように取り組んでおり、以下に示すように、変更を安全にデプロイします。そのような前提があるとしても、Microsoft のお客様とパートナーの皆様は、高可用性を実現できるように設計し、プラットフォームによって送信されたメンテナンス イベントを利用して、必要に応じて調整する必要があります。最後に、お客様は場合によっては、組織に都合のよい時間にプラットフォームの更新を開始することもできます。

安全に変更する

Azure データセンター全体でリリースをデプロイする方法を検討するときに、プロセスを策定する際の重要な前提の 1 つに、その変更がデプロイされることによって生じる未知の問題が発生する可能性を仮定することがあります。それに沿って計画を立てることで、そのような問題を最小限の影響で検出することができ、問題が表面化したときに備えて軽減措置を自動化することができます。開発者が、まったく悪影響を与えないと判断し、サービスに影響しないことを保証する場合もありますが、システムに対する変更が最小限であったとしても、システムの安定性はリスクにさらされます。そのため、ここでの "変更" とは、すべての新しいリリースのことを意味し、またコードの変更と構成の変更の両方を含んでいます。ほとんどの場合、構成の変更によってシステムの動作に劇的に大きい影響がおよぶことはあまりありませんが、コードを変更する場合と同様に、潜在的なコードの欠陥や新しいコード パスをアクティブ化する際の構成の変更についてリスクは付き物です。

Azure を利用しているチームは、類似のプロセスに従うことで、変更に関連する影響を防止したり、最小限に抑えたりすることができます。まず、テストと統合の検証を通じて、デプロイが開始される前に変更が品質基準を満たしていることを確認します。次に、サインオフ後に変更を段階的にロールアウトし、正常性シグナルを継続的に測定します。これにより、テスト中には表面化しなかった、変更に関連する予期しない影響がある場合に、比較的孤立した状態で検出できるようになります。このような変更によって、問題が広範囲の運用環境で起こってほしくはありません。そのため、それを可能な限り回避できるようにするための手順を行います。段階的デプロイを使用すると、広い範囲に影響が広まる前に、より小さな規模 (より小さい "爆発半径") で問題を検出することができます。

Azure では、上記のような上流レベルのプロセスに合わせて変更を自動化できるよう取り組んでおり、これは安全なデプロイ プラクティス (SDP) フレームワークを通じて行われます。これは、すべてのコードと構成の変更が特定のライフサイクル ステージを確実に通過するようにすることを目的としており、その途中では正常性メトリックが監視され、品質の低下が検出された場合には自動アクションとアラートがトリガーされます。これらのステージ (次の図を参照) を経ることによって、ソフトウェアの変更がお客様の既存の Azure ワークロードに悪影響を与えるリスクが軽減されます。

ここでは、デプロイ パイプラインの概略図を示しています。左から、開発者がコードを変更し、その独自のシステムでテストし、ステージング環境にプッシュしています。一般に、この統合環境は、特定のコンポーネントの相互影響をテストする必要がある、Azure サービス サブセットを利用するチーム専用です。たとえば、コンピューティング、ネットワーク、ストレージなどのコア インフラストラクチャのチームが統合環境を共有します。各チームは、その環境内のソフトウェアに対して合成テストとストレス テストを実行し、安定するまで反復します。その後、品質結果で特定のリリース、機能、変更が運用環境向けに準備が整っていることが示されたら、それをカナリア リージョンにデプロイします。

カナリア リージョン

一般に、Microsoft はカナリア リージョンを "早期更新プログラム アクセス プログラム" リージョンと呼んでいます。これらは、圧倒的多数の Azure サービスを備え、完全に成熟した Azure リージョンです。カナリア リージョンの 1 つは可用性ゾーンを使用して構築されており、もう一つは使用されていません。そして、それら両方のリージョンがリージョンのペアを形成しているので、データの geo レプリケーション機能を検証できます。これらのカナリア リージョンは、完全な運用環境レベル、エンドツーエンドの検証、シナリオの対象範囲を大規模に確認するのに使用されます。一部のファースト パーティ サービス (内部の顧客向け)、いくつかのサードパーティ サービス、プログラムに招待された少数の外部顧客がホストされており、さらに複雑で豊富なシナリオをカバーすることができます。つまり、カナリア リージョンでは、パブリック Azure リージョンを代表する使用パターンが確実に網羅されていることになります。また、Azure のチームがこれらの環境でストレスおよび合成テストを実行します。また、リージョンまたは可用性ゾーン レベルでフォールト挿入やディザスター リカバリー訓練を定期的に実行して、実際に起こったときに実行するであろう検出と復旧のワークフローを訓練します。これらの演習を別々に行ったり一緒に行ったりすることで、変更内容が Azure をご利用のお客様のワークロードに広く行き渡る前に、ソフトウェアが最高品質であることを確認できます。

パイロット フェーズ

カナリアからの結果から既知の問題が検出されなかったことが判明したら、運用環境へのプログレッシブ デプロイを開始できます。その始まりをパイロット フェーズと呼びます。このフェーズでは、比較的小規模ではありますが、さまざまなハードウェアと構成で変更を試すことができます。このフェーズは特に、ハードウェアの依存関係があるコア ストレージ サービスやコア コンピューティング インフラストラクチャ サービスなどのソフトウェアにとって重要です。たとえば、Azure では、GPU を搭載したサーバー、大容量メモリを搭載したサーバー、汎用サーバー、複数の世代と種類のプロセッサ、Infiniband などを提供しています。これにより、変更のフライトが実現し、また小規模のテスト中には表面化しなかった問題を検出することもできます。途中の各手順では、徹底的な正常性の監視と拡張された "焼成時間" により、潜在的な障害パターンを表面化させることができ、変更の信頼度を高めながら、顧客に対する全体的なリスクを大幅に軽減することができます。

パイロット フェーズからの結果が良好であると判断したら、変更をさらに多くのリージョンで段階的に進めることにより、デプロイ システムを前に進めます。広範な Azure リージョンへのデプロイ全体を通じて、デプロイ システムは可用性ゾーン (変更はリージョン内の可用性ゾーンにのみ適用される) とリージョン ペアリング (すべてのリージョンは geo 冗長ストレージ用のセカンダリ リージョンと "ペア"になる) の遵守を試みます。つまり、変更は最初に 1 つのリージョンにデプロイされ、次にそのペアにデプロイされます。一般に、負のシグナルが現れない限り、変更はデプロイされます。

安全なデプロイ プラクティスを実行に移す

Azure の規模がグローバルになると、ロールアウト プロセス全体が完全に自動化され、ポリシーによって駆動します。これらの宣言型ポリシーとプロセス (開発者ではありません) により、ソフトウェアをどの程度迅速に展開できるかが決まります。ポリシーは一元的に定義され、ソフトウェアの品質を監視するための必須の正常性シグナルと、上記で説明したさまざまなステージ間の必須の "焼成時間" が含まれます。各フェーズでさまざまな期間にわたってソフトウェアの準備と焼成を行う理由は、そのサービスのあらゆる領域の負荷に変更の作用を受けさせるようにするためです。たとえば、組織のさまざまなユーザーは朝にオンラインになり、ゲームを利用するユーザーは夜間にオンラインになり、顧客による新しい仮想マシン (VM) やリソースの作成は長期間にわたって行われる可能性があります。

グローバル サービスは、さまざまなクラスター、リージョン、サービス リングに段階的にデプロイする方法を採ることはできません。また、SDP との連携によって段階的なロールアウトのうちの 1 つのバージョンを訓練することもできません。これらのサービスは、サービス インスタンスを複数のフェーズで更新するモデルに従っており、Azure Traffic Manager を通じて、更新されたインスタンスにトラフィックを段階的に移します。シグナルが正の場合は、時間の経過とともに更新されたインスタンスに対してより多くのトラフィックが向かうようになり、信頼度が高まり、時間が経過するにしたがって、デプロイがより多くのサービス インスタンスに適用されるようになります。

もちろん、Azure プラットフォームにも変更をすべての Azure に同時にデプロイする機能があります。この機能は、非常に重大な脆弱性を軽減する必要性がある場合に備えたものです。安全なデプロイ ポリシーは必須ですが、特定の緊急条件が満たされた場合には、このポリシーを加速させることもできます。たとえば、通常よりも短時間で移行する必要があるセキュリティ更新プログラムや、顧客に既に多大な影響を与えている問題を軽減するための修正を適用することによって不具合のリスクを克服するための修正プログラムをリリースする場合などです。このような例外は非常にまれです。一般的に、デプロイ ツールやプロセスは速度を意図的に犠牲にして、構築のためのシグナルや大規模に実行するシナリオやワークフローを実現する機会を最大化します。これにより、最小規模の影響範囲で問題を発見することができます。

継続的な改善

Microsoft の安全なデプロイ プラクティスとデプロイ ツールは、以前のサービス停止やメンテナンス イベントからの学びを反映させながら、これからも進化を続けます。またこれは、非常に小さい程度の時点で問題を発見するという目標とも一致しています。たとえば、正常性シグナルを継続的に強化することの重要性や、機械学習を使用して障害を適切に関連付け、異常を検出することについて学んできました。今後も、パイロット版やフライト版での改善を続け、さらに多くのさまざまなハードウェアをより少ないリスクでカバーできるようにしていきます。問題の兆候が現れたときに変更を自動的にロールバックできる機能を強化していきます。そして、変更の影響を広く軽減または排除できるようにプラットフォーム機能への投資を行っていきます。

昨年は 1,000 以上の新機能がリリースされ、Azure での変更が驚くべきペースで進んでいることが分かります。Mark が述べたように、クラウド サービスの迅速で継続的な改善は、クラウドの重要な価値提案の 1 つです。変更は機能であり、バグではありません。最新リリースの詳細情報について、お客様やパートナーの皆様には Azure.com/Updates をご確認いただくようにお勧めしています。Microsoft はここを、開発中のイノベーションのロードマップなど、最新および予定されている Azure 製品の更新情報を確認することができる 1 つの場所にするべく取り組んでいます。これらのさまざまなサービスを利用できるリージョンについて、またそれらの提供時期については、Azure.com/ProductsbyRegion のツールを使用してご確認いただくこともできます。