シングルゾーン展開

シングルゾーン配備では、複数のアプリケーションインスタンスが1つのゾーンに配備される。 アプリケーションインスタンスが1つの仮想サーバーで実行される場合、 Placement Groups を使用すると、これらの仮想サーバーを別々の物理ホストにプロビジョニングできます。 VPC Autoscale を使用すると、ワークロードの変化に基づく動的な容量調整が可能になります。 シングルゾーンの導入は、 99.9のインフラ可用性を備えたコスト効率の高いソリューションを提供します。 この配備は、非本番環境や非ビジネスクリティカルなアプリケーションに適しているかもしれない。 しかし、単一ゾーンの配備では、ゾーン停止からの保護はない。

この展開モデルを使用する際は、ゾーン間の不均衡が生じないようにすることがベストプラクティスです。 ゾーン間の不均衡とは、VPC 仮想サーバーインスタンス（VSI）などのリソースが、各ゾーンに均等に分散されていない状態を指します。 あるワークロードが、VSI容量の70%をゾーン1に、20%をゾーン2に、10%をゾーン3に割り当ててデプロイされている例を考えてみましょう。 ゾーン1に障害が発生した場合、ワークロードは引き続き利用可能ですが、その処理能力は30％に低下する可能性があります。 一つの解決策として、ゾーン1で障害が発生した場合にリソースを追加で割り当てるという方法がありますが、その障害により、残りのゾーンで容量需要が異常に急増する可能性があります。 より良い解決策は、不均衡を解消し、必要な処理能力を各ゾーンに分散させることです。その際、いずれかのゾーンで障害が発生した場合の損失を補うため、各ゾーンに約17％の余裕を持たせる必要があります。 これにより、ゾーンの障害が発生した場合でも、ワークロードの可用性が確保され、フル稼働を維持できるようになります。

マルチゾーン、単一リージョン展開

マルチゾーン、シングルリージョンの展開では、複数のアプリケーションインスタンスが、リージョン内の2つ以上のアベイラビリティゾーンにまたがって展開される。 マルチゾーン・シングルリージョン構成では、アプリケーションを3つのアベイラビリティゾーンにまたがってデプロイすることで、最大 99.99 ％のインフラストラクチャ可用性を実現できます。 この展開方法により、アプリケーションをゾーン障害から保護することができ、可用性要件が 99.9 ％を超える本番環境レベルのエンタープライズワークロードに適しています。 実際のアプリケーションの可用性は、アプリケーションの高可用性設計に依存する。

このデプロイメントモデルを使用する際は、ゾーン間の不均衡が生じないようにしてください。 ゾーン間の不均衡は、 IBM Cloud® Virtual Servers for Virtual Private Cloud （VSI）などの処理能力がゾーン間で均等に分散されていない場合に発生します。 ワークロードのVSI容量の70%がゾーン1に、20%がゾーン2に、10%がゾーン3に割り当てられてデプロイされている例を考えてみましょう。 ゾーン 1 が障害を起こした場合、ワークロードは引き続き利用可能ですが、その処理能力は 30% に低下する可能性があります。 障害が発生した際にリソースを追加で割り当てることは可能ですが、障害によって残りのゾーン全体で容量需要が異常に急増する可能性があります。 その代わりに、必要な処理能力を各ゾーンに均等に配分することで不均衡を解消し、さらに、いずれかのゾーンが停止した場合の損失を補うために、ゾーンごとに約17％の余裕を持たせるようにします。 これにより、あるゾーンに障害が発生した場合でも、ワークロードの可用性が確保され、フル稼働を維持できるようになります。

マルチゾーン、マルチリージョン展開

マルチゾーン、マルチリージョンの配備は、地域の停電に対する保護を提供する。 この配備は、継続的またはほぼ継続的な可用性が要求されるミッションクリティカルなアプリケーションに推奨される。 この配備は、地域間または特定の分離距離の要件があるアプリケーションの地域外災害復旧と事業継続もサポートします。

マルチゾーンの導入は、アベイラビリティ・ゾーン間のアプリケーション・アウェア・データ・レプリケーションに依存し、アクティブ・アクティブおよびアクティブ・スタンバイのアーキテクチャ・パターンをサポートします。 マルチゾーン、マルチリージョンのデプロイは、継続的な可用性と常時オンの要件を持つエンタープライズ・アプリケーションのアーキテクチャ・パターンをサポートします。 以下の表は、さまざまな配備オプションと推奨される使用方法の比較である。

以下のアーキテクチャー・フレームワークは、 IBM Cloud Virtual Private Cloud （VPC）インフラストラクチャー上にレジリエントなアプリケーションをデプロイするための設計上の考慮事項とアーキテクチャー上の決定を提供します。 以下のソリューションの側面と領域をカバーしている：

• ネットワーキングロードバランシング、ドメインネームシステム
• セキュリティデータ・セキュリティ
• 回復力： 高可用性、バックアップと復元、災害復旧
• サービス管理： モニタリング、ログ、監査、アラート

アーキテクチャ設計フレーム ワークは、一連の側面とドメインにまたがる要件に対処することで、クラウド・ソリューションを設計するための一貫したアプローチを提供する。 ドメインは、テクノロジーに関係なく、あらゆる企業ソリューションに考慮が必要なアーキテクチャ領域である。

可用性の高いアプリケーションのためのクライアント再試行ロジック

あなたは、一時的なエラーを効果的に処理できるクライアント・アプリケーションを構築する責任がある。 一時的なエラーには、ネットワークエラーや、地域サービスがゾーン障害から回復するときのように、サービスの高可用性実装によってもたらされる一時的な障害が含まれる。 特定の IBM Cloud サービスの詳細については、 高可用性とディザスタリカバリに関するサービスのドキュメント を参照してください。

IBM Cloud SDKの多くは、429や503エラーのような特定の HTTP エラーに対処するために設計された自動再試行をサポートする IBM Cloud SDK共通。 SDKはすべてのエラーを自動的に処理するわけではありません。 リトライロジックを利用するには、SDKを正しく設定する必要があります。

一部の IBM Cloud サービスはオープンソースのプロトコルをサポートしており、オープンソースのSDKを使用することが適切な場合があります。 これらのSDKを調べて、あなたのアプリケーションに有用かどうか、適切なリトライ機能を提供しているかどうかを判断してください。

再試行ロジックは、 IBM Cloud サービスのタイプと操作のタイプによって異なります。 失敗した操作の中には、再試行に適したステータスコードを生成するものもあれば、再試行に適さないステータスコードを生成するものもある。 失敗した読み取りと HTTP GET操作は、一般に、一定の時間周期で指数関数的バックオフを使用することで再試行できる。 エクスポネンシャル・バックオフは、ネットワーク・リクエストやAPIコールのような操作失敗後の再試行を管理するための再試行戦略である。 指数関数的なパターンで再試行間の遅延を徐々に増加させ、システムに過負荷をかけるリスクを軽減する。 再試行されるべき失敗は、失敗のタイプと特定の IBM Cloud サービスによって異なる。 詳細については、 IBM Cloud サービスのSDKとドキュメントを参照してください。

失敗した書き込み、 HTTP PUT、POST、DELETE、およびその他の操作は、操作が完了しなかったことが明らかで、文書化されたクライアントロジックが再試行が適切であることを示していない限り、単純な再試行メカニズムを使用しても回復できない可能性が高いです。 リソースの作成など、システムの状態を変更する操作が失敗した場合、何が原因で失敗したのか不明なことが多い。 このような不確実性があるため、単純な再試行ロジックに頼って問題を解決することはできない。 代わりに、 IBM Cloud サービス専用に設計された、より高度なメソッドを使用してください。

クライアントの再試行は単一クライアントの可用性を向上させ、ワークロードは多数のクライアントで構成される。 クライアントの障害を IBM Cloud Logs のような集中型ログサービスにログ記録することで、ワークロード全体の障害と可用性の分析が可能になります。