Microsoft AZ-204: Azure のキャッシュ、CDN、およびパフォーマンス — 学習ガイド

By Laurynas Brazys · 5 August 2026 · #microsoft #az-204 #certification #exam-prep #study-guide

こちらの一部です： Microsoft Azure Developer Associate AZ-204 — 学習ガイド. 検証済みの解答で練習： Microsoft試験ハブ, または時間制限付き模擬試験に挑戦： ExamRoll.io.

概要

Azureにおける高速で信頼性の高いユーザーエクスペリエンスは、コンテンツと状態をユーザーの近くに配置し、オリジンの負荷を最小限に抑え、障害を適切に処理することにかかっています。Azure Cache for Redis、Azure CDN、Azure Front Doorを組み合わせることで、インメモリでの高速化、エッジキャッシュ、セキュリティを備えたグローバルエニーキャストルーティングが提供されます。Redisのデータ構造と接続パターン、CDNのプロファイルとキャッシュセマンティクス、Front Doorのルーティングとヘルスプローブを習得することで、低レイテンシーで回復力のあるアプリケーションを設計できます。

Azure Cache for Redis: 階層、データ構造、削除ポリシー、パターン

Azure Cache for Redisは、ミリ秒未満のデータアクセスを提供するマネージドRedisサービスであり、一般的なRedisデータ構造と上位階層での高度な機能をサポートしています。

階層:

• Basic: SLAなし、データレプリケーションなしのシングルノードキャッシュ。開発/テストや重要でないワークロードに適しています。データ永続化、クラスタリング、VNet統合はありません。
• Standard: 自動フェイルオーバーとSLAを備えた2ノードのプライマリ/レプリカ構成。本番環境に適しています。最小限の中断でスケールアップ/ダウンをサポートしますが、クラスタリングや永続化はありません。
• Premium: より高いパフォーマンスとスループット、より大きなキャッシュサイズ、Redis永続化（RDBおよびAOF）、水平スケールのためのクラスタリング（シャーディング）、仮想ネットワーク統合、ゾーン冗長性（サポートされているリージョン）、DRのための地理レプリケーション。また、スケジュールされたパッチ適用ウィンドウと高度なセキュリティもサポートします。

データ構造とそれぞれの使用場面:

• Strings: 基本的なキー/バリュー、カウンター、JSONブロブ。レート制限やカウンターのためのアトミックなINCR/DECR。
• Hashes: オブジェクトのフィールド（例：ユーザープロファイル）を、部分的な更新とスペース効率のためにフィールドと値のペアを持つ単一のキーとして保存します。
• Lists: キューまたはスタック、挿入順に並べられます。単純なワークキューにはLPUSH/BRPOPを使用します。
• Sets: ユニークなコレクション。タグ、メンバーシップチェック、共通集合の算出に使用します。
• Sorted Sets: スコアによるランキング。リーダーボードや時系列イベントに最適です。
• Bitmaps/Bitfields: 位置に基づいたブール値フラグやカウンターのコンパクトな追跡。
• HyperLogLog: 固定メモリでのカーディナリティ（ユニークカウント）の近似計算。
• Geospatial: 緯度/経度の座標の保存とクエリ、半径検索。
• Streams: イベントの取り込みとコンシューマーグループのための追記専用ログ。

削除ポリシー（maxmemoryに達したときに適用されます）:

• volatile-lru: 有効期限が設定されているキーのうち、最も最近使用されていないものを削除します（Azure Cache for Redisのデフォルト）。
• allkeys-lru: 有効期限に関係なく、最も最近使用されていないキーを削除します。
• volatile-ttl: 有効期限が最も近いキーを削除します。
• volatile-random / allkeys-random: ランダムなキーを削除します。対象は有効期限付きのキーまたはすべてのキーに限定されます。
• noeviction: 削除しません。メモリを追加する書き込みコマンドはエラーで失敗します。
• volatile-lfu / allkeys-lfu: 最も使用頻度の低いキーを削除するバリアント（新しいRedisバージョン向け）。

データの重要度とアクセスパターンに基づいて削除ポリシーを選択します。キャッシュの場合、allkeys-lruまたはallkeys-lfuが最も高いヒット率をもたらします。有効期限を慎重に設定した混合ストアの場合、volatile-ttlまたはvolatile-lruは設定したTTLを尊重できます。

一般的なユースケース:

• セッションキャッシュ: IDistributedCacheまたはセッションミドルウェアを介してユーザーセッションの状態を保存します。キーを小さく保ち、セッションタイムアウトに合わせたTTLを使用し、必要に応じてエッジでセッションアフィニティを有効にします。
• 出力キャッシュ: レンダリングされたページのフラグメントや完全なレスポンスを、ルートとユーザーセグメントでキー付けしてキャッシュします。コンテンツの変更時には、キーのバージョニングまたは明示的なDELを使用して無効化します。
• Pub/Sub: 通知やキャッシュ無効化のファンアウトのための、ほぼリアルタイムのメッセージング。チャネルを使用して、複数のサブスクライバーに変更をブロードキャストします。
• リーダーボード: ランキングのためのスコア付きSorted set。ZADD/ZREVRANGEでトップNを更新・読み取りします。時間枠付きランキングにはセカンダリのSorted setを使用します。

Azure Redisへの接続: 接続文字列、StackExchange.Redis、回復性

接続エンドポイントとキーは、Azureポータルの[アクセスキー]で提供されます。プライマリ接続文字列には、ホスト、ポート、TLS、パスワードが含まれます（例: contoso.redis.cache.windows.net:6380,password=…;ssl=True;abortConnect=False）。本番環境では常にポート6380でTLSを使用してください。

StackExchange.Redisのベストプラクティス:

• プロセスごとに単一の長寿命なConnectionMultiplexerを使用します。これはスレッドセーフであり、リクエストを効率的に多重化します。一度作成し、静的変数またはDIコンテナに保存して再利用します。
• 設定オプション：クラウドのフェイルオーバー耐性のためにAbortOnConnectFail=falseを設定し、一時的な問題のためにConnectRetryとConnectTimeoutを設定します。SyncTimeoutはワークロードに合わせて調整し、KeepAliveはNATのピンホールを維持するために使用します。テキスト形式のオプション例: ssl=True, abortConnect=False, connectRetry=5, connectTimeout=5000。
• 負荷がかかった状態でのスレッドプールの枯渇を避けるために、非同期メソッドを使用します。IDatabaseのメソッド（StringGetAsync, HashSetAsync, SortedSetAddAsync）はノンブロッキングです。
• 回復性イベントの処理：ConnectionFailed、ConnectionRestored、ConfigurationChangedイベントをサブスクライブして、トポロジの変更やフェイルオーバーをログに記録し、監視します。StackExchange.Redisはフェイルオーバー時に自動的にプライマリを再解決します。
• 長時間のLuaスクリプトや重いトランザクションは避け、小さくアトミックなコマンドを優先します。マルチプレクサを介して自然にパイプライン処理を行いますが、タイムアウトするほど過度にバッチ処理しないでください。
• タイムアウトとリトライ：冪等でないコマンドをむやみにリトライしないでください。重要な書き込みには、冪等なパターンまたはライトスルーキューを使用します。
• シリアライゼーション：ネットワークトラフィックとメモリを最小限に抑えるために、コンパクトなペイロード（例：MessagePack）を保存します。巨大な値は避け、フィールドレベルのアクセスが可能なハッシュを優先します。
• キーの命名：衝突を避け、一括操作やパージを簡素化するために、アプリ/環境でプレフィックスを付けます（例：prod:session:{userId}）。
• セキュリティ：アクセスキーをローテーションし、VNet（Premium）経由で制限し、プライベートアクセスのためにPrivate Linkを検討します。本番環境で「SSL経由のアクセスのみを許可する」をfalseにしないでください。

Azure CDN: プロファイル、エンドポイント、オリジン、最適化、コンテンツの鮮度

Azure CDNは、エッジPOPで静的コンテンツをキャッシュし、レイテンシーの削減とオリジンへの負荷軽減を実現します。CDNプロファイルは、エンドポイントと価格レベル/プロバイダーをグループ化します。エンドポイントは、エッジホスト名を定義し、1つ以上のオリジンに接続します。

プロファイルとエンドポイント:

• プロファイル配下で、アプリケーションまたは環境ごとに1つ以上のエンドポイントを作成します。各エンドポイントは独自のエッジホスト名（例: app.azureedge.net）を持ち、これをカスタムドメインにTLSでマッピングします。
• 課金を分離したり、必要に応じて異なるプロバイダー/機能を適用したりするには、別々のプロファイルを使用します。

オリジンの種類:

• Azure Blob Storage: 静的Webサイトや大規模なメディアに最適です。「静的なWebサイト」を有効にするか、コンテナーにマッピングします。適切なMIMEタイプとキャッシュヘッダーを確認してください。
• App Service: 選択したレスポンスをキャッシュできる動的コンテンツやREST APIに使用します。オリジンホストヘッダーをアプリのホスト名に設定し、HTTPSを確保してください。
• カスタムオリジン: パブリックIPやリバースプロキシ経由のオンプレミスを含む、パブリックに到達可能な任意のHTTP(S)エンドポイント。

最適化の種類（エンドポイント作成時に適用）:

• 一般的なWeb配信: 広範囲のPOPカバレッジを持ち、多数の小〜中規模アセット（HTML, CSS, JS, 画像）向けにバランスが取られています。
• 大きなファイルのダウンロード: 範囲要求のチューニング、接続管理、スループット指向の設定により、大容量ファイル向けに最適化されています。
• ビデオストリーミング: プログレッシブダウンロードやHLS/DASHセグメント配信向けに最適化されており、セグメントのキャッシュを効率的に保ち、バイト範囲要求を尊重します。

キャッシュ規則と消去（パージ）:

• グローバルおよびカスタムのキャッシュ規則により、パス、ファイル拡張子、リクエストメソッド、クエリ文字列の動作に基づいてTTLを制御できます。Standardレベルでは、エンドポイントのキャッシュ設定で規則を構成します。Premiumでは、高度なルールエンジンが追加されます。
• ポータル、CLI、またはREST APIを介して、ワイルドカード（例: /images/*）を使用してパスで無効なコンテンツを消去します。消去はすべてのPOPに伝播します。影響範囲を最小限に抑えるには、対象を絞った消去を使用します。Premiumレベルでは、キャッシュをウォームアップするためのプリロードをサポートしています。

コンテンツの鮮度管理:

• TTL: CDNはデフォルトで、オリジンからのCache-ControlおよびExpiresヘッダーを尊重します。規則を使用して、TTLを上書きしたり、最小/最大TTLを設定したりできます。不変のアセットには、ヒット率を最大化するために Cache-Control: public,max-age=31536000,immutable を返します。
• Cache-Controlディレクティブ: no-store と private はCDNによってキャッシュされません。must-revalidate と s-maxage は、共有キャッシュのきめ細かな制御を可能にします。ブラウザ向けには max-age を控えめに設定しつつ、CDN固有のTTLには s-maxage を使用することが推奨されます。
• クエリ文字列のキャッシュ動作: クエリ文字列を無視する（パスごとに単一のオブジェクトをキャッシュ）、一意のURLごとにキャッシュする（クエリ文字列の組み合わせごとに個別にキャッシュ）、またはクエリ文字列がある場合はキャッシュをバイパスする、から選択します。バージョン管理されたアセット（例: app.css?v=hash）には、「一意のURLごとにキャッシュ」を使用します。分析パラメータ（utm_）には、ヒット率を向上させるためにクエリ文字列を無視します。
• Varyと圧縮: 圧縮を使用する場合は Vary: Accept-Encoding が設定されていることを確認してください。CDNはVaryキーごとに個別のバリアントをキャッシュします。帯域幅を削減するために、テキストアセットに対してCDNの圧縮を有効にします。

Azure Front Door: グローバルルーティング、ヘルス、セキュリティ、アフィニティ

Azure Front Doorは、エニーキャストベースのレイヤー7グローバル負荷分散、動的サイトアクセラレーション、統合WAFを提供します。動的トラフィックのルーティングと保護を行い、Standard/Premiumではオプションで静的コンテンツをキャッシュすることでCDNを補完します。

ルーティングルール:

• 受信ホスト名とパスパターンを照合し、オリジングループ（バックエンドプール）にルーティングします。ルールごとにパスの書き換え、ヘッダー変換、リダイレクト、プロトコル設定を適用します。
• アプリケーションエッジでより厳密な制御が必要な場合、ルート（Standard/Premium）でキャッシュを構成し、静的または半静的なアセットをエッジキャッシュします。
• オリジン間で優先度ベースのフェイルオーバーと重み付け負荷分散を使用し、オプションでリージョン固有のルーティングのために地理的フィルタリングを利用します。

正常性プローブとバックエンドの正常性:

• プローブのパス、プロトコル、間隔、期待されるHTTPステータスコードを定義します。プローブは複数のエッジロケーションから実行され、オリジンの正常性を判断します。
• Front Doorは正常性ステータスを使用して、低レイテンシで正常なオリジンにトラフィックを誘導します。フラッピングを避けるためにタイムアウトとサンプルサイズを調整し、プローブエンドポイントが軽量でキャッシュされないようにします。

WAFの統合:

• WAFポリシーをFront Doorにアタッチして、一般的なWebの脆弱性に対するマネージドルールセットを適用し、IP制限、地理的ブロッキング、またはリクエストサイズの制限のためのカスタムルールを追加します。
• ボット保護とレート制限を使用して、エッジで不正なトラフィックを吸収し、オリジンのキャパシティを保護します。

セッションアフィニティ:

• アプリケーションが連続したリクエストを同じバックエンドに送信する必要がある場合（例：非分散セッション状態）、セッションアフィニティを有効にします。Front Doorはアフィニティクッキーを挿入し、同じセッション内の後続リクエストをルーティングルール内で選択されたバックエンドにルーティングします。
• 可能な場合は、ステートレス設計やRedisをバックエンドとするセッション状態を優先し、アフィニティを避けます。使用する場合は、アフィニティのスコープを慎重に設定し、適切なクッキーTTLを設定します。

CDNとの連携:

• CDNは静的アセット（画像、スクリプト、メディア）を長いTTLで配信し、Front DoorはWAF、TLS終端、パスベースのルーティングで動的リクエストをルーティングするべきです。この分割により、キャッシュヒット率が最大化され、動的レイテンシが最小化されます。
• キャッシュできないAPIやページについては、TTLを低く設定するか、キャッシュをバイパスします。半静的なHTMLについては、変更時にパージするワークフローと短いTTLを検討します。

実践的な問題シナリオ

Mozillaは、リリース時にトラフィックが急増するアドオン発見のためのグローバルなマイクロサイトを立ち上げようとしています。彼らは、高速な静的アセット配信、回復力のある動的API、そして世界中で安全かつ低レイテンシなユーザーインタラクションを必要としています。

1. グローバルなエントリーポイントとセキュリティのためのFront Door

• カスタムドメインとマネージドTLSを持つFront Door Standardプロファイルを作成します。ルーティングルールを定義します：/api/* はApp Service APIオリジングループへ、/* はCDNエンドポイントのホスト名へ。
• 理由: エニーキャストルーティングにより、ユーザーは最も近いエッジに接続されます。Front DoorのWAFは、オリジンに到達する前に悪意のあるパターンをブロックします。パスベースのルーティングは、動的トラフィックと静的トラフィックをきれいに分離します。

2. WAFポリシーとレート制限

• マネージドルールセットを有効にしたWAFポリシーをアタッチし、/api/searchへの過剰なPOSTリクエストをスロットリングするカスタムルールを追加します。
• 理由: OWASPクラスの攻撃や不正なクライアントからAPIを保護し、トラフィック急増時のオリジンキャパシティを維持します。

3. 正常性プローブとオリジングループ

• 異なるリージョンにある2つのApp ServiceインスタンスでAPIオリジングループを構成します。/healthzに対して、期待されるステータス200、10秒間隔の正常性プローブを使用します。一方のリージョンを優先度1、もう一方を優先度2に設定し、フェイルオーバーを構成します。
• 理由: プライマリリージョンが劣化した際に自動的なリージョナルフェイルオーバーを保証します。プローブはキャッシュされたレスポンスとは独立して正常性を検出します。

4. Redisを利用したセッションと出力キャッシュ

• Azure Cache for Redis Standardを展開し、APIをIDistributedCacheと統合して、最小限のセッション状態と、一般的なAPIレスポンス（例：人気のアドオンリスト）の短期間の出力フラグメントを60〜300秒のTTLで保存します。
• 理由: Web層から状態を分離しつつ、APIのレイテンシとデータベース負荷を削減します。短いTTLは手動での無効化なしに鮮度を維持します。

5. リーダーボードのためのRedisデータ構造

• カテゴリごとにRedisのソート済みセット（例：addons:top:{category}）を使用して、ダウンロード数に基づくランキングを維持します。キューコンシューマーを介して非同期にスコアを更新し、上位N件のエントリを読み取る読み取りAPIを公開します。
• 理由: ソート済みセットはO(log n)の更新と高速な範囲読み取りを提供し、高い読み取り同時実行性を持つリアルタイムランキングに最適です。

6. StackExchange.Redisによる接続の回復性

• ssl=True, abortConnect=False, connectRetry=5、および適切なタイムアウトでシングルトンのConnectionMultiplexerを初期化します。可観測性のためにConnectionFailed/Restoredイベントを処理し、非同期APIを使用しながら、バーストに対応できる程度にSyncTimeoutを高く設定します。
• 理由: 一時的なネットワークイベントやRedisのフェイルオーバー中に、シームレスなフェイルオーバー処理を保証し、プロセス全体のアウトエイジを回避します。

7. 積極的なキャッシュを行う静的アセット用CDN

• General web deliveryに最適化されたAzure CDNプロファイルとエンドポイントを作成し、ストレージアカウントの静的ウェブサイトをオリジンとして使用します。オリジンヘッダーを尊重するようにキャッシュルールを構成しますが、/static/*については7日間のTTLに上書きし、圧縮を有効にします。クエリ文字列のキャッシュを「Cache every unique URL」に設定し、アセットにフィンガープリントを付けます（app.css?v=hash）。
• 理由: エッジキャッシュは世界中にアセットを迅速に配信します。フィンガープリントにより、デプロイ時に即座に更新しつつ、長いTTLが可能になります。圧縮は転送サイズを削減します。

8. CI/CDにおけるパージプロセス

• リリース時にHTMLおよびJSONマニフェストのCDNパス（例：/index.html, /manifest/*.json）をパージし、サポートされているティアでキャッシュをウォームアップするために重要なページをプリロードするデプロイメントステップを追加します。
• 理由: 不変のアセットをキャッシュしたまま、ユーザーが新しいHTMLを迅速に取得できるようにします。プリロードはデプロイ後のコールドスタートレイテンシを削減します。

9. 必要な場合にのみFront Doorのセッションアフィニティを使用

• APIをステートレスに保ち、セッション状態はRedisに依存します。/api/* ルートではFront Doorのセッションアフィニティを無効にします。アフィニティが必要なレガシーな管理ツールについては、/admin/* で短いTTLと共に有効にします。
• 理由: ほとんどのユーザーに対して負荷分散とキャッシュ可能性を最大化しつつ、アフィニティを必要最小限のスコープに限定します。

このアーキテクチャは、安全でインテリジェントなエッジルーティングとWAFのためにFront Doorを、高いヒット率の静的コンテンツ配信と正確な鮮度管理のためにAzure CDNを、そしてホットリードのオフロード、低レイテンシのセッションとリーダーボードデータの維持、トラフィック急増の円滑な吸収のためにAzure Cache for Redisを使用しています。

← Azure のイベントベースとメッセージングソリューション · すべてのドメイン · Azure の監視、診断、および DevOps 統合 →

これらの問題を練習する → · ExamRoll.ioで時間制限付き練習 →

Microsoftを閲覧 →