「ALBの加重ルーティング」と「API GatewayのCanary機能」を使ってクロスアカウントの段階的な移行を試してみた

こんにちは、コンサルティング部のみゃんです！

突然ですが、皆さんはAWS環境の移行時に、できる限りダウンタイム（システムが停止し、ユーザーが利用できない時間）を短くしたいと思ったことはありませんか？

しかも、移行先が同じアカウント内ではなく、別のAWSアカウントだったらどうでしょうか。「リクエストを少しずつ新環境に流したいけれど、アカウントをまたいだ瞬間に一気に難易度が上がる気がする……」と感じる方も多いと思います。実際、私も検証する中で何度もつまずきました。

そこで今回は、フロントエンドではALBの加重ターゲットグループ、バックエンドではAPI GatewayのCanaryリリースを使用し、旧環境（アカウントA）から新環境（アカウントB）へのリクエストを0%→50%→100%と段階的に切り替える構成を、実際に2つの検証用AWSアカウントで構築して確認しました。

この記事は、AWSアカウント間の移行や大規模リリースにおいてダウンタイムを最小限に抑えたい方や、クロスアカウントの段階的な移行で「どのAWS機能を、どのように組み合わせればよいのか」を知りたい方に向けて書いています。

なお、データベースの移行（DMSなど）やアプリケーション自体の作り替えは、今回のスコープ外としています。

1. 背景・やること

1.1 移行ケース

今回は、以下のような移行ケースを想定します。

ゴールは、フロントエンドとバックエンドの両方で、新環境へのリクエストを0%→50%→100%と段階的に切り替えることです。

今回は、段階的な移行方式とクロスアカウント設計という2つのポイントを中心に実際に検証してみました。

1.2 構成

今回は以下のような構成で、段階的な移行を検証しました。

フロントエンド部分

バックエンド部分

ポイントは、フロントエンドとバックエンドで、クロスアカウント接続の方式を使い分けていることです。

VPC PeeringはCIDRが重複していると接続できないため、両アカウントのVPC CIDRは重複しないようにしておく必要があります（今回はA＝10.0.0.0/16、B＝10.1.0.0/16）。CIDRまわりの制約の詳細はVPC Peeringの公式ドキュメントをご確認ください。

一方、PrivateLinkではCIDRの重複が許容されます。「同じクロスアカウント接続でも制約が異なる」という点を覚えておくと、設計の選択肢が増えると思います。

1.3 なぜこの構成に落ち着いたのかの余談

今回この検証をやってみようと思い立った時に、できる限りシンプルな構成にしたいと思い、当初はバックエンドはLambdaを使う想定でした。
しかし色々と調査した結果、Lambdaでは私が実現したいことが難しいという結論にいたりました。(大幅に手戻りしたので悲しい。)
備忘として調査結果を残しておきます。

• ステージ変数ではクロスアカウントのLambda関数を指定できない：当初は、Lambda統合とステージ変数を使用して新旧環境を切り替える案を検討していました。しかし、公式ドキュメントに「Stage variables don't support cross-account Lambda functions」と明記されているため、この案は成立しません。そこで、バックエンドをFargate＋ロードバランサー構成に変更しました。
• VPC Link V2（ALB直接統合）は今回の構成ではCanaryでの切り替えに使用できない：次にLambdaではなくFargateを使うことにしたのですが、その際にシンプルにするために出来ればNLBを使わない構成にしたいと考えました。REST APIではVPC Link V2を使用してALBと直接統合できます。ただし、公式ドキュメントでステージ変数の利用が示されているのはVPC Link IDを指定するconnectionIdであり、接続先ALBを指定するIntegrationTargetは対象として記載されていません。実機検証でもIntegrationTargetをステージ変数で切り替えることはできなかったため、今回はVPC Link V1のconnectionIdをCanaryで切り替える構成を採用しました。
  V2統合の仕様は公式ドキュメントをご確認ください。
• VPC Link V1＋connectionIdのステージ変数による切り替えは、公式ドキュメントで例示されているパターン：V1のプライベート統合では、ルーティング先を決めるのは統合のconnectionId、つまり使用するVPC Linkです。これをステージ変数として差し替える方法が、公式ドキュメントに実例付きで掲載されています。CanaryのstageVariableOverridesでこの変数を上書きすれば、Canaryに振り分けられたリクエストだけを、新環境へ接続するVPC Linkに流せます。

つまり、最終的な構成では「Canaryで切り替えるのはVPC LinkのID。クロスアカウントの物理的な接続は、VPC Linkより先のネットワーク層（PrivateLink）に任せる」という役割分担にしました。(シンプルさよりも、Canaryでの切り替え機能を優先した設計にしました。)

注記：VPC Link V1はレガシーリソースです
公式ドキュメントには「VPC リンク V1 はレガシーリソースです。REST API には VPC リンク V2 を使用することをお勧めします」と記載されています。本記事では、Canaryで統合先を切り替えるためにconnectionId（VPC LinkのID）をステージ変数で差し替える必要があり、V2ではこれに相当する切り替えができなかったため、この推奨を理解したうえであえてV1を採用しています。Canaryでの切り替えを伴わない通常のプライベート統合では、推奨どおりVPC Link V2の使用をご検討ください。

https://docs.aws.amazon.com/ja_jp/apigateway/latest/developerguide/set-up-api-with-vpclink-cli.html

2. やってみた

2.1 検証環境

検証用のAWSアカウントを2つ（A＝旧環境、B＝新環境）用意し、リソースはCloudFormationで作成しました。スタックは、各アカウントに1つずつ作成しています。

新旧どちらの環境にアクセスしたかを一目で判別できるように、各環境のNginxが**レスポンスヘッダーX-Env: old|new**とJSON形式のレスポンス本文を返すようにしています。

curl -si "https://<API ID>.execute-api.ap-northeast-1.amazonaws.com/prod/" | grep -i '^x-env:'
# x-env: old

デプロイは、「B → A → Bを再度更新」の3ステップで行います。VPC Peering接続のIDは、Aのスタックを作成した時点で初めて判明します。そのため、B側の戻りルートのみ、2回目の更新で作成する流れにしています。

クロスアカウントのVPC Peeringでは、承認側（アカウントB）にIAMロールを作成しておき、要求側（アカウントA）のCloudFormationがそのロールを引き受けて自動承認する、公式ドキュメントで紹介されているパターンを使用しました。これにより、コンソール上で手動承認する作業が不要になります。

今回使うCloudFormationのテンプレートはこちらにありますので、皆さんも是非一緒にやってみましょう！
https://github.com/MiyamaYuki-CM/myan-aws/tree/myan-aws-canary-crossaccount

まずはアカウントBにスタックを作成します。

スタック作成時の注意点は以下の2点です。

1. アカウントAのアカウントIDを入力
2. 空欄でOK

作成完了画面

スタックの作成が完了したら、次はアカウントAにスタックを作成します。

スタック作成時の注意点は以下の6点です。

1. アカウントBのアカウントIDを入力
2. AllowedCidrに自身のPCのグローバルIPアドレスを入力
3. アカウントBで作成したVPCエンドポイントサービス名を入力
4. アカウントBで作成したEC2のプライベートIPアドレスを入力
5. アカウントBで作成したPeering用のIAMロールARNを入力
6. アカウントBで作成したVPC IDを入力

アカウントBで作成したスタックの出力タブからパラメータに入力する情報を確認可能です。

「3. アカウントBで作成したVPCエンドポイントサービス名」確認箇所

「4. アカウントBで作成したEC2のプライベートIPアドレス」確認箇所

「5. アカウントBで作成したPeering用のIAMロールARN」確認箇所

「6. アカウントBで作成したVPC ID」確認箇所

作成完了画面

アカウントAでVPC Peeringが作成されているので、アカウントBのスタックを更新してVPC Peering用のルートを作成します。

アカウントBのスタックに対して、変更セットを作成します。
その際、新規作成時には空欄にしていたパラメータPeeringConnectionIdにアカウントAで作成したVPC PeeringのIDを入力します。

アカウントAで作成したVPC Peering IDの確認箇所

変更セット作成完了画面
この画面でオレンジ色の「変更セットを実行」を押下します。

NewBackendTargetGroup（NLB-newのIPターゲットグループ）は空で作成されます。
インターフェースVPCエンドポイントのENIプライベートIPを登録して、NLB-new(A) → PrivateLink の経路で疎通できるようにします。

ターゲットにアカウントAに作成されたインターフェースVPCエンドポイントのIPアドレスを登録
ポートは80

IPアドレス確認箇所

しばらく待って登録したターゲットのヘルスチェックがHealthyになったことを確認
)

ここまでで下準備は完了です。
いよいよ段階的な切り替えを試していきます。

2.2 フロントエンド：ALBの加重ターゲットグループを設定する

まずはフロントエンドのALBから！

リスナールールのforwardアクションで、新旧2つのターゲットグループに0～999の重みを指定します（参考：Action types for listener rules）。

注意点としては、新環境向けにアカウントAに作成したターゲットグループです。別アカウントのEC2はinstanceターゲットとして登録できないため、**ipターゲット＋AvailabilityZone: all**を使用し、アカウントBのEC2のプライベートIPを登録します。VPC外のIPをターゲットに登録する際の条件は公式ドキュメントをご確認ください。

# 新環境側のターゲットグループ（アカウントBのEC2をVPC Peering経由で指定）
FrontNewTargetGroup:
  Type: AWS::ElasticLoadBalancingV2::TargetGroup
  Properties:
    Protocol: HTTP
    Port: 80
    TargetType: ip            # instanceは同一VPC内に限定されるため、ipを使用する
    Targets:
      - Id: 10.1.0.23         # アカウントBのEC2のプライベートIP
        Port: 80
        AvailabilityZone: all # ロードバランサーのVPC外にあるIPにはallの指定が必須

重みはコンソールから変更し、X-Envヘッダーを集計して振り分け結果を確認します。
単発でcurlしてみると、X-Envヘッダーで旧環境ならOld、新環境ならNewが返ってきます。

まずはアカウントAに作成したフロントエンド用のALBのリスナールールを編集します。

2つのルールを押下
)

加重ルーティングのルールを選択し、「アクション」から「ルールの編集」を押下
因みにここから現在は旧環境向けのターゲットグループに100％振り分けられる設定になっていることが分かります。

「アクション」から試しに旧環境と新環境それぞれ50%ずつリクエストが振り分けられるように設定してみます。

加重ルーティングの設定完了

ではターミナルを開いて、以下を実行してみます。

for i in $(seq 1 100); do curl -si "http://<フロントALBのDNS>/" | grep -i '^x-env:'; done | \
  awk '{print tolower($2)}' | sort | uniq -c

何回か実行してみましたが、大体50％ずつ振り分けられていました。

% for i in $(seq 1 100); do curl -si "http://canary-verify-front-alb-706638264.ap-northeast-1.elb.amazonaws.com/" | grep -i '^x-env:'; done | \
  awk '{print tolower($2)}' | sort | uniq -c
  57 new
  43 old
%

では新環境側に100％振り分けられるように設定してみます。

再度ターミナルで、以下を実行してみます。

for i in $(seq 1 100); do curl -si "http://<フロントALBのDNS>/" | grep -i '^x-env:'; done | \
  awk '{print tolower($2)}' | sort | uniq -c

何回実行しても、新環境のみに振り分けされていることが確認できました！

% for i in $(seq 1 100); do curl -si "http://canary-verify-front-alb-706638264.ap-northeast-1.elb.amazonaws.com/" | grep -i '^x-env:'; done | \
  awk '{print tolower($2)}' | sort | uniq -c
  100 new
%

各ALBやEC2のメトリクスを見ると、加重ルーティングの設定に従って、リクエストが新旧環境に振り分けられていることを確認できるので、興味があれば見てみてください。

以下参考、アカウントBのEC2(新環境)のネットワーク関連のメトリクスが加重ルーティング設定後、倍増している

2.3 バックエンド：API GatewayのCanaryリリースでVPC Linkを切り替える

次にバックエンドのAPI GatewayのCanary機能を使った段階的移行を試していきます。

統合にはHTTP_PROXY＋VPC_LINKを使用し、connectionIdとuri（Hostヘッダー用）をステージ変数として設定しています。（設定方法の詳細は公式ドキュメントをご確認ください）。
ここでは、通常トラフィックとCanaryトラフィックで異なるVPC Linkを使用するため、統合のconnectionIdにステージ変数を指定します。通常ステージの変数には旧環境のVPC Link IDを設定し、CanaryのstageVariableOverridesには新環境のVPC Link IDを設定することで、同じ統合定義のまま接続先を切り替えられます。

なお、stageVariableOverridesは既存のステージ変数の上書きだけでなく、Canary専用の新しい変数も追加できます。また、Canary側に異なる統合設定を含むデプロイメントを割り当て、connectionIdを直接変更する構成も可能です。Canaryを使用せず接続先が固定されている場合は、VPC Link IDをconnectionIdに直接指定すればよく、ステージ変数は必須ではありません。

RootGetMethod:
  Type: AWS::ApiGateway::Method
  Properties:
    # ...省略...
    Integration:
      Type: HTTP_PROXY
      IntegrationHttpMethod: GET
      ConnectionType: VPC_LINK
      ConnectionId: '${stageVariables.vpcLinkId}'   # ← Canaryでここを切り替える
      Uri: 'http://${stageVariables.backendHost}'   # ルーティングには使用されず、Hostヘッダーに使用される

ProdStage:
  Type: AWS::ApiGateway::Stage
  Properties:
    StageName: prod
    CacheClusterEnabled: false
    Variables:
      vpcLinkId: <VPC Link①のID>      # prodは旧環境へ接続
      backendHost: <NLB-oldのDNS名>

Canaryはコンソールから作成します（作成手順はCreate a canary release deployment参照）。prodステージのCanaryタブで、リクエストの分配率（%）を指定し、次の2つのステージ変数をオーバーライドします。

• vpcLinkId＝VPC Link②のID（新環境へ接続）
• backendHost＝NLB-newのDNS名

これにより、Canaryに振り分けられたリクエストだけが、VPC Link② → NLB-new → PrivateLink → アカウントBのFargateという経路で流れます。分配率も同じ画面から変更できます。

アカウントAに作成されたAPI Gatewayのステージ「Prod」から「Canary」タブの「Canaryを作成」を押下

まずCanaryの設定で、Canaryと現在のステージを50％ずつに設定
また、Canaryステージ変数のCanaryオーバーライドを入力して「Canaryを作成」を押下
backendHost → CanaryBackendHostの値
vpcLinkId → CanaryVpcLinkIdの値

スタックの出力からそれぞれの値を確認可能

設定完了画面

なお、新環境へ接続するNLBのターゲットには、インターフェースVPCエンドポイントのENIに割り当てられたプライベートIPを登録する必要があります（この構成はAWS公式ブログのクロスアカウントパターンで紹介されています）。インターフェースVPCエンドポイントのENIプライベートIPを、Lambda関数を使用した自動化も可能ですが、今回は検証の簡潔性を優先して、デプロイ後にコンソール上で手動登録しました。

それではターミナルで、以下を実行してみます。

for i in $(seq 1 100); do curl -si "<API GatewayのURL>/" | grep -i '^x-env:'; done | \
  awk '{print tolower($2)}' | sort | uniq -c

何回か実行して、ばらつきはありますが、ALB同様おおよそ50%ずつ新旧環境に振り分けられていることが確認できました！

% for i in $(seq 1 100); do curl -si "https://yjo79w9s8l.execute-api.ap-northeast-1.amazonaws.com/prod/" | grep -i '^x-env:'; done | \
  awk '{print tolower($2)}' | sort | uniq -c
  44 new
  56 old
%

では新環境側に100％振り分けられるように設定してみます。

再度、ターミナルで以下を実行してみます。

for i in $(seq 1 100); do curl -si "<API GatewayのURL>/" | grep -i '^x-env:'; done | \
  awk '{print tolower($2)}' | sort | uniq -c

結果、こちらもALB同様、設定後すぐに新環境へ100%振り分けられることが確認できました！

% for i in $(seq 1 100); do curl -si "https://yjo79w9s8l.execute-api.ap-northeast-1.amazonaws.com/prod/" | grep -i '^x-env:'; done | \
  awk '{print tolower($2)}' | sort | uniq -c
  100 new
%

ALB同様にこちらもECSのメトリクスやログを見ると、新環境側に振り分けされていることが確認できます。

参考に、アカウントB（新環境）のECSのCPU使用率がテスト実行時間に増加していることを確認

3. ハマったところ

今回の検証でつまずいたポイントを紹介します。

3.1 Canary有効中の「APIをデプロイ」はCanary側に反映される

検証中、コンソールの「APIをデプロイ」からprodを選んでデプロイしたにもかかわらず、変更が一向に反映されないことがありました。

原因は、ステージにCanaryが残っていたことです。Canaryが有効な状態でデプロイすると、デプロイはステージ本体ではなく、Canary側のdeploymentIdに関連付けられます。これは仕様です（詳細は公式ドキュメントをご確認ください）。ステージ本体を更新したい場合は、Canaryを昇格または削除してからデプロイする必要があります。

また、ステージがどのデプロイを配信しているかは、「ステージ → デプロイ履歴」から確認・変更できます。「デプロイしたのに反映されない」と感じたら、まずここを確認することをおすすめします。

3.2 リソースポリシーの変更は再デプロイするまで反映されない

APIのリソースポリシー（今回はIPアドレス制限に使用）を更新しても、APIを再デプロイしてステージに反映するまでは、古いポリシーが適用されたままです（詳細は公式ドキュメントをご確認ください）。

ポリシーを修正したにもかかわらず403エラーが続く場合は、デプロイの作成だけでなく、ステージへの関連付けまで確認してください。

4. 注意点

• ステージ変数ではクロスアカウントのLambda関数を指定できない。Lambdaベースの移行を検討している方は注意が必要です（詳細は公式ドキュメントをご確認ください）。
• NLBのALB-typeターゲットグループは、同一アカウントかつ同一VPC内に限定される。NLBから別アカウントのALBへ直接接続することはできないため、PrivateLinkを使用してクロスアカウント接続を実現します（詳細は公式ドキュメントをご確認ください）。
• VPC PeeringではCIDRの重複が許容されない。移行元と移行先のVPC CIDRが重複している場合はVPC Peeringを使用できないため、PrivateLinkを中心とした設計に変更するか、CIDRを再設計する必要があります（詳細は公式ドキュメントをご確認ください）。
• ALBの加重ルーティングでは自動的にフェイルオーバーしない。新環境側のターゲットがすべて異常になっても、設定された重みに従ってリクエストを送信し続けようとします。そのため、監視と、手動で重みを戻す運用を併せて用意しておく必要があります（詳細は公式ドキュメントをご確認ください）。
• 振り分けはランダムに行われる。API Gateway Canaryは、リクエストを設定比率に従ってランダムに分配します。ALBの加重ターゲットグループは、設定した重みに基づいてリクエストを分配します。ALBでターゲットグループスティッキネスを有効にしていない場合、同じユーザーが毎回同じ環境へ送られる保証はありません。したがって、フロントエンドとバックエンドをそれぞれ50%に設定すると、「新フロントエンド×旧バックエンド」のような組み合わせが発生し得ます。（Canaryのランダム分配の詳細は公式ドキュメントをご確認ください）。

5. まとめ

クロスアカウントのAWS環境移行でも、ALBの加重ターゲットグループとAPI GatewayのCanaryリリースを組み合わせることで、リクエストを0%→50%→100%と段階的に切り替えられることを確認できました。
この方式により、一括切り替えと比べて新環境への影響を段階的に確認しやすくなり、問題発生時にはトラフィック比率を旧環境側へ戻せます。
ただし、実際のダウンタイムや切り戻し可否は、セッション、データベース、非同期処理などを含めたシステム全体の設計に依存します。

ポイントを整理すると、次のとおりです。

• 切り替え機能そのものよりも、アカウントをまたぐ接続設計（フロントエンド＝VPC Peering＋IPターゲット、バックエンド＝PrivateLink＋VPC Link V1）が重要になる
• API GatewayのCanaryで切り替える対象は、VPC LinkのID（connectionIdに指定するステージ変数）。V2のALB直接統合は、今回のように新旧の異なるALBをCanaryのステージ変数で切り替える用途には使用できなかった
• ハマりどころの多くは、「個別には仕様として明記されているものの、複数の機能を組み合わせて初めて影響が明確になる制約」。事前に公式ドキュメントを確認しつつ、実機でも検証するのが、結果として最も早い

同じように、アカウントをまたぐ段階的な環境移行を検討している方の参考になれば幸いです。

6. 参考リンク

• Set up an API Gateway canary release deployment
• Set up an API Gateway API with private integrations using the AWS CLI（connectionIdをステージ変数として設定し、切り替える実例）
• Set up a private integration（VPC Link V2／IntegrationTarget）
• API Gateway stage variables reference（クロスアカウントLambda非対応の記載）
• Action types for listener rules（ALB加重ターゲットグループ）
• Register targets with your Application Load Balancer target group（VPC外のIPターゲットとAvailabilityZone: all）
• Use an Application Load Balancer as a target of a Network Load Balancer（同一アカウント・同一VPCの制約）
• Architecture patterns for consuming private APIs cross-account（AWS Blog）
• AWS::EC2::VPCPeeringConnection（クロスアカウント自動承認のPeerRoleArn）
• ALBの加重ターゲットグループで100%と0%に設定した場合、100%側に障害が起きるとどうなりますか？

7. おまけ

最後に、ALBとAPI Gatewayそれぞれ、新旧環境に50%ずつ振り分け設定した時のテスト結果の集計をおまけとしておいておきます。
実行コマンドは上記に掲載済みです。今回はそのコマンドをそれぞれ10回ずつ実行した結果の集計です。

7.1 フロントエンド：ALB加重ターゲットグループ（重み 50:50、各回100リクエスト）

7.2 バックエンド：API Gateway Canaryリリース（分配率 50%、各回100リクエスト）

7.3 所見

• どちらも合計ではほぼ50:50に収束（ALB: 49.0/51.0、APIGW: 50.5/49.5）。設定した比率どおりに振り分けられていることを確認しました。
• 今回の結果では、ALBは45～55%、API Gatewayは42～60%となり、100リクエスト程度では数ポイントから最大10ポイント程度偏る場合がありました。