ミッションクリティカルなワークロード
このセクションでは、Azure でミッション クリティカルなワークロードを設計する場合の課題に取り組みます。 このガイダンスは、多数の顧客アプリケーションとファースト パーティ ソリューションのレビューから学んだ教訓に基づいています。 このセクションでは、Azure で信頼性の高いソリューションを大規模に構築して運用するための技術的基盤として、Well-Architected ベスト プラクティスを適用する、実用的で権限のあるガイダンスを提供します。
ミッション クリティカルなワークロードとは
ワークロードという用語は、共通のビジネス目標または共通のビジネス プロセスの実行をサポートするアプリケーション リソースのコレクションを指し、API やデータ ストアなどの複数のサービスが連携して特定のエンド ツー エンド機能を提供します。
ミッション クリティカルという用語は、利用不能またはパフォーマンス低下に関連する重要な財務コスト (ビジネス クリティカル) または人的コスト (安全クリティカル) をカバーする重要度スケールを指します。
したがって、 ミッション クリティカルなワークロード は、プラットフォーム上で信頼性の高いアプリケーション リソースのコレクションを記述します。 ワークロードは常に使用可能で、障害に対する回復性があり、運用可能である必要があります。
ビデオ: Azure でのミッション クリティカルなワークロード
一般的な課題は何ですか?
Microsoft Azure を使用すると、クラウド ソリューションのデプロイと管理が簡単になります。 ただし、プラットフォームで信頼性の高いミッション クリティカルなワークロードを構築することは、次のメインの理由から引き続き課題となります。
信頼性の高いアプリケーションを大規模に設計するのは複雑です。 適切なテクノロジを選択 し、 エンド ツー エンドの機能を提供するように最適に構成するには、広範なプラットフォーム知識が必要です。
複雑な分散システムでは障害は避けられないため、相関または連鎖的な影響を受ける障害を処理するようにソリューションを設計する必要があります。 これは、オンプレミス環境からクラウドに入る多くの開発者やアーキテクトにとって、考え方の変化です。信頼性エンジニアリングは、インフラストラクチャの対象ではなくなりましたが、アプリケーション開発プロセスの中で一流の懸念事項である必要があります。
ミッション クリティカルなワークロードを運用するには、エンドツーエンドのエンジニアリング ライフサイクル全体にわたる高度なエンジニアリングの厳格さと成熟度と、障害から学ぶ能力が必要です。
ミッション クリティカルなのは信頼性だけですか?
ミッション クリティカルなワークロードの主な焦点は 信頼性ですが、Azure でミッション クリティカルなワークロードを構築して運用する場合、Well-Architected Framework の他の柱も同様に重要です。
セキュリティ: ワークロードが分散型サービス拒否 (DDoS) 攻撃などのセキュリティの脅威を軽減する方法は、全体的な信頼性に大きな影響を与えます。
オペレーショナル エクセレンス: ワークロードが運用上の問題にどのように効果的に対応できるかは、アプリケーションの可用性に直接影響します。
パフォーマンス効率: 可用性は単純なアップタイムではなく、既知の正常な状態に対する一貫したレベルのアプリケーション サービスとパフォーマンスです。
高い信頼性を実現すると、コストのトレードオフが大きくなります。これは、すべてのワークロード シナリオで正当ではない可能性があります。 そのため、設計上の決定はビジネス要件に基づくことが推奨されます。
主要な設計領域は何ですか?
このシリーズのミッション クリティカルなガイダンスは、これらの主要な設計領域を中心としたアーキテクチャ上の考慮事項と推奨事項で構成されています。
設計領域は相互に関連しており、1 つの領域内で行われた決定は、設計全体の決定に影響を与えたり、影響を与えたりする可能性があります。 読者はこれらの設計領域について理解し、提供された考慮事項と推奨事項を確認して、包括的な決定の結果をより深く理解することをお勧めします。 たとえば、ターゲット アーキテクチャを定義するには、主要なコンポーネント間でアプリケーションの正常性を監視する最善の方法を決定することが重要です。 この場合、読者は、意思決定を推進するのに役立つ推奨事項の概要を使用して、 正常性モデリング の設計領域を確認する必要があります。
設計領域 | まとめ |
---|---|
アプリケーションの設計 | 信頼性の高いアプリケーションを構築するコンテキストでのスケール ユニット アーキテクチャの使用。 また、スケーリングとエラー処理を可能にするクラウド アプリケーション設計パターンについても説明します。 |
アプリケーション プラットフォーム | 適切なアプリケーション ホスティング プラットフォーム、アプリケーションの依存関係、フレームワーク、およびライブラリの選択、設計、構成に関連する決定要因と推奨事項。 |
データ プラットフォーム | データ ストア テクノロジの選択肢。必要な量、速度、多様性、真実性を評価することによって通知されます。 |
ネットワークと接続 | 必要な接続と冗長トラフィック管理を考慮した、アプリケーション レベルでのネットワーク トポロジの概念。 セキュリティで保護されたスケーラブルなグローバル ネットワーク トポロジの設計を通知することを目的とした重要な推奨事項。 |
正常性モデリングと可観測性 | 堅牢な正常性モデルを定義するプロセス。定量化されたアプリケーションの正常性状態を可観測性と運用コンストラクトを通じてマッピングし、運用の成熟度を実現します。 |
デプロイとテスト | ダウンタイムを根絶し、デプロイ操作のアプリケーションの正常性を維持し、ミッション クリティカルなアプリケーションに最適な CI/CD パイプラインの設計を通知するための重要な考慮事項と推奨事項を提供します。 |
Security | アプリケーションの信頼性を直接または間接的に侵害することを意図した脅威からアプリケーションを保護します。 |
操作手順 | DevOps と関連するデプロイ方法の導入は、効果的で一貫性のある運用手順を推進するために使用されます。 |
わかりやすい例
このシリーズで提供されるガイダンスは、主要な設計上の考慮事項と推奨事項を示すソリューション指向のアプローチに基づいています。 さらなるソリューション開発の基礎として使用できる参照実装がいくつかあります。
インターネットに接続するアプリケーションのベースライン アーキテクチャ - Microsoft Azure でクラウドネイティブで拡張性の高いインターネット接続アプリケーションを構築するための基盤を提供します。 ワークロードはパブリック エンドポイント経由でアクセスされ、周囲の組織の技術資産へのプライベート ネットワーク接続は必要ありません。
実装を参照してください: Mission-Critical Online
ネットワーク制御を備えたインターネットに接続するアプリケーションのベースライン アーキテクチャ - インターネットからワークロード リソースへの不正なパブリック アクセスを防ぐために、厳密なネットワーク制御を使用してベースライン アーキテクチャを拡張します。
Azure ランディング ゾーンのベースライン アーキテクチャ - 既存のネットワーク インフラストラクチャとプライベート エンドポイントを使用して、Microsoft Azure で企業に接続されたクラウドネイティブ アプリケーションを構築するための基盤を提供します。 ワークロードでは、他の組織リソースへのプライベート接続が必要であり、他の組織リソースへの接続のために、事前に指定された仮想ネットワークに依存します。 このユース ケースは、一般向けまたは内部向けのワークロードに対して、より広範な組織の技術的資産との統合を必要とするシナリオを対象としています。
実装を参照してください。 ミッション クリティカル接続済み
業界のシナリオ
このシリーズのミッション クリティカルなガイダンスは、さまざまな業界コンテキストに適用できる業界に依存しない設計手法を形成します。 次の一覧は、ミッション クリティカルな設計手法が適用され、特定の業界シナリオに合わせて調整された具体的な例を示しています。
- 通信業界におけるキャリアグレード
キャリア グレードのワークロードは、ビジネスクリティカルな側面と安全上重要な側面の両方でピボットします。ここで、1 暦年あたり数分または数秒のダウンタイムだけで運用するという基本的な要件があります。 このアップタイム要件を満たさない場合は、広範囲の生命の損失、重大な罰金、または契約上の罰則が発生する可能性があります。
次のステップ
まず、ミッション クリティカルなアプリケーション シナリオの設計手法を確認します。
フィードバック
https://aka.ms/ContentUserFeedback」を参照してください。
以下は間もなく提供いたします。2024 年を通じて、コンテンツのフィードバック メカニズムとして GitHub の issue を段階的に廃止し、新しいフィードバック システムに置き換えます。 詳細については、「フィードバックの送信と表示