Azure Cache for Redis

解決する課題

データベースへの繰り返しアクセスや遅い計算結果を、メモリ上にキャッシュして肩代わりします。インフラの構築・パッチ適用・監視を自分で抱えずに、Redis の高速なインメモリ処理を利用できます。

• 同じデータへの読み取りが多く、DBの負荷とコストを下げたい
• ミリ秒未満の低レイテンシ応答をユーザーへ返したい
• 複数のアプリインスタンス間でセッションや一時状態を共有したい
• Redis サーバーの運用（パッチ・冗長化・バックアップ）を任せたい

主要概念と用語

• インメモリキャッシュ: データをメモリ上に保持し、ディスクアクセスを避けて高速に読み書きする仕組み
• Redis: キーバリュー型のインメモリデータストア。文字列のほかリスト/ハッシュ/セット/ソート済みセットなどの構造を扱える
• キャッシュアサイド（Cache-Aside）: アプリがまずキャッシュを見て、なければDBから読んでキャッシュに書き戻す代表的なパターン
• TTL（Time To Live）: キーに有効期限を設定し、期限切れで自動的に削除する仕組み
• エビクション（追い出し）ポリシー: メモリが上限に達したとき、どのキーを退避するかを決める方針（LRU など）
• ティア（プラン）: Basic / Standard / Premium / Enterprise / Enterprise Flash といった提供階層
• Pub/Sub: 発行と購読でメッセージを配信する軽量メッセージング機能
• クラスタリング（シャーディング）: データを複数ノードに分割して容量とスループットを拡張する仕組み

仕様・制限・クォータ

• 提供は複数のティアに分かれ、上位ほどメモリ容量・スループット・可用性・機能が増える
• Basic はノード単一構成でSLAなし。検証・開発向け
• Standard は2ノードのレプリケーション構成で、可用性のSLAが付く
• Premium は永続化（データのディスク保存）、VNet 統合、ゾーン冗長、クラスタリング、ジオレプリケーションなど高度な機能に対応
• Enterprise / Enterprise Flash は Redis Enterprise ベースで、より高いパフォーマンスやモジュール（検索など）に対応。Flash はメモリと SSD を併用して大容量を低コストで扱う
• 接続数・帯域・メモリの上限はティアとサイズで決まるため、想定負荷に合わせて選ぶ
• キャッシュは原則として揮発性であり、永続データの唯一の保存先にはしない（権威データはDBに置く）

内部の仕組み

Azure Cache for Redis はマネージドな Redis ノード群として動作します。Standard 以上ではプライマリとレプリカの2ノード構成をとり、プライマリ障害時はレプリカへ自動フェイルオーバーして可用性を保ちます。クライアントは接続文字列とアクセスキー（またはトークン）で接続し、キーごとに値を読み書きします。

メモリが上限に達すると、設定されたエビクションポリシーに従ってキーが追い出されます。多くのキャッシュ用途では、最近使われていないキーを優先的に退避する LRU 系のポリシーが適します。TTL を併用すると、期限切れのキーが自動で消えてメモリを健全に保てます。Premium 以上ではクラスタリングによりデータを複数シャードへ分割し、容量とスループットを水平に拡張できます。

設計パターン / ベストプラクティス

• 最も基本となるキャッシュアサイドで、読み取りの多いデータをDBから肩代わりする
• すべてのキーに適切な TTL を付け、古いデータが残り続けないようにする
• キーには命名規則（プレフィックスやバージョン）を設け、無効化や衝突回避をしやすくする
• 接続オブジェクトは使い回す（プールする）。リクエストごとの接続生成は枯渇とレイテンシ悪化を招く
• 大量データの一括取得や巨大なキー（ホットキー）を避け、負荷を分散する
• セッション状態やレート制限カウンタなど、短命で共有したい状態の置き場として使う

運用・監視

• Azure Monitor / Metrics で Used Memory、Cache Hit/Miss、Connected Clients、Server Load、CPU などを監視する
• ヒット率が低い場合は、キャッシュ対象データやTTL、キー設計を見直す
• メモリ使用率や追い出し（Evicted Keys）が高い場合は、ティア/サイズのスケールアップやクラスタリングでのスケールアウトを検討する
• 接続数が上限に近い場合は、接続の使い回しやプール設定を確認する
• 診断ログ（Diagnostic Settings） を Log Analytics へ送り、遅いコマンドや接続傾向を分析する
• メンテナンス（パッチ適用）の通知に注意し、フェイルオーバーに耐える接続リトライをアプリに実装する

コスト

課金はおおむね選んだティアとキャッシュサイズ（メモリ容量）の時間単価で決まります。トラフィック量ではなく、確保した容量に対して課金される点が特徴です。

長期間動かす場合は**予約容量（Reserved Capacity）**でコミットして割引を受けられます。不要に大きいティアを選ばず、メトリクスを見て必要十分なサイズに調整することがコスト最適化の基本です。

セキュリティ

• 通信は TLS による暗号化を有効にする（平文接続は無効化する）
• Microsoft Entra ID 認証に対応するティア/構成では、アクセスキーのハードコードを避けてトークンベースで接続できる（AWS の IAM 連携に近い考え方）
• アクセスキーは Key Vault で管理し、定期的にローテーションする
• プライベートエンドポイント（Private Link） や Premium の VNet 統合で、パブリックアクセスを閉じて VNet 内からのみ到達させる
• ファイアウォール規則で接続元 IP を最小限に絞る

Well-Architected の観点

• パフォーマンス効率: 読み取りをキャッシュへ逃がし、DBのレイテンシとスループット制約を緩和する。ヒット率とメモリ使用率を継続的に最適化する
• コスト最適化: 確保容量への課金を理解し、必要十分なティア/サイズを選ぶ。長期稼働は予約容量で割引を得る
• 信頼性: Standard 以上の冗長構成とゾーン冗長を使い、キャッシュ障害時もDBへフォールバックできる設計にする
• セキュリティ: TLS、プライベート接続、Entra ID/トークン認証でアクセスを保護する

試験で問われるポイント

関連サービス・比較

ハンズオン / CLI例

# リソースグループを作成
az group create --name demo-rg --location japaneast

# Standard ティアのキャッシュを作成（C1 サイズ）
az redis create \
  --name demo-redis-cache \
  --resource-group demo-rg \
  --location japaneast \
  --sku Standard \
  --vm-size C1 \
  --minimum-tls-version 1.2

# 接続に必要なホスト名を確認
az redis show \
  --name demo-redis-cache \
  --resource-group demo-rg \
  --query hostName --output tsv

# アクセスキーを取得（直書きせず Key Vault 等で管理する）
az redis list-keys \
  --name demo-redis-cache \
  --resource-group demo-rg

# サイズをスケールアップ（C1 から C2 へ）
az redis update \
  --name demo-redis-cache \
  --resource-group demo-rg \
  --set sku.capacity=2