バックツーオリジンルールを設定すると、OSS では元のサイトからリクエストされたデータが複数の方法で検索して読み込まれ、頻繁にアクセスされる (ホット) データの移行要件や特定のリクエストリダイレクトの要件を満たします。

この設定により、各 OSS GET リクエストの URL を一致させることができ、元サイトの検索方法が指定されます。 最大 5 つのルールを設定できます。 有効なルールと一致するまで、リクエストが設定された順序でルールと比較されます。 指定する方法は、ミラーリングまたはリダイレクトです。

ミラーリング



ミラーリングプロセスは、次のとおりです。クライアントからオブジェクトのデータがリクエストされます。 OSS でオブジェクトが存在しないと判断されると、リクエストはソース URL に転送されます。 オブジェクト が OSS を介してソース URL から返され、クライアントに送信されます。 同時に、オブジェクトデータが OSS に書き込まれるため、これから先にリクエストがあった場合、処理できます。

シナリオ例

ミラーリングライトバック機能は、データをシームレスに OSS に移行します。 つまり、ユーザーが構築したサイトや別のクラウド製品で 既に稼働しているサービスは、 サービスを中断することなく OSS に移行できます。 詳細なシナリオは、次のとおりです。

  • オリジンサイトでは、新規のホットデータが生成され、またレガシーコールドデータ も保存されています。

    まず、ユーザーは移行ツール ossimport を使用して、コールドデータを OSS に移行できます。移行中、 ユーザーはミラーリングライトバックを設定し、オリジンサイトの URL を OSS に設定します。 ドメイン名を OSS に切り替えたときに 新しく生成されたデータが移行されない場合でも、 ユーザーは OSS を介してそのデータにアクセスできます。 ファイルは初めてアクセスされた後に OSS に保存されます。 新しいデータが生成されなくなったオリジンサイトの ドメイン名を切り替えると、そのサイトがスキャンされ、 移行されていない全データが OSS にインポートされます。 この場合、ユーザーはミラーリングの 書き戻しを無効にすることができます。

    オリジンサイトに IP アドレスが設定されている場合は、ドメイン名が OSS に移行された後も、 データはオリジンサイトにミラーリングされます。

  • ただし、オリジンサイトがドメイン名の場合、ドメイン名は OSS または CDN に解決されるため、 ミラーリングは作成されません。 この場合、ユーザーは別のドメイン名を申請してオリジンサイトを ミラーリングします。

    このドメイン名と稼働中のドメイン名は、どちらも 同じ IP アドレスに解決されます。 これにより、サービスドメイン名が移行されたとき にオリジンサイトのイメージングを続行できます。

利用規約
  • GetObject（）によって 404 コードが返される場合、OSS ではミラーリング書き戻しが実行され、 オリジンサイトのオブジェクトがリクエストされます。
  • オリジンサイトからリクエストされた URL は、 MirrorURL +オブジェクト で、OSS に書き戻されるファイル名はオブジェクトです。 たとえば、バケット名が example-bucket で、 ミラーリング書き出しが設定されているとします。 MirrorURL は http://www.example-domain.com/です。 ファイル "object.jpg" は、このバケット内に格納されていません。 ファイルをダウンロードするため、OSS では http://www.example.com/object.jpg に対して GET リクエストが実行されます。結果が OSS に保存されてから、ユーザーに返されます。 ファイルは、OSS 上で "object.jpg" として利用できます。 これは、同じ名前のオブジェクトを OSS に移行するのと同じです。 MirrorURL が http://www.example-domain.com/dir1/ のようなパス情報を持っている場合、プロセスは前述の例と同じです。ただし、OSS に書き込まれたオブジェクトは、"object.jpg" のままですが、OSS オリジン検索 URL は http://www.exampledomain.com/dir1/image/example_object.jpg です。 このプロセスは、オリジンサイトのディレクトリから OSS にオブジェクトを移行するときと同じです。
  • OSS に送信されたヘッダーおよびクエリ文字列情報は、 オリジンサイトには送信されません。
  • データがオリジンサイトからチャンク方式で返される場合、データは OSS からユーザーに チャンク方式で返されます。
  • OSS はオリジンサイトから以下のヘッダ情報を返して保存します。 
    Content-Type
Content-Encoding
Content-Disposition
Cache-Control
Expires
Content-Language
Access-Control-Allow-Origin
  • "MIRROR" + space + url_decode (オリジン検索 URL) という値を加えた x-oss-tag レスポンスヘッダーが、ミラーリング書き戻しファイルに追加されます。 上記の 例では、 次のようになります。 
    x-oss-tag:MIRROR http%3a%2f%2fwww.example-domain.com%2fdir1%2fimage%2fexample_object.jpg
    ファイルが OSS に書き戻された後、 再度上書きされない限り、ミラーリングから取得されたことを示すために、 ダウンロードのたびにこのヘッダーが追加されます。
  • ミラーリング書き戻しによってファイルがすでに OSS に書き込まれていると想定した場合、 オリジンサイト上の対応するファイルが変更されても、 OSS に格納されているファイルは更新されません。 OSS に既存のファイルは、ミラーリングの書き戻し 条件を満たしていません。
  • ファイルがミラーリングのソースに存在しない場合、 HTTP ステータス 404 が返されます。このステータスは、OSS を介してユーザーに転送されます。 ミラーリングソースが 200 以外のステータスコード (ネットワーク関連の原因によるファイル 取得の失敗など) が返される場合、ステータス 424 がユーザーに返されます。 これは、MirrorFailed を表すエラーコードです。

リダイレクト

URL リダイレクト機能により、ユーザー定義の条件と対応するホップ構成に基づいて、3xx ホップがユーザーに返されます。 ユーザーはこのホップ機能を使用してファイルをリダイレクトし、このアクションに基づいてさまざまなサービスを提供できます。 プロセスは次のとおりです。



アプリケーションシナリオ

  • データソースを OSS へ移行

    ユーザーは非同期にデータを OSS に移行できます。 このように、移行されていないデータに対するリクエストでは、 URL 書き換えメソッドを使用して 302 リダイレクトリクエストがユーザーに返されます。 次に、302 リダイレクトリクエスト内の位置に基づいて、ユーザーのクライアントのデータソースからデータが返されます。

  • ページリダイレクト機能の設定

    ユーザーが特定のヘッダープレフィックスを使用してオブジェクトを非表示にしたい場合は、カスタマイズしたページをサイト訪問者に表示できます。

  • 404 または 500 エラーが発生したときにリダイレクトされるページの設定

    404 または 500 エラーが発生した場合、ユーザーはライブページにリダイレクトされます。 これにより、OSS エラーがユーザーによって検出されなくなります。

参照