Web ロールと worker ロールを Service Fabric ステートレスサービスに変換する手順

[アーティクル]
06/01/2023

この記事では、Cloud Services の Web ロールと worker ロールを Service Fabric ステートレスサービスに移行する方法について説明します。アーキテクチャ全体をほぼ同じまま維持するアプリケーションの場合、これが Cloud Services から Service Fabric への最も単純な移行パスです。

Cloud Service プロジェクトから Service Fabric アプリケーションプロジェクトへ

Cloud Service プロジェクトと Service Fabric アプリケーションプロジェクトは構造が似ており、いずれもアプリケーションのデプロイ単位を表しています。つまり、それぞれがアプリケーションを実行するためにデプロイされるパッケージ一式を定義しています。 Cloud Service プロジェクトには、1 つ以上の Web ロールまたは worker ロールが含まれています。同様に、Service Fabric アプリケーションプロジェクトには、1 つ以上のサービスが含まれています。

違いは、Cloud Service プロジェクトはアプリケーションのデプロイと VM のデプロイを組み合わせているので、VM 構成が含まれており、Service Fabric アプリケーションプロジェクトは、Service Fabric クラスター内の既存の VM セットにデプロイするアプリケーションのみを定義している点です。 Service Fabric クラスター自体は、Resource Manager テンプレートまたは Azure Portal を介して 1 度だけデプロイされます。複数の Service Fabric アプリケーションをデプロイできます。

Service Fabric プロジェクトと Cloud Services プロジェクトの比較

worker ロールからステートレスサービスへ

概念上、worker ロールは、ステートレスワークロードを表しています。つまり、ワークロードのすべてのインスタンスは同じであり、要求はいつでも任意のインスタンスにルーティングできます。各インスタンスは、前の要求を記憶しません。ワークロードが処理する状態は、Azure Table Storage、Azure Cosmos DB などの外部の状態ストアによって管理されます。 Service Fabric の場合、この種類のワークロードはステートレスサービスで表されます。 worker ロールを Service Fabric に移行する最も簡単なアプローチは、worker ロールコードをステートレスサービスに変換する方法です。

worker ロールからステートレスサービスへ

Web ロールからステートレスサービスへ

worker ロールと同様に、Web ロールもステートレスワークロードを表すため、概念上、Service Fabric ステートレスサービスにマッピングできます。ただし、Web ロールとは異なり、Service Fabric は IIS をサポートしていません。 Web ロールの Web アプリケーションをステートレスサービスに移行するには、まず自己ホスト型で、IIS や System.Web に依存しない Web フレームワーク (ASP.NET Core 1 など) に移行する必要があります。

Application	サポートされています	移行パス
ASP.NET Web Forms	いいえ	ASP.NET Core 1 MVC への変換
ASP.NET MVC	移行あり	ASP.NET Core 1 MVC にアップグレードする
ASP.NET Web API	移行あり	自己ホスト型サーバーまたは ASP.NET Core 1 を使用する
ASP.NET Core 1	はい	該当なし

エントリポイントの API とライフサイクル

worker ロールと Service Fabric サービス API には、同様のエントリポイントが用意されています。

エントリポイント	worker ロール	Service Fabric サービス
処理中	`Run()`	`RunAsync()`
VM の開始	`OnStart()`	該当なし
VM の停止	`OnStop()`	該当なし
クライアント要求に対するリスナーを開く	該当なし	ステートレスの場合、次のようになります。`CreateServiceInstanceListener()` ステートフルの場合、次のようになります。`CreateServiceReplicaListener()`

worker ロール


using Microsoft.WindowsAzure.ServiceRuntime;

namespace WorkerRole1
{
    public class WorkerRole : RoleEntryPoint
    {
        public override void Run()
        {
        }

        public override bool OnStart()
        {
        }

        public override void OnStop()
        {
        }
    }
}

Service Fabric のステートレスサービス


using System.Collections.Generic;
using System.Threading;
using System.Threading.Tasks;
using Microsoft.ServiceFabric.Services.Communication.Runtime;
using Microsoft.ServiceFabric.Services.Runtime;

namespace Stateless1
{
    public class Stateless1 : StatelessService
    {
        protected override IEnumerable<ServiceInstanceListener> CreateServiceInstanceListeners()
        {
        }

        protected override Task RunAsync(CancellationToken cancelServiceInstance)
        {
        }
    }
}

いずれにも、処理を開始するプライマリ "Run" のオーバーライドがあります。 Service Fabric サービスは、Run、Start、Stop を 1 つのエントリポイント RunAsync に結合します。 RunAsync が開始されるとサービスが開始され、RunAsync メソッドの CancellationToken が発信されるとサービスは停止されます。

worker ロールと Service Fabric サービスのライフサイクルと有効期間には、主な違いがいくつかあります。

ライフサイクル: 最も大きな違いは、worker ロールが VM であるため、そのライフサイクルが VM に関連付けられている点です。そのため、VM の開始時と停止時のイベントが含まれます。 Service Fabric サービスには、VM のライフサイクルとは別のライフサイクルがあります。関連性がないため、そのため、ホスト VM またはコンピューターの開始時と停止時のイベントは含まれません。
有効期間: worker ロールインスタンスは、Run メソッドの終了時にリサイクルされます。一方、Service Fabric サービスの RunAsync メソッドは、完了まで実行を継続できるので、サービスインスタンスは有効なままになります。

Service Fabric には、クライアント要求をリッスンするサービス向けに、オプションの通信セットアップエントリポイントがあります。 RunAsync と通信エントリポイントは、いずれも Service Fabric サービスのオプションのオーバーライドです。クライアント要求のリッスンのみを行うか、処理ループのみを実行するか、またはその両方かをサービスで選択できます。クライアント要求のリッスンを継続できるので、サービスインスタンスを再開することなく RunAsync メソッドを終了できます。

アプリケーション API と環境

Cloud Services 環境 API は、現在の VM インスタンスに関する情報と機能だけでなく、他の VM ロールインスタンスに関する情報も提供します。 Service Fabric は、ランタイムに関連する情報や、サービスが現在実行されているノードに関する情報の一部を提供します。

環境タスク	Cloud Services	Service Fabric
構成設定と変更通知	`RoleEnvironment`	`CodePackageActivationContext`
ローカルストレージ	`RoleEnvironment`	`CodePackageActivationContext`
エンドポイント情報	`RoleInstance` 現在のインスタンスの場合、次のようになります。`RoleEnvironment.CurrentRoleInstance` その他のロールとインスタンスの場合、次のようになります。`RoleEnvironment.Roles`	現在のノードアドレスの場合、次のようになります。`NodeContext` サービスエンドポイントの検出の場合、次のようになります。`FabricClient` および `ServicePartitionResolver`
環境のエミュレーション	`RoleEnvironment.IsEmulated`	該当なし
同時変更イベント	`RoleEnvironment`	該当なし

構成設定

VM ロールの構成設定が Cloud Services に設定され、その VM ロールのすべてのインスタンスに適用されます。この構成設定は、ServiceConfiguration.*.cscfg ファイルに設定されたキーと値のペアです。RoleEnvironment を介して直接アクセスできます。 Service Fabric では、設定は VM ではなく、個別に各サービスと各アプリケーションに適用されます。これは、VM が複数のサービスとアプリケーションをホストできるためです。サービスは 3 つのパッケージから構成されます。

Code: サービスの実行可能ファイル、バイナリ、DLL など、サービスの実行に必要なファイルが含まれています。
Config: サービスのすべての構成ファイルと設定。
Data: サービスに関連する静的なデータファイル。

これらの各パッケージは、独立してバージョンを管理し、アップグレードすることができます。 Cloud Services と同様に、config パッケージには、プログラムで API を介してアクセスすることができます。また、イベントを使用して、サービスに config パッケージの変更を通知することができます。 Settings.xml ファイルは、App.config ファイルのアプリ設定セクションと同様に、キーと値の構成とプログラムによるアクセスに使用できます。ただし、Cloud Services とは異なり、Service Fabric の config パッケージには、XML、JSON、YAML、カスタムバイナリ形式など、任意の形式の任意の構成ファイルを含めることができます。

構成にアクセスする

Cloud Services

ServiceConfiguration.*.cscfg の構成設定には、 RoleEnvironmentを介してアクセスできます。この構成設定は、同じ Cloud Service デプロイ内のすべてのロールインスタンスでグローバルに使用できます。


string value = RoleEnvironment.GetConfigurationSettingValue("Key");

Service Fabric

各サービスには、個別の構成パッケージがあります。クラスター内のすべてのアプリケーションからアクセスできるグローバル構成設定に適した組み込みのメカニズムはありません。構成パッケージ内にある Service Fabric の特別な Settings.xml 構成ファイルを使用すると、Settings.xml の値はアプリケーションレベルで上書きできるので、アプリケーションレベルの構成設定が可能です。

構成設定には、サービスの CodePackageActivationContextを介して各サービスインスタンス内でアクセスします。


ConfigurationPackage configPackage = this.Context.CodePackageActivationContext.GetConfigurationPackageObject("Config");

// Access Settings.xml
KeyedCollection<string, ConfigurationProperty> parameters = configPackage.Settings.Sections["MyConfigSection"].Parameters;

string value = parameters["Key"]?.Value;

// Access custom configuration file:
using (StreamReader reader = new StreamReader(Path.Combine(configPackage.Path, "CustomConfig.json")))
{
    MySettings settings = JsonConvert.DeserializeObject<MySettings>(reader.ReadToEnd());
}

構成の更新イベント

Cloud Services

RoleEnvironment.Changed イベントは、環境内で変化 (構成の変更など) が発生したときに、すべてのロールインスタンスに通知するために使用されます。また、ロールインスタンスのリサイクルや worker プロセスの再起動を伴うことなく、構成の更新を利用するために使われます。


RoleEnvironment.Changed += RoleEnvironmentChanged;

private void RoleEnvironmentChanged(object sender, RoleEnvironmentChangedEventArgs e)
{
   // Get the list of configuration changes
   var settingChanges = e.Changes.OfType<RoleEnvironmentConfigurationSettingChange>();
foreach (var settingChange in settingChanges) 
   {
      Trace.WriteLine("Setting: " + settingChange.ConfigurationSettingName, "Information");
   }
}

Service Fabric

Code、Config、Data というサービス内の 3 つの各パッケージには、パッケージの更新時、追加時、または削除時にサービスインスタンスを通知するイベントがあります。 1 つのサービスには、各パッケージを複数含めることができます。たとえば、1 つのサービスに複数の config パッケージを含めて、個別にバージョンを管理し、アップグレードすることができます。

これらのイベントを使用すると、サービスインスタンスを再起動することなく、サービスパッケージの変更を利用することができます。


this.Context.CodePackageActivationContext.ConfigurationPackageModifiedEvent +=
                    this.CodePackageActivationContext_ConfigurationPackageModifiedEvent;

private void CodePackageActivationContext_ConfigurationPackageModifiedEvent(object sender, PackageModifiedEventArgs<ConfigurationPackage> e)
{
    this.UpdateCustomConfig(e.NewPackage.Path);
    this.UpdateSettings(e.NewPackage.Settings);
}

スタートアップタスク

スタートアップタスクは、アプリケーションの起動前に実行されるアクションです。通常、スタートアップタスクは、昇格された特権を使用してセットアップスクリプトを実行するために使用されます。 Cloud Services と Service Fabric のいずれもスタートアップタスクをサポートしています。主な違いは、Cloud Services の場合、ロールインスタンスの一部なので、スタートアップタスクは VM に関連付けられている点です。一方、Service Fabric では、スタートアップタスクはサービスに関連付けられており、特定の VM には関連付けられていません。

Service Fabric	Cloud Services
構成の場所	ServiceDefinition.csdef
特権	"制限付き" または "昇格された" 特権
シーケンス処理	"簡易"、"バックグラウンド"、"フォアグラウンド"

Cloud Services

Cloud Services のスタートアップエントリポイントは、ServiceDefinition.csdef でロールごとに構成されています。


<ServiceDefinition>
    <Startup>
        <Task commandLine="Startup.cmd" executionContext="limited" taskType="simple" >
            <Environment>
                <Variable name="MyVersionNumber" value="1.0.0.0" />
            </Environment>
        </Task>
    </Startup>
    ...
</ServiceDefinition>

Service Fabric

Service Fabric のスタートアップエントリポイントは、ServiceManifest.xml でサービスごとに構成されています。


<ServiceManifest>
  <CodePackage Name="Code" Version="1.0.0">
    <SetupEntryPoint>
      <ExeHost>
        <Program>Startup.bat</Program>
      </ExeHost>
    </SetupEntryPoint>
    ...
</ServiceManifest>

開発環境に関する注意事項

Cloud Services と Service Fabric は、いずれもプロジェクトテンプレートで Visual Studio と統合され、デバッグ、構成、ローカルと Azure 両方へのデプロイがサポートされています。また、Cloud Services と Service Fabric のいずれにも、ローカル開発ランタイム環境が用意されています。違いは、Cloud Services 開発ランタイムは、実行されている Azure 環境をエミュレートしますが、Service Fabric は、エミュレーターを使用しない点です。Service Fabric は、完全な Service Fabric ランタイムを使用します。ローカル開発コンピューターで実行している Service Fabric 環境は、運用時に実行する環境と同じです。

次のステップ

Service Fabric の全機能を活用できるように、Service Fabric の Reliable Services の詳細と、Cloud Services と Service Fabric アプリケーションアーキテクチャの違いについて説明します。

Web ロールと worker ロールを Service Fabric ステートレス サービスに変換する手順

Cloud Service プロジェクトから Service Fabric アプリケーション プロジェクトへ

worker ロールからステートレス サービスへ

Web ロールからステートレス サービスへ

エントリ ポイントの API とライフサイクル

worker ロール

Service Fabric のステートレス サービス

アプリケーション API と環境

構成設定

構成にアクセスする

Cloud Services

Service Fabric

構成の更新イベント

Cloud Services

Service Fabric

スタートアップ タスク

Cloud Services

Service Fabric

開発環境に関する注意事項

次のステップ

その他のリソース

Web ロールと worker ロールを Service Fabric ステートレスサービスに変換する手順

Cloud Service プロジェクトから Service Fabric アプリケーションプロジェクトへ

worker ロールからステートレスサービスへ

Web ロールからステートレスサービスへ

エントリポイントの API とライフサイクル

Service Fabric のステートレスサービス

スタートアップタスク