Azure Kubernetes Service (AKS)へのダウンタイムなしの移行

この記事では、最小限またはゼロのダウンタイムで既存のワークロードをAzure Kubernetes Service (AKS)に移行し、既存の AKS クラスターで新しいアプリケーション バージョンをリリースするための、実稼働に重点を置いた実用的なアプローチについて説明します。

簡単な回答: 移行の場合は、ソース環境と AKS 環境を並列で実行し、トラフィックを段階的にシフトします。 1 つの AKS クラスター内で繰り返し行うアプリケーション リリースには、レディネス プローブ、制御されたトラフィック シフト、可観測性ゲート、検証済みのロールバックを備えた、ローリング アップデート、カナリア、またはクラスター内ブルーグリーン デプロイを使用します。

クイック ランブック: AKSをダウンタイムなしで移行するための5つの手順

1. AKS、証明書、ネットワーク、監視のプロビジョニングを行います。
2. レディネス プローブ、ライブネス プローブ、PodDisruptionBudget、およびリソース リクエストを使用して、アプリをデプロイします。
3. レプリケーション、CSI スナップショット、または Velero とデータを同期します。
4. Traffic Manager で相対 DNS 重みを使用するか、イングレスまたはサービス メッシュ ルーティングで正確な要求パーセンテージを使用して、トラフィックを段階的にシフトします。
5. SLO ゲートを検証し、安定性基準に合格した場合に古いインフラストラクチャを使用停止します。

あなたは次のことを学びます：

• クラスターを置き換えずに、既存の AKS クラスターで新しいアプリケーション バージョンをリリースします。
• ブルーグリーン、カナリア、ローリング DNS の移行戦略を比較します。
• AKS 固有のコマンドを使用して、移行前の準備チェックリストを実行します。
• AKS とAzure Traffic Managerを使用して、クラスターの完全な Blue-Green 移行を実行します。
• CSI スナップショット、Azure Files、または Velero を使用して永続的なデータを移行します。
• カットオーバーの前にロールバック計画を準備します。

移行戦略の比較

この比較を使用して、リスク許容度、可観測性の成熟度、ロールバックの要件に合った移行アプローチを選択します。

戦略	トラフィックへの影響	ロールバック速度	Complexity	AKS の機能とAzure サービス
Blue-Green (クラスターまたは名前空間)	緑が正常な場合にのみトラフィックが切り替わるため、最小限	トラフィックをブルーに戻すことで、非常に迅速に対応できます。	環境とトラフィック ルーティングが重複する必要があるため、中	Azure Traffic Manager、ロード バランサーのパブリック IP アドレス、Ingress
Canary	トラフィックが徐々に変化するため、非常に低い	カナリアの容量を削減するか、カナリア ポッドの規模を縮小することで、高速化を実現する	トラフィックの分割と可観測性が必要なため、中高	イングレス (nginx またはゲートウェイ API)、サービス メッシュ (Istio または Linkerd)、AKS イングレス アドオン
Rolling DNS（TTLベース）	DNS TTL に依存します。TTL が短いほど影響が小さくなります	中(DNS キャッシュはロールバックを遅らせる可能性があるため)	低、セットアップは簡単だが精度はやや低いため	Azure DNS、TTL の短いレコード、LoadBalancer、または イングレス

ワークロードの決定マトリックス

ワークロードの種類別の簡単な戦略の推奨事項が必要な場合は、次の表を使用します。

ワークロードの種類	推奨される戦略	なぜでしょうか	コストと複雑さ
ステートレス Web/API	カナリア、その後ブルーグリーンで最終移行	迅速なロールバックによる進歩的なリスク削減	中程度
データベースをバックエンドとするステートフルなアプリ	ブルー/グリーン＋複製促進型データパス	強力なロールバック制御と明確なフェールバック パス	High
ファイル負荷の高いワークロード	Blue-Green と Azure Files のコピー/スナップショット	切り替え前のデータ パリティの検証が容易	中程度から高い
長時間実行されるジョブ/ワーカー	キューの処理を伴うローリング アップデートまたはメンテナンス期間	ユーザー向けの影響の低減、ルーティングの簡素化	低から中

プログレッシブデリバリーツールオプション

• 手動の重み付けルーティング (Traffic Manager とイングレスまたは LoadBalancer): 明示的なオペレーター制御と単純な依存関係が必要な場合に最適です。
• サービス メッシュ ルーティング (Istio または Linkerd): きめ細かいルーティング、再試行、ポリシー制御が必要な場合に最適です。
• Argo ロールアウトまたはフラグ: 自動プログレッシブ配信、メトリック分析、自動ロールバックが必要な場合に最適です。

グローバル DNS レベルの重み付けに Traffic Manager を使用し、クラスター内で自動ロールアウト分析が必要な場合は、Argo ロールアウトまたはフラグ付けツールと組み合わせます。

既存の AKS クラスターでアプリケーションを解放する

定期的なアプリケーション リリースでは、2 つ目のクラスターや DNS カットオーバーは必要ありません。 AKS で既に実行されているステートレス アプリケーションの場合は、複数のレプリカとRollingUpdate戦略を持つ Kubernetes Deploymentを使用します。 Kubernetes は、同じクラスターに新しいバージョンのポッドを作成し、準備が整うのを待ってから、古いバージョンのポッドを徐々に削除します。

次の例では、Kubernetes が一度に 1 つの追加ポッドを起動している間、すべての既存のレプリカを使用できます。

apiVersion: apps/v1
kind: Deployment
metadata:
  name: myapp
spec:
  replicas: 3
  strategy:
    type: RollingUpdate
    rollingUpdate:
      maxUnavailable: 0
      maxSurge: 1
  minReadySeconds: 10
  progressDeadlineSeconds: 600
  selector:
    matchLabels:
      app: myapp
  template:
    metadata:
      labels:
        app: myapp
    spec:
      terminationGracePeriodSeconds: 60
      containers:
      - name: myapp
        image: myregistry.azurecr.io/myapp:v2
        ports:
        - containerPort: 8080
        readinessProbe:
          httpGet:
            path: /healthz
            port: 8080
          periodSeconds: 5
          failureThreshold: 3
        livenessProbe:
          httpGet:
            path: /live
            port: 8080
          periodSeconds: 10
          failureThreshold: 3
        lifecycle:
          preStop:
            exec:
              command: ["/bin/sh", "-c", "sleep 30"]

クラスターにサージ ポッドの容量があることを確認します。 マニフェストを適用し、ロールアウトを監視し、新しいイメージを確認します。

kubectl apply -f manifests/app-deployment.yaml
kubectl rollout status deployment/myapp --timeout=10m
kubectl get pods -l app=myapp -o custom-columns=NAME:.metadata.name,IMAGE:.spec.containers[0].image,READY:.status.containerStatuses[0].ready

以降のリリースでは、イメージを更新し、展開ロールアウトを監視します。

kubectl set image deployment/myapp myapp=myregistry.azurecr.io/myapp:v3
kubectl rollout status deployment/myapp --timeout=10m

ロールアウト中のエラー率、待機時間、ポッドの準備状況、およびビジネス トランザクションを監視します。 ゲートが失敗した場合は、リリースを停止または元に戻します。

kubectl rollout pause deployment/myapp
kubectl rollout undo deployment/myapp
kubectl rollout status deployment/myapp --timeout=10m

PodDisruptionBudget は、ノードドレインなどの自発的な削除操作中にレプリカを保護しますが、アプリケーションのロールアウト中に Deployment がポッドを置き換える方法を制御しません。 リリースの可用性を制御するには、 maxUnavailable と maxSurge を使用します。 要求レベルのトラフィックの割合または自動メトリック分析を必要とするアプリケーションの場合は、同じクラスターで安定バージョンとカナリア バージョンを実行し、イングレス コントローラー、サービス メッシュ、Argo ロールアウト、またはフラグを使用してトラフィックを段階的にシフトします。

始める前の準備

• Azure CLI バージョン 2.59.0 以降。
• kubectl ソース クラスターに接続されています。
• クラスター、ネットワーク、ID を作成および管理するための AKS アクセス許可。
• テスト済みのアプリケーション正常性エンドポイント ( /healthzなど)。
• トラフィックの切り替え前に承認されたロールバック責任者とロールバック チェックリスト。
• DNS TTL 削減計画は、カットオーバーの少なくとも 24 ~ 48 時間前に準備されました。

TLS と証明書の事前プロビジョニング

トラフィック規制の実施前に、緑地環境における供給証明書を発行します。 現在の環境で TLS が終了する場合は、カットオーバーする前に、証明書を Kubernetes シークレットにエクスポートしてインポートします (または cert-manager を構成します)。

# Example: create a TLS secret in the target namespace
kubectl create secret tls myapp-tls \
  --cert ./tls.crt \
  --key ./tls.key \
  --namespace production

ACME (Let's Encrypt など) を使用する場合は、HTTPS エラーを回避するために、カットオーバーの前にドメイン検証を完了します。

移行前の準備チェックリスト

移行する前に、これらのチェックを実行します。 すべてのエクスポートをバージョン管理またはセキュリティで保護されたストレージに保存します。

ソース クラスターから Kubernetes リソースをエクスポートする

kubectl --context=current-prod-cluster get all --all-namespaces -o yaml > exports/all-namespaces-all-resources.yaml
kubectl --context=current-prod-cluster get deployments,statefulsets,daemonsets --all-namespaces -o yaml > exports/workloads.yaml
kubectl --context=current-prod-cluster get svc --all-namespaces -o yaml > exports/services.yaml
kubectl --context=current-prod-cluster get configmap,secret --all-namespaces -o yaml > exports/configs-secrets.yaml
kubectl --context=current-prod-cluster get pvc --all-namespaces -o yaml > exports/pvcs.yaml
kubectl --context=current-prod-cluster get ingress --all-namespaces -o yaml > exports/ingress.yaml

Important

エクスポートされたシークレット マニフェストを機密データとして扱います。 セキュリティで保護されたシステムにのみ格納します。

サブスクリプション、クォータ、ネットワークの前提条件を検証する

az account show --query "{name:name, id:id, tenantId:tenantId}" -o table
az configure --defaults location=eastus resource_group=rg-aks-migration
az vm list-usage --location eastus -o table
az network public-ip list --resource-group rg-aks-migration -o table

ID と RBAC の要件を検証する

az aks show --resource-group rg-aks-migration --name existing-aks --query aadProfile
az role assignment list --resource-group rg-aks-migration -o jsonc
az identity list --resource-group rg-aks-migration -o table

続行する前に、次の項目を確認します。

• クラスター管理者グループとEntra ID統合モデル。
• マネージド ID スコープとロールの割り当て。
• ターゲット環境で有効になっているログ、メトリック、およびアラート。

戦略のチュートリアル

次のセクションでは、1 つの完全な Blue-Green 例と、ワークロードに適応できる 2 つの短いパターン (カナリアとローリング DNS) を提供します。

Blue-Green クラスター移行

このシナリオでは、運用環境のトラフィックは現在、 app.example.comのレガシ環境から提供されます。 新しい AKS クラスター (aks-green) を作成し、ワークロードをデプロイし、古いエンドポイントと緑のエンドポイントの両方をAzure Traffic Managerに登録し、トラフィックを段階的にシフトします。

基本的な移行ガイダンスについては、Azure Kubernetes Service (AKS)の移行の概要に関するページを参照してください。

1. 緑色の AKS クラスターを作成する

RG=rg-aks-migration
LOCATION=eastus
CLUSTER=aks-green
NODE_COUNT=3

az group create --name $RG --location $LOCATION

az aks create \
  --resource-group $RG \
  --name $CLUSTER \
  --location $LOCATION \
  --node-count $NODE_COUNT \
  --enable-managed-identity \
  --network-plugin azure \
  --load-balancer-sku standard \
  --generate-ssh-keys \
  --enable-addons monitoring \
  --attach-acr <yourACRName> \
  --yes

クラスターの資格情報を取得します。

az aks get-credentials --resource-group $RG --name $CLUSTER --overwrite-existing
kubectl config use-context $CLUSTER

2. ヘルスと中断制御を適用してワークロードをデプロイする

manifests/app-deployment.yamlを作成します。

apiVersion: apps/v1
kind: Deployment
metadata:
  name: myapp
  labels:
    app: myapp
spec:
  replicas: 3
  selector:
    matchLabels:
      app: myapp
  template:
    metadata:
      labels:
        app: myapp
        version: green
    spec:
      terminationGracePeriodSeconds: 60
      containers:
      - name: myapp
        image: myregistry.azurecr.io/myapp:green
        resources:
          requests:
            cpu: 250m
            memory: 256Mi
        ports:
        - containerPort: 8080
        readinessProbe:
          httpGet:
            path: /healthz
            port: 8080
          initialDelaySeconds: 5
          periodSeconds: 5
          failureThreshold: 3
        livenessProbe:
          httpGet:
            path: /live
            port: 8080
          initialDelaySeconds: 15
          periodSeconds: 10
          failureThreshold: 3
        lifecycle:
          preStop:
            exec:
              command: ["/bin/sh", "-c", "sleep 30"]
---
apiVersion: v1
kind: Service
metadata:
  name: myapp-lb
  labels:
    app: myapp
spec:
  type: LoadBalancer
  selector:
    app: myapp
  ports:
  - port: 80
    targetPort: 8080
  externalTrafficPolicy: Local

リソース要求は例です。 監視されたワークロードの使用状況とロード テストの結果からの CPU 要求とメモリ要求のサイズを設定し、ターゲット クラスターが運用スケジュールと容量の動作を表すようします。

externalTrafficPolicy: Local はソース IP を保持しますが、ノードごとに使用可能なバックエンド エンドポイントを減らすことができます。 スティッキー セッション アプリケーションの場合は、移行前にセッション状態 (たとえば、Azure Cache for Redis) を外部化して、トラフィックシフト中のアフィニティ関連の停止を回避します。

manifests/pdb.yamlを作成します。

apiVersion: policy/v1
kind: PodDisruptionBudget
metadata:
  name: myapp-pdb
spec:
  minAvailable: 2
  selector:
    matchLabels:
      app: myapp

リソースを適用し、ロールアウトを確認します。

kubectl apply -f manifests/app-deployment.yaml
kubectl apply -f manifests/pdb.yaml
kubectl rollout status deployment/myapp
kubectl get svc myapp-lb -o wide

3.緑色のエンドポイントを取得する

kubectl get svc myapp-lb -o jsonpath='{.status.loadBalancer.ingress[0].ip}'

次の手順で返された IP を使用します。

4. Azure Traffic Manager プロファイルとエンドポイントを作成する

TM_PROFILE=myapp-tm

az network traffic-manager profile create \
  --name $TM_PROFILE \
  --resource-group $RG \
  --routing-method Weighted \
  --unique-dns-name myapp-tm-$RANDOM \
  --ttl 30 \
  --protocol http \
  --path /healthz \
  --interval 30 \
  --timeout 10

古いエンドポイントを追加します。

az network traffic-manager endpoint create \
  --resource-group $RG \
  --profile-name $TM_PROFILE \
  --type externalEndpoints \
  --name old-endpoint \
  --target old.example.com \
  --endpoint-status Enabled \
  --weight 100

緑色のエンドポイントを追加します。

az network traffic-manager endpoint create \
  --resource-group $RG \
  --profile-name $TM_PROFILE \
  --type externalEndpoints \
  --name green-endpoint \
  --target <green-endpoint-ip> \
  --endpoint-status Disabled \
  --weight 0

コマンドの詳細については、 az network traffic-manager profile と az network traffic-manager endpoint を参照してください。

5. グリーンへのトラフィックの増加

低い重みから始めて、正常性と待機時間を観察します。

az network traffic-manager endpoint update \
  --resource-group $RG \
  --profile-name $TM_PROFILE \
  --name green-endpoint \
  --set properties.endpointStatus=Enabled \
  --weight 10

az network traffic-manager endpoint update \
  --resource-group $RG \
  --profile-name $TM_PROFILE \
  --name old-endpoint \
  --set properties.weight=90

50:50、次に old と green に対して 10:90 のような、段階的な相対ウェイトの切り替えを続けます。 Traffic Manager は、これらの相対的な重みに基づいて各 DNS クエリのエンドポイントを選択します。重みでは、正確な要求の割合は保証されません。 DNS 応答は、クライアントと再帰リゾルバーによってキャッシュされ、観察された分散が歪む可能性があります。 続行する前に、少なくともプロファイル TTL と代表的なアプリケーション トラフィックを測定するのに十分な時間を各ステージに保持します。 要求ごとの正確な分散が必要な場合は、L7 イングレスまたはサービス メッシュを使用します。

移行基準、監視ポイント、ロールバック プレイブック

各トラフィックが増加する前に、明示的なゲートを定義します。

ゲートの例

• HTTP 5xx が 3 分間連続して 1% を超えた場合はロールバックします。
• p95 待機時間がベースラインを 200 ミリ秒以上超えた場合に 5 分間ロールバックします。
• データベース レプリケーションのラグが RPO しきい値を超えた場合は、ロールアウトを一時停止します。
• ポッドの再起動率が通常のベースラインを上回る場合は、ロールアウトを一時停止します。

ロールフォワード シーケンス

1. トラフィックの負荷を少しずつ増やします。
2. SLO ゲートとビジネス スモーク テストを検証します。
3. すべてのゲートが保留期間を通過した場合にのみ続行します。

ロールバック シーケンス

1. 古いエンドポイントへのルーティングを開始します。 クライアントは、TTL の有効期限が切れるまで、キャッシュされた DNS 応答を引き続き使用できます。
2. 必要に応じて、展開を元に戻すか、スケールをゼロに設定します。
3. 古い環境の正常性とデータの整合性を再検証します。

# Restore old endpoint to 100
az network traffic-manager endpoint update \
  --resource-group $RG \
  --profile-name $TM_PROFILE \
  --name old-endpoint \
  --set properties.weight=100

# Set green endpoint to 0
az network traffic-manager endpoint update \
  --resource-group $RG \
  --profile-name $TM_PROFILE \
  --name green-endpoint \
  --set properties.weight=0

# Optional Kubernetes rollback options
kubectl rollout undo deployment/myapp
kubectl scale deployment myapp --replicas=0

6. 必要に応じてすばやくロールバックする

エラーが増加するか、SLO のしきい値を満たさない場合:

• 古いエンドポイントの重みを 100 に戻し、緑を 0に設定します。
• さらにロールアウトを一時停止し、必要に応じて緑色のポッドをスケールダウンします。

kubectl scale deployment myapp --replicas=0

カナリア移行（簡単な手順説明）

最小限の重複インフラストラクチャで増分リリース制御が必要な場合は、カナリアを使用します。

1. 安定版ワークロードとカナリアワークロードをデプロイします。
2. トラフィックのごく一部をカナリアにルーティングします。
3. 重要な信号を観察してから、増加またはロールバックします。

nginx の canary 用 Ingress アノテーションの例:

apiVersion: networking.k8s.io/v1
kind: Ingress
metadata:
  name: myapp-canary
  annotations:
    nginx.ingress.kubernetes.io/canary: "true"
    nginx.ingress.kubernetes.io/canary-weight: "10"
spec:
  rules:
  - host: app.example.com
    http:
      paths:
      - path: /
        pathType: Prefix
        backend:
          service:
            name: myapp
            port:
              number: 80

健康が安定している間、段階的に canary-weight を増やします。

ローリング DNS 移行 (短いチュートリアル)

DNS の切り替えがプライマリ トラフィック制御メカニズムである場合は、ローリング DNS を使用します。

キャッシュがタイムアウトできるように、カットオーバーの少なくとも 24 ~ 48 時間前に DNS TTL を低い値に設定します。移行が安定したら、より高い TTL を復元して、クエリのボリュームとリゾルバーのチャーンを減らします。

1. DNS TTL を下げる (たとえば、 30 秒)。
2. AKS エンドポイントをデプロイします。
3. DNS A/CNAME レコードを更新します。
4. 伝達と正常性を観察します。

例 A レコードの更新:

RG=rg-aks-migration

az network dns record-set a update \
  --resource-group $RG \
  --zone-name example.com \
  --name app \
  --set ttl=30

az network dns record-set a remove-record \
  --resource-group $RG \
  --zone-name example.com \
  --record-set-name app \
  --ipv4-address 13.78.1.2

az network dns record-set a add-record \
  --resource-group $RG \
  --zone-name example.com \
  --record-set-name app \
  --ipv4-address 52.160.1.100

永続ボリュームのデータ移行

ステートフル移行は、通常、最もリスクの高い領域です。 ストレージの種類と整合性の要件に一致するデータ パスを選択します。

データベース戦略

ダウンタイムと整合性の要件に合わせたデータベース移行パターンを選択します。

Pattern	利点	トレードオフ	一般的な使用方法
外部データベース (共有)	最も単純なアプリ移行パス、アプリシフト中に DB のカットオーバーなし	共通の影響範囲、潜在的な性能の連動性	古いアプリと新しいアプリで共有されている既存のマネージド PaaS DB
複製して昇格	制御されたカットオーバーとロールバック ポイント	レプリケーションと昇格の運用上のオーバーヘッド	厳格な RPO が求められる重要なステートフル ワークロード
二重書き込み（一時的）	ダウンタイムをほぼゼロに抑えたアプリケーションのカットオーバーを実現	複雑な照合と冪等性の要件	成熟したデータ パイプラインを備えたイベント ドリブン システム

CDC と移行オーケストレーションの場合は、Azure Database Migration Serviceと Debezium を評価します。 移行中に新旧のアプリ バージョンの互換性を維持するため、expand -> migrate -> contract のスキーマ変更を使用してください。

Azure Disk CSI スナップショット

スナップショット CRD とスナップショット コントローラーがインストールされている場合は、ブロック ボリュームに CSI スナップショットを使用します。

VolumeSnapshotClass例:

apiVersion: snapshot.storage.k8s.io/v1
kind: VolumeSnapshotClass
metadata:
  name: csi-azuredisk-snapclass
driver: disk.csi.azure.com
deletionPolicy: Delete

既存の PVC からのスナップショットの例:

apiVersion: snapshot.storage.k8s.io/v1
kind: VolumeSnapshot
metadata:
  name: mydata-snapshot
spec:
  volumeSnapshotClassName: csi-azuredisk-snapclass
  source:
    persistentVolumeClaimName: mydata-pvc

スナップショットからの PVC 復元の例:

apiVersion: v1
kind: PersistentVolumeClaim
metadata:
  name: mydata-pvc-restored
spec:
  storageClassName: managed-csi
  dataSource:
    name: mydata-snapshot
    kind: VolumeSnapshot
    apiGroup: snapshot.storage.k8s.io
  accessModes:
  - ReadWriteOnce
  resources:
    requests:
      storage: 100Gi

Important

スナップショットは通常、クラッシュ整合性があり、アプリケーション一貫性はありません。 データベースの場合は、レプリケーションまたはアプリケーション対応のバックアップと復元を使用します。

Azure Files

ファイル ベースのワークロードの場合:

• ソース ファイル共有のスナップショットまたはコピー プランを作成します。
• AzCopyなどのツールを使用してデータをコピーします。
• ターゲット共有の StorageClass と PVC の構成を更新します。

コピー パターンの例:

az storage share snapshot --account-name mystorage --name myshare
azcopy copy "https://<src>/myshare" "https://<dest>/myshare" --recursive

Velero のバックアップと復元

Azure プラグインで構成されている場合は、PV データを含む、クラスター リソースのバックアップと復元に Velero を使用します。

RG=rg-aks-migration

velero install \
  --provider azure \
  --bucket my-velero-backups \
  --secret-file ./credentials-velero \
  --backup-location-config resourceGroup=$RG,storageAccount=myvelerostorage,subscriptionId=<subscription-id>

velero backup create pre-migration-backup --include-namespaces my-namespace
velero restore create --from-backup pre-migration-backup

Velero のドキュメントと、AKS で Azure Disk CSI スナップショットを使用するを参照してください。

可観測性と自動ロールバック

トラフィックがシフトする前に、次の信号をインストルメント化します。

• HTTP 要求率と成功率。
• HTTP 5xx エラー率。
• p95 と p99 のリクエスト レイテンシ。
• ポッドの再起動率と準備エラー。
• ノードの負荷と保留中のポッド数。
• データベース レプリケーションのラグ。
• 非同期ワークロードのキューの深さ。

PromQL スタイルのアラート条件の例:

# Rollback gate: 5xx error rate over 1%
sum(rate(http_requests_total{status=~"5.."}[3m]))
/
sum(rate(http_requests_total[3m])) > 0.01

# Rollback gate: p95 latency exceeds 200ms over baseline target
histogram_quantile(0.95, sum(rate(http_request_duration_seconds_bucket[5m])) by (le)) > 0.2

ロールアウトコントローラー (手動ランブック、Argo Rollouts、または Flagger) にアラートを紐付け、ゲートでの失敗時に自動的に一時停止またはロールバックが行われるようにします。

テストと検証のレシピ

シャドウ トラフィック

エンド ユーザーに緑色の応答を返さずに、運用トラフィックのスライスを緑色にミラーリングします。 これにより、ユーザー リスクが低い現実的な負荷での動作が検証されます。

スモークテスト

重みが増えるたびにビジネス クリティカルなチェックを実行します。次に例を示します。

• サインインの流れ
• 支払いまたはチェックアウトのフロー
• API パスの読み取りと書き込み
• バック グラウンドジョブの完了

負荷試験

k6、hey、Azure Load Testingなどのツールを使用して、最終的なカットオーバーの前に容量と自動スケールの動作を検証します。

機能フラグ

機能フラグを使用して、リリースからデプロイを切り離します。 機能フラグは、再デプロイせずに危険なコード パスを無効にする必要がある場合に、2 つ目の安全レイヤーを提供できます。

運用移行チェックリスト

• [ ] 準備状態とライブネス プローブが真のサービス準備を反映していることの確認。
• [ ] 読み込み中の preStop と terminationGracePeriodSeconds の値を検証します。
• [ ] アップグレード イベントと削除イベントの PodDisruptionBudget 値を確認します。
• [ ] 予想される移行トラフィックの急増に対する自動スケール設定を確認します。
• [ ] トラフィックのエントリ ポイントを通じて、エンド ツー エンドの正常性チェックを検証します。
• [ ] カットオーバーの前にログ、メトリック、アラート、および合成チェックを検証します。
• [ ] ロールバックの所有者、ロールバックのトリガー条件、ロールバックのランブックを確認します。
• [ ] 新しいエンドポイントの NSG、ファイアウォール、正常性プローブの規則を検証します。
• [ ] TLS 終了動作と CORS 設定が古い環境と一致するように検証します。
• [ ] 一時的な青緑色の重複期間のコスト計画を検証します。

ロールバック チェックリスト

1. トラフィックを古いエンドポイントにシフトします (Traffic Manager の重み付けまたは DNS ロールバック)。
2. 緑色のデプロイを一時停止またはスケールダウンします。
3. 必要に応じて、以前の構成またはシークレットを復元します。
4. 通常の操作を再開する前に、古い環境の正常性を再検証します。

次のステップ

• Azure Kubernetes Service (AKS)の移行の概要を確認します。
• AKS の運用アップグレード戦略を確認します。
• AKS のブルーグリーン ノード プールのアップグレードを確認する。
• Azure Traffic Managerドキュメントを確認します。