ホストベースルーティングを活用してALBを集約した際のデメリットを検討する

$0.005 per In-use public IPv4 address per hour の明細が高額になる場合の対応を考える の中で記載していた対応策の一つである「ホストベースルーティングを活用してALBを集約する」について検討を行った。

メリットについては容易に思いつくのだが、デメリットとなると考えが及ばない部分が出てくるため、サポートとのやり取りをしながら整理をしてみた。

みなさんもコスト削減のための方法としてALBの集約を検討する場合の参考となれば幸いである。

制約の観点

ALBの配置が同一のサブネットになければならない

すでに構成済みのシステムを集約する場合に一番大きな制約となる部分。既存のALBに新しいサービスを追加することを検討する場合には、サブネットのサイズも気にしておきたい。（スケールアウトする構成の場合にはアドレスが不足する可能性がある）

サービスクォータに抵触する可能性がある

リンク先のドキュメントにに記載されているサービスクオータには以下のものがあるが、アクションあたりのターゲットグループやターゲットグループ数は引き上げができないので、この点は十分に留意する必要がある。

名前	デフォルト	引き上げ可能
Application Load Balancer あたりの証明書 (デフォルト証明書を除く)	25	はい
Application Load Balancer あたりのリスナー	50	はい
Application Load Balancer ごとの、アクションあたりのターゲットグループ	5	いいえ
Application Load Balancer あたりのターゲットグループ	100	いいえ
Application Load Balancer あたりのターゲット	1,000	はい

ALB 属性の変更影響

ALB の集約時には、接続タイムアウトや HTTP/2 の有効・無効化設定などを含む ALB 属性の変更が全ホストに影響してしまう。

セキュリティポリシーの統一化

HTTPS リスナー作成時に設定するセキュリティポリシーに関して、ALB 集約時には各ホストの想定クライアントが対応しているセキュリティポリシーを設定する必要があるため、セキュリティレベルが下がる恐れがある。

可用性の観点

障害の範囲(Blast Radius)を最小化するための取り組みとしてCell-based Architectureというものがあることを最近知りましたが、皆さんはご存知でしょうか？

参考）Guidance for Cell-Based Architecture on AWS

可用性の観点では障害の範囲(Blast Radius)を最小化する点を意識しつつも、コストバランスを求められる点が正直難しいと感じている。

ALB ノード障害が発生した際の影響が大きくなる

ALB ノードの障害などにより一時的に疎通が取れない状況が発生した場合、影響が複数ホストに及んでしまうという点は、障害の範囲が大きくなる意味でアンチパターンとなる。

Route53 のフェイルオーバールーティング使用時の影響

Route 53 により ALB のフェイルオーバーを設定する場合には、特定のターゲットグループの異常が他のターゲットグループのルーティングにも影響を及ぼす可能性がある。

Route53 で ALB へのエイリアスレコードを作成時に指定可能な「Evaluate Target health (ターゲットの正常性の評価)」を Yes に設定した場合に、ALB に紐づくターゲットグループのどれか1つでも Unehealthy となった場合に ALB 自体が異常とみなされてしまう。

そのため、特定のターゲットグループに異常が発生した場合には、他の正常なターゲットグループに対するクエリについてもフェイルオーバー先へルーティングされてしまう動作となることから、障害時の切り分けが困難になりやすい。

運用の観点

ALBのログが混ざってしまうため、運用上の負荷が増える

ALB 属性の変更影響による部分になるが、ALBのログが混ざってしまうのでログを分析している場合には、フィルター条件などを変更する必要がある。