[TIL] 7. AWS ELB
wakakaL4LBとL7LBの違い
L4LBとL7LBの違いは、IPヘッダとTCPヘッダのみを確認するか、これらに加えてHTTPヘッダを確認するかである。
L4LBでは送信元IP、送信元ポート、送信先IP、送信元ポート、プロトコルという条件から振り分け先を決定する。このような単純な条件で振り分け先を決定するので高速に動作する。
L7LBではHTTPリクエストのメソッド、URL、ヘッダなどを検査し、ルーティングルールを適用する。
PUTやDELETEメソッドは拒否したり、/healthcheckパスの場合には固定レスポンスを返すなどL7レベルの情報を確認した上で通信を振り分けることが可能である。
wakakaALBの設定時に登場する4つのポート
- リスナーポート
- ヘルスチェックポート
- ターゲットグループ全体に設定するポート（デフォルトポート）
- ターゲット単位に設定するポート（本設定値により 3.で指定したポートを上書き可能）
3.と4.において異なるポート番号が設定された場合には、4.の方のターゲット単位で指定されたポート番号が採用される。つまり、3.において80番が設定され、4.においてターゲット単位で82番が設定されるとターゲットの82番に対してALBからトラフィックが転送される。
wakakaSG、リスナールール、WAFの評価順序
これは「ALBに付与されたSG→ALBリスナールール→ALBに紐づいたWAF」の順序で評価される
- ALBに到達したリクエストは最初にSGによって評価される
- SGを通過したリクエストはALBリスナールールによって評価される
- 対応するActionを実行する前にリクエストはWAFに転送される
- WAFを通過することができたリクエストはリスナールールで定義されたActionを実行する
wakakaEC2 Auto Scalingのヘルスチェック
Auto Scalingには以下のような2種類のヘルスチェック項目が存在する。
- EC2ヘルスチェック：EC2の起動状態を確認し、running以外の場合に異常と判断（常に有効）
- ELBヘルスチェック：ELBヘルスチェックでUnhealthyとなったEC2を異常と判断（オプション）
ELBヘルスチェックを有効化していないと、「インスタンスは起動しているが該当ポートに対応したサービスが停止している」場合などに、ELBではUnhealthyと判断されるが、Auto ScalingではHealthyと判断されるためにスケーリングが発生せずに障害が発生してしまう。
このように、適切にAuto Scalingのヘルスチェック設定をしてあげないと、ELBのヘルスチェックがUnhealthyだとしてもスケーリングしてくれない。基本的には上記2つのヘルスチェックを組み合わせることが定番である。
wakakaALBの5XX系エラーは基本的にバックエンド側の障害である
ALBにはHTTPCode_ELB_5XX_Count と HTTPCode_Target_5XX_Countというメトリクスが存在する。前者はALBが5XX系エラーを返却したことを示し、後者はバックエンドが5XX系エラーを返却したことを示している。こう聞くとHTTPCode_ELB_5XX_Countが発生した場合にはALB側での障害と判断したくなるが、実際にはバックエンド側での障害であることがほとんどである。
以下の図に示すように、バックエンド側で何らかの障害が発生して、ALBから送信したリクエストに対して応答を返さず接続を閉じた（もしくはタイムアウトした）ため、ALBが5XX系のステータスコードを返す等の状況が考えられる。
wakakaALB自体の自動スケール
ALBは負荷の増減に応じて⾃動でスケーリングしてくれるため、基本的に可用性の考慮は不要である。スケーリングに伴いALBの実体であるENI数が増減するため、ALBでは各サブネット毎に少なくとも8個のIPアドレスが利用可能であることが推奨されている。
※トラフィックが急激に増大した場合にはスケーリングが間に合わないことがあり、結果的に応答が遅くなったりタイムアウトしてしまう。これに対しては、暖気申請 or LCU予約 のいずれかの方法で事前に十分なキャパシティを確保しておくことで対応することができる。