AWSのALBのルールの優先順位を使用してデプロイの切り替えを考えました。
全く同じIFの設定でTHENの設定が異なるルールが存在する場合、上にある方が優先順位が高く採用されますが、
この優先順位を変更した場合、もしも既存セッションが残っている場合は強制的に切断されてしまうのでしょか？
レジュメ
環境・前提条件
ALBのルールの順位変更を検証しました。
全く同じIFに対し、異なるTHENを用意します。
- 転送先にあるサーバーは、アクセスすると300秒間表示を待ち、300秒後にレスポンスを返すsleepページとしました。
- もう一つは、固定レスポンスとして即座に503のhttpレスポンスを返すようにしました。
この環境で、前者の転送先にあるサーバーへアクセスしている最中に、ALBのルールの優先順位を変えた場合、既存セッションがどうなるか確認しました。
結論、既存セッションはセッションが続く限り生き残る。切断されない
既存セッション用にphpをインストールし、以下のようなプログラムのindex.phpを用意しました。
<?php
echo date('h:i:s') . "<br>\n";
sleep(300);
echo date('h:i:s') . "\n";
?>
結果、このセッションは5分間生き残りレスポンス結果がクライアントに帰りました。
時系列で説明しますと
- クライアントからALBへアクセス（THENの転送先はサーバー）
- ALBのルールの順位変更をし、503の固定レスポンスを返すの優先順位を高く変更する
- 別のブラウザからALBへアクセスし503の固定レスポンスが帰るのを確認する
- 5分後、一番初めのALBアクセスの結果が帰る（セッションが切断されず）
なので、ALBのルールの順位変更をしても、その前の既存セッションは切断されずに生き残ります！
既存セッションがまだ結果応答レスポンスが無い間にも新規のアクセスは別のレスポンスを返す
上記、時系列3番の画面です。
まだこの間、時系列1番の画面は応答待ちのままでした。
これが既存セッションが強制切断されない検証になっていると思います。
失敗談。ALBのアイドルタイムアウト値が短いと切断される
検証していた失敗談としまして、index.phpは300秒後に応答を返すのですが、それより先にALBのアイドルタイムアウト（デフォルト60秒）を迎え、切断されてしまい検証失敗してしまった事がありました。
このアイドルタイムアウト値は、phpのwait秒数より長くないと当然切断されてしまうので気を付ける必要があります。