ベースライン アーキテクチャ
ミッション クリティカルな体験を始めたばかりの場合は、このアーキテクチャを参照として使用します。 ワークロードはパブリック エンドポイント経由でアクセスされ、他の会社のリソースへのプライベート ネットワーク接続は必要ありません。
Azure でのミッション クリティカルなワークロードのアーキテクチャ パターン
この記事では、Azure 上のミッション クリティカルなアーキテクチャの主要なパターンについて説明します。 設計プロセスを開始するときにこのパターンを適用し、ビジネス要件に最適なコンポーネントを選択します。 この記事では、北star設計アプローチを推奨し、一般的なテクノロジ コンポーネントを含むその他の例を示します。
次の特性に留意しながら、 主要な設計領域を評価し、基になるコンポーネントを使用する重要なユーザーフローとシステム フローを定義し、Azure リソースとその構成のマトリックスを開発することをお勧めします。
| 特徴 | 考慮事項 |
|---|---|
| 有効期間 | ソリューション内の他のリソースと比較して、リソースの予想される有効期間は何ですか? リソースの有効期間をシステムまたはリージョン全体よりも長くするか、共有する必要はありますか。または一時的にする必要がありますか? |
| State | このレイヤーでの永続化状態が信頼性または管理容易性にどのような影響を与えますか? |
| リーチ | リソースはグローバルに分散する必要がありますか? リソースは、グローバルまたはそのリージョン内にある他のリソースと通信できますか? |
| 依存関係 | 他のリソースへの依存関係は何ですか? |
| スケールの上限 | そのリソースに予想されるスループットは何ですか? その需要に合わせてリソースによって提供されるスケールはどのくらいですか? |
| 可用性とディザスター リカバリー | このレイヤーでの災害による可用性への影響は何ですか? システム障害が発生するか、ローカライズされた容量または可用性の問題のみが発生しますか? |
重要
この記事は、 Azure Well-Architected ミッション クリティカルなワークロード シリーズの 一部です。 このシリーズに慣れていない場合は、ミッション クリティカルなワークロードの概要から始めてお勧めします。
コア アーキテクチャ パターン
グローバル リソース
特定のリソースは、各リージョン内にデプロイされたリソースによってグローバルに共有されます。 一般的な例としては、トラフィックを複数のリージョンに分散し、アプリケーション全体の永続的な状態を格納し、それらのリソースを監視するために使用されるリソースがあります。
| 特徴 | 考慮事項 |
|---|---|
| 有効期間 | これらのリソースは、長生きすることが予想されます (非エフェメラル)。 その有効期間は、システムの有効期間以上に及びます。 ダウンタイムなしの更新操作がサポートされていると仮定すると、多くの場合、リソースはインプレース データとコントロール プレーンの更新で管理されます。 |
| State | これらのリソースは少なくともシステムの有効期間中に存在するため、このレイヤーは多くの場合、グローバルな geo レプリケート状態を格納する役割を担います。 |
| リーチ | リソースをグローバルに分散し、それらのリソースをホストするリージョンにレプリケートする必要があります。 これらのリソースは、待機時間が短く、必要な一貫性を持つリージョンまたは他のリソースと通信することをお勧めします。 |
| 依存関係 | リソースを使用できない状態がグローバル障害の原因になる可能性があるため、リソースはリージョン リソースへの依存関係を回避する必要があります。 たとえば、1 つのコンテナーに保持されている証明書やシークレットは、コンテナーが配置されているリージョンで障害が発生した場合、グローバルに影響を与える可能性があります。 |
| スケールの上限 | 多くの場合、これらのリソースはシステム内のシングルトン インスタンスであり、システム全体のスループットを処理できるようにスケーリングできる必要があります。 |
| 可用性とディザスター リカバリー | リージョン リソースとスタンプ リソースでは、グローバル リソースを使用できます。 グローバル リソースは、システム全体の正常性に合わせて高可用性とディザスター リカバリーを使用して構成することが重要です。 |
リージョン スタンプ リソース
スタンプには、ビジネス トランザクションの完了に参加するアプリケーションとリソースが含まれます。 スタンプは通常、Azure リージョンへのデプロイに対応します。 しかし、リージョンは複数のスタンプを持つことができません。
| 特徴 | 考慮事項 |
|---|---|
| 有効期間 | スタンプ外のリージョン リソースが引き続き保持されている間、リソースの追加と削除を動的に行うことができるようにすることを意図して、リソースは短い存続期間 (一時的) が予想されます。 一時的な性質は、ユーザーにより多くの回復性、スケール、近接性を提供するために必要です。 |
| State | スタンプはエフェメラルであり、デプロイごとに破棄されるため、スタンプは可能な限りステートレスにする必要があります。 |
| リーチ | リージョンおよびグローバル リソースと通信できます。 ただし、他のリージョンや他のスタンプとの通信は避ける必要があります。 |
| 依存関係 | スタンプ リソースは独立している必要があります。 リージョンとグローバルの依存関係が必要ですが、同じリージョンまたは他のリージョンの他のスタンプのコンポーネントに依存しないでください。 |
| スケールの上限 | スループットはテストによって確立されます。 スタンプ全体のスループットは、最もパフォーマンスの低いリソースに制限されます。 スタンプ スループットは、別のスタンプへのフェールオーバーによって発生する高レベルの需要を見積もる必要があります。 |
| 可用性とディザスター リカバリー | スタンプの一時的な性質のため、ディザスター リカバリーはスタンプを再デプロイすることによって行われます。 リソースが異常な状態にある場合は、スタンプ全体を破棄して再デプロイできます。 |
リージョン リソース
システムは、リージョンにデプロイされているが、スタンプ リソースよりも長く存在するリソースを持つことができます。 たとえば、スタンプを含むリージョン レベルでリソースを監視する可観測リソースです。
| 特徴 | 考慮事項 |
|---|---|
| 有効期間 | リソースはリージョンの有効期間を共有し、スタンプ リソースをライブで公開します。 |
| State | リージョンに格納されている状態は、リージョンの有効期間を超えて存続することはできません。 リージョン間で状態を共有する必要がある場合は、グローバル データ ストアの使用を検討してください。 |
| リーチ | リソースをグローバルに分散する必要はありません。 他のリージョンとの直接通信は、必ず回避する必要があります。 |
| 依存関係 | スタンプは有効期間が短いため、リソースはグローバル リソースに依存できますが、スタンプ リソースには依存しません。 |
| スケールの上限 | リージョン内のすべてのスタンプを組み合わせて、リージョン リソースのスケール制限を決定します。 |
ミッション クリティカルなワークロードのベースライン アーキテクチャ
これらのベースラインの例は、ミッション クリティカルなアプリケーションに推奨される北starアーキテクチャとして機能します。 ベースラインでは、コンテナー化と、アプリケーション プラットフォーム用のコンテナー オーケストレーターの使用を強くお勧めします。 ベースラインでは、Azure Kubernetes Service (AKS) が使用されます。
「適切に設計されたミッション クリティカルなワークロード: コンテナー化」を参照してください。
-
-
ネットワーク制御を使用したベースライン
このアーキテクチャは、ベースライン アーキテクチャに基づいています。 この設計は、インターネットからワークロード リソースへの未承認のパブリック アクセスを防ぐために、厳密なネットワーク制御を提供するように拡張されています。
-
Azure ランディング ゾーンのベースライン
このアーキテクチャは、より広範なorganization内での統合が必要なエンタープライズ セットアップでワークロードをデプロイする場合に適しています。 ワークロードは、一元化された共有サービスを使用し、オンプレミスの接続を必要とし、企業内の他のワークロードと統合します。 これは、Corp. 管理グループから継承する Azure ランディング ゾーン サブスクリプションにデプロイされます。
-
App Services を使用したベースライン
このアーキテクチャは、App Services をプライマリ アプリケーション ホスティング テクノロジと見なすことでベースライン参照を拡張し、コンテナーのデプロイに使いやすい環境を提供します。
設計領域
提供されている設計ガイダンスを使用して、設計上の主要な決定事項をナビゲートして最適なソリューションに到達することをお勧めします。 詳細については、「主要な設計領域とは」を参照してください。
次のステップ
ミッション クリティカルなアプリケーション シナリオを設計するためのベスト プラクティスを確認します。