Object Storage Service:ミラーリングベースのオリジンフェッチ

ステップ 1: ミラーリングベースのオリジンフェッチルールを設定する

1. [バケット] ページに移動し、ターゲットバケットの名前をクリックします。

2. 左側のナビゲーションウィンドウで、[データ管理] > [ミラーリングベースのオリジンフェッチ] を選択します。

3. [ミラーリングベースのオリジンフェッチ] ページで、[ルールの作成] をクリックします。

4. [ルールの作成] パネルで、パラメーターを設定します。言及されていないパラメーターについては、デフォルト値を保持します。

   パラメーター	構成
   オリジンフェッチタイプ	[ミラー] を選択します。
   オリジンフェッチ条件	[ファイル名のプレフィックス] を選択し、「examplefolder/」と入力します。
   ソース URL	最初の列 (プロトコル) で https を選択します。2 番目の列 (ドメイン名) に example.com と入力します。3 番目の列 (パスプレフィックス) は空のままにします。パスプレフィックスはドメイン名に追加され、ソース URL のパス部分を形成します。

5. OK をクリックします。

ステップ 2: ルールを検証する

1. https://examplebucket.oss-cn-hangzhou.aliyuncs.com/examplefolder/example.txt にアクセスします。

2. examplefolder/example.txt オブジェクトが examplebucket に存在しない場合、OSS はオブジェクトを求めて https://example.com/examplefolder/example.txt にリクエストを送信します。

3. オブジェクトをフェッチした後、OSS はそれを examplefolder/example.txt に名前を変更し、examplebucket に保存して、リクエスタにオブジェクトを返します。

ステップ 1: ミラーリングベースのオリジンフェッチルールを設定する

1. [バケット] ページに移動し、ターゲットバケットの名前をクリックします。

2. 左側のナビゲーションウィンドウで、[データ管理] > [ミラーリングベースのオリジンフェッチ] を選択します。

3. [ミラーリングベースのオリジンフェッチ] ページで、[ルールの作成] をクリックします。

4. [ルールの作成] パネルで、次の表で説明されているように必須パラメーターを設定します。他のパラメーターについては、デフォルトの構成を保持します。

   パラメーター	構成
   オリジンフェッチタイプ	[ミラー] を選択します。
   オリジンフェッチ条件	[ファイル名のプレフィックス] を選択し、examplefolder/ に設定します。
   プレフィックスの置換または切り捨て	[プレフィックスの置換または切り捨てを有効にする] を選択し、destfolder/ に設定します。 説明 このオプションは、[オリジンフェッチ条件] セクションで [ファイル名のプレフィックス] を設定した後にのみ表示されます。
   ソース URL	最初の列を https に、2 番目の列を example.com に設定し、3 番目の列は空のままにします。
   MD5 の確認	[MD5 チェックを有効にする] を選択します。back-to-origin リクエストへの応答に Content-MD5 フィールドが含まれている場合、OSS はフェッチされたファイルの MD5 ハッシュが Content-MD5 フィールドの値と一致するかどうかを確認します。 一致: クライアントはファイルを取得し、OSS はフェッチされたファイルを保存します。 不一致: MD5 ハッシュの計算には完全なファイルデータが必要であり、ファイルはすでにクライアントにパススルーされているため、クライアントはファイルを取得できますが、OSS はそれを保存しません。

5. [OK] をクリックします。

ステップ 2: ルールを検証する

1. https://bucket-01.oss-cn-hangzhou.aliyuncs.com/examplefolder/example.txt にアクセスします。

2. examplefolder/example.txt オブジェクトが bucket-01 に存在しない場合、OSS はオブジェクトを求めて https://example.com/destfolder/example.txt にリクエストを送信します。

3. オブジェクトをフェッチした後、OSS は次の操作を実行します。

   • back-to-origin 応答に Content-MD5 フィールドが含まれている場合、OSS はフェッチされたオブジェクトの MD5 ハッシュを計算し、Content-MD5 フィールドの値と比較します。MD5 ハッシュが一致する場合、OSS はオブジェクトの名前を examplefolder/example.txt に変更し、bucket-01 に保存して、リクエスタにオブジェクトを返します。MD5 ハッシュが一致しない場合、OSS はオブジェクトをユーザーに返しますが、bucket-01 には保存しません。

   • back-to-origin 応答に Content-MD5 フィールドが含まれていない場合、OSS はオブジェクトの名前を examplefolder/example.txt に変更し、bucket-01 に保存して、リクエスタにオブジェクトを返します。

ステップ 1: ミラーリングベースのオリジンフェッチルールを設定する

1. [バケット] ページに移動し、ターゲットバケットの名前をクリックします。

2. 左側のナビゲーションウィンドウで、[データ管理] > [ミラーリングベースのオリジンフェッチ] を選択します。

3. [ミラーリングベースのオリジンフェッチ] ページで、[ルールの作成] をクリックします。

4. [ルールの作成] パネルで、以下に説明するように 2 つのミラーリングベースのオリジンフェッチルールを設定します。他のパラメーターについては、デフォルトの構成を保持します。

   • ルール 1

     パラメーター	構成
     オリジンフェッチタイプ	[ミラー] を選択します。
     オリジンフェッチ条件	[ファイル名のプレフィックス] を選択し、dir1/ に設定します。
     プレフィックスの置換または切り捨て	[プレフィックスの置換または切り捨てを有効にする] を選択し、example1/ に設定します。 説明 このオプションは、[オリジンフェッチ条件] セクションで [ファイル名のプレフィックス] を設定した後にのみ表示されます。
     ソース URL	最初の列を https に、2 番目の列を example.com に設定し、3 番目の列は空のままにします。
     3xx 応答ポリシー	[オリジンサーバーのリダイレクトに従う] を選択します。 説明 [オリジンサーバーのリダイレクトに従う] が選択されていない場合、OSS はオリジンサーバーのリダイレクトルールで指定されたアドレスをリクエスタに直接返します。

   • ルール 2

     パラメーター	構成
     オリジンフェッチタイプ	[ミラー] を選択します。
     オリジンフェッチ条件	[ファイル名のプレフィックス] を選択し、dir2/ に設定します。
     プレフィックスの置換または切り捨て	[プレフィックスの置換または切り捨てを有効にする] を選択し、example2/ に設定します。 説明 このオプションは、[オリジンフェッチ条件] セクションで [ファイル名のプレフィックス] を設定した後にのみ表示されます。
     ソース URL	最初の列を https に、2 番目の列を example.org に設定し、3 番目の列は空のままにします。
     3xx 応答ポリシー	[オリジンサーバーのリダイレクトに従う] を選択します。

5. [OK] をクリックします。

ステップ 2: ルールを検証する

1. https://bucket-02.oss-cn-beijing.aliyuncs.com/dir1/example.txt にアクセスします。

2. example.txt オブジェクトが dir1 ディレクトリの bucket-02 に存在しない場合、OSS はオブジェクトを求めて https://example.com/example1/example.txt にリクエストを送信します。

   • オリジンサーバー A に example1/example.txt のリダイレクトルールがある場合、OSS はリダイレクトルールで指定されたアドレスに新しいリクエストを送信します。オブジェクトをフェッチした後、OSS はそれを dir1/example1/example.txt に名前を変更し、bucket-02 に保存して、リクエスタに返します。

   • オリジンサーバー A に example1/example.txt のリダイレクトルールがない場合、OSS はオブジェクトをフェッチし、それを dir1/example1/example.txt に名前を変更し、bucket-02 に保存して、リクエスタに返します。

3. リクエスタが https://bucket-02.oss-cn-beijing.aliyuncs.com/dir2/example.txt にアクセスした場合、ミラーリングベースのオリジンフェッチルールによってフェッチされたオブジェクトは bucket-02 の dir2/example2 ディレクトリに保存されます。

ステップ 1: ミラーリングベースのオリジンフェッチルールを設定する

1. [バケット] ページに移動し、ターゲットバケットの名前をクリックします。

2. 左側のナビゲーションウィンドウで、[データ管理] > [ミラーリングベースのオリジンフェッチ] を選択します。

3. [ミラーリングベースのオリジンフェッチ] ページで、[ルールの作成] をクリックします。

4. [ルールの作成] パネルで、次の表で説明されているように必須パラメーターを設定します。他のパラメーターについては、デフォルトの構成を保持します。

   パラメーター	構成
   オリジンフェッチタイプ	[ミラー] を選択します。
   オリジンフェッチ条件	[ファイル名のプレフィックス] を選択し、examplefolder/ に設定します。
   オリジンサーバータイプ	[オリジンフェッチ用のプライベート OSS バケット] を選択し、[オリジンバケット] ドロップダウンリストから bucket-04 を選択します。 このオプションを設定すると、ユーザーが存在しないオブジェクトにアクセスしたときに、OSS はデフォルトのロール AliyunOSSMirrorDefaultRole を使用して、指定されたプライベートオリジンバケットからデータをフェッチします。データ取得プロセスには AliyunOSSReadOnlyAccess 権限が必要です。この権限により、OSS は読み取り専用モードでのみオリジンサーバーデータにアクセスでき、データの変更や削除を防ぐことができます。 Resource Access Management (RAM) ユーザーがプライベート OSS バケットのミラーリングベースのオリジンフェッチを設定する場合、RAM ユーザーは ram:GetRole 権限を持っている必要があります。この権限は、AliyunOSSMirrorDefaultRole ロールが存在するかどうかを確認するために使用されます。 ロールが存在する場合は、直接使用されます。 ロールが存在しない場合は、RAM ユーザーに関連付けられている Alibaba Cloud アカウントが事前に AliyunOSSMirrorDefaultRole ロールを作成し、このロールに AliyunOSSReadOnlyAccess 権限を付与することをお勧めします。これにより、ロールの作成 (ram:CreateRole) やロールへの権限の付与 (ram:AttachPolicyToRole) などのリスクの高い権限を RAM ユーザーに付与することを回避できます。権限付与が完了すると、RAM ユーザーは作成されたロールを直接再利用できるため、権限設定のリスクが軽減されます。
   ソース URL	最初の列を https に設定し、その他は空のままにします。
   オリジンフェッチパラメーター	[クエリ文字列を渡す] を選択します。 OSS は URL リクエストからオリジンサーバーにクエリ文字列を渡します。
   HTTP ヘッダーパススルールールを設定	[指定された HTTP ヘッダーパラメーターを渡す] を選択し、HTTP ヘッダー header1、header2、および header3 を追加します。back-to-origin ルールは、authorization、authorization2、range、content-length、date などの一部の標準 HTTP ヘッダー、または x-oss-、oss-、または x-drs- で始まる HTTP ヘッダーの受け渡しをサポートしていません。 重要 プライベートバケットからフェッチする場合、すべての HTTP ヘッダーパラメーターを渡すように選択しないでください。そうしないと、オリジンフェッチが失敗します。

5. [OK] をクリックします。

ステップ 2: ルールを検証する

1. https://bucket-03.oss-cn-shanghai.aliyuncs.com/examplefolder/example.png?caller=lucas&production=oss にアクセスします。

2. examplefolder/example.png オブジェクトが bucket-03 に存在しない場合、OSS はオブジェクトを求めて https://bucket-04.oss-cn-shanghai.aliyuncs.com/examplefolder/example.png?caller=lucas&production=oss にリクエストを送信します。

3. bucket-04 は、渡された ?caller=lucas&production=oss パラメーターに基づいて example.png オブジェクトを OSS に返します。

4. OSS はフェッチされたオブジェクトを examplefolder/example.png に名前を変更し、bucket-03 に保存します。

リクエストに HTTP ヘッダー header1、header2、および header3 も含まれている場合、それらも bucket-04 に渡されます。

シームレスなデータ移行

この移行ソリューションの詳細については、「ミラーリングベースのオリジンフェッチを使用して Alibaba Cloud OSS にサービスをシームレスに移行する」をご参照ください。

オリジンサーバーからフェッチしたオブジェクトをリフレッシュする

ミラーリングベースのオリジンフェッチは 1 回限りのキャッシュ機構であるため、オリジンサーバー上のソースオブジェクトが更新されても、OSS はオブジェクトを自動的にリフレッシュしたり再フェッチしたりしません。すでに OSS に保存されているオブジェクトをリフレッシュするには、次の方法を使用できます。

• 手動削除: コンソールまたは API を使用して OSS 内のオブジェクトを削除します。次回オブジェクトにアクセスすると、back-to-origin ルールが再度トリガーされます。

• ライフサイクルルール: オリジンサーバーからフェッチされたオブジェクトに有効期限ポリシーを設定して、一定期間後に自動的に削除されるようにします。これにより、定期的なリフレッシュが実現します。

• ファイル名のバージョン管理: オリジンサーバー上のオブジェクトを更新するときは、style.v2.css のように新しい名前を使用します。これにより、キャッシュの問題が根本的に回避され、推奨される方法です。

リスク防止とフォールトトレランス

• オリジンサーバーの負荷: オリジンサーバーに、back-to-origin リクエストを処理するのに十分な帯域幅と処理能力があることを確認してください。移行の初期段階では、back-to-origin リクエストの量が多くなる可能性があります。オリジンサーバーの負荷を監視し、オフピーク時にデータをプリフェッチすることをお勧めします。

• コスト管理: 予期せぬ高コストを防ぐために、Alibaba Cloud 管理センターでコストアラートを設定して、back-to-origin リクエストの量を監視することをお勧めします。

• セキュリティ構成: OSS がオリジンサーバーにアクセスできることを確認してください。ソース URL が HTTPS プロトコルを使用している場合は、オリジンサーバーの証明書が信頼できる認証局 (CA) によって発行されていること、ドメイン名が一致していること、および証明書の有効期限が切れていないことを確認してください。

• ログクエリ: リアルタイムログクエリ機能を使用して、back-to-origin ログを表示できます。back-to-origin リクエストの User-Agent には、文字列 aliyun-oss-mirror が含まれています。

オリジンサーバーからフェッチされたファイルのサイズがソースファイルのサイズと異なるのはなぜですか？

オリジンサーバーからフェッチされたオブジェクトのサイズがソースオブジェクトのサイズと異なる場合は、次のトラブルシューティング手順を実行してください。

1. フェッチされたオブジェクトとソースオブジェクトの Last-Modified タイムスタンプを確認します。

   import oss2
   import requests
   from datetime import datetime
   from oss2.credentials import EnvironmentVariableCredentialsProvider
   
   # 環境変数からアクセス資格情報を取得します。このサンプルコードを実行する前に、OSS_ACCESS_KEY_ID および OSS_ACCESS_KEY_SECRET 環境変数が設定されていることを確認してください。
   auth = oss2.ProviderAuthV4(EnvironmentVariableCredentialsProvider())
   
   # バケットが配置されているリージョンのエンドポイントを指定します。たとえば、バケットが中国 (杭州) リージョンにある場合、エンドポイントを https://oss-cn-hangzhou.aliyuncs.com に設定します。
   endpoint = "https://oss-cn-hangzhou.aliyuncs.com"
   
   # エンドポイントに対応するリージョン情報を指定します (例: cn-hangzhou)。このパラメーターは V4 署名に必要であることに注意してください。
   region = "cn-hangzhou"
   
   # yourBucketName を、ミラーリングベースのオリジンフェッチルールを設定したバケットの名前に設定します。
   bucket = oss2.Bucket(auth, endpoint, "yourBucketName", region=region)
   # オブジェクトファイルの完全なパスを指定します。
   object_key = 'yourObjectKey'
   # ソースファイルの完全なパスを指定します。
   source_url = 'yourSourceUrl'
   
   # フェッチされたファイルの Last-Modified タイムスタンプを取得します。
   oss_object_info = bucket.get_object_meta(object_key)
   oss_last_modified = oss_object_info.headers['last-modified']
   print(f"OSS Last-Modified: {oss_last_modified}")
   
   # ソースファイルの Last-Modified タイムスタンプを取得します。
   response = requests.head(source_url)
   source_last_modified = response.headers.get('last-modified')
   print(f"Source Last-Modified: {source_last_modified}")
   
   # 比較のためにタイムスタンプ文字列を datetime オブジェクトに変換します。
   oss_time = datetime.strptime(oss_last_modified, '%a, %d %b %Y %H:%M:%S %Z')
   source_time = datetime.strptime(source_last_modified, '%a, %d %b %Y %H:%M:%S %Z')
   
   if oss_time < source_time:
       print("ソースファイルが更新されました。")
   elif oss_time > source_time:
       print("フェッチされたファイルの方が新しいです。")
   else:
       print("2 つのファイルのタイムスタンプは同じです。")

   • ソースオブジェクトの Last-Modified タイムスタンプが、フェッチされたオブジェクトの Last-Modified タイムスタンプより後の場合、オブジェクトがフェッチされた後にソースオブジェクトが更新された可能性があります。

     説明

     OSS がオリジンサーバーからオブジェクトをフェッチして宛先バケットに書き込むとき、ソースオブジェクトの Last-Modified タイムスタンプ (ソースオブジェクトが最後に変更された時刻) は保持されません。代わりに、OSS は、フェッチされたオブジェクトの Last-Modified タイムスタンプを、ミラーリングベースのオリジンフェッチ機能を通じて OSS で作成または更新された時刻に設定します。

   • ソースオブジェクトの Last-Modified タイムスタンプが、フェッチされたオブジェクトの Last-Modified タイムスタンプより前または同じ場合、フェッチされたオブジェクトが生成されてからソースオブジェクトは更新されていません。次のステップに進み、MD5 または 64 ビット巡回冗長検査 (CRC-64) の値を確認します。

2. フェッチされたオブジェクトとソースオブジェクトの MD5 または CRC-64 の値を比較します。

   # -*- coding: utf-8 -*-
   import oss2
   import hashlib
   import requests
   # CRC-64 を比較するには、Python 標準ライブラリは CRC-64 をサポートしていないため、crcmod などのサードパーティライブラリを使用できます。
   # crcmod をインストールします: pip install crcmod
   import crcmod
   from oss2.credentials import EnvironmentVariableCredentialsProvider
   
   # 環境変数からアクセス資格情報を取得します。このサンプルコードを実行する前に、OSS_ACCESS_KEY_ID および OSS_ACCESS_KEY_SECRET 環境変数が設定されていることを確認してください。
   auth = oss2.ProviderAuthV4(EnvironmentVariableCredentialsProvider())
   
   # バケットが配置されているリージョンのエンドポイントを指定します。たとえば、バケットが中国 (杭州) リージョンにある場合、エンドポイントを https://oss-cn-hangzhou.aliyuncs.com に設定します。
   endpoint = "https://oss-cn-hangzhou.aliyuncs.com"
   
   # エンドポイントに対応するリージョン情報を指定します (例: cn-hangzhou)。このパラメーターは V4 署名に必要であることに注意してください。
   region = "cn-hangzhou"
   
   # yourBucketName を、ミラーリングベースのオリジンフェッチルールを設定したバケットの名前に設定します。
   bucket = oss2.Bucket(auth, endpoint, "yourBucketName", region=region)
   # オブジェクトファイルの完全なパスを指定します。
   object_key = 'yourObjectKey'
   # ソースファイルの完全なパスを指定します。
   source_url = 'yourSourceUrl'
   
   # フェッチされたファイルのメタデータを取得します。
   oss_object_info = bucket.get_object_meta(object_key)
   
   oss_md5 = oss_object_info.headers.get('etag', '').strip('"')  # ETag は通常 MD5 ハッシュです
   oss_crc64 = oss_object_info.headers.get('x-oss-hash-crc64ecma', '')
   
   print(f"OSS MD5: {oss_md5}")
   print(f"OSS CRC64: {oss_crc64}")
   
   # ソースファイルの内容を取得し、その MD5 と CRC-64 を計算します。
   response = requests.get(source_url)
   if response.status_code == 200:
       source_content = response.content
       source_md5 = hashlib.md5(source_content).hexdigest()
       print(f"Source MD5: {source_md5}")
   
       crc64_func = crcmod.predefined.mkCrcFun('crc-64')
       source_crc64 = hex(crc64_func(source_content))[2:].upper().zfill(16)  # 16 進文字列に変換してフォーマットします
       print(f"Source CRC64: {source_crc64}")
   
       # MD5 値を比較します。
       if oss_md5 == source_md5:
           print("MD5 値が一致します。")
       else:
           print("MD5 値が一致しません。")
   
       # CRC-64 値を比較します。
       if oss_crc64.upper() == source_crc64:
           print("CRC-64 値が一致します。")
       else:
           print("CRC-64 値が一致しません。")
   else:
       print(f"ソースファイルのフェッチに失敗しました。HTTP ステータスコード: {response.status_code}")
       

   • MD5 または CRC-64 の値が一致する場合、2 つのオブジェクトの内容は同じです。この場合、2 つのオブジェクトのサイズは同じである必要があります。

   • MD5 または CRC-64 の値が一致しない場合、2 つのオブジェクトの内容は異なります。次のステップに進み、特別なリクエストヘッダーを確認します。

3. 特別なリクエストヘッダーを確認します。

   

   • ミラーリングベースのオリジンフェッチリクエストに Accept-Encoding: gzip, deflate, br などの特別な HTTP リクエストヘッダーが含まれているかどうかを確認します。このヘッダーは、クライアントが圧縮データ形式を受け入れることができることを示します。

   • ミラーリングベースのオリジンフェッチリクエストが HTTP 圧縮ロジックを使用し、リクエストされたオブジェクトが圧縮条件を満たしている場合、2 つのオブジェクトのサイズも異なります。

   • Accept-Encoding ヘッダーが存在する場合は、その受け渡しを禁止する必要があります。

     • すべての HTTP ヘッダーを渡すようにルールを設定した場合、禁止された HTTP ヘッダーのリストに `accept-encoding` を追加する必要があります。

       

     • 指定された HTTP ヘッダーを渡すようにルールを設定した場合、`accept-encoding` が指定されたヘッダーのリストに含まれていないことを確認してください。

       

オリジンフェッチの失敗をトラブルシューティングするにはどうすればよいですか？

オリジンフェッチが失敗し、424 MirrorFailed などのエラーが返された場合は、次のトラブルシューティング手順を実行してください。

1. オリジンサーバーの到達可能性を確認します。

   # URL を実際のオリジンサーバーアドレスとファイルパスに置き換えます
   curl -I "https://www.example.com/images/test.jpg"

2. DNS 解決を確認します。

   # ドメイン名を実際のオリジンサーバードメイン名に置き換えます
   nslookup www.example.com

3. HTTPS 証明書を確認します (オリジンサーバーが HTTPS を使用している場合)。

   # ドメイン名を実際のオリジンサーバードメイン名に置き換えます
   openssl s_client -connect www.example.com:443 -servername www.example.com

4. OSS リアルタイムログクエリ機能を使用して問題を分析します。

ミラーリングベースのオリジンフェッチでファイルが生成されないのはなぜですか？

クライアントは HEAD リクエストを送信して、実際のオブジェクトコンテンツをダウンロードせずに、サイズやタイプなどのオブジェクトメタデータを取得します。HEAD リクエストはミラーリングベースのオリジンフェッチルールをトリガーしません。したがって、オブジェクトはオリジンサーバーからフェッチされたり、宛先の OSS バケットに書き込まれたりしません。

ミラーリングベースのオリジンフェッチリクエストが予期しないステータスコードを返すのはなぜですか？

back-to-origin リクエストがトリガーされ、オリジンサーバーが 404、200、または 206 以外のステータスコードを返した場合、オリジンサーバーの応答を分析する必要があります。

• オリジンサーバーが OSS の場合: 次の構成項目を確認します。

  • 指定された HTTP ヘッダーの受け渡しを禁止する: `host` ヘッダーの受け渡しを禁止します。これにより、オリジンサーバー情報の公開が防止され、back-to-origin リクエストが期待どおりに処理されることが保証されます。`host` ヘッダーが渡されると、back-to-origin リクエストは宛先バケットの `host` 値をオリジンサーバーに送信します。各バケットの `host` 値は一意です。リクエストされた `host` がオリジンサーバーの実際の `host` と一致しない場合、オリジンサーバーは 403 エラーを返します。その後、OSS はクライアントに 424 エラーを返します。これは、オリジンサーバーがリクエストを処理できなかったために操作が失敗したことを示します。

    

  • オリジンフェッチ用のプライベート OSS バケット: 権限が設定されていない場合は、宛先バケットとそのオブジェクトの ACL が公開読み取りに設定されているかどうかを確認します。権限が設定されている場合は、ミラーリングベースのオリジンフェッチに使用されるロールの権限付与ポリシーが変更され、権限が不十分になった可能性があるかどうかを確認します。ミラーリングベースのオリジンフェッチに使用されるデフォルトのロールは AliyunOSSMirrorDefaultRole で、そのデフォルトのシステムポリシーは AliyunOSSReadOnlyAccess です。

• オリジンサーバーが OSS ではない場合: サーバー側のログと、サーバー名表示 (SNI)、back-to-origin パラメーター、ヘッダーパススルーなどの構成を確認して、オリジンサーバーの例外の具体的な原因を分析します。オリジンサーバーは、401 (Unauthorized)、403 (Forbidden)、または 5xx (Server Internal Error) などのステータスコードを返す場合があります。

オリジンフェッチルールの照合順序は何ですか？

ルールは、ルール番号 (RuleNumber) の昇順で照合されます。最初に一致するルールが見つかると、そのルールが実行され、照合プロセスは停止します。

VPC 内のサービスまたは内部 IP アドレスからフェッチできますか？

いいえ。オリジンサーバーには、公にアクセス可能なアドレスが必要です。VPC 内のサービスにアクセスするには、NAT Gateway またはインターネット向け SLB インスタンスを使用して、インターネットに公開できます。

ソースファイルが更新された後、OSS のファイルが更新されないのはなぜですか？

ミラーリングベースのオリジンフェッチは 1 回限りのプルメカニズムであり、オリジンサーバーからの更新を自動的に同期しません。OSS でフェッチされたオブジェクトを手動で削除するか、ファイル名のバージョン管理戦略を使用して新しいオブジェクトを取得する必要があります。