BLOGAzureブログ

アプリケーションからAzure Cache for Redisに接続してみよう

2025.03.03

クラウドサーバーご検討中の方必見 お役立ち資料一覧

皆さまこんにちは、SB C&Sの八釼(やつるぎ)です。
現代の一般的なアプリケーションが使用するデータはリレーショナルデータベースに保存することが多いのではないでしょうか?

しかしこれではあまり都合がよくない場合が現代では増えてきました。RDBMSを介して直接(リレーショナル)データベースを利用するとデータの書き込み・読み出しの時間がかかります。大量のトランザクションで高速なデータのやり取りを求められるアプリケーション、例えばIoTや大規模なWebサービスなどの場合です。

このような課題がでてくるともちろん解決するための手法を考えますよね。Azureでもこのような課題を解決できるサービスが提供されます。それがAzure Cache for Redisです。

ということで、今回はAzure Cache for Redisについての概要をご紹介しつつ、アプリケーションからこのサービスのリソースに接続する体験をしていただければと思います。

Azure Cache for Redisとは

詳細については公式ドキュメントをご確認いただければと思いますが、細かなことはさておきざっくりインメモリ データストア(データベース)と考えていただいて差し支えありません。若干補足するとオープンソースのKVS(Key-Value Store)であるRedis(Remote Dictionary Server)をAzure上のマネージドサービスとして利用できるものです。データをキーとバリュー(値)のペアで格納します。

なお、データをメモリ(キャッシュ)上の領域に格納することになるということは、電源を切るとデータは消失してしまうわけですが、Azure Cache for Redisは永続化機能も備えています。

また、必ずしも一般的にデータベースと言われるものに取って代わるサービス(仕組み)というわけではありません。それぞれの長所と短所を組み合わせるために、むしろ併用する場合が多いです。何となくのイメージでも、大量のデータをメモリに保存するというのは色々と不都合がありそうではないでしょうか?

チュートリアルの実施

今回は以下のチュートリアルを実施していただくことで、少しだけAzure Cache for Redisに触れていただこうと思います。AKSにアプリケーションをデプロイしてそれからキャッシュに接続しますので、人気のコンテナオーケストレーションにも触れられますし色々勉強になる部分が多くあります。

【関連記事】Azure Kubernetes ServicesをAzureリソースの視点で見てみよう

1. リソースグループとユーザー割り当てマネージド ID、ACRの作成

今回は licensecounter-blog-redisCache-rg という名前のリソースグループを作成しました。そして後々必要になるのでまずはユーザー割り当てマネージド ID(licensecounter-blog-userAssignedId)を作成しました。

2. Cache for Redis インスタンスの準備


licensecounter-blog-redisCache という名前のAzure Cache for Redisインスタンスを作成しました。そしてさきほど作成したユーザー割り当てマネージド IDにてこのキャッシュ インスタンスに接続できるようにし、Redisユーザー名を確認しました。

そして acrypzm3qbq7ni5i という名前のAzure Container Registry(ACR)リソースも作成しました。


3. AKS クラスターの構成


ここからはチュートリアルと同様にAzure CLI(Azure Cloud Shell)を使って進めていきます。


3-1. AKS クラスターを作成


まずは以下のように環境変数を設定します。


Bicep
                            
export RESOURCE_GROUP="licensecounter-blog-redisCache-rg"
export CLUSTER_NAME="licensecounter-blog-AKSCluster"
                            
                        


そしてAKSクラスターをデプロイするため、以下のコマンドを実行しました。


Azure CLI
                            
az aks create --resource-group "${RESOURCE_GROUP}"\
 --name "${CLUSTER_NAME}"\
 --enable-oidc-issuer\
 --enable-workload-identity\
 --generate-ssh-keys
                            
                        
3-2. OIDC 発行者 URL を取得


OIDC(OpenID Connect)発行者URLを取得するべく、環境変数AKS_OIDC_ISSUERを追加します。


Bash
                            
export AKS_OIDC_ISSUER="$(az aks show --name "${CLUSTER_NAME}" --resource-group "${RESOURCE_GROUP}" --query "oidcIssuerProfile.issuerUrl" --output tsv)"
                            
                        


念のためAKS_OIDC_ISSUERの値を出力させ確認します。


Bash
                            
echo $AKS_OIDC_ISSUER

https://japaneast.oic.prod-aks.azure.com/1e0e9558-c816-4936-a147-bef523f3e718/3e75997f-b5ee-4055-9b8f-9cb62bb40de0/
                            
                        
3-3. Kubernetes サービス アカウント作成


さきほど作成したKubernetes クラスターのアクセス資格情報を.kube/config ファイルにマージすべく以下のコマンドを実行しました。


Azure CLI
                            
az aks get-credentials --name "${CLUSTER_NAME}" --resource-group "${RESOURCE_GROUP}"

Merged "licensecounter-blog-AKSCluster" as current context in /home/yusuke_yatsurugi/.kube/config
                            
                        


そして新たに以下の環境変数を追加しました。


Bash
                            
export SERVICE_ACCOUNT_NAMESPACE="default"
export SERVICE_ACCOUNT_NAME="workload-identity-sa"
export USER_ASSIGNED_IDENTITY_NAME="licensecounter-blog-userAssignedId"
export FEDERATED_IDENTITY_CREDENTIAL_NAME="myFedIdentity"
export USER_ASSIGNED_CLIENT_ID="$(az identity show --resource-group "${RESOURCE_GROUP}" --name "${USER_ASSIGNED_IDENTITY_NAME}" --query 'clientId' --output tsv)"
                            
                        


そしてこれらの環境変数を使って "default" という名前空間に "workload-identity-sa" というサービスアカウントを作成しました。


Bash
                            
cat <<EOF | kubectl apply -f -
apiVersion: v1
kind: ServiceAccount
metadata:
annotations:
    azure.workload.identity/client-id: "${USER_ASSIGNED_CLIENT_ID}"
name: "${SERVICE_ACCOUNT_NAME}"
namespace: "${SERVICE_ACCOUNT_NAMESPACE}"
EOF

serviceaccount/workload-identity-sa created
                            
                        
3-4. フェデレーション ID 資格情報を作成

以下のコマンドにて、マネージド ID、サービスアカウント発行者、サブジェクトの間にフェデレーションID資格情報を作成しました。

Azure CLI
                            
az identity federated-credential create --name ${FEDERATED_IDENTITY_CREDENTIAL_NAME} --identity-name "${USER_ASSIGNED_IDENTITY_NAME}" --resource-group "${RESOURCE_GROUP}" --issuer "${AKS_OIDC_ISSUER}" --subject system:serviceaccount:"${SERVICE_ACCOUNT_NAMESPACE}":"${SERVICE_ACCOUNT_NAME}" --audience api://AzureADTokenExchange
                            
                        

4. Cache for Redis に接続するワークロードを構成


まずはGiHubで公開されるサンプルアプリのコードをダウンロードします。今回はリポジトリをCloneし、\azure-cache-redis-samples\tutorial\connect-from-aks\ConnectFromAKSにカレントディレクトリを移動した後、以下のコマンドを実行しました。


Azure CLI
                        
az acr build --image sample/connect-from-aks-sample:1.0\
 --registry acrypzm3qbq7ni5i\
 --file Dockerfile .
                        
                    


そして序盤に作成したACRを今回使用するAKSクラスターにアタッチします。


Azure CLI
                        
az aks update --name akscluster\
 --resource-group licensecounter-blog-redisCache-rg\
 --attach-acr acrypzm3qbq7ni5i
                        
                    

5. Cache for Redis に接続するワークロードをデプロイ

Kubectlをインストールしている端末は持っていますが、今回はあえてAzure Cloud Shellを使用しました。インストールできない事情がある場合やインストールの手間を省きたい場合にはAzure Cloud Shellをぜひ使っていただければと思います。

5-1. AKS クラスターに接続

設定した環境変数を利用してコマンドを実行しました。出力は問題なさそうです。

Azure CLI
                            
az aks get-credentials --resource-group "${RESOURCE_GROUP}" --name "${CLUSTER_NAME}"

Merged "licensecounter-blog-AKSCluster" as current context in /home/yusuke_yatsurugi/.kube/config
                            
                        

そして以下のKubectlコマンドを実行してクラスターに接続できるか確認します。問題なくクラスターノードの一覧が表示されました。

kubectl
                            
kubectl get nodes

NAME                                STATUS   ROLES    AGE   VERSION
aks-nodepool1-41487293-vmss000000   Ready    <none>   32m   v1.30.9
aks-nodepool1-41487293-vmss000001   Ready    <none>   32m   v1.30.9
aks-nodepool1-41487293-vmss000002   Ready    <none>   32m   v1.30.9                                
                            
                        

6. Cache for Redis に接続するワークロードを実行


今回はアクセスキー認証を使用しました。そのためpodspec.yamlにおいて


  • ・AUTHENTICATION_TYPE
  • ・REDIS_HOSTNAME
  • ・REDIS_ACCESSKEY
  • ・REDIS_PORT

の環境変数に値を記述しました。もちろんACRに格納したイメージの部分についても書き換えました。

kubectl
                        
apiVersion: v1
kind: Pod
metadata:
    name: entrademo-pod
    labels:
      azure.workload.identity/use: "true"  # Required. Only pods with this label can use workload identity.
spec:
    serviceAccountName: workload-identity-sa
    containers:
    - name: entrademo-container
      image: acrypzm3qbq7ni5i.azurecr.io/sample/connect-from-aks-sample:1.0
      imagePullPolicy: Always
      command: ["dotnet", "ConnectFromAKS.dll"] 
      resources:
        limits:
          memory: "256Mi"
          cpu: "500m"
        requests:
          memory: "128Mi"
          cpu: "250m"
      env:
          - name: AUTHENTICATION_TYPE
            value: "ACCESS_KEY" # change to ACCESS_KEY to authenticate using access key
          - name: REDIS_HOSTNAME
            value: "licensecounterakscluster.redis.cache.windows.net"
          - name: REDIS_ACCESSKEY
            value: "UeN4ckv3Z8qtV4MlGnWzcBIAKtfJJhHneAzCaBgWqk4=" 
          - name: REDIS_PORT
            value: "6380" # change to 10000 for Azure Managed Redis
    restartPolicy: Never
                        
                    

そしてAKSクラスターに適用しました。

kubectl
                        
kubectl apply -f podspec.yaml

pod/entrademo-pod created
                        
                    

ではアプリケーションのテストです。まずはポッドの正常性を確認します。問題なしですね。

kubectl
                        
kubectl get pods

NAME            READY   STATUS      RESTARTS   AGE
entrademo-pod   0/1     Completed   0          24s
                        
                    

そして想定どおりに実行されたことを確認するためにポッドのログを確認してみます。正常に接続されたことを示す出力が返されました。

kubectl
                        
kubectl logs entrademo-pod

This sample shows how to connect to an Azure Redis cache using an Microsoft Entra identity or an access key. You can also run this sample locally with your user principal configured as a Redis User for your redis instance.
Connecting to {cacheHostName} with an access key..
Retrieved value from Redis: Hello, Redis!
                        
                    


ちなみに、本記事執筆時点では、このチュートリアルに記載されているコマンドの記述は間違っており(×entrademo-app)正しくは kubectl logs entrademo-pod です。podspec.yamlではentrademo-podと記述しましたからね。チュートリアル通りにコマンドを実行しするとエラーが出るのでご注意ください。


最後に

RedisのようなKVSの出番はIoTや比較的規模の大きなシステム開発に携わらないとなかなかないかとは思いますが、このようなインメモリデータストアが手軽に使えるのがAzureのようなクラウドプラットフォームサービスの醍醐味ですし無視できないサービスです。

Azureを活用したアプリケーション開発にあたっては色々とお困りごとが出てくるかもしれませんが、その際にはぜひとも法人でのAzure導入前の相談窓口であるAzure相談センターまでお気軽にお問い合わせいただけますと幸いです。弊社では、ユーザー様のご状況やご要望を踏まえて最適な形でのAzureの導入のご支援を提供しており、Azure に精通したスタッフが丁寧にご回答させていただきます。

  • 【 著者紹介 】
    八釼 友輔 - Azure エヴァンジェリスト
    SB C&S株式会社 ICT事業本部 クラウド・ソフトウェア推進本部
    クラウド・ソフトウェア戦略企画部 1課
yyatsurugi-image-v3.png

Azureの導入や運用に関するお悩みは SoftBankグループのSB C&Sにご相談ください

SoftBankグループのSB C&Sは、さまざまな分野のエキスパート企業との協力なパートナーシップによって、多岐にわたるAzure関連ソリューションをご提供しています。

「Azureのサービスを提供している企業が多すぎて、どの企業が自社にベストか分からない」
「Azure導入のメリット・デメリットを知りたい」
「Azureがどういう課題を解決してくれるのか知りたい」
など、Azureに関するお悩みならお気軽にお問い合わせください。
中立的な立場で、貴社に最適なソリューションをご提案いたします。

クラウドサーバーご検討中の方必見
お役立ち資料一覧

クラウドサーバーご検討中の方必見 お役立ち資料一覧
  • クラウドサーバーの導入を検討しているがオンプレミスとどう違うのか
  • AWSとAzureの違いについて知りたい
  • そもそもAzureについて基礎から知りたい
  • 今、話題の「WVD」って何?

そのようなお悩みはありませんか?
Azure相談センターでは、上記のようなお悩みを解決する
ダウンロード資料を豊富にご用意しています。
是非、ご覧ください。

Azureの導入・運用に役立つ資料を
無料でダウンロードしていただけますDOWNLOAD

オンプレミスからクラウドへの移行を検討している方のために、安心・スムーズな移行を実現する方法を解説し、
運用コストの削減に有効な「リザーブドインスタンス」もご紹介するホワイトペーパーです。

Azureのことなら、
SB C&Sにご相談を!

導入から活用まで専門スタッフが回答いたします。
お気軽にお問い合わせください。