運用環境の準備状況チェックリスト

  • [アーティクル]

お使いのアプリケーションとクラスターは、運用環境のトラフィックに対応する準備ができていますか。 アプリケーションとクラスターを実行してテストしたからといって、必ずしも運用環境に移行するための準備ができているというわけではありません。 次のチェックリストを検討して、アプリケーションとクラスターが円滑に実行されるようにします。 これらの項目すべてをチェック済みにすることを強くお勧めします。 当然ながら、特定の項目に代替ソリューションを使用することができます (独自の診断フレームワークなど)。

運用環境の前提条件

  1. Azure Service Fabric のベスト プラクティス:アプリケーションの設計、セキュリティ、ネットワーク、キャパシティ プランニングとスケール、コードとしてのインフラストラクチャ、および監視と診断。
  2. Reliable Actors プログラミング モデルを使用していて、セキュリティで保護されたサービス間通信が必要な場合は、FabricTransport 設定を構成します。
  3. 20 を超えるコアまたは 10 個を超えるノードを持つクラスターの場合は、システム サービス用に専用のプライマリ ノード タイプを作成します。 配置の制約を追加して、システム サービス用にプライマリ ノード タイプを予約します。
  4. プライマリ ノード タイプには D2v2 または上位の SKU を使用します。 少なくとも 50 GB のハード ディスク容量を持つ SKU を選択することをお勧めします。
  5. 運用環境クラスターは、セキュリティで保護されている必要があります。 セキュリティで保護されたクラスターの設定例については、このクラスター テンプレートを参照してください。 証明書の共通名を使用します。自己署名証明書は使用しないでください。
  6. コンテナーとサービスのリソース制約を追加して、ノード リソースの消費が 75% を超えないようにします。
  7. 持続性レベルを理解して設定します。 ステートフル ワークロードを実行しているノード タイプには、シルバー以上の持続性レベルを推奨し、以下のノードタイプでは必須とします。
  8. ノード タイプの信頼性レベルを理解して選択します。 シルバー以上の信頼性が推奨され、製品化には必要です。
  9. クラスターの容量の要件を特定するため、ワークロードのロード テストとスケール テストを実行します。
  10. アラートを使用して、サービスとアプリケーションが監視され、アプリケーション ログが生成され、格納されています。 例については、「Service Fabric アプリケーションにログ記録を追加する」と「Monitor containers with Azure Monitor logs (Azure Monitor ログによるコンテナーの監視)」を参照してください。
  11. クラスターがアラート (Azure Monitor ログなど) で監視されています。
  12. 基になる仮想マシン スケール セット インフラストラクチャが、アラート (Azure Monitor ログなど) で監視されています。
  13. ロックアウトされないように、クラスターには、常にプライマリ証明書とセカンダリ証明書があります。
  14. 開発、ステージング、および運用環境用に個別のクラスターを維持します。
  15. アプリケーションのアップグレードとクラスターのアップグレードは、最初に開発クラスターとステージング クラスターでテストされます。
  16. 自動アップグレードは、運用環境クラスターではオフにして、開発環境クラスターとステージング クラスターではオンにします (必要に応じてロールバック)。
  17. サービスの目標復旧時点 (RPO) を確立し、ディザスター リカバリー プロセスを設定してそれをテストします。
  18. クラスターの手動またはプログラムを使用したスケーリングを計画します。
  19. クラスター ノードへの修正プログラムの適用を計画します。
  20. 最新の変更が継続的にテストされるように、CI/CD パイプラインを確立します。 たとえば、Azure DevOps または Jenkins を使用して
  21. Fault Analysis Service と制御された混乱の誘発を使用して、負荷の下で開発クラスターとステージング クラスターをテストします。
  22. アプリケーションのスケーリングを計画します。

Service Fabric の Reliable Services または Reliable Actors プログラミング モデルを使用している場合は、次の項目をチェック済みにする必要があります。

  1. ローカル開発中にアプリケーションをアップグレードして、サービス コードが RunAsync メソッドでキャンセル トークンを受け入れること、およびカスタム通信リスナーを終了することを確認します。
  2. Reliable Collection を使用する場合は、よくある落とし穴を回避します。
  3. ロード テストの実行時に、.NET CLR メモリ パフォーマンス カウンターを監視して、高いレートのガベージ コレクションやランナウェイ ヒープの増加を確認します。
  4. Reliable Services と Reliable Actors のオフライン バックアップを保持して、復元プロセスをテストします。
  5. プライマリ NodeType 仮想マシン インスタンス数は理想的には、クラスターの信頼性レベルの最小と等しくする必要があります。レベルの最小を超えることが適切な場合の条件は、プライマリ NodeTypes 仮想マシン スケール セット SKU を垂直方向にスケーリングする場合の一時的なものなどです。

省略可能なベスト プラクティス

上記のリストは、運用に入るための前提条件ですが、次の項目も考慮する必要があります。

  1. 組み込みの正常性評価とレポートを拡張するため、Service Fabric の正常性モデルにプラグインします。
  2. リソース分散のためにアプリケーションとレポートの負荷を監視しているカスタム ウォッチドッグをデプロイします。

次のステップ