前提
- app1とapp2が存在している
- app2はサービス検出を使っている
- app1からapp2に対してリクエストを送信することがある
注意したいこと
app2でCodeDeployのブルーグリーンデプロイが行われたとします。
それぞれのフェーズの最中にapp1からapp2にリクエストが送信された場合どんな挙動になるか確認してみました。
- 新コンテナデプロイ中
- 旧コンテナのみ繋がる
- 新コンテナのデプロイ完了(トラフィック切り替え待ち)
- 旧コンテナ、新コンテナのどちらかにランダムで繋がる
- 新コンテナへトラフィック切り替え完了(旧コンテナ停止待ち)
- 旧コンテナ、新コンテナのどちらかにランダムで繋がる
- 旧コンテナ停止完了
- 新コンテナのみ繋がる
なぜこのようになるかというと、クラスメソッドさんの記事が参考になりました。
サービス検出ではこのマルチバリューの回答という仕組みを使っているようです。
試しにapp1のコンテナからtracerouteを叩いてみると、以下のようにランダムで繋がっているように見えます。
example@ip-10-20-10-87:/app# traceroute app2.example_namespace.internal
traceroute to app2.example_namespace.internal (10.20.10.131), 30 hops max, 60 byte packets^C
example@ip-10-20-10-87:/app# traceroute app2.example_namespace.internal
traceroute to app2.example_namespace.internal (10.20.10.131), 30 hops max, 60 byte packets^C
example@ip-10-20-10-87:/app# traceroute app2.example_namespace.internal
traceroute to app2.example_namespace.internal (10.20.10.207), 30 hops max, 60 byte packets^C
example@ip-10-20-10-87:/app# traceroute app2.example_namespace.internal
traceroute to app2.example_namespace.internal (10.20.10.131), 30 hops max, 60 byte packets^C
example@ip-10-20-10-87:/app# traceroute app2.example_namespace.internal
traceroute to app2.example_namespace.internal (10.20.10.207), 30 hops max, 60 byte packets^C
これは公式ドキュメントだと複数値回答ルーティングと言われています。
つまり...何が言いたいか
- 新コンテナデプロイ中
- 旧コンテナのみ繋がる
- 新コンテナのデプロイ完了(トラフィック切り替え待ち)
- 旧コンテナ、新コンテナのどちらかにランダムで繋がる
- 新コンテナへトラフィック切り替え完了(旧コンテナ停止待ち)
- 旧コンテナ、新コンテナのどちらかにランダムで繋がる
- 旧コンテナ停止完了
- 新コンテナのみ繋がる
新コンテナのデプロイ完了(トラフィック切り替え待ち)、新コンテナへトラフィック切り替え完了(旧コンテナ停止待ち)のこの2つのフェーズのみ新旧両方のコンテナにリクエストが送信されることがあるため、これが許容できない場合は何かしら工夫が必要かと思います。
AppSpec の「hooks」セクションを使えば、デプロイフローの各フェーズでLambda関数を実行可能なので、各hooksでLambda関数を実行し、制御することもできそうです。
補足
サービス検出とは
私の過去記事から確認できます。
CodeDeployブルーグリーンデプロイとは
AWSのCodeDeployサービスで提供されているデプロイ手法です。
ブルーグリーンデプロイでは、2つの同一環境を使用します。
- ブルー環境: 現在稼働中の本番環境
- グリーン環境: 新バージョンをデプロイする新環境
主な流れ
- 既存の本番環境（ブルー）と同じ構成の新環境（グリーン）を作成
- 新環境に新バージョンのアプリケーションをデプロイ
- 新環境でテストを実施
- 問題なければ、トラフィックを一斉にブルーからグリーン環境に切り替え
- グリーン環境が新たな本番環境となり、旧環境は必要に応じて破棄または保持
Discussion