次の方法で共有

Azure Service Fabric の Well-Architected Framework の観点

  • [アーティクル]

Azure Service Fabric は、スケーラブルで信頼性の高いマイクロサービスとコンテナーのパッケージ化、デプロイ、管理を容易にする分散システム プラットフォームです。 これらのリソースは、クラスターと呼ばれる、ネットワークに接続された仮想マシンまたは物理マシンのセットにデプロイされます。

この記事では、アーキテクトとして、コンピューティング デシジョン ツリー を確認し、ワークロードのコンピューティング プラットフォームとして Service Fabric を選択していることを前提としています。 この記事のガイダンスでは、Well-Architected Framework の柱の原則にマップされるアーキテクチャに関する推奨事項を示します。

重要

このガイドの使用方法

各セクションには、設計チェックリスト があり、テクノロジ スコープにローカライズされた設計戦略と共に、関心のあるアーキテクチャ領域が示されています。

また、これらの戦略の具体化に役立つテクノロジ機能の推奨事項も含まれています。 推奨事項は、Azure Service Fabric とその依存関係で使用できるすべての構成の完全な一覧を表すわけではありません。 代わりに、設計パースペクティブにマップされた主要な推奨事項が一覧表示されます。 推奨事項を使用して概念実証を構築するか、既存の環境を最適化します。

主要な推奨事項を示す基本的なアーキテクチャ: Azure Service Fabric でのマイクロサービス アーキテクチャの。

技術範囲

このレビューでは、次の Azure リソースに関する相互に関連する決定に焦点を当てます。

  • Service Fabric

手記

このサービス ガイドは、Virtual Machines とスケール セット サービス ガイドに記載されているガイダンスに基づいています。 Service Fabric ノードは VM スケール セットによってサポートされるため、Service Fabric ノードのコンピューティング バックエンドの運用に関する推奨事項については、そのサービス ガイドを参照してください。

Azure Service Fabric でアーキテクチャに関する考慮事項と構成に関する推奨事項について説明するときは、クラスター とワークロード 区別することが重要です。 クラスターの構成は、Service Fabric クラスター管理者とそのリソース プロバイダーの間で共有される責任ですが、ワークロード構成は開発者のドメインです。 Azure Service Fabric には、これらの両方のロールに関する考慮事項と推奨事項があります。

設計チェックリストの と推奨事項の一覧 では、各選択がクラスター アーキテクチャ、ワークロード アーキテクチャ、またはその両方に適用されるかどうかを示すコールアウトが行われます。

確実

信頼性の柱の目的は、十分な回復性を構築 し、障害から迅速に回復する機能をして継続的な機能を提供することです。

信頼性設計の原則、個々のコンポーネント、システム フロー、およびシステム全体に適用される高度な設計戦略を提供します。

設計チェックリスト

信頼性 の設計レビュー チェックリストに基づいて、設計戦略を開始します。 [オファリング固有の側面] を念頭に置いて、ビジネス要件との関連性を判断します。 必要に応じて、より多くのアプローチを含むように戦略を拡張します。

  • (クラスター)ワークロードの全体的な信頼性ターゲット メトリックに基づいて、クラスターの適切な 信頼性レベル を決定します。 識別するクラスターの信頼性レベルによって、プライマリ ノード タイプにデプロイするノードの最小数が決まります。 これらの決定の詳細については、容量計画のドキュメント を参照してください。
  • (クラスター)重要なワークロードの場合は、Service Fabric クラスターに Availability Zones を使用することを検討してください。
  • (クラスター)運用環境のシナリオでは、Silver 持続性レベル (5 VM) 以上の Standard マネージド クラスター SKU を使用します。 この SKU は、非運用環境のシナリオで使用する必要がある Basic SKU よりも高い信頼性機能を提供します。
  • (クラスター)ワークロード用の追加のセカンダリ ノード タイプを作成して、さまざまなワークロードの種類を分離します。 これにより、バックエンド サービスからフロントエンド サービスを分離し、それらのサービスを個別に管理およびスケーリングできます。 各 ノード タイプは、独自のスケール セットによってサポートされます。

推奨 事項

勧告 利点
(クラスター) API Management (APIM) は Service Fabric と直接統合できます。 これを使用して、クラスターでホストされている API のクロスカット機能を公開してオフロードすることを検討してください。 APIM は、Service Fabric クラスターにデプロイされた API を安全に発行、管理、監視するのに役立つ機能豊富なアプリケーション ゲートウェイです。
(ワークロード) ステートフル ワークロードシナリオの場合は、Reliable Servicesの使用を検討してください。 Reliable Services モデルを使用すると、システム障害やネットワークの問題が発生した場合や、サービス自体が故障した場合に、サービスを稼働状態に保ちます。 ステートフル サービスの場合、誤動作が発生しても状態は保持されます。

安全

セキュリティの柱の目的は、ワークロードに対する機密性、整合性、可用性の保証を提供することです。

セキュリティ設計の原則、Service Fabric の技術設計にアプローチを適用することで、これらの目標を達成するための高度な設計戦略を提供します。

設計チェックリスト

セキュリティ の設計レビューチェックリストに基づいて設計戦略を作成します。

  • (クラスターとワークロード)Service Fabric 製品のセキュリティ ガイダンスについて理解を深めてください。 セキュリティのベスト プラクティス、クラスター のセキュリティ シナリオ、Service Fabric アプリケーションとサービス セキュリティの を参照してください。
  • (クラスター)NSG を構成して、サブネットとノードの種類の間のトラフィック フローを制限することで、ネットワークのセグメント化と制御を適用します。
  • (クラスター)ネイティブ ツールを使用して、アプリケーション シークレットとクライアント証明書を安全に管理します。 アプリケーション シークレットは Service Fabric シークレット ストアで管理する必要があり、証明書は Key Vault で管理する必要があります。
  • (クラスター)独自のロード バランサーを導入することを検討してください。これにより、内部ロード バランサーを使用し、ノードの種類ごとに異なるロード バランサーと NSG を定義できます。
  • (クラスター)Microsoft Entra 統合を有効にして、ユーザーが Entra 資格情報で認証できるようにすることで、クラスターへのアクセスを安全に制御できます。 または、クラスター クライアント証明書と管理者証明書を使用することもできます。 Service Fabric Explorer のユーザー間でクラスター クライアント証明書を配布しないでください。
  • (クラスターとワークロード)クライアント証明書の有効期限を監視するプロセスを作成します。
  • (クラスターとワークロード)開発、ステージング、運用のために個別のクラスターを維持します。 運用環境では通常、非運用環境よりも厳密なセキュリティ制御が必要であり、環境を相互に分離すると、1 つの環境が侵害された場合に一層のセキュリティが追加されます。

推奨 事項

勧告 特長
(クラスター)アプリケーションのデプロイとワークロード用に 正しいポートが開かれていることを確認します。 この構成により、Service Fabric リソースと残りのワークロード間の通信がセキュリティで保護されます。
(クラスター)Service Fabric シークレット ストアを使用してシークレットを配布する場合は、別の データ暗号化証明書 を使用して値を暗号化します。 個別の暗号化証明書を使用すると、証明書間の分離が確保され、単一障害点のリスクが軽減され、より詳細なアクセス制御が可能になります。
(クラスター)アクセス制御リスト (ACL) を Service Fabric クラスターのクライアント証明書に適用します。 ACL を使用すると、追加レベルの認証が提供され、証明書にアクセスできるユーザーをより細かく制御できます。
(クラスター)リソース要求と制限 を使用して、クラスター内のノード全体のリソース使用量を管理します。 リソース制限を適用すると、1 つのサービスで消費されるリソースが多くなりすぎず、他のサービスが不足しないようにすることができます。
(ワークロード)Service Fabric アプリケーションにクライアント証明書を含めます。 アプリケーションで認証にクライアント証明書を使用すると、クラスターレベルとワークロード レベルの両方でセキュリティを確保できます。
(ワークロード)マネージド ID を使用して、Azure リソースService Fabric アプリケーションを認証します。 マネージド ID を使用すると、開発者ワークステーションやソース管理でローカルに保存することなく、さまざまなサービスに対する認証のためにコード内の資格情報を安全に管理できます。
(クラスターとワークロード)信頼されていないアプリケーションをホストする場合は、適用可能な最も強力なサンドボックス テクノロジを使用し、Service Fabric ランタイムへのアクセスを削除し、他の Service Fabric のベスト プラクティスに従。 提供されているベスト プラクティスに従うと、信頼されたアプリケーションと検証済みのアプリケーションのみが重要なコンポーネントとの対話を許可され、信頼されていないアプリケーションに脆弱性や悪意のあるコードがクラスターの通常の操作に与える影響を制限できます。

コストの最適化

コストの最適化では、支出パターンの検出 、重要な領域への投資の優先順位付け、ビジネス要件を満たしながら組織の予算を満たすために他の での最適化に重点を置いています。

コスト最適化の設計原則、Service Fabric とその環境に関連する技術的な設計において、これらの目標を達成し、必要に応じてトレードオフを行う高度な設計戦略を提供します。

設計チェックリスト

投資のコスト最適化 の 設計レビュー チェックリストに基づいて、設計戦略を開始します。 ワークロードの設計を、そのワークロードに割り当てられた予算に合わせて微調整します。 設計では、適切な Azure 機能を使用し、投資を監視し、時間の経過と同時に最適化する機会を見つける必要があります。

  • (ワークロードとクラスター)Azure 料金計算ツールを使用して、インテリアル コストを見積もります。 Service Fabric クラスターの作成時に選択したコンピューティング インスタンス、ストレージ、ネットワーク リソース、および IP アドレスに対してのみ課金されます。 Service Fabric 自体によって提供されるサービスに対する料金はかかりません。 コスト モデリングの開始に役立つには、アプリケーション計画 コスト計算プロセスの例を参照してください。
  • (クラスター)適切な VM SKU を選択します。 ワークロードの特性に基づいて VM を選択します。 ワークロードで、CPU 負荷が高いか、割り込み可能なプロセスが実行されるかを考えます。
  • (クラスター)適切なクラスター SKU を選択します。 運用環境には Standard を使用し、非運用環境では Basic を使用します。そうでない場合は、説得力のある理由がない限り使用してください。 各環境で適切なノードの種類とサイズを使用します。
  • (クラスターとワークロード)適切なマネージド ディスクの階層とサイズを選択します。 ディスク ストレージの については、WAFサービス ガイドを確認してください。 不要なリソースの支払いを回避するために、一時ディスク オファリングで VM SKU を使用しないようにします。

推奨 事項

勧告 利点
(クラスター) ステートフル性を維持する必要がない場合は、一時ディスクサポート のある VM SKU を選択することを検討してください。 支払っているリソースを最大限に活用します。 マネージド ディスクの代わりに一時ディスクを使用すると、ステートレス ワークロードのコストを削減できます。
(クラスターとワークロード) VM SKU の選択 をワークロードの要件 に合わせます。 要件を満たすために、適切なノードタイプ がスケールセットでホストされていることを確認します。 選択内容をワークロードの需要に合わせることにより、不要な高価な VM SKU の支払いを回避できます。
(クラスターとワークロード)ディスクの種類 選択 ワークロードの要件に合わせます。 適切なマネージド ディスクの種類を選択すると、不要なコストの高い種類に対する支払いを回避できます。

オペレーショナル エクセレンス

オペレーショナル エクセレンスは主に、開発プラクティス、可観測性、リリース管理の手順に重点を置いています。

オペレーショナル エクセレンス設計原則、ワークロードの運用要件に対してこれらの目標を達成するための高度な設計戦略を提供します。

設計チェックリスト

Service Fabric に関連する監視、テスト、デプロイのプロセスを定義するためのオペレーショナル エクセレンス の 設計レビュー チェックリストに基づいて、設計戦略を開始します。

  • (クラスターとワークロード)クラスター、関連インフラストラクチャ、アプリケーション自体を含む Service Fabric コンポーネントを監視およびアラート プラットフォームに統合します。 詳細なガイダンスについては、監視のベスト プラクティス 記事を参照してください。
  • (クラスターとワークロード)Service Fabric 正常性モデル を使用して、ソリューションの正常性を継続的に監視します。 このツールで、全体的なワークロード正常性モデルを補完します。
  • (クラスターとワークロード)クライアント証明書の有効期限を監視するプロセスを作成します。 たとえば、Key Vault には、証明書の有効期間の x% が経過したときに電子メールを送信する機能が用意されています。
  • (クラスターとワークロード)継続的インテグレーションと継続的デプロイのプラクティスを使用して、クラスターのデプロイを管理します。 Azure Pipelines や Github Actions などの意図的に構築されたツールを使用して CI/CD パイプラインを管理します。これにより、適切なソース管理戦略を使用して、すべての環境のすべてのワークロード デプロイを一元的に管理できます。

推奨 事項

勧告 特長
(ワークロード)Application Insights を使用して、ワークロードのを監視します。 Application Insights は、ライブ Web アプリケーションの包括的なアプリケーション パフォーマンス監視 (APM) を提供し、アプリケーション テレメトリを収集して分析し、アプリケーションの正常性とパフォーマンスの監視を強化します。
(クラスターとワークロード)Azure Monitor を使用して、クラスターとコンテナーインフラストラクチャのイベント監視します。 Azure Monitor には包括的な監視と診断機能が用意されており、アプリケーションや Azure インフラストラクチャからログとメトリックを収集して分析できます。 Azure Monitor は、Service Fabric を含む Azure プラットフォームと適切に統合されます。
(クラスター)健康モデルの一環として の適切なクラスター健康ポリシー を実装します。 ポリシーを使用すると、クラスターの正常性の観点からエラーを解釈する方法をカスタマイズできます。 たとえば、クラスターがエラーと見なされる前に異常になる可能性があるノードの最大許容パーセンテージを設定できます。
(クラスター) 正常性モデリングの一環として、適切なアプリケーションとサービス タイプの正常性ポリシーを実装します。 アプリケーションの正常性ポリシー は、アプリケーションとその子に関して、イベントの評価方法および子の状態の集計方法を記述します。 正常性レポートがある場合や、正常性状態が警告またはエラーになっている子がある場合、Service Fabric はエンティティを異常と見なします。
(クラスターとワークロード) テスト戦略の一環として、Azure Chaos Studio を使用してソリューションに不具合を挿入します。 ソリューションに誤動作を意図的に導入すると、潜在的な障害点を特定し、インシデント対応策を実践するのに役立ちます。
(クラスターとワークロード)継続的インテグレーションとデプロイ (CI/CD) ソリューション には、Azure Pipelines を使用します。 Azure Pipelines などの CI/CD ソリューションを使用すると、デプロイを効率的かつ一貫して安全に管理できます。 Azure Pipelines には、Service Fabric デプロイのネイティブ サポートがあります。

パフォーマンス効率

パフォーマンス効率とは、容量の管理により、負荷が増加してもユーザー エクスペリエンスを維持することです。 この戦略には、リソースのスケーリング、潜在的なボトルネックの特定と最適化、ピーク パフォーマンスの最適化が含まれます。

パフォーマンス効率設計の原則、予想される使用に対してこれらの容量目標を達成するための高度な設計戦略を提供します。

設計チェックリスト

パフォーマンス効率 の設計レビュー チェックリストに基づいて、設計戦略を開始します。 Service Fabric の主要業績評価指標に基づくベースラインを定義します。

  • (クラスター)ワークロードで必要に応じて、パフォーマンスの最適化と機能の強化を活用します。 基になるコンピューティング プラットフォームに関連する推奨事項については、VM サービス ガイドの を参照してください。
  • (クラスター)未使用の容量に対して不要な費用を発生させることなく、パフォーマンス要件を満たす VM とディスク サイズをデプロイします。 将来の成長計画に合わせて容量を簡単に追加できることを確認します。
  • (ワークロード)Service Fabric でサポートされているプログラミング モデルを理解し、ワークロード要件に最適なモデルを選択します。 各プログラミング モデルには固有の長所と短所があり、特定のワークロード要件は、他のモデルよりも優れた 1 つのモデルと一致する可能性があります。
  • (ワークロード)確立されたクラウド アーキテクチャ パターンを使用して、ワークロードを設計します。 Microsservices、イベント ドリブン、および バックグラウンド処理 アーキテクチャ パターンはすべて、Service Fabric アプリケーション設計に適しています。

勧告

勧告 特長
(クラスター) セキュリティ ポリシーでオープンソース ソフトウェアのプロセスとパスを除外できる場合は、Windows VM で実行されている Service Fabric プロセスを Windows Defender から除外します。 Service Fabric プロセスを除外すると、Windows Defender によって発生するパフォーマンスへの影響とリソース消費のオーバーヘッドが軽減されます
(クラスター)クラスター 自動スケール を使用して、セカンダリ ノード タイプでオンデマンドでノードを追加または削減することを検討してください。 自動スケールにより、ワークロードにサービスを提供するノードの量を監視および最適化することで、管理オーバーヘッドと潜在的なビジネスへの影響が軽減されます。
(クラスター)高速ネットワーク 使用することを検討してください。 高速ネットワークにより、データ パスからホストをバイパスする高パフォーマンス パスが可能になり、最も要求の厳しいネットワーク ワークロードの待機時間、ジッター、CPU 使用率が削減されます。
(クラスター)Azure Disk Encryption (ADE) ではなく、ホスト で 暗号化を使用することを検討してください。 ホストでの暗号化は、Azure Storage サービス内のデータを暗号化することで、VM のすべての OS の種類とイメージ (カスタム イメージを含む) をサポートすることで、ADE で向上します。
(ワークロード)ワークロードに最適な Service Fabric プログラミング モデル 実装します。 適切なプログラミング モデルを選択すると、状態管理、コンカレンシー、既存のコードベースの再利用などのワークロード要件をサポートする組み込み機能を利用できます。 また、これらの標準に合ったプログラミング モデルを選択することで、デプロイ標準が確実に維持されるようにすることもできます。
(クラスターとワークロード)ビジネス要件を満たすためにスケーリングを実装します。 ワークロードに適したスケーリング メカニズムを見つけます。. スケーリングを使用して、ソリューションの最大リソース使用率を有効にすることができます。

Azure ポリシー

Azure には、Service Fabric とその依存関係に関連する広範な組み込みポリシー セットが用意されています。 上記の推奨事項の一部は、Azure Policy を使用して監査できます。 たとえば、次のことを確認できます。

  • Service Fabric クラスターはゾーン冗長として構成されます。
  • Service Fabric クラスターには、ClusterProtectionLevel プロパティが EncryptAndSignに設定されています。
  • Service Fabric クラスターは、クライアント認証にのみ Azure Active Directory を使用するように構成されます。

包括的なガバナンスについては、Service Fabric および [クラウド インフラストラクチャ領域] のセキュリティに影響を与える可能性があるその他のポリシーの Azure Policy 組み込み定義 を確認します。

Azure Advisor の推奨事項

Azure Advisor は、Azure デプロイを最適化するためのベスト プラクティスに従うのに役立つ、パーソナライズされたクラウド コンサルタントです。 Service Fabric の信頼性、セキュリティ、コスト効率、パフォーマンス、オペレーショナル エクセレンスの向上に役立つ推奨事項をいくつか次に示します。

関連コンテンツ

クラスターの作成と保守中に使用できるすべてのオプションの一覧については、Azure Service Fabric マネージド クラスター構成オプションの に関する記事を参照してください。

ワークロードを開発する方法のガイダンスについては、Azure アプリケーション アーキテクチャの基礎 を確認します。 Service Fabric はコンテナー ホスティング プラットフォームとしてのみ使用できますが、適切に設計されたワークロードを使用すると、Service Fabric の完全な機能が活用されます。

ARM テンプレートまたは Azure portal を使用して Service Fabric マネージド クラスターを作成するときは、次の推奨事項を使用します。