Azure Service Fabric でのマイクロサービスアーキテクチャ

Azure API Management

Azure Key Vault

Azure Monitor

Azure Pipelines

Azure Service Fabric

この参照アーキテクチャでは、Azure Service Fabric にデプロイされるマイクロサービスアーキテクチャを示します。それには、ほとんどのデプロイの出発点にすることができる基本的なクラスター構成が示されています。

GitHub logo このアーキテクチャのリファレンス実装は、GitHub で入手できます。

アーキテクチャ

Diagram that shows the Service Fabric reference architecture.

このアーキテクチャの Visio ファイルをダウンロードします。

注意

この記事では、Service Fabric の Reliable Services プログラミングモデルに注目します。 Service Fabric を使用したコンテナーのデプロイと管理については、この記事では説明されていません。

ワークフロー

アーキテクチャは、次のコンポーネントで構成されます。他の用語については、「Service Fabric の用語の概要」をご覧ください。

Service Fabric クラスター。クラスターとは、マイクロサービスをデプロイして管理する、ネットワークに接続された一連の仮想マシン (VM) です。
仮想マシンスケールセット。仮想マシンスケールセットを使用すると、負荷分散と自動スケーリングが行われる同一の VM のグループを作成して管理できます。これらのコンピューティングリソースでは、障害ドメインとアップグレードドメインも提供されます。
ノード。ノードは、Service Fabric クラスターに属する VM です。
ノードタイプ。ノードタイプは、ノードのコレクションをデプロイする仮想マシンスケールセットを表します。 Service Fabric クラスターには、少なくとも 1 つのノードタイプがあります。

クラスターに複数のノードタイプがある場合は、その 1 つをプライマリノードタイプとして宣言する必要があります。クラスターのプライマリノードタイプでは、Service Fabric システムサービスが実行されます。これらのサービスでは、Service Fabric のプラットフォーム機能が提供されます。プライマリノードタイプは、シードノードとしても機能します。シードノードは、基になるクラスターの可用性を維持するノードです。

独自のサービスを実行するには、追加のノードタイプを構成します。
サービス。サービスでは、他のサービスから独立して開始および実行できる、スタンドアロンの機能が実行されます。サービスのインスタンスは、クラスター内のノードにデプロイされます。 Service Fabric のサービスには、2 つの種類があります。
- ステートレスサービス。ステートレスサービスでは、サービス内の状態は保持されません。状態の永続性が必要な場合は、Azure Cosmos DB などの外部ストアに状態を書き込み、取得します。
- ステートフルサービス。サービスの状態は、サービス自体の内部に保持されます。ほとんどのステートフルサービスでは、Service Fabric のリライアブルコレクションによってこれが実装されます。
Service Fabric Explorer。 Service Fabric Explorer は、Service Fabric クラスターを検査および管理するためのオープンソースツールです。
Azure Pipelines。 Azure Pipelines は Azure DevOps Services の一部であり、自動化されたビルド、テスト、およびデプロイを実行します。 Jenkins などのサードパーティの継続的インテグレーションと継続的デリバリー (CI/CD) ソリューションを使用することもできます。
Azure Monitor。 Azure Monitor では、ソリューション内の Azure サービスのプラットフォームメトリックやアプリケーションテレメトリなど、メトリックとログが収集されて格納されます。このデータは、アプリケーションを監視したり、アラートやダッシュボードを設定したり、障害の根本原因分析を実行したりするために使用します。 Azure Monitor は、Service Fabric と連携して、コンテナーやノードのログとともに、コントローラー、ノード、コンテナーからのメトリックを収集します。
Azure Key Vault。接続文字列など、マイクロサービスで使用されるすべてのアプリケーションシークレットを格納するには、Key Vault を使用します。
Azure API Management。このアーキテクチャの API Management は、クライアントから要求を受け取って独自のサービスにルーティングする API ゲートウェイとして機能します。

考慮事項

これらの考慮事項には、ワークロードの品質を向上させる一連の基本原則である Azure Well-Architected Framework の要素が組み込まれています。

設計上の考慮事項

この参照アーキテクチャでは、マイクロサービスアーキテクチャに重点が置かれています。マイクロサービスは、独立してバージョン管理されるコードの小さな単位です。サービス検出メカニズムによって検出可能であり、API 経由で他のサービスと通信できます。各サービスは自己完結型であり、1 つのビジネス機能を実装している必要があります。アプリケーションドメインをマイクロサービスに分解する方法について詳しくは、「Using domain analysis to model microservices (ドメイン分析を使用してマイクロサービスをモデル化する)」をご覧ください。

Service Fabric では、マイクロサービスを効率的に構築、デプロイ、およびアップグレードするためのインフラストラクチャが提供されています。また、自動スケーリング、状態の管理、正常性の監視、および障害発生時のサービスの再起動に対するオプションも提供されています。

Service Fabric は、アプリケーションがマイクロサービスのコレクションであるアプリケーションモデルに従います。このアプリケーションについては、アプリケーションマニフェストファイルを参照してください。このファイルでは、アプリケーションに含まれるサービスの種類と、独立したサービスパッケージへのポインターが定義されています。

アプリケーションパッケージには、通常、サービスによって使用される特定の設定に対するオーバーライドとして機能するパラメーターも含まれています。サービスパッケージごとにマニフェストファイルがあり、バイナリ、構成ファイル、読み取り専用データなど、そのサービスを実行するために必要な物理ファイルとフォルダーが記述されています。サービスとアプリケーションは、個別にバージョン管理され、アップグレード可能です。

アプリケーションマニフェストでは、必要に応じて、アプリケーションのインスタンスが作成されるときに自動的にプロビジョニングされるサービスを記述できます。これらは "既定のサービス" と呼ばれます。この場合、アプリケーションマニフェストでは、これらのサービスに必要な作成方法も記述されます。この情報には、サービスの名前、インスタンスの数、セキュリティまたは分離ポリシー、配置の制約などが含まれます。

注意

独自のサービスの有効期間を制御する場合は、既定のサービスを使用しないでください。既定のサービスは、アプリケーションが作成されると作成され、アプリケーションが実行されている限り実行されます。

詳細については、「Service Fabric に興味をお持ちでしょうか」をご覧ください。

アプリケーションからサービスへのパッケージ化モデル

マイクロサービスの基本思想は、各サービスを独立してデプロイできる、というものです。 Service Fabric では、すべてのサービスを 1 つのアプリケーションパッケージにグループ化した場合、1 つのサービスのアップグレードが失敗すると、アプリケーション全体のアップグレードがロールバックされます。このロールバックにより、他のサービスもアップグレードされなくなります。

そのため、マイクロサービスアーキテクチャでは、複数のアプリケーションパッケージを使用することをお勧めします。 1 つのアプリケーションの種類には、1 つまたは密接に関連する複数のサービスの種類を格納します。たとえば、チームが次のいずれかの属性を持つ一連のサービスを担当している場合は、サービスの種類を同じアプリケーションの種類にします。

同じ期間に実行され、同時に更新される必要がある。
ライフサイクルが同じ。
依存関係や構成などのリソースが共有されている。

Service Fabric のプログラミングモデル

Service Fabric アプリケーションにマイクロサービスを追加するときは、高可用性で高信頼性にする必要がある状態またはデータがあるかどうかを判断します。そうである場合、データを外部に格納できますか、それともデータはサービスの一部として含まれますか。外部ストレージにデータを格納する必要がない場合、またはデータを格納したくない場合は、ステートレスサービスを選択します。次の記述のいずれかに該当する場合は、ステートフルサービスを選択することを検討してください。

サービスの一部として状態またはデータを維持する必要がある。たとえば、そのデータがコードに近いメモリに存在する必要がある。
外部ストアへの依存関係を許容できない。

Service Fabric で実行する既存のコードがある場合は、"ゲスト実行可能ファイル" として実行できます。ゲスト実行可能ファイルは、サービスとして実行される任意の実行可能ファイルです。または、デプロイに必要なすべての依存関係が含まれるコンテナーに、実行可能ファイルをパッケージ化することができます。

Service Fabric では、コンテナーとゲスト実行可能ファイルの両方が、ステートレスサービスとしてモデル化されます。モデルの選択に関するガイダンスについては、「Service Fabric プログラミングモデルの概要」をご覧ください。

ゲスト実行可能ファイルが実行される環境は自身で管理する必要があります。たとえば、ゲスト実行可能ファイルで Python が必要であるとします。実行可能ファイルが自己完結型でない場合、必要なバージョンの Python が環境にプレインストールされていることを、自分で確認する必要があります。 Service Fabric では、環境の管理は行われません。 Azure では、カスタム仮想マシンイメージや拡張機能など、環境を設定する複数のメカニズムが提供されています。

リバースプロキシを通してゲスト実行可能ファイルにアクセスするには、ゲスト実行可能ファイルのサービスマニフェストの Endpoint 要素に UriScheme 属性を追加したことを確認します。

    <Endpoints>
      <Endpoint Name="MyGuestExeTypeEndpoint" Port="8090" Protocol="http" UriScheme="http" PathSuffix="api" Type="Input"/>
    </Endpoints>

サービスに追加のルートがある場合は、PathSuffix の値でそのルートを指定します。値の前または後にスラッシュ (/) を付けないでください。もう 1 つの方法は、サービス名にルートを追加することです。

    <Endpoints>
      <Endpoint Name="MyGuestExeTypeEndpoint" Port="8090" Protocol="http" PathSuffix="api" Type="Input"/>
    </Endpoints>

詳細については、次を参照してください。

API ゲートウェイ

API ゲートウェイ (イングレス) は、外部クライアントとマイクロサービスの間に配置されます。これは、要求をクライアントからマイクロサービスにルーティングするリバースプロキシとして機能します。さらに、認証、SSL 終了、レート制限などの横断的タスクを実行することもできます。

ほとんどのシナリオでは Azure API Management が推奨されますが、Traefik は人気のあるオープンソースの代替手段です。どちらのテクノロジのオプションも、Service Fabric と統合されます。

API Management。パブリック IP アドレスが公開され、サービスにトラフィックがルーティングされます。 Service Fabric クラスターと同じ仮想ネットワーク内の専用サブネットで実行されます。

API Management では、プライベート IP アドレスを使用してロードバランサー経由で公開されるノードタイプのサービスにアクセスできます。このオプションは、API Management の Premium レベルと Developer レベルでのみ使用できます。運用ワークロードの場合は、Premium レベルを使用します。価格の情報については、「API Management の価格」をご覧ください。

詳しくは、「Azure Service Fabric と API Management の概要」をご覧ください。
Traefik。ルーティング、トレース、ログ、メトリックなどの機能がサポートされています。 Traefik は、Service Fabric クラスターでステートレスサービスとして実行されます。サービスのバージョン管理は、ルーティングによってサポートできます。

サービスイングレス用に、およびクラスター内のリバースプロキシとして Traefik を設定する方法については、Traefik Web サイトの「Azure Service Fabric プロバイダー」をご覧ください。 Service Fabric での Traefik の使用について詳しくは、Traefik による Service Fabric でのインテリジェントなルーティングに関するブログ記事をご覧ください。

Azure API Management とは異なり、Traefik には、要求がルーティングされる先の (複数のパーティションがある) ステートフルサービスのパーティションを解決する機能がありません。詳しくは、「Add a matcher for partitioning services (サービスをパーティション分割するためにマッチャーを追加する)」をご覧ください。

API 管理のその他のオプションとしては、Azure Application Gateway と Azure Front Door があります。これらのサービスを API Management と組み合わせて使用し、ルーティング、SSL 終了、ファイアウォールなどのタスクを実行できます。

サービス間の通信

サービス間通信を円滑にするために、以下の推奨事項を検討してください。

通信プロトコル。マイクロサービスアーキテクチャでは、サービス同士が実行時に最小限の結合で通信する必要があります。言語に依存しないで通信を行う手段としては HTTP が業界標準であり、さまざまな言語に対応した広範なツールと HTTP サーバーが提供されています。 Service Fabric では、これらのすべてのツールとサーバーがサポートされています。

ほとんどのワークロードでは、Service Fabric に組み込まれているサービスリモート処理の代わりに HTTP を使用することをお勧めします。
サービスの探索。クラスター内の他のサービスと通信するには、クライアントサービスで対象サービスの現在の場所を解決する必要があります。 Service Fabric では、サービスはノード間を移動できるため、サービスエンドポイントは動的に変化します。

古いエンドポイントへの接続を防ぐには、Service Fabric のネームサービスを使用して、更新されたエンドポイント情報を取得できます。ただし、Service Fabric では、ネームサービスを抽象化する組み込みのリバースプロキシサービスも提供されています。このオプションは使いやすく、コードがシンプルになるため、ほとんどのシナリオのベースラインとしてサービス検出に使用することをお勧めします

サービス間通信用のオプションとしては、他に次のものがあります。

高度なルーティング用の Traefik。
DNS を使用する必要があるサービスとの互換性シナリオ用の DNS。
サービスエンドポイントをキャッシュする ServicePartitionClient<TCommunicationClient> クラス。仲介者やカスタムプロトコルを必要とせずにサービス間で直接呼び出しが行われるので、パフォーマンスが向上します。

スケーラビリティ

Service Fabric では、次のクラスターエンティティのスケーリングがサポートされています。

各ノードタイプのノード数のスケーリング
サービスのスケーリング

このセクションでは、自動スケーリングに注目します。それが適切な状況では、手動スケーリングを選択できます。たとえば、インスタンスの数を設定するために手動による介入が必要になる場合があります。

スケーラビリティのための初期クラスター構成

Service Fabric クラスターを作成するときに、セキュリティとスケーラビリティのニーズに基づいて、ノードタイプをプロビジョニングします。各ノードタイプは 1 つの仮想マシンスケールセットにマップされ、独立してスケーリングできます。

スケーラビリティまたはリソースの要件が異なるサービスのグループごとに、ノードタイプを作成します。最初に、Service Fabric システムサービス用のノードタイプをプロビジョニングします (これがプライマリノードタイプになります)。パブリックサービスやフロントエンドサービスを実行する個別のノードタイプを作成します。必要に応じて、バックエンド、プライベートまたは分離サービスに他のノードタイプを作成します。サービスが目的のノードタイプにのみデプロイされるように、配置の制約を指定します。
各ノードタイプの "持続性層"を指定します。持続性層は、仮想マシンスケールセットの更新とメンテナンス操作に対して Service Fabric が影響を与える機能を表します。運用ワークロードでは、シルバー以上の持続性層を選択します。各層については、クラスターの持続性の特徴に関する記事をご覧ください。
ブロンズ持続性層を使用する場合は、特定の操作で手動の手順が必要になります。ブロンズ持続性層のノードタイプでは、スケールイン時に追加の手順が必要です。スケーリング操作について詳しくは、こちらのガイドをご覧ください。

ノードのスケーリング

Service Fabric では、スケールインとスケールアウトに対する自動スケーリングがサポートされています。ノードタイプごとに個別に自動スケーリングを構成できます。

各ノードタイプは、最大 100 個のノードを持つことができます。少数のノードセットで開始し、負荷に応じてノードを追加します。 1 つのノードタイプで必要なノードが 100 個を超える場合は、ノードタイプをさらに追加する必要があります。詳しくは、「Service Fabric クラスターの容量計画に関する考慮事項」をご覧ください。仮想マシンスケールセットは瞬時にはスケーリングしないので、自動スケーリングの規則を設定するときは、そのことを考慮する必要があります。

自動スケールインをサポートするには、シルバーまたはゴールドの持続性層を持つようにノードタイプを構成します。この構成により、Service Fabric によるサービスの再配置が完了するまで、スケールインが遅延されます。また、仮想マシンスケールセットから Service Fabric に、一時的なダウンではなく VM が削除されたことが通知されます。

ノードまたはクラスターレベルでのスケーリングについて詳しくは、「Azure Service Fabric クラスターのスケーリング」をご覧ください。

サービスのスケーリング

ステートレスサービスとステートフルサービスでは、適用されるスケーリングのアプローチが異なります。

ステートレスサービス (自動スケーリング) の場合は、以下を行います。

パーティションの平均負荷トリガーを使用します。このトリガーでは、スケーリングポリシーで指定されている負荷のしきい値に基づいて、サービスがスケールインまたはスケールアウトされるタイミングが決定されます。トリガーをチェックする頻度も設定できます。「インスタンスベースのスケーリングで使用するパーティションの平均負荷トリガー」をご覧ください。このアプローチにより、使用可能なノードの数までスケールアップできます。
サービスマニフェストで InstanceCount を -1 に設定すると、すべてのノードでサービスのインスタンスを実行するよう Service Fabric に指示されます。この方法では、クラスターのスケーリングに合わせてサービスを動的にスケーリングできます。クラスターのノードの数が変化すると、Service Fabric はそれと一致するようにサービスインスタンスを自動的に作成および削除します。

注意

場合によっては、サービスを手動でスケーリングしたいことがあります。たとえば、Azure Event Hubs から読み取るサービスがある場合、専用のインスタンスで各イベントハブパーティションからの読み取りを行うことがあります。これにより、パーティションへの同時アクセスを回避できます。

ステートフルサービスでのスケーリングは、パーティションの数、各パーティションのサイズ、およびマシンで実行されるパーティションやレプリカの数によって制御されます。

パーティション分割されたサービスを作成する場合は、リソースの競合が発生することなく、ワークロードが均等に分散されるよう、各ノードが適切なレプリカを取得するようにします。ノードを追加した場合、Service Fabric は既定で新しいマシンにワークロードを分配します。たとえば、5 個のノードと 10 個のパーティションがある場合、既定では、Service Fabric は 2 個のプライマリレプリカを各ノードに配置します。ノードをスケールアウトすると、より多くのリソースに作業が均等に分配されるため、パフォーマンスを向上させることができます。

この戦略を利用するシナリオについては、「Service Fabric での拡大縮小」をご覧ください。
パーティションの追加または削除は、あまり適切にサポートされていません。スケーリングによく使用されるもう 1 つのオプションは、サービスまたはアプリケーションインスタンス全体を動的に作成または削除することです。そのパターンの例については、「新しい名前付きサービスの作成または削除による拡大縮小」で説明されています。

詳細については、次を参照してください。

メトリックを使用して負荷を分散させる

パーティションの設計方法によっては、あるノードのレプリカに他よりも多くのトラフィックが送られることがあります。このような状況を避けるには、すべてのパーティションに分散されるようにサービスの状態をパーティション分割します。範囲パーティション構成と適切なハッシュアルゴリズムを使用します。「パーティション分割の使用」をご覧ください。

Service Fabric では、メトリックを使用して、クラスター内にサービスを配置してバランスを取る方法が認識されます。サービスを作成するときに、そのサービスに関連付けられる各メトリックの既定の負荷を指定することができます。その後、Service Fabric では、サービスを配置するとき、あるいはサービスの移動が必要なとき (アップグレード時など)、その負荷を考慮したうえでクラスター内のノードのバランスが調整されます。

サービスに対して最初に指定された既定の負荷は、サービスの有効期間を通して変更されません。サービスについて変化するメトリックをキャプチャするため、サービスを監視して負荷を動的にレポートすることお勧めします。このアプローチにより、Service Fabric では特定の時点に報告された負荷に基づいて割り当てを調整できます。カスタムメトリックを報告するには、IServicePartition.ReportLoad メソッドを使用します。詳しくは、「動的な負荷」をご覧ください。

可用性

プライマリノードタイプ以外のノードタイプに、サービスを配置します。 Service Fabric のシステムサービスは、プライマリノードタイプに常にデプロイされます。独自のサービスをプライマリノードタイプにデプロイすると、それらがリソースについてシステムサービスと競合 (干渉) する可能性があります。ノードタイプでステートフルサービスをホストすることが予想される場合は、ノードインスタンスの数を 5 個以上にして、シルバーまたはゴールドの持続性層を選択します。

サービスのリソースを制限することを検討します。「リソースガバナンスのメカニズム」をご覧ください。

一般的な考慮事項を次に示します。

リソース管理サービスとリソース非管理サービスを同じノードタイプに混在させないでください。非管理サービスによって消費されるリソースが多すぎて、管理サービスに影響する可能性があります。これらの種類のサービスが同じノードのセットで実行されないようにするには、配置の制約を指定します。 (これは、バルクヘッドパターンの例です)。
サービスインスタンス用に予約する CPU コア数とメモリを指定します。リソースガバナンスポリシーの使用と制限事項については、「リソースガバナンス」をご覧ください。

単一障害点 (SPOF) を回避するため、すべてのサービスのターゲットインスタンスまたはレプリカの数を 1 より大きくします。サービスインスタンスまたはレプリカの数として使用できる最大数は、サービスが制約されているノードの数と同じです。

すべてのステートフルサービスに、少なくとも 2 つのアクティブなセカンダリレプリカがあるようにします。運用ワークロードでは 5 個のレプリカをお勧めします。

詳しくは、「Service Fabric サービスの可用性」をご覧ください。

セキュリティ

セキュリティは、重要なデータやシステムの意図的な攻撃や悪用に対する保証を提供します。詳細については、「セキュリティの重要な要素の概要」を参照してください。

Service Fabric でアプリケーションを保護するための重要な点を次に示します。

仮想ネットワーク

各仮想マシンスケールセットにサブネット境界を定義し、通信のフローを制御することを検討します。各ノードタイプには、Service Fabric クラスターの仮想ネットワーク内のサブネットに、専用の仮想マシンスケールセットがあります。ネットワークセキュリティグループ (NSG) をサブネットに追加して、ネットワークトラフィックを許可または拒否できます。たとえば、フロントエンドとバックエンドのノードタイプでは、バックエンドサブネットに NSG を追加し、フロントエンドサブネットからの受信トラフィックのみを受け取ることができます。

クラスターから外部の Azure サービスを呼び出すとき、Azure サービスでサポートされている場合は、仮想ネットワークサービスエンドポイントを使用します。サービスエンドポイントを使用すると、サービスはクラスターの仮想ネットワークのみに固定されます。

たとえば、Azure Cosmos DB を使ってデータを格納する場合は、サービスエンドポイントで Azure Cosmos DB アカウントを構成し、特定のサブネットからのアクセスのみを許可します。「仮想ネットワークから Azure Cosmos DB リソースへのアクセス」をご覧ください。

エンドポイントとサービス間の通信

セキュリティ保護されていない Service Fabric クラスターを作成しないでください。クラスターでパブリックインターネットに管理エンドポイントを公開している場合、匿名ユーザーがそのクラスターに接続できるようになります。セキュリティで保護されていないクラスターは、運用ワークロードでサポートされません。「Service Fabric クラスターのセキュリティに関するシナリオ」をご覧ください。

サービス間通信をセキュリティで保護するには、以下を実行します。

ASP.NET Core サービスまたは Java Web サービスでは、HTTPS エンドポイントを有効にすることを考えます。
リバースプロキシとサービスの間に、セキュリティ保護された接続を確立します。詳しくは、セキュリティで保護されたサービスへの接続に関する記事をご覧ください。

API ゲートウェイを使用している場合は、ゲートウェイに認証をオフロードすることができます。メッセージを認証する追加のセキュリティが設定されていない限り、個々のサービスに直接 (API ゲートウェイなしで) アクセスできないようにします。

Service Fabric のリバースプロキシをパブリックに公開しないでください。そのようにすると、HTTP エンドポイントを公開するすべてのサービスが、クラスターの外部からアドレス指定可能になります。これによりセキュリティの脆弱性が発生し、その他の情報が不必要にクラスターの外部に公開される可能性があります。サービスをパブリックにアクセス可能にする場合は、API ゲートウェイを使用します。この記事で後述する「API ゲートウェイ」セクションでは、いくつかのオプションについて触れています。

リモートデスクトップは診断やトラブルシューティングに便利ですが、必ず閉じてください。開いたままにしておくと、セキュリティホールの原因になります。

シークレットと証明書

接続文字列などのシークレットをキーコンテナーのデータストアに格納します。キーコンテナーは、仮想マシンスケールセットと同じリージョン内にある必要があります。キーコンテナーを使用するには、以下を実行します。

キーコンテナーに対するサービスのアクセスを認証します。

サービスがホストされている仮想マシンスケールセットでマネージド ID を有効にします。
キーコンテナーにシークレットを格納します。

キーと値のペアに変換できる形式でシークレットを追加します。たとえば、 CosmosDB--AuthKeyを使用します。構成のビルド時に、二重ハイフン (--) がコロン (:) に変換されます。
サービスでこれらのシークレットにアクセスします。

appSettings.json ファイルでキーコンテナーの URI を追加します。サービスで、キーコンテナーから読み取り、構成をビルドし、ビルド済みの構成からシークレットにアクセスする、構成プロバイダーを追加します。

次に示す例では、Workflow サービスが CosmosDB--Database という形式でキーコンテナーにシークレットを格納しています。

namespace Fabrikam.Workflow.Service
{
    public class ServiceStartup
    {
        public static void ConfigureServices(StatelessServiceContext context, IServiceCollection services)
        {
            var preConfig = new ConfigurationBuilder()
                …
                .AddJsonFile(context, "appsettings.json");

            var config = preConfig.Build();

            if (config["AzureKeyVault:KeyVaultUri"] is var keyVaultUri && !string.IsNullOrWhiteSpace(keyVaultUri))
            {
                preConfig.AddAzureKeyVault(keyVaultUri);
                config = preConfig.Build();
            }
    }
}

シークレットにアクセスするには、ビルド済みの構成でシークレット名を指定します。

       if(builtConfig["CosmosDB:Database"] is var database && !string.IsNullOrEmpty(database))
       {
            // Use the secret.
       }

クライアント証明書を使用して Service Fabric Explorer にアクセスしないでください。代わりに、Microsoft Entra ID を使います。「Microsoft Entra 認証をサポートする Azure サービス」を参照してください。

運用環境では自己署名証明書を使用しないでください。

保存データの保護

Service Fabric クラスターの仮想マシンスケールセットにデータディスクをアタッチしていて、サービスによってそれらのディスクにデータが保存されている場合は、ディスクを暗号化する必要があります。詳細については、Azure PowerShell (プレビュー) を使用した仮想マシンスケールセットの OS および接続されているデータディスクの暗号化に関する記事を参照してください。

Service Fabric のセキュリティ保護について詳しくは、以下をご覧ください。

回復性

障害から復旧し、完全に機能する状態を維持するには、アプリケーションで特定の回復性パターンを実装する必要があります。一般的なパターンを以下に示します。

再試行: リソースの一時的な利用不可など、一時的であると思われるエラーを処理する場合。
サーキットブレーカー: 修正に長くかかる可能性がある障害に対処する場合。
バルクヘッド: 各サービスのリソースを分離する場合。

このリファレンス実装では、オープンソースオプションの Polly を使って、すべてのパターンを実装します。

監視

監視オプションを調べる前に、Service Fabric での一般的なシナリオの診断に関するこちらの記事を読むことをお勧めします。データの監視については以下のセットで考えることができます。

アプリケーションのメトリックとログ
Service Fabric の正常性とイベントデータ
インフラストラクチャのメトリックとログ
依存サービスのメトリックとログ

そのデータを分析するための主なオプションは次の 2 つです。

Application Insights
Log Analytics

Azure Monitor を使用して、監視用のダッシュボードを設定し、オペレーターにアラートを送信することができます。 Dynatrace など、Service Fabric と統合できるサードパーティ製の監視ツールもあります。詳しくは、「Azure Service Fabric 監視パートナー」をご覧ください。

アプリケーションのメトリックとログ

アプリケーションのテレメトリでは、サービスの正常性を監視して問題を特定するのに役立つデータが提供されます。サービスでトレースとイベントを追加するには:

ASP.NET Core でサービスを開発している場合は、Microsoft.Extensions.Logging を使用します。他のフレームワークの場合は、Serilog などの適当なログ記録ライブラリを使用します。
SDK の TelemetryClient クラスを使用して独自のインストルメンテーションを追加し、Application Insights でデータを表示します。「カスタムインストルメンテーションをアプリケーションに追加する」をご覧ください。
EventSource を使用して、Event Trace for Windows (ETW) イベントをログに記録します。このオプションは、Visual Studio の Service Fabric ソリューションにおいて既定で使用できます。

Application Insights には、多くの組み込みテレメトリ (要求、トレース、イベント、例外、メトリック、依存関係) が用意されています。サービスで HTTP エンドポイントを公開する場合は、Microsoft.AspNetCore.Hosting.IWebHostBuilder に対して UseApplicationInsights 拡張メソッドを呼び出すことにより、Application Insights を有効にします。 Application Insights に対するサービスのインストルメント化については、次の記事をご覧ください。

トレースとイベントログを表示するには、構造化ログのシンクの 1 つとして Application Insights を使用します。 AddApplicationInsights 拡張メソッドを呼び出すことにより、インストルメンテーションキーを使用して Application Insights を構成します。この例では、インストルメンテーションキーはキーコンテナーにシークレットとして格納されます。

    .ConfigureLogging((hostingContext, logging) =>
        {
            logging.AddApplicationInsights(hostingContext.Configuration ["ApplicationInsights:InstrumentationKey"]);
        })

サービスで HTTP エンドポイントを公開しない場合は、Application Insights にトレースを送信するカスタム拡張機能を記述する必要があります。たとえば、リファレンス実装の Workflow サービスを参照してください。

ASP.NET Core サービスでは、アプリケーションログ記録に ILogger インターフェイスが使用されます。これらのアプリケーションログを Azure Monitor で使用できるようにするには、ILogger イベントを Application Insights に送信します。 Application Insights では、相関関係プロパティを ILogger イベントに追加できます。これは、分散トレースの視覚化に役立ちます。

詳細については、次を参照してください。

Service Fabric の正常性とイベントデータ

Service Fabric のテレメトリには、Service Fabric クラスターとそのエンティティ (ノード、アプリケーション、サービス、パーティション、レプリカ) の操作とパフォーマンスに関する正常性メトリックとイベントが含まれます。正常性データとイベントデータは、以下から取得できます。

EventStore。このステートフルなシステムサービスでは、クラスターとそのエンティティに関連するイベントが収集されます。 Service Fabric では EventStore を使用して Service Fabric イベントが書き込まれ、クラスターの状態の更新、トラブルシューティング、監視のための情報が提供されます。また、EventStore では、特定の時点でのさまざまなエンティティからのイベントが関連付けられ、クラスター内の問題が識別されます。サービスでは、REST API を介してこれらのイベントが公開されます。

EventStore API のクエリを実行する方法については、「クラスターイベントに対して EventStore API のクエリを実行する」をご覧ください。 Windows 用の Azure Diagnostics 拡張機能 (WAD) でクラスターを構成することにより、EventStore からのイベントを Log Analytics で表示することができます。
HealthStore。このステートフルサービスでは、クラスターの現在の正常性のスナップショットが提供されます。階層内のエンティティによって報告されたすべての正常性データが集約されます。データは、Service Fabric Explorer で視覚化されます。 HealthStore では、アプリケーションのアップグレードも監視されます。 PowerShell、.NET アプリケーション、または REST API で、正常性クエリを使用できます。「Service Fabric の正常性モニタリングの概要」をご覧ください。
カスタム正常性レポート。実行中のサービスの障害の状態など、カスタム正常性データを定期的に報告できる内部ウォッチドッグサービスの実装を検討してください。 Service Fabric Explorer で正常性レポートを読み取ることができます。

インフラストラクチャのメトリックとログ

インフラストラクチャのメトリックを使用すると、クラスター内のリソース割り当てを把握することができます。この情報を収集するための主なオプションを次に示します。

WAD。 Windows のノードレベルでログとメトリックを収集します。ノードタイプにマップされる任意の仮想マシンスケールセットで IaaSDiagnostics VM 拡張機能を構成することにより、WAD を使用して診断イベントを収集できます。これらのイベントには、Windows イベントログ、パフォーマンスカウンター、ETW/マニフェストシステムと運用イベント、カスタムログなどが含まれます。
Log Analytics エージェント。 MicrosoftMonitoringAgent VM 拡張機能を構成し、Windows イベントログ、パフォーマンスカウンター、カスタムログを Log Analytics に送信します。

パフォーマンスカウンターなど、上記のメカニズムを通じて収集されるメトリックの種類にはいくつか重複するものがあります。重複するものがある場合は、Log Analytics エージェントを使うことをお勧めします。 Log Analytics エージェントでは Azure ストレージが使用されないため、待機時間は短くなります。また、IaaSDiagnostics のパフォーマンスカウンターは、Log Analytics に簡単にフィードできません。

Diagram that shows infrastructure monitoring in Service Fabric.

VM 拡張機能の使用については、「Azure 仮想マシンの拡張機能と機能」をご覧ください。

データを表示するには、WAD によって収集されたデータを表示するように Log Analytics を構成します。ストレージアカウントからイベントを読み取るように Log Analytics を構成する方法については、「クラスターに Log Analytics を設定する」をご覧ください。

Service Fabric クラスター、ワークロード、ネットワークトラフィック、保留中の更新プログラムなどに関連するパフォーマンスログとテレメトリデータを表示することもできます。 Log Analytics でのパフォーマンスの監視に関する記事をご覧ください。

Log Analytics の Service Map ソリューションでは、クラスターのトポロジ (つまり、各ノードで実行されているプロセス) に関する情報が提供されます。ストレージアカウント内のデータを Application Insights に送信します。 Application Insights へのデータの取得には若干の遅延がある可能性があります。データをリアルタイムで見たい場合は、シンクとチャネルを使用して Event Hubs を構成することを検討します。詳しくは、「Windows Azure 診断を使用したイベントの集計と収集」をご覧ください。

依存サービスのメトリック

Application Insights のアプリケーションマップでは、インストールされている Application Insights SDK によりサービス間で行われた HTTP 依存関係呼び出しを使用して、アプリケーションのトポロジが提供されます。
Log Analytics の Service Map では、外部サービスとの間の受信および送信トラフィックについての情報が提供されます。 Service Map は、更新やセキュリティなどの他のソリューションと連携します。
カスタムウォッチドッグでは、外部サービスでのエラー状態をレポートできます。たとえば、このサービスでは、外部サービスまたはデータストレージ (Azure Cosmos DB) にアクセスできない場合に、エラー正常性レポートが提供されます。

分散トレース

マイクロサービスアーキテクチャでは、タスクを完了するために複数のサービスが参加することがよくあります。それらの各サービスからのテレメトリは、分散トレースのコンテキストフィールド (操作 ID や要求 ID など) を通じて関連付けられます。

Application Insights でアプリケーションマップを使用することにより、分散型論理操作のビューを構築し、アプリケーションのサービスグラフ全体を視覚化できます。また、Application Insights でトランザクション診断を使用して、サーバー側テレメトリを関連付けることもできます。くわしくは、「統合されたコンポーネント間のトランザクションの診断」をご覧ください。

キューを使用して非同期にディスパッチされるタスクを関連付けることも重要です。キューメッセージで相関関係テレメトリを送信する方法について詳しくは、「キューのインストルメンテーション」をご覧ください。

詳細については、次を参照してください。

アラートとダッシュボード

Application Insights と Log Analytics では広範なクエリ言語 (Kusto クエリ言語) がサポートされており、ログデータを取得して分析できます。クエリを使用してデータセットを作成し、診断ダッシュボードでそれらを視覚化します。

Azure Monitor のアラートを使用して、特定のリソースで特定の状態が発生したときにシステム管理者に通知します。通知には、メール、Azure 関数、Webhook などを使用できます。詳しくは、Azure Monitor でのアラートに関する記事をご覧ください。

ログ検索アラートルールでは、Kusto クエリを定義し、一定の間隔で Log Analytics ワークスペースに対して実行できます。クエリの結果が特定の条件に一致する場合は、アラートが作成されます。

コスト最適化

コストの見積もりには、Azure 料金計算ツールをご利用ください。その他の考慮事項については、Microsoft Azure Well-Architected Framework のコスト最適化の柱に関する記事で説明されています。

ここでは、このアーキテクチャで使用されるサービスの一部について考慮する点について説明します。

Azure Service Fabric

Service Fabric クラスターを作成するときに選択したコンピューティングインスタンス、ストレージ、ネットワークリソース、IP アドレスに対して課金されます。 Service Fabric のデプロイ料金が発生します。

仮想マシンスケールセット

このアーキテクチャでは、マイクロサービスは仮想マシンスケールセットであるノードにデプロイされます。クラスターの一部としてデプロイされる Azure VM や、基になるインフラストラクチャリソース (ストレージやネットワークなど) に対して課金されます。仮想マシンスケールセット自体に対する増分料金は発生しません。

Azure API Management

Azure API Management は、クライアントからクラスター内のサービスに要求をルーティングするためのゲートウェイです。

さまざまな価格オプションがあります。従量課金オプションでは従量課金ベースで課金され、ゲートウェイコンポーネントが含まれています。ワークロードに基づいて、「API Management の価格」で説明されているオプションを選択します。

Application Insights

Application Insights を使用して、あらゆるサービスのテレメトリを収集し、トレースやイベントログを構造化された方法で表示することができます。 Application Insights の価格は、取り込まれたデータの量とデータ保持のオプションに基づく従量課金制モデルです。詳しくは、Application Insights の使用量とコストの管理に関する記事をご覧ください。

Azure Monitor

Azure Monitor Log Analytics では、データインジェストとデータの保持について料金が発生します。詳細については、「Azure Monitor の価格」を参照してください。

Azure Key Vault

Azure Key Vault を使用して、Application Insights のインストルメンテーションキーをシークレットとして格納します。 Azure では、2 つのサービスレベルで Key Vault が提供されています。 HSM で保護されたキーが不要な場合は、Standard レベルを選択します。各レベルの機能の詳細については、「Key Vault の価格」をご覧ください。

Azure DevOps Services

この参照アーキテクチャでは、デプロイに Azure Pipelines が使用されます。 Azure Pipelines では、CI/CD 用に 1 か月あたり 1,800 分の無料の Microsoft ホステッドジョブに加え、1 か月あたり無制限の分数の 1 セルフホステッドジョブを利用できます。追加のジョブには料金がかかります。詳細については、Azure DevOps Services の料金に関するページをご覧ください。

マイクロサービスアーキテクチャでの DevOps の考慮事項については、マイクロサービスの CI/CD に関するページを参照してください。

CI/CD を使用してコンテナーアプリケーションを Service Fabric クラスターにデプロイする方法については、こちらのチュートリアルをご覧ください。

このシナリオのデプロイ

このアーキテクチャの参照実装をデプロイするには、GitHub リポジトリの手順に従ってください。

Azure Service Fabric でのマイクロサービス アーキテクチャ

アーキテクチャ

ワークフロー

考慮事項

設計上の考慮事項

アプリケーションからサービスへのパッケージ化モデル

Service Fabric のプログラミング モデル

API ゲートウェイ

サービス間の通信

スケーラビリティ

スケーラビリティのための初期クラスター構成

ノードのスケーリング

サービスのスケーリング

メトリックを使用して負荷を分散させる

可用性

セキュリティ

仮想ネットワーク

エンドポイントとサービス間の通信

シークレットと証明書

保存データの保護

回復性

監視

アプリケーションのメトリックとログ

Service Fabric の正常性とイベント データ

インフラストラクチャのメトリックとログ

依存サービスのメトリック

分散トレース

アラートとダッシュボード

コスト最適化

Azure Service Fabric

仮想マシン スケール セット

Azure API Management

Application Insights

Azure Monitor

Azure Key Vault

Azure DevOps Services

このシナリオのデプロイ

次の手順

関連リソース

フィードバック

フィードバック

その他のリソース

Azure Service Fabric でのマイクロサービスアーキテクチャ

Service Fabric のプログラミングモデル

Service Fabric の正常性とイベントデータ

仮想マシンスケールセット