次の方法で共有

Azure でのミッション クリティカルなワークロードの運用手順

  • [アーティクル]

信頼性の高い効果的な操作は、可能な限り 自動化 の原則と コードとしての構成に基づいている必要があります。 このアプローチでは、DevOps プロセスへの多額のエンジニアリング投資が必要です。 自動化されたパイプラインは、アプリケーションとインフラストラクチャのコード成果物をデプロイするために使用されます。 このアプローチの利点には、最小限の手動操作手順で一貫した正確な運用結果が含まれます。

この設計領域では、効果的で一貫性のある運用手順を実装する方法について説明します。

重要

この記事は、 Azure Well-Architected Framework のミッション クリティカルなワークロード シリーズの 一部です。 このシリーズに慣れていない場合 は、「ミッション クリティカルなワークロードとは」から始めてお勧めします。

DevOps プロセス

DevOps は、 開発プロセスと運用プロセスとチームを 1 つのエンジニアリング機能に組み合わせます。 アプリケーションのライフサイクル全体が含まれており、自動化と DevOps ツールを使用して、迅速で効率的で信頼性の高い方法でデプロイ操作を実行します。 DevOps プロセスでは、継続的インテグレーションと継続的デリバリー (CI/CD) がサポートされ、維持され、継続的な改善の文化が促進されます。

ミッション クリティカルなアプリケーションの DevOps チームは、次のタスクを担当する必要があります。

  • CI/CD 自動化によるアプリケーションおよびインフラストラクチャ リソースの作成と管理。
  • アプリケーションの監視と監視。
  • アプリケーション コンポーネントの Azure ロールベースのアクセス制御 (RBAC) と ID 管理。
  • アプリケーション コンポーネントのネットワーク管理。
  • アプリケーション リソースのコスト管理。

DevSecOps は 、セキュリティ監視、アプリケーション監査、品質保証をアプリケーション ライフサイクル全体の開発と運用と統合することで、DevOps モデルを拡張します。 DevOps チームは、特定のリリース ステージまたはゲートではなく、開発ライフサイクル全体でセキュリティが確実に組み込まれるように、セキュリティに依存し、厳しく規制されたシナリオに必要です。

設計上の考慮事項

  • リリースと更新のプロセス。 アプリケーション コンポーネントや基になるインフラストラクチャを変更するための手動プロセスは避けてください。 手動プロセスは、一貫性のない結果につながる可能性があります。

  • 中央 IT チームへの依存関係。 DevOps プロセスは、一元化された関数にハード依存関係がある場合に適用するのが難しい場合があります。これらの依存関係によってエンド ツー エンドの操作が妨げられるためです。

  • ID とアクセスの管理。 DevOps チームは、データベース管理用の AppDataOps など、さまざまな技術的機能に対して詳細な Azure RBAC ロールを検討できます。 DevOps ロール間でゼロ トラスト モデルを適用します。

設計の推奨事項

  • 構成設定と更新プログラムをコードとして定義します。 キーやシークレットのローテーションやアクセス許可の管理などのタスクを含む、一貫したリリースおよび更新プロセスを有効にするには、コードを使用して変更管理を適用します。 組み込みの自動更新メカニズムではなく、スケジュールされたパイプラインの実行など、パイプラインで管理された更新プロセスを使用します。

  • アプリケーション リソースのインスタンス化または管理には、中央プロセスやプロビジョニング パイプラインを使用しないでください。 これにより、外部アプリケーションの依存関係と、ノイズの多い近隣シナリオに関連付けられているような追加のリスク ベクトルが導入されます。

    一元化されたプロビジョニング プロセスを使用する必要がある場合は、依存関係の可用性要件がミッション クリティカルな要件と完全に一致していることを確認します。 中央チームは、エンドツーエンドのアプリケーションの包括的な運用化を実現するために、透明性を提供する必要があります。

  • 各スプリント中のエンジニアリング能力の割合を、プラットフォームの基本的な改善を推進し、信頼性を強化することに専念します。 これらの機能強化には、容量の 20 ~ 40% を割り当てることをお勧めします。

  • コア設計原則に沿った一般的なエンジニアリング基準、参照アーキテクチャ、およびライブラリ を開発します。 Azure Policyを使用するポリシー駆動型アプローチを使用して、信頼性、セキュリティ、および操作に一貫したベースライン構成を適用します。

    また、一般的な設計パターンには、Azure ポリシーや Terraform リソースなどの一般的なエンジニアリング基準と関連する成果物を、organizationの広範なアプリケーション エコシステム内の他のワークロードにわたって使用することもできます。

  • 重要なアプリケーション環境でゼロ トラスト モデルを適用します。 Microsoft Entra Privileged Identity Managementなどのテクノロジを使用して、操作が一貫性があり、CI/CD プロセスまたは自動化された運用手順によってのみ実行されるようにします。

    チーム メンバーは、環境への永続的な書き込みアクセス権を持つべきではありません。 開発環境で例外を作成して、テストとデバッグを容易にすることができます。

  • 運用環境への Just-In-Time アクセスのための緊急プロセスを定義します。 認証プロバイダーで重大な問題が発生した場合に、重大なアカウントが存在することを確認します。

  • AIOps を使用して、運用手順とトリガーを継続的に改善することを検討してください。

アプリの操作

アプリケーションの設計とプラットフォームに関する推奨事項は、運用手順に影響します。 また、特に高可用性と復旧のために、さまざまな Azure サービスによって提供される運用機能もあります。

設計上の考慮事項

  • Azure サービスの組み込み操作。 Azure サービスは、組み込み (既定で有効) と構成可能なプラットフォーム機能 (ゾーン冗長や geo レプリケーションなど) を提供します。 アプリケーションの信頼性は、これらの操作によって異なります。 構成可能な特定の機能では、Azure Cosmos DB の複数書き込みデプロイ構成など、追加のコストが発生します。 絶対に必要な場合を除き、カスタム ソリューションの構築は避けてください。

  • 操作アクセスと実行時間。 ほとんどの必要な操作は、Azure Resource Manager API またはAzure portalを介して公開され、アクセスできます。 ただし、特定の運用ではサポート エンジニアの支援が必要です。 たとえば、Azure Cosmos DB データベースの定期的なバックアップからの復元、または削除されたリソースの復旧は、サポート ケースを介してAzure サポートエンジニアのみが実行できます。 この依存関係は、アプリケーションのダウンタイムに影響する可能性があります。 ステートレス リソースの場合は、サポート エンジニアが削除されたリソースの回復を試みるのを待つのではなく、再デプロイすることをお勧めします。

  • ポリシーの適用。 Azure Policyは、ミッション クリティカルなアプリケーションの一般的なエンジニアリング基準への準拠を確保するために、セキュリティと信頼性のベースラインを適用および監査するためのフレームワークを提供します。 具体的には、Azure Policyは Azure Resource Manager コントロール プレーンの重要な部分を形成し、承認されたユーザーが実行できるアクションを制限することで RBAC を補完します。 Azure Policyを使用して、プラットフォーム サービス間で重要なセキュリティと信頼性の規則を適用できます。

  • リソースの変更と削除。 Azure リソースをロックして、変更または削除されないようにすることができます。 ただし、ロックを使用すると、デプロイ パイプラインの管理オーバーヘッドが発生します。 ほとんどのリソースでは、リソース ロックではなく厳しい制限を持つ堅牢な RBAC プロセスをお勧めします。

設計の推奨事項

  • フェールオーバー手順を自動化します。 アクティブ/アクティブ モデルの場合は、正常性モデルと自動スケール操作を使用して、フェールオーバーの介入が必要ないことを確認します。 アクティブ/パッシブ モデルの場合は、フェールオーバー手順が自動化されているか、パイプライン内で少なくとも体系化されていることを確認します。

  • Azure ネイティブ自動スケーリングをサポートするサービスの使用に優先順位を付けます。 ネイティブ自動スケーリングをサポートしていないサービスの場合は、自動化された運用プロセスを使用してサービスをスケーリングします。 スケーラビリティを実現するには、複数のサービスでスケール ユニットを使用します。

  • バックアップと復元にはプラットフォームネイティブ機能を使用し、RTO/RPO とデータ保持の要件に合わせて調整します。 必要に応じて、長期的なバックアップ保有期間の戦略を定義します。

  • Azure Front Door で提供される機能と同様に、SSL 証明書の管理と更新に組み込みの機能を使用します。

  • 外部チームの場合は、支援が必要なリソースの回復プロセスを確立します。 たとえば、データ プラットフォームが誤って変更または削除された場合は、回復方法をよく理解し、回復プロセスを実施する必要があります。 同様に、使用停止のコンテナー イメージをレジストリで管理する手順を確立します。

  • 標準的なビジネス継続性の準備の一環として、運用以外のリソースとデータに対して、復旧操作を事前に実践します。

  • 重要なアラートを特定し、対象ユーザーとシステムを定義します。 適切な利害関係者に到達するための明確なチャネルを定義します。 アクション可能なアラートのみを送信して、ホワイト ノイズを回避し、運用上の利害関係者がアラートを無視したり、重要な情報を見逃したりしないようにします。 継続的な改善を実装してアラートを最適化し、観察されたホワイト ノイズを削除します。

  • ポリシー駆動型のガバナンスとAzure Policyを適用して、すべてのアプリケーション サービスで運用機能と信頼性の高い構成基準を適切に使用できるようにします。

  • 一時的なリージョン リソースに対してリソース ロックを使用しないようにします。 代わりに、RBAC と CI/CD パイプラインを適切に使用して運用更新を制御します。 リソース ロックを適用して、有効期間の長いグローバル リソースが削除されないようにすることができます。

更新管理

ミッション クリティカルな設計は、エフェメラルステートレス アプリケーション リソースの原則を強く支持します。 この原則を適用する場合は、通常、新しいデプロイと標準の配信パイプラインを使用して更新を実行できます。

設計上の考慮事項

  • Azure ロードマップとの連携。 プラットフォーム リソースとランタイムの依存関係が定期的に更新されるように、ワークロードを Azure ロードマップに合わせます。

  • 更新プログラムの自動検出。 更新プログラムを監視して自動的に検出するプロセスを設定します。 GitHub Dependabot などのツールを使用します。

  • テストと検証。 リリース前に、運用コンテキストでパッケージ、コンポーネント、依存関係の新しいバージョンをテストして検証します。 新しいバージョンには破壊的変更が含まれている可能性があります。

  • ランタイムの依存関係。 ランタイムの依存関係は、アプリケーションに対する他の変更と同様に扱います。 以前のバージョンでは、セキュリティの脆弱性が発生し、パフォーマンスに悪影響を及ぼす可能性があります。 アプリケーション ランタイム環境を監視し、最新の状態に保ちます。

  • コンポーネントの衛生とハウスキーピング。 使用されていないリソースを使用停止または削除します。 たとえば、コンテナー レジストリを監視し、使用していない古いイメージ バージョンを削除します。

設計の推奨事項

  • これらのリソースを監視し、最新の状態に保ちます。

    • アプリケーション ホスティング プラットフォーム。 たとえば、特に古いバージョンのサポートが維持されない場合は、Azure Kubernetes Service (AKS) の Kubernetes バージョンを定期的に更新する必要があります。 また、cert-manager や Azure Key Vault CSI など、Kubernetes で実行されるコンポーネントを更新し、AKS の Kubernetes バージョンに合わせる必要があります。
    • 外部ライブラリと SDK (.NET、Java、Python)。
    • Terraform プロバイダー。

  • コンポーネントを更新するための手動操作の変更は避けてください。 緊急時にのみ手動変更を使用することを検討してください。 ドリフトや問題の繰り返しを回避するために、手動による変更をソース リポジトリに再調整するプロセスがあることを確認します。

  • Azure Container Registryから古いバージョンのイメージを削除するための自動化された手順を確立します。

シークレットの管理

キー、シークレット、証明書の有効期限は、アプリケーションの停止の一般的な原因です。 ミッション クリティカルなアプリケーションのシークレット管理は、必要なセキュリティを提供し、最大限の信頼性要件に合わせて適切なレベルの可用性を提供する必要があります。 マネージド サービスを使用するか、更新管理の一部としてキー、シークレット、証明書のローテーションを定期的に実行し、コードと構成の変更にプロセスを適用する必要があります。

多くの Azure サービスでは、接続文字列やキーに依存するのではなく、Microsoft Entra認証がサポートされています。 Microsoft Entra ID を使用すると、運用上のオーバーヘッドが大幅に削減されます。 シークレット管理ソリューションを使用する場合は、他のサービスと統合し、ゾーンとリージョンの冗長性をサポートし、認証と承認のためにMicrosoft Entra ID との統合を提供する必要があります。 Key Vaultは、これらの機能を提供します。

設計上の考慮事項

シークレット管理には、3 つの一般的な方法があります。 各方法では、シークレット ストアからシークレットを読み取り、異なるタイミングでアプリケーションに挿入します。

  • デプロイ時の取得。 この方法の利点は、シークレット管理ソリューションは、その後に直接の依存関係がないため、デプロイ時にのみ使用できる必要があることです。 たとえば、Kubernetes デプロイまたは Kubernetes シークレットへの環境変数としてのシークレットの挿入などです。

    デプロイ サービス プリンシパルのみがシークレットにアクセスできる必要があります。これにより、シークレット管理システム内の RBAC アクセス許可が簡略化されます。

    ただし、このアプローチには欠点があります。 DevOps ツールでは、サービス プリンシパルのアクセスの制御と、取得したシークレットの保護に関するアプリケーションでの RBAC の複雑さが導入されています。 また、シークレット管理ソリューションのセキュリティ上の利点は適用されません。このアプローチは、アプリケーション プラットフォームでのアクセス制御にのみ依存するためです。

    シークレットの更新またはローテーションを実装するには、完全な再デプロイを実行する必要があります。

  • アプリケーションスタートアップの取得。 この方法では、シークレットが取得され、アプリケーションの起動時に挿入されます。 利点は、シークレットを簡単に更新またはローテーションできることです。 アプリケーション プラットフォームにシークレットを格納する必要はありません。 最新の値をフェッチするには、アプリケーションの再起動が必要です。

    一般的なストレージの選択肢としては、Azure Key Vault Provider for Secrets Store CSI Driver と akv2k8s などがあります。 ネイティブ Azure ソリューション (参照されているアプリ設定Key Vault) も使用できます。

    この方法の欠点は、シークレット管理ソリューションにランタイム依存関係を作成することです。 シークレット管理ソリューションで障害が発生した場合、既に実行されているアプリケーション コンポーネントが要求の処理を続行できる 可能性があります 。 再起動またはスケールアウト操作を行うと、エラーが発生する可能性があります。

  • ランタイムの取得。 アプリケーション プラットフォームでもシークレットにアクセスできないため、実行時にアプリケーション自体からシークレットを取得することが最も安全な方法です。 アプリケーションは、シークレット管理システムに対して自身を認証する必要があります。

    ただし、この方法では、アプリケーション コンポーネントには、直接の依存関係とシークレット管理システムへの接続が必要です。 これにより、コンポーネントを個別にテストするのが難しくなり、通常は SDK の使用が必要になります。

設計の推奨事項

  • 可能な場合は、接続文字列やキーを使用する代わりに、Microsoft Entra認証を使用してサービスに接続します。 アプリケーション プラットフォームにシークレットを格納する必要がないように、この認証方法を Azure マネージド ID と共に使用します。

  • Key Vaultの有効期限設定を利用し、今後の有効期限のアラートを構成します。 標準のリリース プロセスを使用して、すべてのキー、シークレット、および証明書の更新を実行します。

  • リージョン スタンプの一部としてKey Vault インスタンスをデプロイして、単一のデプロイ スタンプに障害が発生した場合の潜在的な影響を軽減します。 グローバル リソースには別のインスタンスを使用します。 これらのリソースの詳細については、ミッション クリティカルなワークロードの一般的な アーキテクチャ パターン に関するページを参照してください。

  • サービス プリンシパルの資格情報または API キーを管理する必要がないようにするには、サービス プリンシパルの代わりにマネージド ID を使用して、可能な限りKey Vaultにアクセスします。

  • 実行時に承認エラーが発生したときにシークレットが確実に再取得されるように、コーディング パターンを実装します。

  • ソリューション内で定期的に実行される完全に自動化されたキーローテーション プロセスを適用します。

  • Azure Key Vault のキーの有効期限に近い通知を使用して、今後の有効期限に関するアラートを取得します。

VM を使用する場合の IaaS 固有の考慮事項

IaaS VM を使用する必要がある場合は、このドキュメントで前述した手順とプラクティスの一部が異なる場合があります。 VM を使用すると、構成オプション、オペレーティング システム、ドライバー アクセス、低レベルのオペレーティング システム アクセス、インストールできるソフトウェアの種類の柔軟性が向上します。 欠点は、運用コストの増加と、PaaS サービスを使用するときに通常クラウド プロバイダーによって実行されるタスクの責任です。

設計上の考慮事項

  • 個々の VM では、高可用性、ゾーン冗長性、または geo 冗長性は提供されません。
  • 個々の VM は、デプロイ後に自動的に更新されません。 たとえば、Windows Server 2019 に展開された SQL Server 2019 は、新しいリリースに自動的に更新されません。
  • VM で実行されているサービスをコードとしてインフラストラクチャ経由でデプロイおよび構成する場合は、特別な処理と追加のツールが必要です。
  • Azure では、そのプラットフォームが定期的に更新されます。 これらの更新では、VM の再起動が必要になる場合があります。 再起動が必要な更新は、通常、事前に発表されます。 「Azure での仮想マシンのメンテナンス」と「計画メンテナンス通知の処理」を参照してください。

設計の推奨事項

  • VM での手動操作を回避し、変更をデプロイしてロールアウトするための適切なプロセスを実装します。

    • Azure Resource Manager (ARM) テンプレート、Bicep、Terraform、その他のソリューションなどのコードとしてのインフラストラクチャ ソリューションを使用して、Azure リソースのプロビジョニングを自動化します。

  • VM、更新プログラム、バックアップと回復のデプロイのための運用プロセスが適切に実施され、適切にテストされていることを確認します。 回復性をテストするには、アプリケーションに障害を挿入し、障害をメモして、それらのエラーを軽減します。

  • 新しいバージョンが正しく機能しない場合は、最後の正常な状態にロールバックする戦略が整っていることを確認します。

  • ステートフル ワークロードの頻繁なバックアップを作成し、バックアップ タスクが効果的に機能することを確認し、失敗したバックアップ プロセスのアラートを実装します。

  • VM を監視し、障害を検出します。 監視用の生データは、さまざまなソースから取得できます。 問題の原因を分析します。

  • スケジュールされたバックアップが想定どおりに実行され、必要に応じて定期的なバックアップが作成されていることを確認します。 バックアップ センターを使用して分析情報を取得できます。

  • VM ではなくVirtual Machine Scale Setsの使用に優先順位を付けて、スケール、自動スケーリング、ゾーン冗長性などの機能を有効にします。

  • 維持する必要があるカスタム イメージではなく、Azure Marketplaceからの標準イメージの使用に優先順位を付けます。

  • Azure VM Image Builder またはその他のツールを使用して、必要に応じてカスタマイズされたイメージのビルドおよびメンテナンス プロセスを自動化します。

これらの特定の推奨事項を超えて、ミッション クリティカルなアプリケーション シナリオの運用手順のベスト プラクティスを適宜適用します。

次のステップ

ミッション クリティカルなアプリケーション シナリオのアーキテクチャ パターンを確認します。

アーキテクチャ パターン