Service Fabric アプリケーションのライフサイクル

通常は、その他のプラットフォームと同様に、Azure Service Fabric のアプリケーションは、デザイン、開発、テスト、デプロイ、アップグレード、保守、削除のフェーズを通過します。 Service Fabric は、開発からデプロイ、日常的な管理、保守、最終的な使用停止に至るまで、クラウド アプリケーションの完全なアプリケーション ライフサイクルに対して高度なサポートを提供します。 そのサービス モデルにより、アプリケーションのライフサイクルで個別に関与するさまざまな役割が有効になります。 この記事では、API の概要と、Service Fabric アプリケーション ライフサイクルのフェーズでさまざまなロールがその API をどのように使用するかを示します。

アプリケーションのライフサイクルを管理する方法を説明したトレーニングビデオについては、こちらのページをご覧ください。

サービス モデルのロール

サービス モデルのロールは、次のとおりです。

• サービス開発者:同じ種類や別の種類の複数のアプリケーションで再利用、使用できるモジュールと汎用サービスを開発します。 たとえば、チケット発行のアプリケーション (ヘルプ デスク) または電子商取引アプリケーション (ショッピング カート) を作成するために Queue サービスを使用できます。
• アプリケーション開発者:特定の要件またはシナリオを満たすために、サービスのコレクションを統合してアプリケーションを作成します。 たとえば、電子商取引 Web サイトには、"JSON ステートレス フロントエンド サービス"、"オークション ステートフル サービス"、"ステートフル キュー サービス" を統合して、オークション ソリューションが構築されることがあります。
• アプリケーション管理者:アプリケーションの構成 (テンプレートの構成パラメーターを入力)、デプロイ (使用可能なリソースへのマッピング)、およびサービスの品質を決定します。 たとえば、アプリケーション管理者は、アプリケーションの言語ロケール (米国には英語、日本には日本語) を決定します。 別のデプロイされたアプリケーションには、さまざまな設定を含めることができます。
• オペレーター:アプリケーションの構成に基づくアプリケーションと、アプリケーション管理者が指定する要件をデプロイします。 たとえば、オペレーターはアプリケーションをプロビジョニングしてデプロイし、Azure で実行されていることを確認します。 オペレーターは、アプリケーションの正常性とパフォーマンスの情報を監視し、必要に応じて、物理インフラストラクチャを管理します。

開発

1. "サービス開発者" は、Reliable Actors または Reliable Services プログラミング モデルを使用してさまざまな種類のサービスを開発します。
2. サービス開発者 は、1 つ以上のコード、構成、データのパッケージで構成されるサービス マニフェスト ファイルで、開発したサービスの種類について宣言によって記述します。
3. アプリケーション開発者 は、異なる種類のサービスを使用するアプリケーションを構築します。
4. アプリケーション開発者 は、構成サービスのサービス マニフェストを参照し、異なる構成と構成サービスのデプロイ設定を適切にオーバーライドしてパラメーター化し、アプリケーション マニフェストでアプリケーションの種類を宣言によって記述します。

例については、「Reliable Actors の使用」と「Reliable Services の使用」を参照してください。

配置

1. アプリケーション管理者 は、アプリケーション マニフェストで ApplicationType 要素を指定して、Service Fabric クラスターにデプロイされるように、特定のアプリケーションに合わせてアプリケーションの種類を調整します。
2. "オペレーター" は、CopyApplicationPackage メソッドまたは Copy-ServiceFabricApplicationPackage コマンドレットを使用して、クラスター イメージ ストアにアプリケーション パッケージをアップロードします。 アプリケーション パッケージには、アプリケーション マニフェストとサービス パッケージのコレクションが含まれています。 Service Fabric は、Azure Blob ストアまたは Service Fabric のシステム サービスが対象となる、イメージ ストアに格納されているアプリケーション パッケージからアプリケーションをデプロイします。
3. "オペレーター" は、ProvisionApplicationAsync メソッド、Register-ServiceFabricApplicationType コマンドレット、Provision an Application REST 操作を使用して、アップロードされたアプリケーション パッケージから対象のクラスターでアプリケーションの種類をプロビジョニングします。
4. アプリケーションをプロビジョニングした後、"オペレーター" は CreateApplicationAsync メソッド、New-ServiceFabricApplication コマンドレット、Create Application REST 操作を使用して、"アプリケーション管理者" によって提供されるパラメーターでアプリケーションを起動します。
5. アプリケーションをデプロイした後、"オペレーター" は CreateServiceAsync メソッド、New-ServiceFabricService コマンドレット、Create Service REST 操作を使用して、使用可能なサービスの種類に基づいて、アプリケーションの新しいサービス インスタンスを作成します。
6. これで、Service Fabric のクラスターで、アプリケーションが実行されます。

例については、「 Deploy an application (アプリケーションをデプロイする) 」を参照してください。

テスト

1. ローカル開発クラスターまたはテスト クラスターにデプロイした後、"サービス開発者" は FailoverTestScenarioParameters、FailoverTestScenario クラス、Invoke-ServiceFabricFailoverTestScenario コマンドレットを使用して、組み込みのフェールオーバー テスト シナリオを実行します。 フェールオーバー テスト シナリオで、重要な切り替えとフェールオーバーを通して指定したサービスを実行して、引き続き利用可能で動作していることを確認します。
2. 次に、"サービス開発者" は、ChaosTestScenarioParameters と ChaosTestScenario クラスまたは Invoke-ServiceFabricChaosTestScenario コマンドレットを使用して、組み込みの chaos テスト シナリオを実行します。 chaos テスト シナリオは、複数のノード、コード パッケージ、レプリカのエラーをクラスターにランダムに誘導します。
3. サービス開発者は、クラスタでプライマリ レプリカを移動するテスト シナリオを作成して、サービス対サービスの通信をテストします。

詳細については、「 Introduction to the Fault Analysis Service (Fault Analysis サービスの概要) 」を参照してください。

アップグレード

1. サービス開発者 は、インスタンス化されたアプリケーションの構成サービスの更新、バグの修正を行い、サービス マニフェストの新しいバージョンを提供します。
2. アプリケーション開発者 は、一貫性のあるサービスの構成とデプロイメント設定をオーバーライドしてパラメーター化し、新しいバージョンのアプリケーション マニフェストを提供します。 アプリケーション開発者は、アプリケーションに新しいバージョンのサービス マニフェストを組み込み、更新されたアプリケーション パッケージで新しいバージョンのアプリケーションの種類を提供します。
3. アプリケーション管理者 は、適切なパラメーターを更新して、対象のアプリケーションに新しいバージョンのアプリケーションの種類を組み込みます。
4. "オペレーター" は、CopyApplicationPackage メソッドまたは Copy-ServiceFabricApplicationPackage コマンドレットを使用して、クラスター イメージ ストアに更新されたアプリケーション パッケージをアップロードします。 アプリケーション パッケージには、アプリケーション マニフェストとサービス パッケージのコレクションが含まれています。
5. "オペレーター" は、ProvisionApplicationAsync メソッド、Register-ServiceFabricApplicationType コマンドレット、Provision an Application REST 操作を使用して、対象のクラスターで新しいバージョンのアプリケーションをプロビジョニングします。
6. "オペレーター" は、UpgradeApplicationAsync メソッド、Start-ServiceFabricApplicationUpgrade コマンドレット、Upgrade an Application REST 操作を使用して、対象のアプリケーションを新しいバージョンにアップグレードします。
7. "オペレーター" は、GetApplicationUpgradeProgressAsync メソッド、Get-ServiceFabricApplicationUpgrade コマンドレット、Get Application Upgrade Progress REST 操作を使用して、アップグレードの進行状況を確認します。
8. 必要に応じて、"オペレーター" は、UpdateApplicationUpgradeAsync メソッド、Update-ServiceFabricApplicationUpgrade コマンドレット、Update Application Upgrade REST 操作を使用して、現在のアプリケーション アップグレードのパラメーターを変更して再適用します。
9. 必要に応じて、"オペレーター" は、RollbackApplicationUpgradeAsync メソッド、Start-ServiceFabricApplicationRollback コマンドレット、Rollback Application Upgrade REST 操作を使用して、現在のアプリケーション アップグレードをロールバックします。
10. Service Fabric はその構成サービスのいずれかの可用性を失うことなく、クラスター内で実行されている対象アプリケーションをアップグレードします。

例については、「 アプリケーション アップグレードのチュートリアル 」を参照してください。

管理

1. オペレーティング システムのアップグレードと修正プログラムに対しては、Service Fabric はクラスター内で実行しているすべてのアプリケーションの可用性を保証する Azure インフラストラクチャとつなぐインターフェイスです。
2. Service Fabric プラットフォームへのアップグレードと修正プログラムに対しては、クラスターで実行されているアプリケーションの可用性が失われることなく、Service Fabric 自体でアップグレードされます。
3. アプリケーション管理者 は、過去の容量使用率のデータと予測される将来の要求を分析した後、ノードの追加やクラスターからのノードの削除を承認します。
4. "オペレーター" は、"アプリケーション管理者" が指定したノードを追加、削除します。
5. 新しいノードをクラスターに追加する、または既存のノードをクラスターから削除するとき、Service Fabric は最適なパフォーマンスを実現するために、クラスター内のすべてのノード間でアプリケーションを実行している負荷を自動的に分散します。

[削除]

1. "オペレーター" は、DeleteServiceAsync メソッド、Remove-ServiceFabricService コマンドレット、Delete Service REST 操作を使用して、アプリケーション全体を削除することなく、クラスター内の実行中のサービスの特定のインスタンスを削除できます。
2. "オペレーター" は、DeleteApplicationAsync メソッド、Remove-ServiceFabricApplication コマンドレット、Delete Application REST 操作を使用して、アプリケーションのインスタンスとそのすべてのサービスも削除できます。
3. アプリケーションとサービスが停止されると、"オペレーター" は UnprovisionApplicationAsync メソッド、Unregister-ServiceFabricApplicationType コマンドレット、Unprovision an Application REST 操作を使用して、アプリケーションの種類のプロビジョニングを解除できます。 プロビジョニングを解除されたアプリケーションの種類の場合、ImageStore からアプリケーション パッケージが削除されません。
4. "オペレーター" は、RemoveApplicationPackage メソッドまたは Remove-ServiceFabricApplicationPackage コマンドレットを使用して、ImageStore からアプリケーション パッケージを削除します。

例については、「 Deploy an application (アプリケーションをデプロイする) 」を参照してください。

クラスター イメージ ストアのディスク領域を確保する

ImageStoreService にはコピーおよびプロビジョニングされたパッケージが保持され、ファイルが蓄積する可能性があります。 ファイルが蓄積すると、ImageStoreService (fabric:/System/ImageStoreService) でディスクがいっぱいになり、ImageStoreService レプリカのビルド時間が長くなる可能性があります。

ファイルが蓄積しないようにするには、次のプロビジョニング シーケンスを使います。

1. パッケージを ImageStore にコピーし、圧縮オプションを使います

2. パッケージをプロビジョニングします

3. イメージ ストアのパッケージを削除します

4. アプリケーションやクラスターをアップグレードします

5. 古いバージョンをプロビジョニング解除します

上の手順のステップ 3 と 5 により、イメージ ストアにファイルが蓄積しなくなります。

自動クリーンアップの構成

上のステップ 3 は、PowerShell または XML を使って自動化できます。 これにより、アプリケーションの種類の登録が正常に完了すると、アプリケーション パッケージが自動的に削除されます。

PowerShell:

Register-ServiceFabricApplicationTye -ApplicationPackageCleanupPolicy Automatic

XML:

<Section Name="Management">
  <Parameter Name="CleanupApplicationPackageOnProvisionSuccess" Value="True" />
</Section>

上のステップ 5 は、XML を使って自動化できます。 これにより、使われていないアプリケーションの種類が自動的に登録解除されます。

<Section Name="Management">
  <Parameter Name="CleanupUnusedApplicationTypes" Value="true" />
  <Parameter Name="PeriodicCleanupUnusedApplicationTypes" Value="true" />     
  <Parameter Name="TriggerAppTypeCleanupOnProvisionSuccess" Value="true" />
  <Parameter Name="MaxUnusedAppTypeVersionsToKeep" Value="3" />
</Section>

ノード上のファイルとデータのクリーンアップ

アプリケーション ファイルのレプリケーションでは、分散アクションに応じて、最終的にすべてのノードにファイルが配布されます。 これにより、アプリケーションの数とそのファイル サイズによってはディスクの負荷が生じることがあります。 ノードで実行中のアクティブなインスタンスがない場合であっても、前のインスタンスからのファイルが保持されます。 ステートフル サービスで使用される Reliable Collection のデータの場合も同様です。 これによって、高可用性の目的が果たされます。 同じノード上の新しいアプリケーション インスタンスの場合、ファイルをコピーする必要はありません。 Reliable Collection の場合、差分のみをレプリケートする必要があります。

アプリケーション バイナリを完全に削除するには、アプリケーションの種類の登録を解除する必要があります。

ディスクの負荷を下げるためのお勧めは次のとおりです。

1. Remove-ServiceFabricApplicationPackage は、一時的なアップロードの場所からパッケージを削除します。
2. Unregister-ServiceFabricApplicationType は、イメージ ストア サービスとすべてのノードからアプリケーションの種類ファイルを削除することで、記憶域スペースを解放します。 削除マネージャーは、既定で 1 時間ごとに実行されます。
3. CleanupUnusedApplicationTypes は、古い未使用のアプリケーション バージョンを自動的にクリーンアップします。

   {
     "name": "Management",
     "parameters": [
       {
         "name": "CleanupUnusedApplicationTypes",
         "value": true
       },
       {
         "name": "MaxUnusedAppTypeVersionsToKeep",
         "value": "3"
       }
     ]
   }
   

4. Remove-ServiceFabricClusterPackage は、古い未使用のランタイム インストール バイナリを削除します。

次のステップ

Service Fabric アプリケーションとサービスの開発、テスト、管理に関する詳細については、以下を参照してください。

• Reliable Actor
• Reliable Service
• アプリケーションをデプロイする
• アプリケーションのアップグレード
• Testability の概要