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

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

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

アーキテクチャ

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

ワークフロー

アーキテクチャは、次のコンポーネントで構成されます。 他の用語については、「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>

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

• アプリケーションのパッケージ化
• 既存の実行可能ファイルのパッケージ化と Service Fabric へのデプロイ

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 はそれと一致するようにサービス インスタンスを自動的に作成および削除します。

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

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

  この戦略を利用するシナリオについては、「Service Fabric での拡大縮小」をご覧ください。

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

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

• 自動スケール ルールを使用した、または手動による Service Fabric クラスターのスケールインとスケールアウト
• プログラムによる Service Fabric クラスターのスケール
• 仮想マシン スケール セットを追加して Service Fabric クラスターをスケールアウトする

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

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

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 ゲートウェイ」セクションでは、いくつかのオプションについて触れています。

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

シークレットと証明書

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

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

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

2. キー コンテナーにシークレットを格納します。

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

3. サービスでこれらのシークレットにアクセスします。

   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 のセキュリティ保護について詳しくは、以下をご覧ください。

• Azure Service Fabric のセキュリティの概要
• Azure Service Fabric のセキュリティに関するベスト プラクティス
• Azure 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 に対するサービスのインストルメント化については、次の記事をご覧ください。

• チュートリアル: Application Insights を使用して Service Fabric 上の ASP.NET Core アプリケーションを監視および診断する
• Application Insights for ASP.NET Core
• Application Insights .NET SDK
• Application Insights SDK for Service Fabric

トレースとイベント ログを表示するには、構造化ログのシンクの 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 のテレメトリには、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 に簡単にフィードできません。

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 におけるテレメトリの相関付け

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

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 の概要
• Azure Service Fabric の概要
• API Management のドキュメント
• Azure Pipelines とは

関連リソース

• ドメイン分析を使用したマイクロサービスのモデル化
• マイクロサービス アーキテクチャの設計