次の方法で共有


Azure でのミッション クリティカルなアーキテクチャ

Azure Front Door
Azure Container Registry
Azure Kubernetes Service (AKS)
Azure ロールベースのアクセス制御

この記事シリーズでは、Azure でミッション クリティカルなワークロードを設計するためのガイダンスを提供します。 信頼性と運用上の有効性を最大化するために、クラウドネイティブの機能に優先順位を付けます。 これは、 ミッション クリティカルなワークロードWell-Architected 設計手法を適用します。

主要な設計戦略

障害から復旧する機能、リージョンの可用性、デプロイの有効性、セキュリティなど、多くの要因がアプリケーションの信頼性に影響を与える可能性があります。 これらの要因に対処し、ターゲットの信頼性レベルが確実に達成されるように、一連の包括的な設計戦略を適用します。

ミッション クリティカルなワークロードは、通常、99.99% 以上の SLO をターゲットとします。これは、52 分 35 秒の年間ダウンタイムに対応します。 したがって、すべての包括的な設計上の決定は、このターゲット SLO を達成することを目的としています。

  • レイヤーの冗長性

    • アクティブ/アクティブ モデル内の複数のリージョンにデプロイします。 アプリケーションは、アクティブなユーザー トラフィックを処理する 2 つ以上の Azure リージョンに分散されます。

    • すべての検討対象サービス に可用性ゾーン を利用して、1 つの Azure リージョン内の可用性を最大化し、リージョン内の物理的に分離されたデータ センターにコンポーネントを分散します。

    • グローバル分散をサポートするリソースを選択します。

      Well-Architected ミッション クリティカルなワークロード: グローバル分散を参照してください。

  • デプロイ スタンプ

    需要の変化に対応するために、リソースの論理セットを個別にプロビジョニングできる スケール ユニット としてリージョン スタンプをデプロイします。 また、各スタンプは、個別にスケールインおよびスケールアウトできるフロントエンド API やバックグラウンド プロセッサなど、複数の入れ子になったスケール ユニットも適用します。

    ミッション クリティカルなワークロードWell-Architected スケール ユニット アーキテクチャを参照してください。

  • 信頼性が高く反復可能なデプロイ

    • Terraform などのテクノロジを使用して 、コードとしてのインフラストラクチャ (IaC) の原則 を適用して、インフラストラクチャ コンポーネントのバージョン管理と標準化された運用アプローチを提供します。

    • ダウンタイムゼロの青/緑のデプロイ パイプラインを実装します。 継続的な検証が適用された青/緑のデプロイを使用して、スタンプを 1 つの運用ユニットとしてデプロイするには、ビルドパイプラインとリリース パイプラインを完全に自動化する必要があります。

    • 運用環境と運用前環境で同じデプロイ パイプライン コードを使用して、すべての検討対象環境に環境 の整合性 を適用します。 これにより、環境間のデプロイとプロセスのバリエーションに関連するリスクが排除されます。

    • アプリケーション コードと基になるインフラストラクチャの両方の正常性を完全に検証するために、同期された読み込みと混乱のテストを含む DevOps プロセスの一部として自動テストを統合することで、 継続的な検証 を行います。

    Well-Architected ミッション クリティカルなワークロード: デプロイとテストを参照してください。

  • 運用上の情報

    • 監視データ用のフェデレーション ワークスペースがある。 グローバル リソースとリージョン リソースの監視データは、個別に格納されます。 単一障害点を回避するために、一元化された監視ストアは推奨されません。 ワークスペース間のクエリは、統合されたデータ シンクと操作用の 1 つのウィンドウを実現するために使用されます。

    • コンテキスト化のために、アプリケーションの正常性を信号モデルにマップする 階層化された正常性 モデルを構築します。 正常性スコアは、個々のコンポーネントごとに計算され、ユーザー フロー レベルで集計され、アプリケーションの正常性を定量化するための係数として、パフォーマンスなどの主要な機能以外の要件と組み合わされます。

      ミッション クリティカルなワークロードWell-Architected:正常性モデリングを参照してください。

設計領域

ミッション クリティカルなアーキテクチャを定義する際の推奨事項とベスト プラクティスのガイダンスについては、これらの設計領域を確認することをお勧めします。

デザイン領域 説明
アプリケーション プラットフォーム 障害が発生する可能性がある場合のインフラストラクチャの選択と軽減策。
アプリケーションの設計 スケーリングとエラー処理を可能にする設計パターン。
ネットワークと接続 受信トラフィックをスタンプにルーティングするためのネットワークに関する考慮事項。
データ プラットフォーム データ ストア テクノロジの選択肢。必要な量、速度、多様性、および真実性の特性を評価して情報を得ます。
展開とテスト 同期ロード テストや障害挿入 (混乱) テストなどの組み込みテスト シナリオを使用した CI/CD パイプラインと自動化に関する考慮事項に関する戦略。
正常性モデリング お客様の影響分析による可観測性に関する考慮事項は、アプリケーションの全体的な正常性を判断するために相関監視を行いました。
セキュリティ Microsoft ゼロ トラスト モデルによる攻撃ベクトルの軽減。
運用手順 デプロイ、キー管理、修正プログラムの適用、更新に関連するプロセス。

次のステップ