Azure Well-Architected フレームワークのレビュー - Azure Service Fabric
Azure Service Fabric は、スケーラブルで信頼性の高いマイクロサービスとコンテナーを容易にパッケージ化、展開、管理できる分散システム プラットフォームです。 これらのリソースは、ネットワークに接続された仮想または物理マシンのセット (クラスターと呼ばれます) にデプロイされます。
Azure Service Fabric には、 標準クラスターとマネージド クラスターという 2 つのクラスター モデルがあります。
標準クラスターでは、多数のサポート リソースと共にクラスター リソースを定義する必要があります。 これらのリソースは、デプロイ時に正しく設定し、クラスターのライフサイクル全体にわたって正しく維持する必要があります。 そうしないと、クラスターとお使いのサービスが正しく機能しません。
マネージド クラスター によりデプロイと管理の業務が簡略化します。 マネージド クラスター モデルは、基になるリソースをカプセル化して抽象化する単一の Service Fabric マネージド クラスター リソースで構成されます。
この記事では、わかりやすくするため、主に マネージド クラスター モデルについて説明します。 ただし、標準クラスター モデルに適用される特別な考慮事項がある場合は、それをコールアウト表示しています。
この記事では、Azure Service Fabric のアーキテクチャのベスト プラクティスについて説明します。 このガイダンスは、アーキテクチャの卓越性の 5 つの柱に基づいています。
- 信頼性
- セキュリティ
- コストの最適化
- オペレーショナルエクセレンス
- パフォーマンス効率
前提条件
Well-Architected Framework の柱に関するガイダンスを理解すると、高品質で安定した効率的なクラウド アーキテクチャを作成するのに役立ちます。 Azure Well-Architected フレームワークの概要ページをご覧になり、アーキテクチャの卓越性の 5 つの柱を確認してください。
Azure Service Fabric とマイクロサービス アーキテクチャの主要な概念を確認すると、この記事で提供されるベスト プラクティスのコンテキストを理解するのに役立ちます。
信頼性
以下のセクションでは、特に Azure Service Fabric と信頼性の設計上の考慮事項と構成に関する推奨事項について説明します。
Azure Service Fabric での信頼性について検討するときは、"クラスターの信頼性" と "ワークロードの信頼性" を区別することが重要です。 クラスターの信頼性は、Service Fabric クラスター管理者とそのリソース プロバイダーの間で共有される責任ですが、ワークロードの信頼性は開発者の領域です。 Azure Service Fabric には、これらの両方のロールに関する考慮事項と推奨事項があります。
以下の設計チェックリストおよび推奨事項のリストでは各選択がクラスター アーキテクチャ、ワークロード アーキテクチャ、またはその両方に適用されるかどうかをコールアウト表示で示しています。
Azure Service Fabric クラスターの信頼性の詳細については、キャパシティ プランニングに関するドキュメントを参照してください。
Azure Service Fabric ワークロードの信頼性の詳細については、Service Fabric アーキテクチャに含まれる 責任サブシステム を参照してください。
設計チェック リスト
Azure Service Fabric の設計上の選択を行う際は、アーキテクチャの信頼性を向上させるために「設計の原則」を確認してください。
- クラスター アーキテクチャ: 運用シナリオに Standard SKU を使用します。 標準クラスター: 運用環境のシナリオでは、持続性レベル Silver (5 個の VM) 以上を使用します。
- クラスター アーキテクチャ: 重要なワークロードの場合は、Service Fabric クラスターに対して Availability Zones を使用することを検討します。
- クラスター アーキテクチャ: 運用環境のシナリオでは、Standard レベルのロード バランサーを使用します。 マネージド クラスターで、プライマリとセカンダリの両方のノード タイプ用に、静的パブリック IP を使用して Azure のパブリック Standard Load Balancer と完全修飾のドメイン名が作成されます。 Basic および Standard SKU の両方のロード バランサーをサポートする Bring Your Own Load Balancer 使用することもできます。
- クラスター アーキテクチャ: ワークロード用の追加のセカンダリ ノード タイプを作成します。
推奨事項
次の表に記載されている推奨事項を参照して、サービスの信頼性を確保するように Azure Service Fabric 構成を最適化します。
| Azure Service Fabric に関する推奨事項 | ベネフィット |
|---|---|
| クラスター アーキテクチャ: 運用シナリオに Standard SKU を使用します。 | このレベルは、リソース プロバイダーでクラスターの信頼性を維持できます。 標準クラスター: Standard SKU マネージド クラスターでは、持続性レベル Silver と同等の内容が提供されます。 標準クラスター モデルを使用してこれを実現するには、5 つの VM (またはそれ以上) を使用する必要があります。 |
| クラスター アーキテクチャ: Service Fabric クラスターに対して Availability Zones を使用することを検討します。 | Service Fabric マネージド クラスターは、ゾーンの回復性を提供するために、複数の Availability Zones にまたがるデプロイをサポートしています。 このように構成すると、重要なシステム サービスとアプリケーションの高可用性によって、単一障害点の発生を防ぐことができます。 |
| クラスター アーキテクチャ: Azure API Management を使用して、クラスターでホストされている API の横断的な機能を公開およびオフロードすることを検討します。 | API Management は直接 Service Fabric と統合できます。 |
| ワークロード アーキテクチャ: ステートフル ワークロード シナリオの場合は、 Reliable Servicesの使用を検討します。 | Reliable Services モデルを使用すると、マシンでの障害、またはネットワークの問題が発生した場合や、サービス自体にエラーが発生し、クラッシュまたは失敗した場合でも、サービスは稼働を続けることができます。 ステートフル サービスの場合、ネットワークまたはその他の障害が発生した場合でも、状態は保持されます。 |
その他の推奨事項については、信頼性の柱の原則を参照してください。
セキュリティ
以下のセクションでは、特に Azure Service Fabric とセキュリティの設計上の考慮事項と構成に関する推奨事項について説明します。
Azure Service Fabric でのセキュリティについて検討するときは、"クラスターのセキュリティ" と "ワークロードのセキュリティ" を区別することが重要です。 クラスターのセキュリティは、Service Fabric クラスター管理者とそのリソース プロバイダーの間で共有される責任ですが、ワークロードのセキュリティは開発者の領域です。 Azure Service Fabric には、これらの両方のロールに関する考慮事項と推奨事項があります。
以下の設計チェックリストおよび推奨事項のリストでは各選択がクラスター アーキテクチャ、ワークロード アーキテクチャ、またはその両方に適用されるかどうかをコールアウト表示で示しています。
Azure Service Fabric クラスターのセキュリティの詳細については、「Service Fabric クラスターのセキュリティ シナリオ」を参照してください。
Azure Service Fabric ワークロードのセキュリティの詳細については、「Service Fabric アプリケーションとサービス セキュリティ」を参照してください。
設計チェック リスト
Azure Service Fabric の設計上の選択を行う際は、アーキテクチャにセキュリティを追加するために「設計の原則」を確認してください。
- クラスター アーキテクチャ: サブネットとノードの種類の間のトラフィック フローを制限するようにネットワーク セキュリティ グループ (NSG) が構成されていることを確認します。 アプリケーションのデプロイとワークロード用に 修正ポート が開かれていることを確認します。
- クラスター アーキテクチャ: Service Fabric シークレット格納を使用してシークレットを配布する場合は、別のデータ暗号化証明書を使用して値を暗号化します。
- クラスター アーキテクチャ: Azure Key Vault にクライアント証明書を追加して、それをデプロイし、デプロイ内の URI を参照します。
- クラスター アーキテクチャ: クラスターの Microsoft Entra 統合を有効にして、ユーザーが Microsoft Entra 資格情報を使用して Service Fabric Explorer にアクセスできるようにします。 Explorer にアクセスするために、クラスター クライアント証明書をユーザーに配布しないでください。
- クラスター アーキテクチャ: クライアント認証には、管理者および読み取り専用のクライアント証明書または Microsoft Entra 認証を使用します。
- クラスターおよびワークロード アーキテクチャ: クライアント証明書の有効期限を監視するプロセスを作成します。
- クラスターおよびワークロード アーキテクチャ: 開発、ステージング、運用向けに個別のクラスターを維持します。
推奨事項
セキュリティのために Azure Service Fabric 構成を最適化するには、次の推奨事項を考慮してください。
| Azure Service Fabric に関する推奨事項 | ベネフィット |
|---|---|
| クラスター アーキテクチャ: サブネットとノードの種類の間のトラフィック フローを制限するようにネットワーク セキュリティ グループ (NSG) が構成されていることを確認します。 | たとえば、API Management インスタンス (1 つのサブネット)、フロントエンド サブネット (Web サイトを直接公開)、バックエンド サブネット (フロントエンドにのみアクセス可能) がある場合。 |
| クラスター アーキテクチャ: Service Fabric クラスターの仮想マシン スケール セットに Key Vault 証明書をデプロイします。 | アプリケーション シークレットのストレージを Azure Key Vault に一元化することで、その配布を制御できます。 Key Vault によって、シークレットが誤って漏洩する可能性が大幅に小さくなります。 |
| クラスター アーキテクチャ: Service Fabric クラスター用の証明書にアクセス制御リスト (ACL) を適用します。 | ACL を使用すると、追加レベルの認証が提供されます。 |
| クラスター アーキテクチャ: リソースの要求と制限を使用してクラスター内のノード全体のリソース配分状況を管理します。 | リソース制限を適用すると、1 つのサービスで消費されるリソースが多くなりすぎず、他のサービスで不足しないようにすることができます。 |
| ワークロード アーキテクチャ: Service Fabric パッケージのシークレット値を暗号化します。 | シークレット値の暗号化により、さらにセキュリティのレベルが向上します。 |
| ワークロード アーキテクチャ: Service Fabric アプリケーションにクライアント証明書を含めます。 | アプリケーションで認証にクライアント証明書を使用すると、クラスターおよびワークロード レベルの両方でセキュリティを確保できます。 |
| ワークロード アーキテクチャ: マネージド ID を使用して Azure リソースに対して Service Fabric アプリケーションを認証します。 | マネージド ID を使用すると、資格情報開発者ワークステーションやソース管理でローカルに保存することなく、さまざまなサービスに対する認証用にコード内で安全に管理できます。 |
| クラスターおよびワークロード アーキテクチャ: 信頼されていないアプリケーションをホストする場合は、Service Fabric のベスト プラクティスに従います。 | ベスト プラクティスに従うと、従うセキュリティ標準が提供されます。 |
その他の推奨事項については、「セキュリティの重要な原則」を参照してください。
Azure Advisor は、Azure Service Fabric のセキュリティの確保と向上に役立ちます。 推奨事項は、この記事の Azure Advisor のセクションで確認できます。
ポリシーの定義
Azure Policy は、組織の標準を維持し、リソース全体のコンプライアンスを評価するのに役立ちます。 Azure Service Fabric を構成するときは、次の組み込みポリシーを考慮してください。
- Service Fabric クラスターでは、ClusterProtectionLevel プロパティを
EncryptAndSignに設定する必要があります。 これはマネージド クラスターの既定値であり、変更できません。 標準クラスター: ClusterProtectionLevel がEncryptAndSignに設定してあることを確認します。 - Service Fabric クラスターでは、クライアント認証に Microsoft Entra ID のみを使用する必要があります。
Azure Service Fabric に関連するすべての組み込みポリシー定義は、「組み込みポリシー - Service Fabric」に記載されています。
コストの最適化
以下のセクションでは、特に Azure Service Fabric とコストの最適化の設計上の考慮事項と構成に関する推奨事項について説明します。
Azure Service Fabric でコストの最適化について検討する場合は、"クラスター リソースのコスト" と "ワークロード リソースのコスト" を区別することが重要です。 クラスター リソースは Service Fabric クラスター管理者とそのリソース プロバイダーの間で共有される責任ですが、ワークロード リソースは開発者の領域です。 Azure Service Fabric には、これらの両方のロールに関する考慮事項と推奨事項があります。
以下の設計チェックリストおよび推奨事項のリストでは各選択がクラスター アーキテクチャ、ワークロード アーキテクチャ、またはその両方に適用されるかどうかをコールアウト表示で示しています。
クラスターのコストの最適化については、Azure 料金計算ツールに移動し利用可能な製品から Azure Service Fabric を選択します。 計算ツールでは、さまざまな構成と支払いプランを試すことができます。
Azure Service Fabric ワークロードの価格の詳細については、「アプリケーション計画のコスト計算プロセスの例」を参照してください。
設計チェック リスト
Azure Service Fabric の設計を選択する際は、アーキテクチャのコストを最適化するために「設計の原則」を確認してください。
- クラスター アーキテクチャ: 適切な VM SKU を選択します。
- クラスター アーキテクチャ: 適切なノードの種類とサイズを使用します。
- クラスターとワークロードのアーキテクチャ: 適切なマネージド ディスク層とサイズを使用します。
推奨事項
コストを考慮して Azure Service Fabric の構成を最適化するには、次の推奨事項の表を参照してください。
| Azure Service Fabric に関する推奨事項 | ベネフィット |
|---|---|
| クラスター アーキテクチャ: 一時ディスク オファリングを含む VM SKU を避けます。 | Service Fabric では既定でマネージド ディスクが使用されるため、一時ディスクのオファリングを避けることで、不要なリソースに対する支払いが生じなくなります。 |
| クラスター アーキテクチャ: 容量上の理由から特定の VM SKU を選択する必要があり、これにより一時ディスクのオファーが生じる場合は、ステートレス ワークロードの一時ディスクのサポートの使用を検討してください。 | 現在、支払いの対象になっているリソースを最大限に活用します。 マネージド ディスクではなく一時ディスクを使用すると、ステートレス ワークロードのコストを削減できます。 |
| クラスターおよびワークロード アーキテクチャ: SKU の選択とマネージド ディスクのサイズをワークロードの要件に合わせます。 | 選択内容をワークロードの需要と一致させると、不要なリソースに対する支払いが発生しません。 |
その他の推奨事項については、コスト最適化の柱の原則を参照してください。
オペレーショナルエクセレンス
以下のセクションでは、特に Azure Service Fabric とオペレーショナル エクセレンスの設計上の考慮事項と構成に関する推奨事項について説明します。
Azure Service Fabric でのセキュリティについて検討するときは、"クラスターの操作" と "ワークロードの操作" を区別することが重要です。 クラスターの操作は Service Fabric クラスター管理者とそのリソース プロバイダーの間で共有される責任ですが、ワークロードの操作は開発者の領域です。 Azure Service Fabric には、これらの両方のロールに関する考慮事項と推奨事項があります。
以下の設計チェックリストおよび推奨事項のリストでは各選択がクラスター アーキテクチャ、ワークロード アーキテクチャ、またはその両方に適用されるかどうかをコールアウト表示で示しています。
設計チェック リスト
Azure Service Fabric の設計を選択する際は、オペレーショナル エクセレンスの「設計の原則」を確認してください。
- クラスター アーキテクチャ: クラスター監視ソリューションを準備します。
- クラスター アーキテクチャ: Service Fabric 正常性モデルのクラスター正常性ポリシーを確認します。
- ワークロード アーキテクチャ: アプリケーション監視ソリューションを準備します。
- ワークロード アーキテクチャ: Service Fabric 正常性モデルのアプリケーションとサービスの種類の正常性ポリシーを確認します。
- クラスターおよびワークロード アーキテクチャ: インフラストラクチャ監視ソリューションを準備します。
- クラスターおよびワークロード アーキテクチャ: 継続的インテグレーションとデプロイのためのビルドおよびリリース パイプラインを使用してクラスターを設計します。
推奨事項
次の表に記載されている推奨事項を参照して、オペレーショナル エクセレンスを実現するためにAzure Service Fabric 構成を最適化します。
| Azure Service Fabric に関する推奨事項 | ベネフィット |
|---|---|
| ワークロード アーキテクチャ: Application Insights を使用してワークロードを監視します。 | Application Insights は、Service Fabric を含む Azure プラットフォームと統合されます。 |
| クラスターおよびワークロード アーキテクチャ: クライアント証明書の有効期限を監視するプロセスを作成します。 | たとえば、Key Vault には、証明書の有効期間の x% が経過したときにメールを送信する機能が用意されています。 |
| クラスターおよびワークロード アーキテクチャ: 運用前クラスターの場合は、 Azure Chaos Studio を使用して、仮想マシン スケール セット インスタンスの障害に対するサービスの中断に対する訓練を行います。 | サービス中断シナリオの実践は、インフラストラクチャで危険にさらされている部分と、問題が発生した場合に最もそれを軽減できる方法を理解するのに役立ちます。 |
| クラスターおよびワークロード アーキテクチャ: Azure Monitor を使用して、クラスターとコンテナーのインフラストラクチャ イベントを監視します。 | Azure Monitor は、Service Fabric を含む Azure プラットフォームと適切に統合されます。 |
| クラスターおよびワークロード アーキテクチャ: 継続的インテグレーションとデプロイ ソリューションに Azure Pipelines を使用します。 | Azure Pipelines は、Service Fabric を含む Azure プラットフォームと適切に統合されます。 |
その他の推奨事項については、オペレーショナル エクセレンスの柱の原則を参照してください。
パフォーマンス効率
次のセクションでは、Azure Service Fabric に固有の構成の推奨事項とパフォーマンス効率について説明します。
Azure Service Fabric でのセキュリティについて検討するときは、"クラスターの操作" と "ワークロードの操作" を区別することが重要です。 クラスターのパフォーマンスは、Service Fabric クラスター管理者とそのリソース プロバイダーの間で共有される責任ですが、ワークロードのパフォーマンスは開発者の領域です。 Azure Service Fabric には、これらの両方のロールに関する考慮事項と推奨事項があります。
以下の設計チェックリストおよび推奨事項のリストでは各選択がクラスター アーキテクチャ、ワークロード アーキテクチャ、またはその両方に適用されるかどうかをコールアウト表示で示しています。
Azure Service Fabric で Service Fabric パフォーマンス カウンターを使用してワークロードのパフォーマンスの問題を軽減する方法の詳細については、「Azure Service Fabric での監視と診断のベスト プラクティス」を参照してください。
設計チェック リスト
- クラスター アーキテクチャ: パフォーマンスを向上させるため、Windows Defender から Service Fabric プロセスを除外します。
- クラスター アーキテクチャ: 適切な VM SKU を選択します。
- ワークロード アーキテクチャ: サービスに使用する プログラミング モデル 決定します。
- クラスターとワークロードのアーキテクチャ: 適切なマネージド ディスク層とサイズを使用します。
推奨事項
パフォーマンス効率のために Azure Service Fabric 構成を最適化するには、次の推奨事項を考慮してください。
| Azure Service Fabric に関する推奨事項 | ベネフィット |
|---|---|
| クラスター アーキテクチャ:パフォーマンスを向上させるため、Windows Defender から Service Fabric プロセスを除外します。 | Windows Server 2016 と 2019 には、Windows Defender ウイルス対策が既定でインストールされています。 Windows Defender によるパフォーマンスへの影響とリソース消費のオーバーヘッドを軽減するために、セキュリティ ポリシーでオープンソース ソフトウェアのプロセスとパスを除外することが許可されている場合は除外できます。 |
| クラスター アーキテクチャ: クラスターに自動スケールを使用することを検討します。 | 自動スケーリングにより、優れた弾力性が得られ、セカンダリ ノード タイプでオンデマンドでノードを追加または縮小できるようになります。 この自動化された柔軟な動作により、ワークロードを処理するノードの量を監視および最適化することで、管理のオーバーヘッドと潜在的なビジネスへの影響が軽減されます。 |
| クラスター アーキテクチャ: 高速ネットワークの使用を検討します。 | 高速ネットワークにより、データ パスからホストをバイパスするハイ パフォーマンス パスが有効になり、最も要求の厳しいネットワーク ワークロードの待機時間、ジッター、CPU 使用率が削減されます。 |
| クラスター アーキテクチャ: Azure Disk Encryption (ADE) の代わりにホストで暗号化を使用することを検討します。 | この暗号化方法は、データを暗号化して Azure Storage サービスに格納することにより、VM に関してすべての OS タイプとイメージ (カスタム イメージを含む) に対応することで、ADE を強化したものです。 |
| ワークロード アーキテクチャ: Service Fabric プログラミング モデルを確認し、サービスに最適なモデルを決定します。 | Service Fabric では、いくつかのプログラミング モデルがサポートされています。 それぞれに長所と短所があります。 使用可能なプログラミング モデルを知ることは、サービスの設計に最適な選択をするのに役立ちます。 |
| ワークロード アーキテクチャ: 適切な場合は、ワークロードに疎結合 microservices を活用します。 | マイクロサービスを使用すると、Service Fabric の機能を最大限に活用できます。 |
| ワークロード アーキテクチャ: 適切な場合は、ワークロードに イベントドリブン アーキテクチャ を活用します。 | イベント ドリブン アーキテクチャを使用すると、Service Fabric の機能を最大限に活用できます。 |
| ワークロード アーキテクチャ: 適切な場合は、ワークロードにバックグラウンド処理を活用します。 | バックグラウンド処理を使用すると、Service Fabric の機能を最大限に活用できます。 |
| クラスターおよびワークロード アーキテクチャ: Service Fabric でソリューションをスケーリングするさまざまな方法を確認します。 | スケーリングを使用して、ソリューションのリソースを最大限に活用することができます。 |
その他の推奨事項については、パフォーマンス効率の柱の原則を参照してください。
Azure Advisor の推奨事項
Azure Advisor は、ベスト プラクティスに従って Azure デプロイメントを最適化できるようにする、個人用に設定されたクラウド コンサルタントです。 Azure Service Fabric を使用する場合の信頼性、セキュリティ、コスト効率、パフォーマンス、オペレーショナル エクセレンスの向上に役立つ推奨事項を次にいくつか示します。
セキュリティ
- Service Fabric クラスターでは、ClusterProtectionLevel プロパティを
EncryptAndSignに設定する必要があります。 これはマネージド クラスターの既定値であり、変更できません。 標準クラスター: ClusterProtectionLevel がEncryptAndSignに設定してあることを確認します。 - Service Fabric クラスターでは、クライアント認証に Microsoft Entra ID のみを使用する必要があります。
その他のリソース
クラスターの作成および保守中に使用できるすべてのオプションの一覧については Azure Service Fabric マネージド クラスターの構成オプションに関する記事を参照してください。
ワークロードの開発方法のガイダンスについては、「Azure アプリケーション アーキテクチャの基礎」を確認してください。 Service Fabric はコンテナー ホスティング プラットフォームとしてのみ使用できますが、適切に設計されたワークロードを使用すると、Service Fabric の完全な機能を活用できます。
次のステップ
ARM テンプレートを使用して、または Azure portal から Service Fabric マネージド クラスターを作成する際は、次の推奨事項を参照してください。