こんにちは。ATOM 事業部エンジニアの田村です。
AWS CodeDeploy を利用しているのですが、デプロイに時間がかかるのが問題になっていました。 あまり時間がかかりすぎるせいかデプロイが失敗する事もあるので、対処法を考えます。
特に BlockTraffic が2〜5分かかっているようです。
検索してみたら既に FAQ だったようで、 わかりやすい記事がいくつも当たりますね。
codedeploy blocktraffic - Google 検索
しかし実際やってみたら AWS の画面が変わっている部分もあったので、いまさら感はありますが改めてまた記事にしてみました。
現状
BlockTraffic に5分以上かかっています。 ただ同時にデプロイしている別のインスタンスでは2分弱で終わる場合もあり、アクセス状況によって大きく変動するようです。
EC2 の [ロードバランシング] → [ターゲットグループ] で対象ターゲットグループの [HealthCheck] の設定を確認します。 Timeout, Interval はデフォルト値の状態です。
対処
AWS のフォーラムにあった記事の通り、Timeout, Interval を最小値に変更します。 BlockTraffic/AllowTraffic durations | AWS re:Post
最小値にすることで Healthy / Unhealthy の判定が早くなるので、 ちょっとした負荷変動に影響されやすくなりそうです。
結果
BlockTraffic は12秒になりました。AllowTraffic も早くなっています。
別の記事では ALB の Connection draining の設定を300秒から変更する必要があるという記述もあったのですが、今回は変更しなくても効果がありました。 しかし状況によっては設定する必要があるのかもしれないので、今後様子を見ることにします。
[Attributes] の [Deregistration delay] がそれに当たります。
終わりに
ロードバランサーの設定変更だけで、大幅に速度改善することが確認できました。
設定変更したことによる弊害もないようで、デプロイが失敗せず安定するようになりました。 AWS が用意していたデフォルト値は、負荷変動による影響をある程度許容する設定になっていたようですが、今回設定を変更したことによりピーキーな挙動になるので、それには注意しておく必要がありそうです。例えば一時的な高負荷が続く場合に、今までは耐えられていたのが、短時間で一気に Unhealthy 判定されていく・・・などの可能性が考えられます。 BlockTraffic にかかる時間をそこまで短くする必要がないのであれば、設定値を見直してもう少し反応を緩やかにしてもいいかもしれません。このへんは実際のシステムに合わせて状況を見ながら調整していくと良さそうです。
