プールに配置できます。複数のゾーンに配置できます。ベースのプロパティが適用されます。アドレスは、すべてのゾーンによって処理されます。アドレスは、それが保証されているゾーンによってのみ処理されます。これは、影響を受けたゾーンによってフローが処理された場合、ゾーン冗長のシナリオで転送または接続の再確立が必要になることがあります。影響を受けるゾーン以外のゾーン内のフローは、影響を受けません。ポートの事前割り当てアルゴリズムは、可用性ゾーンがあってもなくても同じです。probes既存の正常性プローブの定義は、可用性ゾーンがない場合でも同じです。レベルで拡張されています。内部正常性モデルは、各可用性ゾーンからの仮想マシンの到達可能性を独立してプローブし、障害が発生した可能性のあるゾーンとのパスをユーザーの介入なしにシャットダウンするように、拡張されます。この障害を検出して回避することができます。処理を続けることができます。エンドのサービスの全体的な正常性を保護するために、各ゾーンで新しいフローのディストリビューションが若干異なる可能性があります。可用性ゾーンのコンテキストにおいて柔軟性を持つように意図されています。ゾーンに一致させることも、規則ごとにゾーン冗長にすることもできます。可用性を高めると複雑さが増す可能性があり、パフォーマンスが最適になるように可用性を設計する必要があります。以下では、設計に関する重要な考慮事項を示します。アドレスを簡単に持つことができます。複数のゾーンで障害があっても存続できます。ベースのフロントエンドは、単一のゾーンへのサービスの縮小であり、対応するゾーンの正常性に依存します。プレーンを明示します。ゾーン冗長なフローは任意のゾーンを使うことができ、ユーザーのフローはリージョン内で正常なすべてのゾーンを使います。フローは影響を受けません。フローは影響を受ける可能性がありますが、アプリケーションは復旧できます。ゾーンの障害を収束したら、再送信または再確立時にリージョン内に残っている正常なゾーンでこれらのフローを続行できます。つのゾーンではなく複数のゾーンの正常性に依存する可能性があることを理解しておくことが重要です。ベースではない展開より可用性が高くならない可能性があります。deployments.可用性ゾーンを使ったときの可用性のメリットがなくなる、意図しないクロスゾーンの依存関係が発生しないようにします。アプリケーションが複数のコンポーネントで構成されていて、ゾーンの障害に対する回復力が必要な場合は、ゾーンで障害が発生したときに十分な数の重要なコンポーネントが存続するように注意する必要があります。つの重要なコンポーネントが、障害を存続できなかったゾーンに存在していた場合、アプリケーション全体に影響する可能性があります。ゾーンの復元とアプリケーションの収束方法についても検討します。アプリケーションがその一部の障害に関してどのように判別するかを理解する必要があります。以下で確認する重要な点を、特定のシナリオについて考えるときの質問の参考にしてください。サービスは存続できません。ベースのシナリオでゾーンをクロスさせないようにしてください。このシナリオでは柔軟性を提供できます。エンドのサービスは存続できます。フロントエンドの到達可能性だけを観察している場合は、サービスの正常性を判断する機能が若干失われます。広範な正常性と容量のモデルの開発を検討します。ベースの概念を組み合わせて、洞察と管理容易性を拡張する場合があります。サービスの容量はゾーン障害の間に低下する可能性があります。以上のゾーンで障害が発生しても展開は存続することができ、これにより次のような質問が発生します。questions:このような障害および容量低下をアプリケーションが判断する方法を理解していますか。ペアに強制的にフェールオーバーする安全策が必要ですか。necessary?どのような方法で、このようなシナリオを監視、検出、軽減しますか。サービスのパフォーマンスの監視を強化できる場合があります。使用可能なもの、および全体像のために拡張が必要なものを検討します。picture.ゾーンを使うと、障害の把握と阻止が容易になる可能性があります。アルゴリズムなどの概念に関しては、ゾーンの障害も他の障害と違いはありません。レベルでは、障害が発生すると再送信または再確立が行われる可能性があり、アプリケーションが障害に対処する方法を理解しておくことが重要です。負荷分散スキームは存続しますが、次のことを計画する必要があります。サービスはそれを認識しますか。状態が失われた場合、どのようにして復旧しますか。recover?ゾーンが復帰したとき、アプリケーションは安全に収束する方法を認識しますか。クラウド設計パターンに関する記事を参照してください。アドレスでの回復性オプションの併用により、シンプルさを実現します。複雑さを低下させることができます。ゾーン冗長は、ゾーンを越えて移動することもでき、任意のゾーンのリソースで安全に使用できます。可用性ゾーンのないリージョンでも将来的に保証されており、リージョンで可用性ゾーンを利用できるようになったときに必要な変更を制限できます。アドレスまたはフロントエンドの構成構文は、可用性ゾーンがないリージョンも含めて、すべてのリージョンで成功します。プロパティ内で指定されません。つのゾーンに対する明示的な保証を提供し、そのゾーンの正常性に明示的に依存します。ベースの仮想マシンであるときは特に望ましい場合があります。なければおそらく、アプリケーションはリソースが存在するゾーンを前もって明確に知る必要があり、ユーザーは別のゾーンの可用性を明示的に判別する必要があります。ベースのフロントエンド)。サービスを公開することができます。パーティ製の監視ソリューションによりゾーンごとの正常性とパフォーマンスの洞察を取得でき、ゾーン冗長なフロントエンドでサービス全体を公開することができます。シナリオは回避する必要があります。ベースのリソースは、可用性ゾーンが存在するリージョンにのみ存在します。アーキテクチャを理解することなく、選択肢の優劣を判断するための一般的なガイダンスはありません。クラウド設計パターンに関する記事を参照してください。クラウド設計パターンについての記事を確認する。scenarios.お勧めのコンテンツこのページはお役に立ちましたか?はいいいえ追加のフィードバックはありますか?スキップ送信ありがとうございます。直接フィードバックを残すこともできます。直接フィードバックを残すこともできます。Cookie利用条件サイトのフィードバック商標このページはお役に立ちましたか?はいいいえ追加のフィードバックはありますか?スキップ送信ありがとうございます。Cookie利用条件サイトのフィードバック。