Cloud & IT Cert Prep · レッスン

CDN ルールによるパフォーマンスの最適化

Q: 「CDN ルールによるパフォーマンスの最適化」で何を学びますか？

ルール エンジンを使用して HTTP を HTTPS にリダイレクトし、セキュリティ ヘッダーを追加して、特定の国からのコンテンツへのアクセスを制限する地理フィルターを適用します。 ブラウザで直接実行するハンズオンコードでCloud & IT Cert Prepを演習し、24時間対応のAIチューターがレッスンを進める中での質問に答えます。

ルールエンジンを使用して HTTP を HTTPS にリダイレクトし、セキュリティヘッダーを追加して、特定の国からのコンテンツへのアクセスを制限する地理フィルターを適用します。

「CDN ルールによるパフォーマンスの最適化」はCoddyKit上の無料Cloud & IT Cert Prepレッスンです。これはレッスン4/4です。下記で完全なレッスンを無料で読むことができます。その後、ブラウザ内の組み込みコードエディタと24時間対応のAIチューターでハンズオン演習できます。これはCloud & IT Cert Prep学習パスの一部であり、ウェブとCoddyKitアプリ全体で進捗が同期されます。 Cloud & IT Cert Prepコースには全4レッスンが含まれています。

ルールエンジンが重要な理由

Azure Front Door のルールエンジン（Standard/Premium では Rule sets と呼ばれます）を使用すると、HTTP リクエストとレスポンスをエッジの PoP でインターセプトして変更できます。これらはキャッシュされたりオリジンへ転送されたりする前に処理されます。ルールエンジンがない場合、HTTP から HTTPS へのリダイレクト、セキュリティレスポンスヘッダー、地域ブロックなどの処理をオリジンアプリケーションのコード内で行う必要があり、遅延が増加し、セキュリティ上の関心事とビジネスロジックが密結合します。エッジでルールを実行すると、より高速に処理でき、オリジンの負荷も軽減できます。

HTTP から HTTPS へのリダイレクト

ルールエンジンの最も一般的な用途の 1 つは HTTPS の強制です。クライアントが HTTP でサイトにアクセスすると、Front Door のエッジにあるリダイレクトルールが、HTTPS URL を示す301 Moved Permanently（または 302 Found）レスポンスを直ちに返します。このリクエストがオリジンに到達することはありません。オリジン側でリダイレクトするより高速で、すべてのトラフィックを転送中に暗号化できます。RequestScheme 条件が HTTP と等しいリクエストに対するリダイレクトアクションとして設定します。

// Rules engine rule — redirect HTTP to HTTPS
// Match condition: RequestScheme Equals HTTP
// Action: URL Redirect
//   Redirect type: Moved (301)
//   Destination protocol: HTTPS
//   Destination host: {http.request.host}
//   Destination path: {http.request.uri.path}
//   Query string: {http.request.uri.querystring}

セキュリティレスポンスヘッダーの追加

最新のブラウザーは、一般的な攻撃を防ぐ HTTP セキュリティヘッダーをサポートしています。ルールエンジンのAppend response header アクションを使用すると、オリジンサーバーを変更せずに、すべてのレスポンスへこれらのヘッダーを追加できます。主なヘッダーには、Strict-Transport-Security（一定期間 HTTPS を強制）、X-Content-Type-Options: nosniff（MIME スニッフィングを防止）、X-Frame-Options: DENY（クリックジャッキングを防止）、Content-Security-Policy（コンテンツソースを制限）があります。エッジで追加すれば、すべてのオリジンに一貫して適用できます。

// Rules engine — add security headers to all responses
// Action 1: Append response header
//   Header name: Strict-Transport-Security
//   Value: max-age=31536000; includeSubDomains
// Action 2: Append response header
//   Header name: X-Content-Type-Options
//   Value: nosniff
// Action 3: Append response header
//   Header name: X-Frame-Options
//   Value: DENY

ルールごとのキャッシュ設定の上書き

ルールエンジンを使用すると、特定の URL パターンに対して既定のキャッシュ TTL を上書きできます。たとえば、/static/images/* は 30 日間キャッシュし、/api/* のレスポンスは 60 秒だけキャッシュする、といった設定が可能です。RequestUri に一致条件を設定し、カスタムキャッシュ期間を指定するRoute configuration override アクションを使用します。これにより、コンテンツタイプごとに複数の個別ルートを作成しなくても、キャッシュ動作をきめ細かく制御できます。

// Rules engine — cache API responses for 60 seconds
// Match condition: RequestUri BeginsWith /api/
// Action: Route configuration override
//   Cache: Enabled
//   Caching duration: 0 days, 0 hours, 1 minute
//   Query string caching: Include All

// Rules engine — cache static images for 30 days
// Match condition: RequestUri BeginsWith /static/images/
// Action: Route configuration override
//   Cache: Enabled
//   Caching duration: 30 days

エッジでの URL 書き換え

URL rewrite アクションは、クライアントに表示される URL を変更せずに、オリジンへ転送する前のリクエスト URL を変更します。ある URL 構造から別のバックエンドパスへリクエストを送る場合に便利です。たとえば、クライアントのリンクを更新せずにバックエンド API の変更に対応するため、/products/item/{id} を /catalog/v2/products/{id} に書き換えられます。URL rewrite はルールエンジンのアクションであり、文字列置換またはキャプチャグループを使って URL path を変更します。

地域フィルタリングルール

ルールエンジンレベルの地域フィルタリングを使用すると、クライアントの IP から判定した地理的位置に基づいて、特定の国のユーザーをリダイレクトまたはブロックできます。403 を返す CDN の地域フィルタリングとは異なり、ルールエンジンの地域フィルタリングでは柔軟な制御が可能です。ブロックした国のユーザーを、地域での提供状況を説明するランディングページへリダイレクトしたり、特定の国からのアクセスを地域固有のオリジングループへルーティングしたりできます（例: GDPR 準拠のため、EU ユーザーを EU のオリジンへルーティング）。RemoteAddress の地域一致では、MaxMind の IP アドレスと国の対応データベースが使用されます。

リクエストヘッダーの操作

ルールエンジンでは、オリジンへ転送する前にリクエストヘッダーを追加、上書き、または削除できます。一般的な用途は、X-Forwarded-For や X-Front-Door-Id のようなカスタムヘッダーを追加し、リクエストが Front Door 経由であることをオリジンが把握して検証できるようにすることです。また、元の Host ヘッダーを削除してオリジンのホスト名に置き換えることもできます。これは、オリジンが Host ヘッダーを検証する場合に重要です。これにより、オリジンサーバーに表示される情報を完全に制御できます。

リクエストヘッダーに基づくルーティング

ルールエンジンの条件ではリクエストヘッダーの値に一致させることができ、高度なルーティングロジックを実現できます。たとえば、X-API-Version: 2 ヘッダーを含むリクエストを v2 API を実行する別のオリジングループへルーティングし、そのヘッダーを含まないリクエストを v1 オリジンへ送ることができます。これにより、API バージョンごとに別のホスト名を用意せず、エッジでブルーグリーン API バージョニングを実現できます。ヘッダーベースのルーティングは、カスタムユーザーセグメント Cookie に基づく A/B テストにも使用されます。

エッジでのレスポンス圧縮

Front Door のレスポンス圧縮では、テキストベースのレスポンス（HTML、CSS、JavaScript、JSON）を gzip または Brotli で圧縮してから PoP から配信します。圧縮は大きな JS バンドルに特に効果的で、転送サイズを最大 70% 削減できます。圧縮をルート設定で有効にし、圧縮する MIME タイプを指定します。圧縮されたコンテンツは PoP に圧縮形式でキャッシュされるため、各アセットで圧縮が行われるのは最初のリクエストだけです。その後のリクエストでは、キャッシュされた圧縮ファイルがすぐに配信されます。

Origin Shield

Origin Shield は、Front Door が PoP のエッジノードとオリジンの間に配置する、追加のオプションキャッシュレイヤーです。有効にすると、100 以上ある各エッジ PoP がキャッシュされていないコンテンツを個別にオリジンへ要求する代わりに、すべての PoP がキャッシュミスを 1 つのリージョンの Origin Shield PoP へ転送し、そこからオリジンへ転送します。これにより、オリジンに到達するリクエスト数（origin offload ratio と呼ばれます）を大幅に削減しながら、エッジ PoP からコンテンツをグローバルに配信できます。

Front Door Explorer によるルールのテスト

ルールエンジンの変更を本番環境にデプロイする前に、ポータルの診断およびテストツールを使って検証してください。検出モードの WAF ログを表示する Diagnostic settings ブレードでは、どのルールが一致したかを確認できます。ルールエンジンでは、ステージング環境にデプロイした後、ブラウザーの開発者ツールで実際のリクエストヘッダーとレスポンスヘッダーを確認することもできます。または、curl -v を使って特定のリクエストを送信し、レスポンスヘッダーとリダイレクトの動作が想定どおりであることを確認してから本番環境へ切り替えます。

# Test HTTP-to-HTTPS redirect at the CDN/Front Door edge
curl -v -L http://myapp.azurefd.net/ 2>&1 | grep -E '< (HTTP|Location)'
# Expected output:
# < HTTP/1.1 301 Moved Permanently
# < Location: https://myapp.azurefd.net/

クイックチェック

このレッスンで学んだ Microsoft Azure Fundamentals（AZ-900）の概念について理解度を確認しましょう。

レッスンのまとめ

このレッスンでは、Front Door のルールエンジンによって、オリジンを変更せずにエッジで HTTP から HTTPS へのリダイレクト、セキュリティレスポンスヘッダー、キャッシュ TTL の上書きを処理できること、URL rewriteではオリジンへ転送するリクエストパスを静かに変更する一方、URL リダイレクトではクライアントに表示される URL が変更されること、そしてOrigin Shieldによってキャッシュミスのリクエストをリージョンのシールドノードに集約し、オリジンの負荷を軽減できることを学びました。次は、Azure AI Services を使ってアプリケーションにインテリジェンスを追加する方法を学びます。

よくある質問