次の方法で共有

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

  • [アーティクル]

重要

2024 年 9 月 1 日に、すべてのお客様に対して Cloud Services (クラシック) は非推奨になりました。 既存の実行中のデプロイはすべて Microsoft によって停止およびシャットダウンされ、2024 年 10 月以降、データは永久的に失われます。 新しいデプロイでは、新しい Azure Resource Manager ベースのデプロイ モデル、 Azure Cloud Services (延長サポート) を使用してください。

ロールとゲスト オペレーティング システムの両方を含むクラウド サービスを更新するプロセスには、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 分間待機します。 このタイムアウト期間が経過すると、ファブリック コントローラーは次のロール インスタンスに進みます。

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

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

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

上の一覧では、E: ドライブはロールのルート ドライブを表しており、ハードコーディングする必要はありません。 代わりに、 %RoleRoot% 環境変数を使用してドライブを表してください。

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

更新のロールバック

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

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 フラグを調べて、特定のデプロイで変更操作を呼び出すことができるかどうかを判断できます。

これらの操作のうち、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 の構成方法