Azure でのミッション クリティカルなワークロードの設計手法
任意のクラウド プラットフォームでミッション クリティカルなアプリケーションを構築するには、技術的な専門知識とエンジニアリングへの多大な投資が必要です。特に、次に関連する非常に複雑さがあるためです。
- クラウド プラットフォームについて
- 適切なサービスと構成の選択
- 正しいサービス構成を適用する
- 利用サービスの運用
- 常に最新のベスト プラクティスとサービス ロードマップに合わせます。
この設計手法は、この複雑さをナビゲートし、最適なターゲット アーキテクチャを生成するために必要な設計上の決定を通知するのに役立つ、簡単に従う設計パスを提供することを目指しています。
1 - ビジネス要件の設計
ミッション クリティカルなワークロードのすべてが同じ要件を持っているわけではありません。 この設計手法によって提供されるレビューの考慮事項と設計に関する推奨事項によって、さまざまなアプリケーション シナリオで異なる設計上の決定とトレードオフが生じすることを期待します。
信頼性レベルを選択する
信頼性は相対的な概念であり、ワークロードを適切に信頼できるようにするには、それを取り巻くビジネス要件を反映する必要があります。 たとえば、可用性サービス レベル目標 (SLO) が 99.999% のミッション クリティカルなワークロードでは、SLO が 99.9% の他の重要度の低いワークロードよりもはるかに高いレベルの信頼性が必要です。
この設計手法では、可用性 SLO として表される信頼性レベルの概念を適用して、必要な信頼性特性を通知します。 次の表は、一般的な信頼性レベルに関連付けられている許可されたエラー予算をキャプチャします。
| 信頼性レベル (可用性 SLO) | 許可されたダウンタイム (週) | 許可されたダウンタイム (月) | 許可されたダウンタイム (年) |
|---|---|---|---|
| 99.9% | 10 分 4 秒 | 43 分 49 秒 | 8 時間 45 分 56 秒 |
| 99.95% | 5 分 2 秒 | 21 分 54 秒 | 4 時間 22 分 58 秒 |
| 99.99% | 1 分 | 4 分 22 秒 | 52 分 35 秒 |
| 99.999% | 6 秒 | 26 秒 | 5 分 15 秒 |
| 99.9999% | <1 秒 | 2 秒 | 31 秒 |
重要
可用性 SLO は、この設計手法では、単純なアップタイムではなく、既知の正常なアプリケーション状態に対して一貫したレベルのアプリケーション サービスと見なされます。
最初の演習として、読者は、許容されるダウンタイムの量を決定することで、ターゲットの信頼性レベルを選択することをお勧めします。 特定の信頼性レベルを追求すると、最終的には設計パスと包括的な設計上の決定に大きな影響が生じ、その結果、ターゲット アーキテクチャが異なります。
この図は、さまざまな信頼性レベルと基になるビジネス要件が、概念参照実装のターゲット アーキテクチャにどのように影響するかを示しています。特に、リージョンデプロイの数とグローバル テクノロジの使用に関するものです。
目標復旧時間 (RTO) と目標復旧ポイント (RPO) は、必要な信頼性を決定する際にさらに重要な側面です。 たとえば、アプリケーション RTO を 1 分未満で達成しようと努力している場合、バックアップ ベースの復旧戦略やアクティブ/パッシブデプロイ戦略が不十分である可能性があります。
2 — 設計原則を使用して設計領域を評価する
この手法の中核となるのは、次の重要な設計パスです。
各設計領域内で行われた決定の影響は、他の設計領域と設計上の決定に影響を及ぼします。 提供された考慮事項と推奨事項を確認して、包含された決定の結果をより深く理解します。これにより、関連する設計領域内でトレードオフが生じる可能性があります。
たとえば、ターゲット アーキテクチャを定義するには、主要なコンポーネント間でアプリケーションの正常性を監視する最適な方法を決定することが重要です。 意思決定の推進に役立つ推奨事項の概要を使用して、正常性モデリングの設計領域を確認することを強くお勧めします。
3 - ミッション クリティカルな最初のアプリケーションをデプロイする
この手法に基づく設計上の決定事項については、これらの参照アーキテクチャを参照してください。
ヒント
このアーキテクチャは、設計上の推奨事項を示す Mission-Critical Online の実装によってサポートされています。
運用グレードの成果物 すべての技術的成果物は、すべてのエンド ツー エンドの運用面が考慮された運用環境で使用できる状態です。
現実世界のエクスペリエンスに根ざした 技術的な決定はすべて、Azure のお客様のエクスペリエンスと、それらのソリューションのデプロイから学んだ教訓によって導かれます。
Azure ロードマップの配置 ミッション クリティカルな参照アーキテクチャには、Azure 製品ロードマップに沿った独自のロードマップがあります。
4 - ワークロードを Azure ランディング ゾーンに統合する
Azure ランディング ゾーン サブスクリプションは、 一元化されたガバナンスを必要とするエンタープライズ デプロイ用の共有インフラストラクチャを提供します。
ミッション クリティカルなアプリケーションで必要な接続ユース ケースを評価することが重要です。 Azure ランディング ゾーンでは、次の図に示すように、異なる管理グループ スコープに分離された 2 つのメインアーキタイプがサポートされています。オンラインまたは Corp.
オンライン サブスクリプション
ミッション クリティカルなワークロードは、独立したソリューションとして動作し、Azure ランディング ゾーン アーキテクチャの残りの部分に企業ネットワークを直接接続する必要はありません。 アプリケーションは、 ポリシー主導のガバナンス を通じてさらに保護され、ポリシーを介して一元化されたプラットフォーム のログ記録と自動的に統合されます。
ベースライン アーキテクチャと Mission-Critical Online の実装は、オンライン アプローチと一致します。
Corp. サブスクリプション
Corp. サブスクリプションにデプロイする場合、ミッション クリティカルなワークロードは、接続リソースを提供するために Azure ランディング ゾーンに依存します。 この方法により、他のアプリケーションや共有サービスとの統合が可能になります。 いくつかの基本的なリソースを中心に設計する必要があります。これは、共有サービス プラットフォームの一部として事前に存在します。 たとえば、リージョンデプロイ スタンプは、Corp. サブスクリプションに存在するため、エフェメラル Virtual Networkまたは Azure プライベート DNS ゾーンを含めなくなります。
このユース ケースを開始するには、 Azure ランディング ゾーン参照アーキテクチャのベースライン アーキテクチャ をお勧めします。
ヒント
上記のアーキテクチャは、 Mission-Critical Connected の実装によってサポートされています。
5 - サンドボックス アプリケーション環境をデプロイする
設計アクティビティと並行して、Mission-Critical参照実装を使用してサンドボックス アプリケーション環境を確立することを強くお勧めします。
これにより、ターゲット アーキテクチャをレプリケートして設計上の決定を検証する実践的な機会が提供され、設計の不確実性を迅速に評価できます。 代表的な要件範囲で正しく適用すると、進行を妨げる可能性が高い最も問題のある問題を発見し、その後対処できます。
6 - Azure ロードマップを使用して継続的に進化する
この設計手法を使用して確立されたアプリケーション アーキテクチャは、最適化された持続可能性をサポートするために 、Azure プラットフォームのロードマップに沿って進化 し続ける必要があります。
次のステップ
ミッション クリティカルなアプリケーション シナリオの設計原則を確認します。