Service Fabric アプリケーションのアップグレード

Azure Service Fabric アプリケーションは、サービスのコレクションです。 アップグレード中、Service Fabric は新しい アプリケーション マニフェスト を以前のバージョンと比較し、更新が必要なアプリケーション内のサービスを決定します。 Service Fabric は、サービス マニフェストのバージョンと以前のバージョンを比較します。 サービスのバージョンが変更されていない場合、そのサービスはアップグレードされません。

$myApplication = Get-ServiceFabricApplication -ApplicationName fabric:/myApplication
$appParamCollection = $myApplication.ApplicationParameters

$applicationParameterMap = @{}
foreach ($pair in $appParamCollection)
{
    $applicationParameterMap.Add($pair.Name, $pair.Value);
}

Start-ServiceFabricApplicationUpgrade -ApplicationName fabric:/myApplication -ApplicationTypeVersion 2.0.0 -ApplicationParameter $applicationParameterMap -Monitored -FailureAction Rollback

ローリング アップグレードの概要

ローリング アプリケーションのアップグレードでは、アップグレードは段階的に実行されます。 アップグレードは、各段階で、更新ドメインと呼ばれるクラスター内のノードのサブセットに適用されます。 その結果、アプリケーションはアップグレード中も引き続き使用できます。 アップグレード中に、クラスターに古いバージョンと新しいバージョンが混在している場合があります。

そのため、2 つのバージョンは前方互換性と下位互換性がある必要があります。 互換性がない場合、アプリケーション管理者は、可用性を維持するために複数フェーズのアップグレードをステージングする必要があります。 複数フェーズのアップグレードでは、最初の手順は、以前のバージョンと互換性のあるアプリケーションの中間バージョンにアップグレードすることです。 2 番目の手順は、更新前のバージョンとの互換性を破るが、中間バージョンと互換性がある最終バージョンをアップグレードすることです。

更新ドメインは、クラスターを構成するときにクラスター マニフェストで指定されます。 更新ドメインは、特定の順序で更新プログラムを受信しません。 更新ドメインは、アプリケーションの展開の論理単位です。 更新ドメインを使用すると、アップグレード中もサービスの高可用性を維持できます。

アップグレードがクラスター内のすべてのノードに適用されている場合は、非ローリング アップグレードが可能です。これは、アプリケーションに更新ドメインが 1 つしかない場合です。 サービスが停止し、アップグレード時に使用できないため、この方法はお勧めしません。 さらに、クラスターが 1 つの更新ドメインのみで設定されている場合、Azure では保証されません。

アップグレードが完了すると、すべてのサービスとレプリカ (インスタンス) は同じバージョンに維持されます。つまり、アップグレードが成功した場合は、新しいバージョンに更新されます。アップグレードが失敗し、ロールバックされた場合は、古いバージョンにロールバックされます。

アップグレード中の健康状態のチェック

アップグレードの場合は、正常性ポリシーを設定する必要があります (または既定値を使用することもできます)。 アップグレードは、すべての更新ドメインが指定されたタイムアウト内でアップグレードされ、すべての更新ドメインが正常と見なされた場合に成功と呼びます。 正常な更新ドメインとは、更新ドメインが正常性ポリシーで指定されたすべての正常性チェックに合格したことを意味します。 たとえば、正常性ポリシーでは、Service Fabric によって正常性が定義されているため、アプリケーション インスタンス内のすべてのサービスが 正常である必要があることを義務付ける場合があります。

Service Fabric によるアップグレード中の正常性ポリシーとチェックは、サービスとアプリケーションに依存しません。 つまり、サービス固有のテストは実行されません。 たとえば、サービスにはスループット要件がありますが、Service Fabric にはスループットを確認するための情報がありません。 健康に関する記事を参照して、実行されるチェックを確認してください。 アップグレード中に発生するチェックには、アプリケーション パッケージが正しくコピーされたかどうか、インスタンスが開始されたかどうかなどのテストが含まれます。

アプリケーションの正常性は、アプリケーションの子エンティティの集計です。 つまり、Service Fabric は、アプリケーションで報告される正常性を通じてアプリケーションの正常性を評価します。 また、この方法でアプリケーションのすべてのサービスの正常性も評価されます。 Service Fabric は、サービスのレプリカなどの子の正常性を集約して、アプリケーション サービスの正常性をさらに評価します。 アプリケーションの正常性ポリシーが満たされたら、アップグレードを続行できます。 健康ポリシーに違反すると、アプリケーションのアップグレードは失敗します。

アップグレード モード

アプリケーションのアップグレードに推奨されるモードは、一般的に使用されるモードである監視モードです。 監視モードでは、1 つの更新ドメインでアップグレードが実行され、すべての正常性チェックが (指定されたポリシーに従って) 合格した場合、次の更新ドメインに自動的に移動します。 正常性チェックに失敗した場合やタイムアウトに達した場合、アップグレードは更新ドメインに対してロールバックされるか、モードが監視対象外の手動に変更されます。 アップグレードを構成して、失敗したアップグレードに対してこれら 2 つのモードのいずれかを選択できます。

監視対象外の手動モードでは、次の更新ドメインでアップグレードを開始するために、更新ドメインでのアップグレードのたびに手動介入が必要です。 Service Fabric の正常性チェックは実行されません。 管理者は、次の更新ドメインでアップグレードを開始する前に、正常性または状態チェックを実行します。

既定のサービスをアップグレードする

アプリケーション マニフェストで定義されている一部の既定のサービス パラメーターは、アプリケーションのアップグレードの一部としてアップグレードすることもできます。 アップグレードの一環として変更できるのは、 Update-ServiceFabricService による変更をサポートするサービス パラメーターのみです。 アプリケーションのアップグレード中に既定のサービスを変更する動作は次のとおりです。

1. クラスターにまだ存在しない新しいアプリケーション マニフェスト内の既定のサービスが作成されます。
2. 前のアプリケーション マニフェストと新しいアプリケーション マニフェストの両方に存在する既定のサービスが更新されます。 新しいアプリケーション マニフェストの既定のサービスのパラメーターによって、既存のサービスのパラメーターが上書きされます。 既定のサービスの更新が失敗した場合、アプリケーションのアップグレードは自動的にロールバックされます。
3. 新しいアプリケーション マニフェストに存在しない既定のサービスは、クラスター内に存在する場合は削除されます。 既定のサービスを削除すると、そのサービスのすべての状態が削除され、元に戻すことができないことに注意してください。

アプリケーションのアップグレードがロールバックされると、既定のサービス パラメーターはアップグレードが開始される前に古い値に戻されますが、削除されたサービスを古い状態で再作成することはできません。

HTTPS エンドポイントを使用した複数のアプリケーションのアップグレード

HTTPS を使用する場合は、同じアプリケーションの異なるインスタンスに同じポートを使用しないように注意する必要があります。 その理由は、Service Fabric ではアプリケーション インスタンスの 1 つの証明書をアップグレードできないためです。 たとえば、アプリケーション 1 またはアプリケーション 2 の両方が証明書 1 を証明書 2 にアップグレードする場合です。 アップグレードが行われると、他のアプリケーションでまだ使用されている場合でも、Service Fabric が証明書 1 の登録を http.sys でクリーンアップした可能性があります。 これを防ぐために、Service Fabric は、(http.sysが原因で) 証明書を使用してポートに登録されている別のアプリケーション インスタンスが既に存在することを検出し、操作に失敗します。

そのため、Service Fabric では、異なるアプリケーション インスタンスで 同じポートを 使用した 2 つの異なるサービスのアップグレードはサポートされていません。 つまり、同じポート上の異なるサービスで同じ証明書を使用することはできません。 同じポートに共有証明書が必要な場合は、配置の制約がある異なるマシンにサービスが配置されていることを確認する必要があります。 または、可能であれば、各アプリケーション インスタンスの各サービスに対して Service Fabric 動的ポートを使用することを検討してください。

https でアップグレードが失敗する場合は、"Windows HTTP Server API はポートを共有するアプリケーションに対して複数の証明書をサポートしていません" というエラー警告が表示されます。

アプリケーションアップグレードフローチャート

この段落に続くフローチャートは、Service Fabric アプリケーションのアップグレード プロセスを理解するのに役立ちます。 特に、このフローでは、 HealthCheckStableDuration、 HealthCheckRetryTimeout、 UpgradeHealthCheckInterval などのタイムアウトが、1 つの更新ドメインでのアップグレードが成功または失敗と見なされるタイミングを制御する方法を説明します。

次のステップ

Visual Studio を使用したアプリケーションのアップグレードに関する記事では、Visual Studio を使用してアプリケーションをアップグレードする方法について説明します。

PowerShell を使用したアプリケーションのアップグレードに関する記事では、PowerShell を使用したアプリケーションのアップグレードについて説明します。

アップグレード パラメーターを使用して、アプリケーションのアップグレード方法を制御します。

データのシリアル化の方法を学ぶことで、アプリケーションのアップグレードに互換性を持たせます。

高度なトピックを参照して、アプリケーションをアップグレードするときに高度な機能を使用する方法について説明 します。

「アプリケーションのアップグレードのトラブルシューティング」の手順を参照して、アプリケーションのアップグレードでの一般的な問題を修正します。