ミッション クリティカルな設計手法は、重要な設計領域全体で後続の設計決定のためのコンパスとして機能する 5 つの主要な設計原則によって支えられています。 これらの原則を理解し、その影響と非準拠に関連するトレードオフをより深く理解することを強くお勧めします。
信頼性
| 設計原則 | 考慮事項 |
|---|---|
| アクティブ/アクティブデザイン | 可用性を最大化し、リージョンのフォールト トレランスを実現するには、可能な限りアクティブ/アクティブデプロイ モデルを使用して、ソリューション コンポーネントを複数の Availability Zones と Azure リージョンに分散する必要があります。 |
| 爆発範囲の縮小と故障の隔離 | Azure のような高度に分散されたハイパースケール クラウド環境では、障害を回避することはできません。 個々のコンポーネントから Azure リージョン全体への障害と相関する影響を予測することで、回復性のある方法でソリューションを設計および開発できます。 |
| アプリケーションの正常性を確認する | アプリケーションの信頼性に影響する問題を軽減する前に、まず問題を検出して理解する必要があります。 既知の正常な状態に対するアプリケーションの動作を監視することで、信頼性の問題を検出または予測することが可能になり、迅速な修復アクションを実行できるようになります。 |
| 自動化を推進する | アプリケーションのダウンタイムの主な原因の 1 つは、十分にテストされていないソフトウェアの展開によるものか、構成が間違っているかに関係なく、人為的エラーです。 ヒューマン エラーの可能性と影響を最小限に抑えるには、信頼性を向上させるために、クラウド ソリューションのすべての側面で自動化に努める必要があります。自動テスト、デプロイ、および管理。 |
| 自己治癒のための設計 | 自己復旧は、ソリューション内の障害モードに接続された事前に定義された修復プロトコルを使用して、システムが障害に自動的に対処する機能を表します。 これは高度な概念であり、監視と自動化を備えた高度なシステム成熟度を必要としますが、信頼性を最大限に高めるためには、当初からの願望である必要があります。 |
| 複雑さの回避 | 信頼性と管理の効率を高めるためにソリューションとすべての運用プロセスを設計する際に不要な複雑さを避け、障害の可能性を最小限に抑えます。 |
パフォーマンス効率
| 設計原則 | 考慮事項 |
|---|---|
| スケールアウト用の設計 | スケールアウトは、水平方向の成長を通じて需要に対応するシステムの能力に焦点を当てた概念です。 つまり、トラフィックが増えるにつれて、既存のリソースのサイズを増やす代わりに、より多くのリソース ユニットが並列に追加されます。 スケール ユニットを通じて予期しないトラフィックの増加を処理するシステム機能は、単一のリソース障害の影響をさらに減らすことで、全体的なパフォーマンスと信頼性に不可欠です。 |
| ハイパースケールの自動化 | トラフィックの予期しない増加や予想される増加によるパフォーマンスと可用性への影響を最小限に抑えるために、ソリューション全体のスケール操作を完全に自動化し、スケール操作の実行にかかる時間を理解し、アプリケーションの正常性のモデルに合わせる必要があります。 |
| 継続的な検証とテスト | アプリケーションの変更ごとに継続的な検証を行うために、CI/CD プロセス内で自動テストを実行する必要があります。 既存のしきい値、ターゲット、前提条件を検証し、回復性と可用性に対するリスクをすばやく特定できるように、同期された混乱の実験を使用したパフォーマンス ベースラインに対するロード テストを含める必要があります。 このようなテストは、ステージング環境とテスト環境内で行う必要がありますが、必要に応じて開発環境内でも実行する必要があります。 運用環境に対してテストのサブセットを実行することも有益です。特にブルー/グリーン デプロイ モデルと組み合わせて、運用環境のトラフィックを受信する前に新しいデプロイ スタンプを検証します。 |
| マネージド コンピューティング サービスによるオーバーヘッドの削減 | マネージド コンピューティング サービスとコンテナー化アーキテクチャを使用すると、インフラストラクチャのデプロイとメンテナンスをマネージド サービス プロバイダーに移行することで、アプリケーションの設計、運用、スケーリングに伴う継続的な管理および運用上のオーバーヘッドが大幅に削減されます。 |
| ベースライン パフォーマンスを確立し、ボトルネックを特定する | すべてのシステム コンポーネントからの詳細なテレメトリを使用したパフォーマンス テストでは、他のコンポーネントに関連してスケーリングする必要があるコンポーネントなど、システム内のボトルネックを特定できます。この情報は容量モデルに組み込む必要があります。 |
| モデル容量 | 容量モデルを使用すると、特定の負荷プロファイルのリソース スケール レベルの計画が可能になり、さらにシステム コンポーネントが相互に関連して実行される方法が公開されるため、システム全体の容量割り当て計画が可能になります。 |
オペレーショナル エクセレンス
| 設計原則 | 考慮事項 |
|---|---|
| 疎結合コンポーネント | 疎結合により、サポート、サービス、リソース、または承認に対するチーム間の依存関係を最小限に抑えながら、アプリケーションのコンポーネントに対する独立したオンデマンドのテスト、デプロイ、更新が可能になります。 |
| ビルドとリリースのプロセスを自動化する | 完全に自動化されたビルドおよびリリース プロセスにより、摩擦が軽減され、更新プログラムの展開速度が向上し、環境全体で再現性と一貫性が実現します。 自動化により、開発者からのフィードバック ループが短縮され、コードの品質、テスト カバレッジ、回復性、セキュリティ、パフォーマンスに関する分析情報が得られ、開発者の生産性が向上します。 |
| 開発者の機敏性 | 継続的インテグレーションと継続的配置 (CI/CD) 自動化により、関連する機能ブランチのライフサイクルに関連付けられた有効期間の短い開発環境を使用できます。これにより、開発者の機敏性が向上し、エンジニアリング サイクル内でできるだけ早く検証が促進され、バグのエンジニアリング コストが最小限に抑えられます。 |
| 運用の正常性を定量化する | すべてのコンポーネントとリソースの完全な診断インストルメンテーションにより、ログ、メトリック、トレースを継続的に監視できるだけでなく、可用性とパフォーマンスの要件に関するコンテキストでアプリケーションの正常性を定量化するための正常性モデリングも容易になります。 |
| 回復の訓練と失敗の学習を実践する | ビジネス継続性 (BC) とディザスター リカバリー (DR) の計画と実践の訓練は不可欠であり、計画外のダウンタイムが発生した場合に回復性を最大限に高めるために、学習によって計画と手順を繰り返し改善できるため、頻繁に実施する必要があります。 |
| 継続的な運用の改善を受け入れる | 正常性モデルを使用して、フィードバック メカニズムを使用して運用効率を理解および測定し、アプリケーション チームが反復的にギャップを理解して対処できるように、システムとユーザー エクスペリエンスの日常的な改善に優先順位を付けます。 |
安全
| 設計原則 | 考慮事項 |
|---|---|
| ソリューション全体のセキュリティを監視し、インシデント対応を計画する | セキュリティ イベントと監査イベントを関連付けて、アプリケーションの正常性をモデル化し、アクティブな脅威を特定します。 セキュリティ情報イベント管理 (SIEM) ツールを使用して、インシデントに対応するための自動化された手動の手順を確立して追跡します。 |
| 潜在的な脅威に対するモデル化とテスト | 侵入テストを使用して脅威の軽減を検証し、静的コード分析とコード スキャンを使用して、適切なリソースのセキュリティ強化を確保し、既知の脅威を特定して軽減する手順を確立します。 |
| エンドポイントを識別して保護する | ファイアウォールや Web アプリケーションファイアウォールなどのセキュリティ機能やアプライアンスを通じて、社内外のエンドポイントのネットワークの完全性を監視し、保護します。 業界標準のアプローチを使用して、SlowLoris などの分散型拒否Of-Service (DDoS) 攻撃などの一般的な攻撃ベクトルから保護します。 |
| コード レベルの脆弱性から保護する | クロスサイト スクリプティングや SQL インジェクションなどのコード レベルの脆弱性を特定して軽減し、依存関係を含むコードベースのすべての部分の運用ライフサイクルにセキュリティ 修正プログラムを組み込みます。 |
| 最小限の特権を自動化して使用する | 自動化を推進して、人間の操作の必要性を最小限に抑え、アプリケーションとコントロール プレーンの両方で最小限の特権を実装して、データ流出や悪意のあるアクターのシナリオから保護します。 |
| データの分類と暗号化 | リスクに応じてデータを分類し、保存時および転送中の業界標準の暗号化を適用して、キーと証明書が安全に保存され、適切に管理されるようにします。 |
コストの最適化
高い信頼性の導入に関連するコストのトレードオフは明らかです。これは、ワークロード要件のコンテキストで慎重に検討する必要があります。
信頼性を最大化すると、ソリューションの全体的な財務コストに影響を与える可能性があります。 たとえば、高可用性を実現するためにリソースの重複やリージョン間でのリソースの分散は、コストに明確な影響を与えます。 過剰なコストを回避するために、関連するビジネス要件を超えて過剰なエンジニアリングや過剰プロビジョニングを行わないでください。
また、コードとしてのインフラストラクチャの採用、デプロイの自動化、テスト自動化など、基本的な信頼性の概念へのエンジニアリング投資に関連するコストも追加されます。 これは、時間と労力の両方の点でコストがかかります。これは、新しいアプリケーションの機能と機能を提供するために他の場所に投資することができます。
次のステップ
設計領域は相互接続されているため、1 つの領域の変更が他の領域に影響を与える可能性があります。 ビジネスにとって最も重要な領域から始めて、考慮事項と推奨事項を確認して、アーキテクチャ全体でトレードオフを生み出す方法を理解します。