ミッション クリティカルなワークロードの設計原則

ミッション クリティカルな設計手法は、重要な設計領域全体で後続の設計決定のためのコンパスとして機能する 5 つの主要な設計原則によって支えられています。 これらの原則を理解し、その影響と非準拠に関連するトレードオフをより深く理解することを強くお勧めします。

重要

この記事は、 Azure Well-Architected ミッション クリティカルなワークロード シリーズの 一部です。 このシリーズに慣れていない場合は、ミッション クリティカルなワークロードとは何かから始めてお勧めします。

これらのミッション クリティカルな設計原則は、Azure Well-Architected Framework (信頼性、 セキュリティ、 コスト最適化、 オペレーショナル エクセレンス、 パフォーマンス効率) の品質の柱を共感させ、拡張します。

[信頼性]

最大限の信頼性 - 最も信頼性の高いソリューションの基本的な追求により、トレードオフが適切に理解されるようにします。

設計原則	考慮事項
アクティブ/アクティブデザイン	可用性を最大化し、リージョンのフォールト トレランスを実現するには、可能な限りアクティブ/アクティブ デプロイ モデルを使用して、ソリューション コンポーネントを複数のAvailability Zonesと Azure リージョンに分散する必要があります。
ブラスト半径の低減と障害の分離	Azure のような高度に分散されたマルチテナント クラウド環境では、障害を回避することはできません。 個々のコンポーネントから Azure リージョン全体への障害と相関した影響を予測することで、回復性のある方法でソリューションを設計および開発できます。
アプリケーション正常性の監視	アプリケーションの信頼性に影響を与える問題を軽減する前に、まず問題を検出して理解する必要があります。 既知の正常な状態に対するアプリケーションの動作を監視することで、信頼性の問題を検出または予測することが可能になり、迅速な修復アクションを実行できるようになります。
自動化の推進	アプリケーションのダウンタイムの主な原因の 1 つは、不十分なテスト済みソフトウェアのデプロイによるものであるか、構成が誤っているかに関係なく、人的エラーです。 人的エラーの可能性と影響を最小限に抑えるためには、信頼性を向上させるためにクラウド ソリューションのすべての側面で自動化を目指す必要があります。自動テスト、デプロイ、および管理。
自動修復機能の設計	自己復旧は、ソリューション内の障害モードに接続された事前に定義された修復プロトコルを使用して、システムが障害に自動的に対処する機能を表します。 これは高度な概念であり、監視と自動化を備えた高レベルのシステム成熟度が必要ですが、信頼性を最大限に高めるためには、開始からの願望である必要があります。
複雑さの回避	信頼性と管理の効率を高めるためにソリューションとすべての運用プロセスを設計する際に不要な複雑さを避け、障害の可能性を最小限に抑えます。

パフォーマンス効率

持続可能なパフォーマンスとスケーラビリティ - パフォーマンスのボトルネックを伴わないエンド ツー エンド ソリューション全体のスケーラビリティを設計します。

設計原則	考慮事項
スケールアウトの設計	スケールアウトは、水平成長を通じて需要に対応するシステムの能力に焦点を当てた概念です。 つまり、トラフィックが増加すると、既存のリソースのサイズを大きくするのではなく、リソース ユニットが並列に追加されます。 スケール ユニットを通じて予期しないトラフィックの増加を処理するシステム機能は、単一のリソース障害の影響をさらに減らすことで、全体的なパフォーマンスと信頼性に不可欠です。
ハイパースケールの自動化	トラフィックの予期しない増加や予想される増加によるパフォーマンスと可用性の影響を最小限に抑えるために、ソリューション全体のスケーリング操作を完全に自動化する必要があります。スケーリング操作の実行にかかる時間を理解し、アプリケーションの正常性のモデルに合わせて調整します。
継続的な検証とテスト	CI/CD プロセス内で自動テストを実行して、アプリケーションの変更ごとに継続的な検証を推進する必要があります。 同期されたカオス実験を使用してパフォーマンス ベースラインに対するロード テストを含め、既存のしきい値、ターゲット、前提条件を検証し、回復性と可用性に対するリスクをすばやく特定できるようにする必要があります。 このようなテストは、ステージング環境とテスト環境内で行う必要がありますが、必要に応じて開発環境内でも実行する必要があります。 また、運用環境に対してテストのサブセットを実行すると便利な場合もあります。特にブルー/グリーン デプロイ モデルと組み合わせて、運用トラフィックを受信する前に新しいデプロイ スタンプを検証します。
マネージド コンピューティング サービスを使用してオーバーヘッドを削減する	マネージド コンピューティング サービスとコンテナー化されたアーキテクチャを使用すると、インフラストラクチャのデプロイとメンテナンスをマネージド サービス プロバイダーに移行することで、アプリケーションの設計、運用、スケーリングの継続的な管理オーバーヘッドと運用オーバーヘッドが大幅に削減されます。
ベースライン パフォーマンスとボトルネックの特定	すべてのシステム コンポーネントからの詳細なテレメトリを使用したパフォーマンス テストでは、他のコンポーネントに関連してスケーリングする必要があるコンポーネントなど、システム内のボトルネックを特定できます。この情報は容量モデルに組み込む必要があります。
モデル容量	容量モデルを使用すると、特定の負荷プロファイルのリソース スケール レベルの計画が可能になり、さらにシステム コンポーネントが相互に関連して実行される方法が公開されるため、システム全体の容量割り当て計画が可能になります。

オペレーショナル エクセレンス

設計による運用 - 堅牢でアサート的な運用管理で最後まで設計されました。

設計原則	考慮事項
疎結合コンポーネント	疎結合を使用すると、サポート、サービス、リソース、または承認のためのチーム間の依存関係を最小限に抑えながら、アプリケーションのコンポーネントに対する独立したオンデマンドのテスト、デプロイ、更新が可能になります。
ビルドとリリースのプロセスを自動化する	完全に自動化されたビルドおよびリリース プロセスにより、摩擦が軽減され、更新プログラムのデプロイ速度が向上し、環境間で再現性と一貫性がもたらされます。 自動化により、開発者からのフィードバック ループが短縮され、コード品質、テスト カバレッジ、回復性、セキュリティ、パフォーマンスに関する分析情報が得られ、開発者の生産性が向上します。
開発者の機敏性	継続的インテグレーションと継続的デプロイ (CI/CD) の自動化により、関連する機能ブランチのライフサイクルに関連付けられた有効期間の短い開発環境を使用できます。これにより、開発者の機敏性が向上し、エンジニアリング サイクル内でできるだけ早く検証が促進され、バグのエンジニアリング コストが最小限に抑えられます。
運用の正常性を定量化する	すべてのコンポーネントとリソースの完全な診断インストルメンテーションにより、ログ、メトリック、トレースを継続的に監視できるだけでなく、可用性とパフォーマンスの要件に合わせてコンテキスト内のアプリケーションの正常性を定量化するための正常性モデリングも容易になります。
復旧およびプラクティス障害のリハーサルを行う	ビジネス継続性 (BC) とディザスター リカバリー (DR) の計画と実践の訓練は不可欠であり、計画外のダウンタイムが発生した場合に回復性を最大化するために計画と手順を反復的に改善できるため、頻繁に実施する必要があります。
継続的な運用上の改善を取り入れる	正常性モデルを使用して、フィードバック メカニズムを使用して運用効率を理解して測定し、アプリケーション チームが反復的な方法でギャップを理解して対処できるように、システムとユーザー エクスペリエンスの日常的な改善に優先順位を付けます。

セキュリティ

常にセキュリティで保護 - アプリケーションの安定性を維持し、可用性を確保するためにエンドツーエンドのセキュリティを設計します。

設計原則	考慮事項
ソリューション全体のセキュリティを監視し、インシデント対応を計画する	セキュリティ イベントと監査イベントを関連付けて、アプリケーションの正常性をモデル化し、アクティブな脅威を特定します。 セキュリティ情報イベント管理 (SIEM) ツールを使用して、インシデントに対応するための自動および手動の手順を確立します。
潜在的な脅威に対するモデル化とテスト	侵入テストを使用して脅威の軽減を検証し、静的コード分析とコード スキャンを使用して、既知の脅威を特定して軽減するための適切なリソースのセキュリティ強化と手順を確立します。
エンドポイントを識別して保護する	ファイアウォールや Web アプリケーション ファイアウォールなどのセキュリティ機能とアプライアンスを使用して、内部エンドポイントと外部エンドポイントのネットワーク整合性を監視および保護します。 業界標準のアプローチを使用して、SlowLoris などの分散型サービス拒否 (DDoS) 攻撃などの一般的な攻撃ベクトルから保護します。
コード レベルの脆弱性から保護する	クロスサイト スクリプティングや SQL インジェクションなどのコード レベルの脆弱性を特定して軽減し、コードベースのすべての部分 (依存関係を含む) の運用ライフサイクルにセキュリティ修正プログラムを組み込みます。
最小限の特権を自動化して使用する	自動化を推進して、人間との対話の必要性を最小限に抑え、アプリケーションとコントロール プレーンの両方で最小限の特権を実装して、データ流出や悪意のあるアクター シナリオから保護します。
データを分類して暗号化する	リスクに応じてデータを分類し、保存時と転送中に業界標準の暗号化を適用し、キーと証明書が安全に保存され、適切に管理されるようにします。

コストの最適化

より高い信頼性の導入に関連する明らかなコストのトレードオフがあります。これは、ワークロード要件のコンテキストで慎重に検討する必要があります。

信頼性を最大化すると、ソリューションの全体的な財務コストに影響を与える可能性があります。 たとえば、高可用性を実現するために、リソースの重複やリージョン間でのリソースの分散には、明らかなコストの影響があります。 過剰なコストを回避するために、関連するビジネス要件を超えて過剰なエンジニアリングや過剰プロビジョニングを行わないでください。

また、インフラストラクチャをコードとして受け入れる、デプロイの自動化、カオス エンジニアリングなど、基本的な信頼性の概念へのエンジニアリング投資に関連するコストも追加されます。 これは、新しいアプリケーションの機能と機能を提供するために他の場所に投資できる時間と労力の両方の点でコストがかかります。

クラウド ネイティブ設計

• Azure ネイティブマネージド サービス - Azure ネイティブマネージド サービスは、管理と運用のオーバーヘッドが少なく、アプリケーション スタック全体で一貫した構成とインストルメンテーションとの緊密な統合が行われるため、優先順位が付けられます。

• ロードマップの配置 - 今後の新しい Azure サービス機能を組み込み、一般公開 (GA) になり、Azure の最先端に近づくようにします。

• プレビュー機能を採用し、既知のギャップを軽減 する - サポート性のために一般提供 (GA) サービスが優先されますが、Azure サービス プレビューは迅速な組み込みのために積極的に検討され、ギャップに対処するために Azure 製品グループに技術的で実用的なフィードバックを提供します。

• Azure ランディング ゾーンの配置 - Azure ランディング ゾーン 内にデプロイでき、Azure ランディング ゾーンの設計手法に合わせて配置できますが、ランディング ゾーンの外部のベア環境でも完全に機能し、デプロイできます。

次のステップ

ミッション クリティカルなワークロードに関連する横断的な懸念事項を確認します。

横断的な懸念事項