ゼロ ダウンタイム デプロイのために CNAME スワッピングで Elastic Beanstalk を使用する場合、DNS キャッシング (クライアントが TTL を尊重しない) により、一部のクライアントが古い環境にトラフィックを送信し続けます (最大数日間)。
Elastic Beanstalk と Route53 エイリアスを使用してゼロ ダウンタイム デプロイを行う場合、DNS キャッシングは引き続き問題になりますか?
ゼロ ダウンタイム デプロイのために CNAME スワッピングで Elastic Beanstalk を使用する場合、DNS キャッシング (クライアントが TTL を尊重しない) により、一部のクライアントが古い環境にトラフィックを送信し続けます (最大数日間)。
Elastic Beanstalk と Route53 エイリアスを使用してゼロ ダウンタイム デプロイを行う場合、DNS キャッシングは引き続き問題になりますか?
http://docs.aws.amazon.com/elasticbeanstalk/latest/dg/using-features.CNAMESwap.html それは言う
新しいバージョンを別の環境にデプロイしてから、2 つの環境の CNAME を交換して、トラフィックを新しいバージョンに即座にリダイレクトします。
と
ただし、DNS の変更が反映され、古い DNS レコードの有効期限が切れるまで、古い環境を終了しないでください。DNS サーバーは、DNS レコードに設定した存続時間 (TTL) に基づいて、キャッシュから古いレコードを必ずしもクリアするとは限りません。
衝突ではないですか?DNSキャッシングはまだ問題だと思います。
古いバージョンのクライアントが存在する場合に、DB を新しいバージョンに移行するにはどうすればよいですか。2つのバージョンの両方で機能する場合にのみ、dbを移行できると思います。
ここで良い記事を見つけました。 http://fbrnc.net/blog/2016/05/green-blue-deployments-with-aws-lambda-and-cloudformation ですが、Elastic Beanstalk ではなく Cloud Formation を使用しています。
これはまだテストしていませんが、route53 で行うのではなく、「環境 URL のスワップ」アクションを実装したのはこのためだと思いました。
残念ながらそうです。現在推奨される方法は、ローリング アップデートを使用することです。