物理的距離

アプリケーションが COS に要求を出すときには、ある程度の物理的な距離を越える必要があります。  この距離が増えると、要求の待ち時間も増加します。 物理的な距離によって課される待ち時間を短縮するために、可能な場合はコンピュート・リソースとオブジェクト・ストレージを同じ場所に配置することが最適です。 アプリケーションが us-south 領域の IBM Cloud で実行されている場合は、パフォーマンスを最適化するために、 us-south 領域にもあるバケットに対してデータの読み取りと書き込みを行うことをお勧めします。

広範囲に及ぶ場所にあるデータにアクセスする必要があるワークロードでは、 IBM Asperaを使用すると、特に重大なパケット・ロスが発生した場合にメリットが得られる可能性があります。  IBM Aspera High-Speed Transfer および COS の使用方法について詳しくは、「 Aspera 」ガイドを参照してください。

グローバルなリーチを持つアプリケーションは、 Content Delivery Network を使用して、エンド・ユーザーに近い場所の COS に保管されている資産をキャッシュに入れることでメリットを得られます。  元のファイルは引き続きバケットでホストされますが、ユーザーが要求を発信する世界中のさまざまな場所にコピーをキャッシュすることができます。

レジリエンシー要件

ワークロードによっては、クロス・リージョン・バケットへのデータの書き込みに伴う追加レベルの回復力を必要とするものもあれば、単一データ・センター・バケットで検出される限界パフォーマンスの向上に依存するものもあります。  各アプリケーションは、可用性の向上とパフォーマンスの高速化のバランスを取る必要があります。

クロス・リージョン・エンドポイントを使用すると、3 つのリージョンすべてにデータを分散させながら、インバウンド・トラフィックを特定のアクセス・ポイントに送信することができます。 個々のアクセス・ポイントに要求を送信する場合、 その領域が使用不可になっても自動フェイルオーバーは行われません。 トラフィックを geo エンドポイントの代わりにアクセス・ポイントに送信するアプリケーションは、領域間ストレージの可用性の利点を実現するために、適切なフェイルオーバー・ロジックを内部で実装する 必要があります。

アクセス・ポイントを使用する理由の 1 つは、データの入口と出口がどこで発生するかを制御しながら、可能な限り最も広い領域にデータを分散させることです。 米国クロス・リージョン・バケットにデータを保管したいが、すべての読み取りおよび書き込み要求がダラス・エリアに残るようにしたい、 us-south リージョンで実行されているアプリケーションを想定します。

1. アプリケーションは、 https://s3.private.dal.us.cloud-object-storage.appdomain.cloud エンドポイントを使用してクライアントを作成します。
2. ダラスの COS サービスで障害が発生しています。
3. アプリケーションが、アクセス・ポイントを使用しようとしているときに、永続的な障害を検出しました。
4. アプリケーションは、別のアクセス・ポイント (サンノゼなど) にフェイルオーバーする必要があることを認識します。
5. アプリケーションは、 https://s3.private.sjc.us.cloud-object-storage.appdomain.cloud エンドポイントを使用して新規クライアントを作成します。
6. 接続が再開され、サービスが復元されたときにアクセスをダラスに再ルーティングできます。

対照的に、米国の通常の地域間エンドポイントを使用する別のアプリケーションを想像してみてください。

1. アプリケーションは、 https://s3.us.cloud-object-storage.appdomain.cloud エンドポイントを使用してクライアントを作成します。
2. ダラスの COS サービスで障害が発生しています。
3. サービスが復元されるまで、すべての COS 要求は自動的にサンノゼまたはワシントンに転送されます。

ネットワーク・タイプ

COS に送信されるトラフィックは、Public、Private、または Direct の 3 つのネットワークのいずれかから発生する可能性があります。 ターゲットとなるネットワークは、バケットへのアクセスに使用される COS サービス・エンドポイントによって定義されます。 バケットは単一の場所 (Cross Region、Regional、または Single Site など) に作成されますが、上記の 3 つのネットワーク・タイプのいずれかを介して同じバケットにアクセスすることは引き続き可能です。

パブリック・トラフィックは、 IBM Cloud に到達するまでパブリック・インターネットをトラバースし、COS 分散ストレージ・ネットワークにトラフィックを転送するロード・バランサーにルーティングされます。 プライベート・トラフィックは IBM Cloud 内で発生し、パブリック・インターネットにアクセスすることはありません。  直接トラフィックは、ローカル・データ・センターと IBM Cloud リソースの両方を含む可能性がある仮想プライベート・クラウドで発生します。 このアーキテクチャーには IBM Direct Linkが必要です。ユーザーは、パブリック・インターネットに接続することなく、(リバース・プロキシーを使用して) ユーザーのデータ・センターからプライベート IBM Cloud ネットワークに直接接続できます。

プライベート・ネットワークでは、パブリック・インターネットで検出された差異、輻輳、脆弱性がすべて除去されるため、可能な限りすべてのワークロードでプライベート・ネットワークを使用することをお勧めします。