Object Storage Service:CDN による OSS アクセスの高速化

必須構成

1. Range GET の有効化：加速ドメイン名に対して範囲ベースのオリジンフェッチを有効化します。これにより、CDN エッジノードが大容量ファイルをチャンク単位でリクエストでき、動画のシークや再開可能なダウンロードがサポートされます。

2. 適切なキャッシュ TTL の構成：動画ファイルは通常、頻繁に更新されません。キャッシュ TTL を長め（例：30 日以上）に設定して、頻繁なオリジンフェッチを削減します。

3. リソースプリフェッチの使用：動画を公開する前に、CDN のリソースのリフレッシュとプリフェッチ機能を使用して、動画をエッジノードに配信します。

動画ビットレートの推奨値

動画の読み込み速度はビットレートと密接に関係しています。ユーザーから動画再生が途切れたりカクついたりするとの報告がある場合は、動画のビットレートを確認してください。

方法 1：個別のサブドメインアーキテクチャ

機能やリソースタイプごとに意味のある個別のサブドメインをバケットに割り当て、各サブドメインに対して個別に CDN 高速化を構成します。

個別のサブドメインアーキテクチャを使用すると、以下のメリットがあります。

• 意味のあるサブドメインにより、開発チームが識別および保守しやすくなります。

• トラフィックが DNS レベルで分散されるため、単一ドメインの同時接続制限を回避できます。

• 各バケットに独自のキャッシュポリシー、セキュリティ構成、モニタリングアラートを設定できます。

• 個別のモニタリングにより、パフォーマンスボトルネックや異常なトラフィックを特定しやすくなります。

方法 2：パスベースルーティングによる統合ドメイン

異なるサービスのバケットへの統合アクセスポイントを提供するには、単一の加速ドメイン名を構成し、ルールエンジンを使用して、リクエストパスに基づいて特定のバケットにリクエストをルーティングします。この例では、加速ドメイン名 oss.example.com を構成して、2 つのバケット cdn-bucket1 および cdn-bucket2 からコンテンツをフェッチする方法を示します。

1. オリジン情報の追加：加速ドメイン名の オリジンサイト情報 に cdn-bucket1 および cdn-bucket2 を追加し、ドメインの CNAME 解決を構成します。

2. パスルールの追加：加速ドメイン名について、ルールの追加 に移動して、それぞれ http://oss.example.com/bucket1/* および http://oss.example.com/bucket2/* に一致する 2 つの URL パスルールを作成します。

   ルール名	タイプ	一致演算子	一致値
   bucket1（カスタマイズ可能）	URI	いずれかを含む	/bucket1/*
   bucket2（カスタマイズ可能）	URI	いずれかを含む	/bucket2/*

3. 条件付きオリジンの追加：基本設定 で、条件付き配信元の追加 オプションを使用して、パスルールを対応するオリジンに関連付けます。

   ルール条件	配信元アドレス
   bucket1	cdn-bucket1.oss-<region-id>.aliyuncs.com
   bucket2	cdn-bucket2.oss-<region-id>.aliyuncs.com

4. オリジン Host ヘッダーの指定：Back-to-Origin 設定 で、[オリジン HOST の指定] オプションを使用して、オリジンフェッチリクエストがターゲットバケットに正しくルーティングされるようにします。

   配信元サーバーのタイプ	配信元アドレス	オリジン HOST タイプ	Back-to-Origin ホスト	ルール条件
   プライマリオリジンアドレス	cdn-bucket1.oss-<region-id>.aliyuncs.com	プライマリオリジンドメイン	cdn-bucket1.oss-<region-id>.aliyuncs.com	bucket1
   プライマリオリジンアドレス	cdn-bucket2.oss-<region-id>.aliyuncs.com	プライマリオリジンドメイン	cdn-bucket2.oss-<region-id>.aliyuncs.com	bucket2

5. オリジン URL の書き換え：Back-to-Origin 設定 で、back-to-origin Path の書き換え ルールを追加します。このルールにより、オリジンフェッチ時に仮想パス（例：/bucket1）が削除され、オブジェクトの実際の保存パスに一致します。

   書き換えのパス	変更後のパス	フラグ
   ^/bucket1/(.*)$	/$1	break
   ^/bucket2/(.*)$	/$1	break

6. 構成の検証：構成を完了後、単一の加速ドメイン名を使用して、パスに基づいて異なる OSS バケットからリソースにアクセスできます。たとえば、http://oss.example.com/bucket1/example.jpg へのリクエストは、cdn-bucket1 バケットのルートディレクトリにある example.jpg ファイルをフェッチします。

安全な通信：HTTPS の有効化

クライアントと CDN ノード間のデータ転送を暗号化するには、加速ドメイン名に対してHTTPS 証明書を構成し、強制 HTTPS リダイレクトを有効化してください。HTTPS は、転送中のデータが盗まれたり改ざんされたりするのを防ぐだけでなく、ブラウザーのセキュリティ警告を回避し、ユーザーの信頼とブランドイメージを高めます。

証明書構成場所

パフォーマンス最適化：キャッシュポリシーの構成

キャッシュポリシーは CDN パフォーマンスにとって極めて重要であり、キャッシュ期間とパラメーター処理の両方をカバーする必要があります。

キャッシュ有効期限の設定

CDN キャッシュ有効期限ルールを構成して、キャッシュヒット率を最大化します。

画像処理を有効にするためのパラメーター処理の構成

リサイズ、トリミング、ウォーターマークなどの機能を含む OSS 画像処理は頻繁に使用されます。デフォルトでは、CDN はキャッシュヒット率を最大化するためにすべてのパラメーターをフィルタリングするため、?x-oss-process などの画像処理命令が無効になります。この機能を使用するには、CDN コンソールの加速ドメイン名の パフォーマンスの最適化 セクションで、パラメーターフィルタリング 設定を変更する必要があります。

可用性：プリフェッチと自動更新の使用

キャッシュを有効化した後、オリジンファイルの更新はすぐに CDN エッジノードに反映されません。以下の戦略を使用してください。

• プリフェッチ：新規リリースやプロモーションイベントの前に、CDN のリソースのリフレッシュとプリフェッチ機能を使用して、人気のあるリソースを世界中のエッジノードに配信します。これにより、ローンチ時にオリジンへのリクエストが急増して圧倒されるのを防ぎます。

• 自動キャッシュ更新：バケットの バケットの設定 > ドメイン名 セクションで、バインドされたドメインの自動 CDN キャッシュ更新を有効化します。API を使用して OSS ファイルを更新すると、OSS が自動的に CDN 更新タスクをトリガーします。

クロスオリジンアクセス：CORS ポリシーの構成

フロントエンドアプリケーションが CDN で高速化された OSS リソースにクロスオリジンリクエストを行う必要がある場合、OSS バケットにのみ構成された CORS ルールは、CDN キャッシュの影響で機能しない可能性があります。ベストプラクティスは、CDN レベルで直接 CORS 関連のレスポンスヘッダーを構成することです。

1. CDN コンソールで、加速ドメイン名をクリックするか、[操作] 列の 管理 をクリックします。

2. キャッシュ設定 > 送信レスポンスヘッダーの変更 タブで、レスポンスヘッダーのパラメーターと値を構成します。

   応答ヘッダー	応答ヘッダー値	CORS
   Access-Control-Allow-Origin	*	有効
   Access-Control-Allow-Methods	POST, GET, HEAD, PUT, DELETE	該当なし
   Access-Control-Max-Age	3600	該当なし

   説明

   パラメーター設定は参考用です。実際のビジネスシナリオに基づいて調整してください。

パフォーマンス最適化：大容量ファイルおよびデータ転送の改善

• Range オリジンフェッチの有効化：ビデオ・オン・デマンドや大容量ファイル配信などのシナリオでは、Range オリジンフェッチを構成することが極めて重要です。この機能により、CDN ノードが大容量ファイルをチャンク単位でリクエストでき、動画のシークなどの高度な機能を有効にし、オリジントラフィックとファーストビュー遅延を大幅に削減できます。

• データ転送の最適化：JS、CSS、HTML などのテキストベースのファイルの転送サイズを削減するために、CDN コンソールで Gzip 圧縮 または ページ最適化 を有効化できます。

スムーズなロールアウト：ゼロダウンタイムドメイン切り替え

既存のサービスを OSS バケットドメインから加速ドメイン名に切り替える際は、段階的なアプローチを採用してください。

1. 準備フェーズ：加速ドメイン名のすべての構成を完了し、ステージング環境で機能とパフォーマンスを徹底的にテストします。

2. カナリアリリースフェーズ（オフピーク時間帯での実施を推奨）：カナリアリリースを使用して、トラフィックの一部を加速ドメイン名に切り替え、リスクを軽減しながら徐々にトラフィック量を増やします。

3. 検証フェーズ：アクセスログとエラー率を綿密に監視します。応答時間や成功率などの主要メトリックを分析して、サービスが正常に機能していることを確認します。

4. フルリリースフェーズ：徹底的な検証後、すべてのトラフィックを加速ドメイン名に切り替えます。

5. ロールバック計画：問題が発生した場合は、直ちにバケットドメインにロールバックし、根本原因を分析した後、再デプロイします。

ホットリンク保護：Referer および URL 認証の構成

不正な Web サイトによるリソースのホットリンクを防止し、不要なトラフィックコストや帯域幅消費を回避するには、セキュリティポリシーを構成する必要があります。

• Referer ベースのホットリンク保護：HTTP リクエストヘッダーの Referer フィールドを検証して、指定されたドメインからのみアクセスを許可するため、Referer ホワイトリストまたはブラックリストを構成します。

• URL 認証：プライベート OSS バケットの場合、プライベートバケットのオリジンフェッチを有効化すると、CDN ノードがアクセスできるようになります。つまり、以前は署名が必要だったプライベートリソースが、CDN ドメイン経由で公開アクセス可能になります。これらのリソースに対するセキュリティ制御を復元するには、CDN レベルでURL 認証を構成してください。

トラフィック異常の監視

Cloud Monitor で加速ドメイン名のアラートルールを作成して、CDN トラフィックの異常な急増を迅速に検出します。

オリジンセキュリティ：SNI およびホストの構成

CDN と OSS 間の安定的かつ安全な通信を確保することは、サービス可用性にとって極めて重要です。

オリジン SNI の構成

サーバ名表示（SNI）を含まないオリジンリクエストが OSS へのアクセス障害を引き起こすのを防ぐために、CDN でデフォルトのオリジン SNI を構成する必要があります。SNI は、オリジンフェッチホスト（デフォルトでは加速ドメイン名）と一致するように設定します。オリジンリクエストに SNI が含まれている場合、OSS は TLS ハンドシェイク中にビジネスドメインを識別し、一致する証明書を返します。OSS が SNI を含まないリクエストを受信した場合、ビジネスドメインを正確に識別できず、より厳しいトラフィック制限がトリガーされる可能性があります。

オリジン情報の非表示

デフォルトでは、CDN はオリジンリクエストにバケットドメインを使用します。オリジンエラー（例：ファイルが見つからない）が発生した場合、エラーメッセージに OSS バケットドメインが公開される可能性があり、セキュリティリスクとなります。この情報を非表示にするには、オリジンフェッチホストを加速ドメイン名に変更します。

1. [バケット] ページで、ターゲットバケットをクリックします。次に、バケットの設定 > ドメイン名 セクションで、加速ドメイン名をバケットにバインドします。

2. CDN コンソールで、ターゲット加速ドメイン名をクリックします。次に、Back-to-Origin 設定 > デフォルトの配信元ホスト セクションで、変更 をクリックし、ドメインタイプ を ドメイン名 に変更します。

監査およびトラブルシューティング：アクセスログの有効化

本番環境では、セキュリティ監査、パフォーマンス分析、トラブルシューティングのための包括的なロギング機能が必要です。CDN コンソールでリアルタイムログ配信を構成して、アクセスログを Log Service に送信します。Log Service を使用して、アクセス動作、トラフィック分布、人気リソース、リクエストエラーについて詳細な分析を行い、アラートを設定できます。