あらゆるクラウド プラットフォームでミッション クリティカルなアプリケーションを設計する場合は、慎重なエンジニアリング アプローチが必要です。 プラットフォームの機能を理解し、適切なサービスを選択し、正しく構成し、効果的に運用し、進化するベスト プラクティスとサービス ロードマップに沿った状態を維持するという複雑さがあります。
この複雑さに対応するには、特にアップタイムと復旧に関して、ビジネス要件に合った明確でシンプルな設計手法を確立します。 意思決定が困難になったり、分析の麻痺に陥ったりした場合は、基準点として方法論に戻ります。 これは、選択を検証し、設計に重点を置き、全体的な目標に確実に合わせるのに役立ちます。
この記事では、Azure にデプロイされたミッション クリティカルな多数のアプリケーションのレビューから得られた分析情報によって情報を得られる設計手法を提案します。
信頼性目標の設計
「ミッションクリティカル」は、必ずしもすべての人にとって同じ意味を持つわけではありません。 アーキテクチャは、ワークロードのビジネス要件と許容されるダウンタイムによって異なります。 これらは、多くの場合、99.9% と 99.999% 可用性など、サービス レベル目標 (SLO) によって定義されます。 可用性の目標は、単なるアップタイム以上のものであると考えてください。 これらは、正常なアプリケーションの状態に対する一貫性のあるサービスを表します。 出発点として、チームは許容されるダウンタイムの量を定義する必要があります。 稼働時間/ダウンタイム計算ツールを使用して、許容されるダウンタイム時間を決定します。
この設計手法は、目標が設定された後のアーキテクチャ上の決定とトレードオフの開始点として機能します。 ドラフトターゲットアーキテクチャが形成され、コストと複雑さが明確になるにつれて、初期要件は、代替ソリューションを通じて再検討、チャレンジ、調整、または対処される可能性があります。
たとえば、単一リージョンのマルチゾーンセットアップでは、多くの重要なワークロードで十分ですが、信頼性の向上には、より多くのエンジニアリング作業と複雑さが必要です。 強い要件がない限り、アクティブ-アクティブなマルチリージョンのような複雑な解決策に頼ることは避けてください。
RTO (目標復旧時間) と RPO (目標復旧ポイント) も、信頼性のニーズを定義する上で重要です。 たとえば、1 分以内にアプリケーションを回復することが目標の場合、バックアップ ベースまたはアクティブ/パッシブ戦略では十分な速度が得られない可能性があります。
信頼性目標の定義に関する推奨事項を参照してください
エンドツーエンドの自動化に努める
デプロイと継続的な管理アクティビティの両方にまたがる包括的な自動化戦略を採用します。 この手法では、自動化優先の原則を通じて、一貫性、再現性、回復性が重視されます。
自動化の一般的な領域は、修正プログラムの適用、スケーリング、監視などの日常的なタスクで、手動での作業とエラーを減らします。 テンプレートが実行可能でない場合にのみスクリプトを使用して、一貫性と明確さを確保するために、構成とデプロイ用のテンプレートを優先します。
自動化を有効にするための推奨事項を参照してください
ダウンタイムなしのデプロイの設計
ダウンタイムなしのデプロイにより、ユーザーは変更中に中断が発生しません。
この手法では、更新プログラムに欠陥、脆弱性、不安定性が生じないように、厳密なプレリリース テストが必要です。 これをサポートするには、展開ツールとプロセスの可用性と回復性が高い必要があります。
整合性が重要です。 手動エラーが発生する可能性を排除し、全体的なリスクを軽減するために、すべての環境で同じアーティファクトと自動化されたプロセスを使用する必要があります。 エンドツーエンドの自動化は好ましいだけではありません。信頼性の高い反復可能で中断のないデプロイを実現するには必須です。
デプロイとテストに関する推奨事項を参照してください
迅速な障害検出と復旧のための設計
高速障害検出は、明確に定義された正常性モデルから始まります。 多くの場合、障害はコンポーネント間で連鎖するため、ワークロード コンポーネント間の早期検出と明確な依存関係は、爆発半径を最小限に抑え、復旧を高速化するために交渉できません。
つまり、実際のユーザー フローとパフォーマンスと可用性のビジネスしきい値に基づいて、各コンポーネントの 正常 で 異常 な外観を明確に識別します。 これらの定義は、監視するメトリックをガイドし、問題を根本原因に戻すのに役立ちます。
正常性モデリングに関する設計ガイドを参照してください
Azure で進化する
アーキテクチャをモジュール式で柔軟に設計し、大きな変更を加えずに新機能を簡単に導入できるようにします。 Azure の進化するサービスと機能を常に最新の状態に保つよう、設計を定期的に確認します。 運用オーバーヘッドが低く、統合が向上するために、Azure ネイティブマネージド サービスに優先順位を付けます。 Azure は頻繁に更新されるため、アーキテクチャをロードマップに合わせることは、アプリケーションの最適化と将来の準備を確実に行うのに役立ちます。
新しいサービスと機能に関する最新情報については、Azure と Azure の更新プログラムを使用した進化に関するページを参照してください。
次のステップ
Well-Architected Framework の柱がミッション クリティカルなワークロードクラスにどのように適用されるかを確認して、設計の過程を開始します。
設計領域は相互接続されているため、1 つの領域の変更が他の領域に影響を与える可能性があります。 ビジネスにとって最も重要な領域から始めて、考慮事項と推奨事項を確認して、アーキテクチャ全体でトレードオフを生み出す方法を理解します。
この手法に基づく設計上の決定について説明するこれらの参照アーキテクチャを参照してください。