Azure Cloud Services (クラシック) の更新方法

  • [アーティクル]

重要

現在、Cloud Services (クラシック) は新しいお客様に対して非推奨となっており、2024 年 8 月 31 日に、すべてのお客様に対して廃止される予定です。 新しいデプロイでは、新しい Azure Resource Manager ベースのデプロイ モデル、 Azure Cloud Services (延長サポート) を使用してください。

クラウド上でロールとゲスト OS の両方を含むクラウド サービスを更新するには、次の 3 つの手順を実施します。 最初に、クラウド サービスまたは OS の新しいバージョン用のバイナリ ファイルと構成ファイルをアップロードする必要があります。 次に、Azure で、クラウド サービスの新しいバージョンの要件に基づいて、クラウド サービスのコンピューティング リソースとネットワーク リソースが予約されます。 最後に、Azure で、ローリング アップグレードが実行され、可用性を維持しながら、テナントが新しいバージョンまたは新しいゲスト OS に段階的に更新されます。 この記事では、この最後の手順であるローリング アップグレードの詳細について説明します。

Azure サービスを更新する

Azure では、ロール インスタンスが、アップグレード ドメイン (UD) と呼ばれる論理的なグループに編成されます。 アップグレード ドメイン (UD) は、1 つのグループとして更新されるロール インスタンスの論理セットです。 Azure ではクラウド サービスの更新を一度に 1 つの UD に対して行います。そのため、他の UD 内のインスタンスは引き続きトラフィックを処理できます。

アップグレード ドメインの既定の数は 5 です。 アップグレード ドメインの数を変更するには、サービスの定義ファイル (.csdef) に upgradeDomainCount 属性を追加します。 upgradeDomainCount 属性について詳しくは、「Azure Cloud Services 定義スキーマ (.csdef ファイル)」をご覧ください。

サービス内の 1 つ以上のロールをインプレースで更新すると、Azure では、そのロールが属するアップグレード ドメインに相当するロール インスタンスのセットが更新されます。 Azure は、1 つのアップグレード ドメイン内のすべてのインスタンスを更新してから (つまり、インスタンスを停止し、更新して、オンラインに復帰させてから)、次のドメインの処理に移ります。 現在のアップグレード ドメインで実行されているインスタンスのみを停止することで、更新が実行中のサービスに与える影響を最小限に抑えています。 詳細については、この記事で後ほど説明する「 アップグレードの処理のしくみ 」を参照してください。

注意

更新とアップグレードという用語は、Azure に関する文脈では若干異なる意味で使用されますが、このドキュメントで取り上げる機能のプロセスと説明においては同じ意味と考えて問題ありません。

ダウンタイムなしでロールをインプレース更新するには、サービスにそのロール インスタンスを少なくとも 2 つ定義する必要があります。 サービスが 1 つのロールの 1 つのインスタンスのみで構成されている場合、インプレース更新が完了するまでサービスを使用できません。

このトピックでは、Azure の更新に関する次の情報について説明します。

更新中に許可されるサービスの変更

次の表は、更新中に許可されるサービスの変更を示しています。

ホスティング、サービス、ロールに対して許可される変更 インプレース更新 ステージング (VIP スワップ) 削除と再デプロイ
オペレーティング システムのバージョン はい はい はい
.NET 信頼レベル はい はい Yes
仮想マシンのサイズ1 はい2 はい Yes
ローカル ストレージの設定 増加のみ2 Yes はい
サービス内のロールの追加または削除 はい はい はい
特定のロールのインスタンスの数 はい はい Yes
サービスのエンドポイントの数または種類 はい2 いいえ はい
構成設定の名前と値 はい はい はい
構成設定の値 (名前は不可) はい はい はい
新しい証明書の追加 はい はい はい
既存の証明書の変更 はい はい はい
新しいコードのデプロイ はい はい Yes

1 サイズ変更は、クラウド サービスで使用できるサイズのサブセットに制限されます。

2 Azure SDK 1.5 以降のバージョンが必要です。

警告

仮想マシンのサイズを変更すると、ローカル データが破棄されます。

更新中、次の操作はサポートされていません。

  • ロールの名前の変更。 そのロールを削除してから、新しい名前を持つロールを追加してください。
  • アップグレード ドメインの数の変更。
  • ローカル リソースのサイズの縮小。

ローカル リソースのサイズの縮小など、サービスの定義に他の更新を加える場合は、代わりに VIP スワップ更新を実行する必要があります。 詳細については、「 Swap Deployment」を参照してください。

アップグレードの処理のしくみ

サービス内のすべてのロールを更新するか、サービス内の単一のロールを更新するかを決めることができます。 どちらの場合も、アップグレード対象の最初のアップグレード ドメインに属する各ロールのインスタンスがすべて停止され、アップグレードされてから、オンラインに復帰します。 最初のアップグレード ドメインがオンラインに戻った後で、2 番目のアップグレード ドメイン内のインスタンスが、停止後にアップグレードされて、オンラインに復帰します。 クラウド サービスでは、一度に 1 つのアップグレードしかアクティブになりません。 アップグレードは常に、クラウド サービスの最新のバージョンに対して実行されます。

次の図は、サービス内のすべてのロールをアップグレードする場合のアップグレードの処理のしくみを示しています。

サービスのアップグレード

この次の図では、単一のロールのみをアップグレードする場合の更新の処理のしくみを示しています。

ロールのアップグレード

自動更新中、Azure ファブリック コントローラーがクラウド サービスの正常性を定期的に評価し、次の UD に進む安全なタイミングを判断します。 この正常性の評価はロールごとに実行され、最新バージョンのインスタンス (つまり、処理済みの UD のインスタンス) のみが対象になります。 この評価では、ロールごとに、最小限の数のロール インスタンスが良好な最終状態になったかどうかが検証されます。

ロール インスタンス開始のタイムアウト

ファブリック コントローラーは、各ロール インスタンスが開始状態に到達するまで 30 分間待機します。 このタイムアウト期間が経過すると、ファブリック コントローラーは次のロール インスタンスに進みます。

クラウド サービスのアップグレード中のドライブ データへの影響

単一のインスタンスから複数のインスタンスにサービスをアップグレードすると、Azure によるサービスのアップグレード方法の理由から、アップグレードの実行中はサービスが停止されます。 サービス レベル アグリーメントによるサービスの可用性保証は、複数のインスタンスでデプロイされたサービスのみに適用されます。 次の一覧は、各ドライブ上のデータが Azure サービスのアップグレード シナリオによってどのような影響を受けるかを示しています。

シナリオ C ドライブ D ドライブ E ドライブ
VM の再起動 保持される 保持される 保持される
ポータルの再起動 保持される 保持される Destroyed
ポータルの再イメージ化 保持される Destroyed Destroyed
インプレース アップグレード 保持される 保持される 破棄される
ノードの移行 破棄される Destroyed Destroyed

上の一覧中の E: ドライブはロールのルート ドライブを表しているため、ハードコーディングしないように注意してください。 代わりに、 %RoleRoot% 環境変数を使用してドライブを表してください。

単一のインスタンスのみで構成されるサービスをアップグレードする場合にダウンタイムを最小限に抑えるには、複数のインスタンスで構成される新しいサービスをステージング サーバーにデプロイし、VIP スワップを実行します。

更新のロールバック

Azure では、更新中のサービス管理の柔軟性を高めるために、最初の更新要求が Azure ファブリック コントローラーで受信された後もサービスに対する追加の操作を実行することができます。 ロールバックを実行できるのは、配置上で更新 (構成変更) またはアップグレードが進行中であるときのみです。 更新またはアップグレードが進行中であると見なされるのは、新しいバージョンに更新されていないサービスのインスタンスが少なくとも 1 つある場合です。 ロールバックが許可されるかどうかをテストするには、Get Deployment と Get Cloud Service Properties の操作で返される RollbackAllowed フラグの値が true に設定されているかどうかを確認します。

Note

ロールバックは、インプレースでの更新またはアップグレードに対してのみ呼び出します。VIP スワップ アップグレードでは実行中のサービス インスタンス全体が別のインスタンスに置き換わるため、ロールバックを行う妥当性がないためです。

進行中の更新をロールバックすると、デプロイに次の影響を与えます。

  • 新しいバージョンへの更新またはアップグレードが完了していないロール インスタンスは、更新またはアップグレードされません。これらのインスタンスでは、目的のバージョンのサービスが既に実行されているためです。
  • 新しいバージョンのサービス パッケージ (*.cspkg) ファイルやサービス構成 (*.cscfg) ファイルへの更新 (アップグレード) が完了したロール インスタンスは、アップグレードする前のバージョンのファイルに戻されます。

ロールバックは、次の機能によって実現されています。

  • Rollback Update Or Upgrade 操作。新しいバージョンへの更新が完了していないインスタンスがサービスに少なくとも 1 つある場合に、構成の更新 (Change Deployment Configuration 呼び出しによってトリガーされた操作) またはアップグレード (Upgrade Deployment の呼び出しによってトリガーされた操作) に対して呼び出すことができます。

  • Locked 要素と RollbackAllowed 要素。Get Deployment 操作と Get Cloud Service Properties 操作の応答本文の一部として返されます。

    1. Locked 要素を使用すると、特定のデプロイで変更操作を呼び出すことができるタイミングを検出できます。
    2. RollbackAllowed 要素を使用すると、特定のデプロイで Rollback Update Or Upgrade 操作を呼び出すことができるタイミングを検出できます。

    ロールバックを実行するために、Locked 要素と RollbackAllowed 要素の両方を確認する必要はありません。 RollbackAllowed が true に設定されていることを確認するだけで十分です。 "x-ms-version: 2011-10-01" またはそれ以降のバージョンに設定されている要求ヘッダーを使用してこれらのメソッドが呼び出された場合のみ、この 2 つの要素が返されます。 バージョン管理ヘッダーの詳細については、「 サービス管理のバージョン管理」を参照してください。

更新やアップグレードのロールバックがサポートされないのは、次のような場合です。

  • ローカル リソースの不足: 更新によってロールのローカル リソース使用量が増える場合、Azure のプラットフォームではロールバックが許可されません。
  • クォータの制限: 更新することでスケールダウンする場合、ロールバック操作を完了できるだけのコンピューティング クォータがなくなる可能性があります。 Azure の各サブスクリプションには、そのサブスクリプションに関連付けられているクォータがあります。このクォータは、そのサブスクリプションに属するすべてのホストされるサービスで使用できるコアの最大数を指定しています。 特定の更新のロールバックを実行することでサブスクリプションがクォータを越える場合、ロールバックは有効になりません。
  • 競合状態: 最初の更新が完了している場合、ロールバックできません。

更新のロールバックが役立つ例の 1 つが、 Upgrade Deployment 操作を手動モードで使用して、Azure のホストされるサービスに対する大規模なインプレース アップグレードがロール アウトされるペースを制御する場合です。

このようなアップグレードのロールアウトでは、Upgrade Deployment を手動モードで呼び出して、アップグレード ドメインの逐次処理を開始します。 アップグレードの監視中に、ある時点で、最初のアップグレード ドメインの一部のロール インスタンスが応答しなくなっていることに気付いた場合、そのデプロイに対して Rollback Update Or Upgrade 操作を呼び出すことができます。これによって、まだアップグレードされていないインスタンスはそのまま、アップグレード済みのインスタンスは以前のサービス パッケージと構成にロールバックできます。

進行中のデプロイに対する複数の変更操作の開始

進行中のデプロイに対して複数の変更操作を同時に開始することが必要になる場合があります。 たとえば、サービス更新を実行していて、その更新がサービス全体にロール アウトされている間に、更新のロールバック、別の更新の適用、場合によってはデプロイの削除など、なんらかの変更を加える必要が生じることがあります。 これが必要になる一例は、アップグレード後のロール インスタンスでクラッシュが繰り返し発生するようなバグがサービス アップグレードのコードに含まれている状況です。 この場合、アップグレード済みのドメイン内で正常な状態のインスタンスが少なくなるため、Azure ファブリック コントローラーでは、アップグレードの適用を進めることができなくなります。 この状態を "配置がスタックした (固まった)" などと表現します。 更新をロールバックするか、失敗したデプロイを上書きする形で新しい更新を適用することで、スタック デプロイを正常な状態に戻すことができます。

サービスを更新またはアップグレードする最初の要求が Azure ファブリック コントローラーで受信されると、後続の変更操作を開始できます。 つまり、別の変更操作を開始するために、最初の操作が完了するまで待つ必要はありません。

最初の更新の進行中に 2 つ目の更新操作を開始すると、ロールバック操作と似た方法で処理が実行されます。 2 番目の更新が自動モードである場合、最初のアップグレード ドメインが直ちにアップグレードされ、複数のアップグレード ドメインのインスタンスが同時にオフラインになる可能性があります。

変更操作には、Change Deployment Configuration、Upgrade Deployment、Update Deployment Status、Delete Deployment、および Rollback Update Or Upgrade があります。

Get Deployment と Get Cloud Service Properties の 2 つの操作は Locked フラグを返します。このフラグを調べることで、特定のデプロイに対して変更操作を呼び出すことができるかどうかを判断できます。

これらの操作のうち、Locked フラグを返すバージョンを呼び出すには、要求ヘッダーに "x-ms-version: 2011-10-01" 以降を設定する必要があります。 バージョン管理ヘッダーの詳細については、「 サービス管理のバージョン管理」を参照してください。

複数のアップグレード ドメインへのロールの分配

Azure では、設定された数のアップグレード ドメイン全体に対してロール インスタンスが均等に分配されます。この数は、サービス定義 (.csdef) ファイルの一部として構成することができます。 アップグレード ドメインの最大数は 20 で、既定値は 5 です。 サービス定義ファイルの変更方法の詳細については、「Azure Service Definition Schema (.csdef File) (Azure サービスの定義スキーマ (.csdef ファイル))」を参照してください。

たとえば、ロールに 10 個のインスタンスがある場合、既定では各アップグレード ドメインに 2 個のインスタンスが含まれます。 ロールに 14 個のインスタンスがある場合は、4 つのアップグレード ドメインにそれぞれ 3 個のインスタンスが含まれ、5 番目のアップグレード ドメインには 2 個が含まれます。

アップグレード ドメインは、0 から始まるインデックスで識別されます。最初のアップグレード ドメインの ID は 0、2 番目のアップグレード ドメインの ID は 1、と続きます。

次の図は、サービスに 2 つのアップグレード ドメインが定義されているときに、2 つのロールで構成されるサービスが分配されるしくみを示しています。 サービスは、Web ロールの 8 個のインスタンスと worker ロールの 9 個のインスタンスを実行しています。

アップグレード ドメインの分配

Note

複数のアップグレード ドメインにインスタンスを割り当てる方法は、Azure が制御します。 どのインスタンスをどのドメインに割り当てるかを指定することはできません。

次のステップ

Cloud Services の管理方法
クラウド サービスの監視方法
Cloud Services の構成方法