Redis:シングルレプリカから高可用性(HA)モードのRedisへの移行
Cognigy.AIリリースv4.65から、シングルレプリカのRedis設定は廃止され、高可用性(HA)モードのRedisに置き換えられました。
RedisとRedis永続HA構成の準備
Cognigy.AI v4.65にアップグレードする前に、以下の手順を実行し、Cognigy.AI Helmリリースのvalues.yamlを適宜変更する必要があります。
自己管理型Redisのインストール
AI Helm Chartで提供されるRedisおよびRedis永続サービスを使用せず、代わりに自己管理型の外部Redisサービスを使用する場合は、values.yamlに以下の変数があることをご確認ください:
statefulRedis:
  enabled: false
statefulRedisPersistent:
  enabled: false1. 自己管理型のRedisインストールを使用し続けるには、values.yamlの以下の設定で、新しいRedisおよびRedis永続HAデプロイメントを無効にします:
redisHa:
  enabled: false
redisPersistentHa:
  enabled: false2. values.yamlからstatefulRedisおよびstatefulRedisPersistentセクションを削除し、この移行ガイドの残りの手順をスキップします。
クラウドインフラの構成
1. RedisとHAモードのRedis永続は、サービスの可用性を高めるために3つのレプリカでプロビジョニングされます。Kubernetesクラスタに、HAセットアップのRedisポッドとRedis永続ポッドを追加するのに十分な空き容量があることをご確認ください。合計で、どちらの構成でも、クラスタに3つのCPUコアと3GBのRAMを追加でプロビジョニングする必要があります。
2. 以下のコマンドを使用して、既存のredis-persistent StorageClassのreclaimPolicyを確認します:
kubectl get storageclass redis-persistent -o yamlreclaimPolicy: Deleteの場合は、このガイドの[Persistent Volume Clean-up(永続ボリュームのクリーンアップ)]のセクションをスキップできます。reclaimPolicy: Retainの場合は、[Persistent Volume Clean-up(永続ボリュームのクリーンアップ)]セクションで説明するように、永続ボリュームと基礎となるディスクを手動でクリーンアップしてください:
3. Redis HAデフォルト設定では、クラスタを3つのAvailability Zone (AZ)(Cognigy.AI推奨セットアップ)で実行し、Helmリリースでは3つのAZにわたってHAレプリカを生成します。クラスタがAvailability Zoneなしでプロビジョニングされている場合は、values.yamlでzonal podAntiAffinityをオーバーライドします:
redisHa:
  replica:
    affinity:
      podAntiAffinity:
        requiredDuringSchedulingIgnoredDuringExecution: []
redisPersistentHa:
  replica:
    affinity:
      podAntiAffinity:
        requiredDuringSchedulingIgnoredDuringExecution: []4. クラウドプロバイダーがAWSでもAzureでもない場合は、redis-persistent-ha StorageClassを手動で作成します。新しい redis-persistent-ha StorageClass のすべてのパラメータを、既存の redis-persistent StorageClass と同等に設定します:
- 既存の redis-persistent-ha StorageClassを取得し、redis-persistent-ha.yamlファイルに保存します:kubectl get storageclass redis-persistent -o yaml > redis-persistent-ha.yaml
- テキストエディタでredis-persistent-ha.yamlファイルを開きます。name: フィールドをredis-persistent-haに変更します。uid:、resourceVersion:、creationTimestamp:フィールドを削除します。
- ファイルを保存し、kubectl apply -f redis-persistent-ha.yamlをクラスタに適用して、新しいredis-persistent-ha StorageClassを作成します。
- 新しいStorageClassがkubectl get storageclass redis-persistent-ha -o yamlクラスタに作成されたことを確認します。
5. クラウドプロバイダーが AWS または Azure の場合、redis-persistent-ha StorageClass が自動的に作成されます。Helmリリースをアップグレードする前に、以下をご確認ください:
- AWSの場合: gp3ストレージとebs.csi.aws.comプロビジョナーがクラスタで有効になっていること。
- Azureの場合:Premium_LRSストレージアカウントとdisk.csi.azure.comプロビジョナーがクラスタで有効になっていること。
- 代わりに、storageClass: セクションのredisPersistentHaの設定を上書きして、既存のredis-persistent StorageClassのパラメータと一致させることができます。AWSとAzureのリファレンスについては、values.yamlをご参照ください。
カスタムRedisおよびRedis永続設定の移行
- Cognigy.AI Helm Release values.yamlのstatefulRedisおよびstatefulRedisPersistentセクションにカスタム設定がない場合は、このセクションをスキップしてください。
- statefulRedisセクションおよび/または- statefulRedisPersistentセクションにカスタム設定がある場合は、以下のようにredisHaおよび- redisPersistentHaにそれぞれコピーする必要があります:- statefulRedis.auth.passwordが平文で定義されている場合は、- redisHa.auth.passwordの下にコピーする。
- statefulRedisPersistent.auth.passwordが平文で定義されている場合、その値を- redisPersistentHa.auth.passwordの下にコピーする。
- カスタムstatefulRedis.auth.existingSecretが定義されている場合は、その値をredisHa.auth.existingSecretの下にコピーします。対応するカスタムシークレットがクラスタ内に存在することを確認する。
- カスタムstatefulRedisPersistent.auth.existingSecretが定義されている場合は、その値をredisPersistentHa.auth.existingSecretの下にコピーします。対応するカスタムシークレットがクラスタ内に存在することを確認する。
- values.yamlに- statefulRedis用のカスタムリソースが定義されている場合は、- resourcesセクション(- requestsと- limitsの両方を含む)を- redisHa.replica.resourcesにコピーします。- redisHa.replica.configurationパラメータの- maxmemory設定を- resources.limits.memoryの85%に設定する。詳細は values.yaml をご参照ください。
- values.yamlに- statefulRedisPersistent用のカスタムリソースが定義されている場合は、resourcesセクション(requestsとlimitsの両方を含む)を- redisPersistentHa.replica.resourcesにコピーします。詳細は、values.yamlをご参照ください。
 
Cognigy.AI Helmリリースをv4.65にアップグレードする
- Cognigy.AI Helmリリースをv4.65にアップグレードする
- values.yaml のすべてのパラメータが上記のように調整されていることを再確認します。- 通常通り、Cognigy.AI Helm リリースを v4.65 にアップグレードします。アップグレード中:
- 新しいredis-ha-nodeとredis-persistent-ha-node StatefulSetsと対応するポッドがクラスタに作成されます。
- 古いredisおよびredis-persistentデプロイメントと対応するポッドがクラスタから削除されます。
- Cognigy.AIのサービスがRedisおよびRedisパーシステントHAセットアップに再接続します。
- kubectl get pods -n=cognigy-ai.を実行することで、すべてのPodが期待通りに動作していることを確認します。
 
永続ボリュームのクリーンアップ
Cognigy.AIをv4.65にアップグレードし、リリースが正しく動作することを確認した後、古いredis-persistent Deploymentの残りの永続ボリューム(PV)をクリーンアップすることができます:
- 古いredis-persistent StorageClassにreclaimPolicy:Deleteが設定されている場合は、このセクションをスキップしてください。基礎となるPVとPVCは自動的に削除されます。
- 古いredis-persistent StorageClassにreclaimPolicy:Retainが設定されている場合は、古いredis-persistent Deploymentに関連付けられたPVと、クラウドインフラの基盤となるディスクを手動で削除します:- kubectl get pvクラスタ内のPVを取得する。
- ReleasedステータスのPVの名前をCLAIM: cognigy-ai/redis-persistent(以下PV_NAME)と記述する。
- kubectl delete pv PV_NAME で PV を削除する。
- クラウド環境の PV_NAME に対応するストレージディスクを削除する。