Azure Cache for Redis入門｜SKUの選び方・接続設定・料金をオンプレ経験者向けに徹底解説

Webアプリのレスポンスが遅い。DBのCPUが高騰している。セッション管理をどこに持たせるか悩んでいる——こうした課題に直面したとき、インメモリキャッシュの導入は定番の解決策です。オンプレ時代はRedisを自前サーバーに立てていたエンジニアも多いでしょう。Azureではこれをフルマネージドで提供するAzure Cache for Redisがあります。

この記事では、Azure Cache for Redisの基本概念・SKU選定・接続設定・料金体系を、オンプレでRedisを運用した経験のあるインフラエンジニア向けに解説します。AWS ElastiCacheとの違いや、実務でよくあるハマりポイントも合わせて整理します。

Azure Cache for Redisとは（オンプレRedisとの違い・背景）

Azure Cache for Redisは、Microsoftが提供するフルマネージドのインメモリデータストアです。オープンソースのRedisをベースにしており、データのキャッシュ・セッション管理・メッセージブローカーとして広く使われています。

オンプレでRedisを運用していた場合、以下の作業がAzure側に委任されます。

・OS・ミドルウェアパッチ適用: バージョン管理や適用作業が不要
・レプリケーション設定: Standard以上でプライマリ/レプリカが自動構成
・クラスタリング: Premium以上でRedisクラスターを簡単に有効化
・バックアップ: Premium SKUでRDB永続化が利用可能

一方で「自由なRedis設定ができない」「特定のモジュールが使えない」という制約もあります。カスタム設定でRedisを動かしたい場合はAzure VM上に自前でインストールする選択肢も残りますが、運用コストを考えればフルマネージドが現実解です。

なお、Azure Cache for RedisはAzure Virtual Network（VNet）と組み合わせて使うケースが多くなります。VNetの基本はAzure Virtual Network（VNet）入門を参考にしてください。

SKU（価格レベル）の選び方

Azure Cache for Redisには4つのSKUがあります。選択を誤ると後からサイズ変更が制限される場合があるため、最初の設計が重要です。

オンプレでRedisを使っていたエンジニアに一言アドバイスすると、「とりあえずBasicで試して後でStandardに上げよう」という発想は危険です。BasicからStandardへの移行は新規作成＋データ移行が必要なケースがあり、本番では最初からStandard以上を選んでおくのが無難です。

1. キャッシュサイズの目安

各SKUにはキャッシュメモリサイズ（C0～C6やP1～P5）のオプションがあります。Standard C1（1GB）から始めて、ヒット率とメモリ使用率をAzure Monitorで監視しながら段階的にスケールアップするのが現実的なアプローチです。

基本的な使い方（コンソール操作 or CLI）

2. Azure PortalからCache for Redisを作成する

1. Azureポータルで「Azure Cache for Redis」を検索して「作成」をクリック
2. リソースグループ・キャッシュ名・リージョン（japaneast = 東日本リージョン（japaneast））を入力
3. SKUとキャッシュサイズを選択
4. ネットワーク設定でパブリックエンドポイントまたはプライベートエンドポイントを選択
5. 「作成」でデプロイ開始（5～10分程度）

Azure CLIでも同様の操作ができます。

# Azure CLI — Standard C1（1GB）のキャッシュを東日本リージョンに作成
az redis create \
  --name myRedisCache \
  --resource-group myResourceGroup \
  --location japaneast \
  --sku Standard \
  --vm-size C1

3. 接続設定とアクセスキーの確認

作成後、Azureポータルの「アクセスキー」ブレードでプライマリ接続文字列を確認できます。

# 接続文字列の例（TLS有効・ポート6380）
myRedisCache.redis.cache.windows.net:6380,password=<アクセスキー>,ssl=True,abortConnect=False

オンプレのRedisはデフォルトでTLSなしのポート6379を使うことが多いですが、Azure Cache for RedisはTLS（ポート6380）がデフォルトです。クライアントライブラリの設定でSSL=Trueを明示しないと接続できないため、移行時に注意してください。

4. VNetとの統合（Premiumの場合）

Premium SKUではRedisインスタンスをAzure VNet内に配置できます。アプリケーションと同一VNetまたはピアリングされたVNetに置くことで、インターネットを経由しないプライベート通信が実現します。本番環境ではこの構成を強く推奨します。

料金の仕組み（コスト感覚）

Azure Cache for Redisの料金は「SKU × サイズ × 稼働時間」で決まります。代表的な料金例（東日本リージョン（japaneast）、2026年3月時点・USD表示）は以下の通りです。

データ転送料は、同一リージョン内のVNet通信であれば基本的に無料です。ただしgeo-replication（地理的レプリケーション）を使う場合、リージョン間のデータ転送料が別途発生します。コスト管理はAzure Cost Managementと組み合わせると管理しやすくなります。Azure Cost Management入門も参考にしてください。

応用・実務Tips

5. セッション管理への活用

WebアプリのセッションをAzure Cache for Redisに保存するのは最も一般的なユースケースです。ASP.NETであれば`StackExchange.Redis`、Javaであれば`Spring Session`、Node.jsであれば`connect-redis`を使うことで、セッションデータをインメモリに格納しつつアプリサーバーをステートレスに保てます。

Azure App ServiceやAKSで水平スケーリングする際も、どのインスタンスにリクエストが届いてもセッションが維持されます。Azure App Serviceとの組み合わせ方についてはAzure App Service入門を参照してください。

6. DBクエリキャッシュの実装パターン

頻繁に参照されるがほとんど更新されないデータ（商品カタログ、マスターデータ等）をRedisにキャッシュするパターンです。

# Python（redis-py）でのキャッシュ実装イメージ
import redis, json

r = redis.StrictRedis(
    host='myRedisCache.redis.cache.windows.net',
    port=6380,
    password='<アクセスキー>',
    ssl=True
)

def get_product(product_id):
    cache_key = f"product:{product_id}"
    cached = r.get(cache_key)
    if cached:
        return json.loads(cached)
    # DBから取得してキャッシュに保存（TTL 3600秒）
    product = db.query_product(product_id)
    r.setex(cache_key, 3600, json.dumps(product))
    return product

TTL（有効期限）の設定を忘れると古いデータが残り続ける「キャッシュ汚染」が発生するため、必ず有効期限を設定してください。

7. AWS ElastiCacheとの主な違い

AWSからAzureへの移行やマルチクラウド設計を検討しているエンジニアのために、主な違いを整理します。

VNet統合はElastiCacheが全プランで対応している点がAzureより柔軟です。ElastiCacheの詳細はAmazon ElastiCache入門｜RedisとMemcachedの違いとクラウドキャッシュ設計の基礎知識を参照してください。

よくあるトラブルと対処法

接続タイムアウトが頻発する
原因の大半は`maxmemory-policy`による古いキーの削除か、クライアント接続数の上限超過です。Azure MonitorでConnected Clients・Server Loadメトリクスを確認し、サイズアップを検討してください。Azure Monitor入門でメトリクス監視の基本を押さえておくと対応が速くなります。

TLSエラーで接続できない
クライアントライブラリのSSL設定が正しくない場合に発生します。.NETの`StackExchange.Redis`であれば設定文字列の末尾に`ssl=true`を付けることを確認してください。非TLSの6379ポートへの接続はデフォルトで無効です。

BasicをそのままNon-productionで使い続けてしまった
BasicはSLAがなく単一ノードのため、メンテナンス時にダウンタイムが発生します。本番へのBasic投入は設計ミスです。早急にStandard以上に切り替えてください（新規作成→データ移行→接続文字列変更の手順が必要）。

メモリ使用率が常に90%を超える
キャッシュキーのTTLが設定されていないか、キャッシュしているデータ量がサイズに対して多すぎます。TTL見直しとサイズアップを並行して検討してください。

本記事のまとめ

オンプレでRedisを自前運用していたエンジニアにとって、Azure Cache for Redisへの移行は比較的スムーズです。ただしTLSのデフォルト有効・SKU設計・VNet統合の要件を最初に整理しておかないと、本番後に設定変更の手間がかかります。まずStandard C1で動かしてみて、Azure Monitorでメトリクスを確認しながら段階的にチューニングしていきましょう。

Linuxサーバーの基礎については、姉妹サイトLinuxMaster.JPで詳しく解説しています。