次の方法で共有


ミッションクリティカルなワークロード

このセクションでは、Azure でのミッション クリティカルなワークロードを設計するという課題に取り組みます。 このガイダンスは、多数の顧客アプリケーションとファースト パーティ ソリューションのレビューから得られた経験に基づいています。 このセクションでは、Azure 上の信頼性の高いソリューションを大規模に構築および運用するための技術的基盤として Well-Architected のベスト プラクティスを適用する、実用的で信頼できるガイダンスを提供します。

ミッション クリティカルなワークロードとは

ワークロードという用語は、共通のビジネス目標または共通のビジネス プロセスの実行をサポートするアプリケーション リソースのコレクションを指します。これらは、API やデータ ストアなどの複数のサービスが連携して特定のエンド ツー エンド機能を提供します。

"ミッション クリティカル" という用語は、利用不能またはパフォーマンス不足に関連する重要な財務コスト (ビジネス クリティカル) または人的コスト (安全性クリティカル) を表す重要度スケールを指します。

したがって、"ミッション クリティカルなワークロード" は、プラットフォーム上で高い信頼性が求められるアプリケーション リソースのコレクションを表します。 ワークロードは常に使用可能で、障害に対する回復性があり、運用可能である必要があります。

ビデオ: Azure でのミッション クリティカルなワークロード

一般的な課題とは

Microsoft Azure を使用すると、クラウド ソリューションのデプロイと管理が簡単になります。 ただし、プラットフォームで信頼性の高いミッション クリティカルなワークロードを構築することは、次の主な理由から引き続き課題となります。

  • 信頼性の高いアプリケーションを大規模に設計するのは複雑なことです。 適切なテクノロジを選択し、かつ、エンド ツー エンドの機能を提供するように最適に構成するには、プラットフォームの広範な知識が必要です。

  • あらゆる複雑な分散システムにおいて、障害は避けられないため、相関的または連鎖的な影響を持つ障害を処理するソリューションを設計する必要があります。 これは、オンプレミス環境からクラウドに移行する多くの開発者やアーキテクトにとって、考え方の変化です。信頼性エンジニアリングはもはやインフラストラクチャの問題ではなく、アプリケーション開発プロセスにおける最優先事項とする必要があります。

  • ミッション クリティカルなワークロードを運用するには、エンド ツー エンドのエンジニアリング ライフサイクル全体にわたる高度なエンジニアリングの厳密さと成熟度に加えて、失敗から学ぶ能力が必要です。

ミッション クリティカルとは信頼性だけの問題ですか?

ミッション クリティカルなワークロードの主な焦点は信頼性ですが、Azure でのミッション クリティカルなワークロードを構築して運用する場合、Well-Architected フレームワークの他の柱も同様に重要です。

  • セキュリティ: ワークロードで分散型サービス拒否 (DDoS) 攻撃などのセキュリティの脅威をどのように軽減するかは、全体的な信頼性に大きな影響を与えます。

  • オペレーショナル エクセレンス: ワークロードで運用上の問題にどのように効果的に対応できるかは、アプリケーションの可用性に直接影響します。

  • パフォーマンス効率: 可用性は単なるアップタイムのことではなく、既知の正常な状態と比較して一貫したレベルのアプリケーション サービスとパフォーマンスを意味します。

高信頼性の実現には多大なコストのトレードオフが伴い、必ずしもすべてのワークロード シナリオで妥当とは限りません。 そのため、設計上の決定はビジネス要件によって決めることをお勧めします。

このガイダンスを使用する方法

✔ 最初に、技術的および運用領域全体の論理的根拠と定期的なテーマの概要を示す 設計手法から始めます。 この体系的なアプローチは、要件と設計戦略を定義するのに役立ちます。 ワークロードの全体的な目標に沿った状態を保つ不確実な選択に直面する場合は、この手法を見直します。

「設計原則 」に進み、ミッション クリティカルな設計手法が、成長の進化を考慮して、フレームワークの柱 Well-Architected 中核となる要素とどのように整合しているかを確認します。 トレードオフを含め、すべての柱の基礎となる原則をまとめて評価します。

✔ ソリューションに最も大きな影響を与える設計領域に焦点を当てます。 このシリーズのミッション クリティカルなガイダンスは、アーキテクチャに関する考慮事項と、これらの主要な設計領域に関する推奨事項で構成されています。

Mission-critical design areasミッション クリティカルな設計領域ミッション クリティカルな設計領域

重要な設計領域

設計領域 まとめ
アプリケーションの設計 信頼性の高いアプリケーションを構築するコンテキストでのスケール ユニット アーキテクチャの使用。 また、スケーリングとエラー処理を可能にするクラウド アプリケーション設計パターンについても確認します。
アプリケーション プラットフォーム 適切なアプリケーション ホスティング プラットフォーム、アプリケーションの依存関係、フレームワーク、ライブラリの選択、設計、構成に関連する決定要因と推奨事項。
データ プラットフォーム データ ストア テクノロジの選択肢。必要なボリューム、速度、多様性、正確性を評価することで知ることができます。
Azure ネットワークと接続性 必要な接続と冗長トラフィック管理を考慮した、アプリケーション レベルでのネットワーク トポロジの概念。 セキュリティで保護されたスケーラブルなグローバル ネットワーク トポロジの設計に情報を提供することを目的とした、重要な推奨事項。
正常性モデリングと監視 信頼性の高い正常性モデルを定義するプロセス。運用の成熟度を達成するために、監視と運用コンストラクトを通じて定量化されたアプリケーションの正常性状態をマッピングします。
デプロイとテスト ダウンタイムを根絶し、デプロイ操作のアプリケーションの正常性を維持し、ミッション クリティカルなアプリケーションに最適な CI/CD パイプラインの設計に情報を提供するための重要な考慮事項と推奨事項を示しsます。
Security 信頼性を直接または間接的に侵害することを意図した脅威からアプリケーションを保護します。
操作手順 DevOps および関連するデプロイ方法の導入は、効果的で一貫性のある運用手順を推進するために使用されます。

参照アーキテクチャの例

このシリーズで提供されるガイダンスは、主要な設計上の考慮事項と推奨事項を示すソリューション指向のアプローチに基づいています。 以降のソリューション開発の基礎として使用できる参照実装がいくつかあります。

  • インターネットに接続するアプリケーションのベースライン アーキテクチャ— クラウド ネイティブで拡張性の高い、インターネットに接続するアプリケーションを Microsoft Azure で構築するための基盤を提供します。 ワークロードはパブリック エンドポイント経由でアクセスされ、周囲の組織の技術資産へのプライベート ネットワーク接続は必要ありません。

  • ネットワーク制御を備えた、インターネットに接続するアプリケーションのベースライン アーキテクチャ— インターネットからワークロード リソースへの未承認のパブリック アクセスを防ぐために、厳格なネットワーク制御を適用してベースライン アーキテクチャを拡張します。

  • Azure ランディング ゾーンのベースライン アーキテクチャ— 既存のネットワーク インフラストラクチャとプライベート エンドポイントを使用して、企業に接続されたクラウド ネイティブ アプリケーションを Microsoft Azure で構築するための基盤を提供します。 ワークロードには他の組織リソースへのプライベート接続が必要であり、他の組織リソースへの接続のために事前に提供された仮想ネットワークに依存します。 このユース ケースは、一般公開または内部向けのワークロードに対して、より広範な組織の技術資産との統合を必要とするシナリオを対象としています。

次のステップ

まず、ミッション クリティカルなアプリケーション シナリオの設計手法を確認します。