背景
AWS基盤のシステムでECS on Fargateで稼働させるコンテナベースのアプリケーションを2つ開発することになった。
どちらのアプリケーションも前段にALBを置いて、インターネット経由のHTTPSアクセスをALBで受け付けて、ALBからトラフィックがルーティングされるような構成をとることになった。
以上のようなシステムを構築する際に、ALB 1台を2つのアプリケーションで共用する構成が可能か(案1)、それともアプリケーションごとに専用のALBを用意する構成をとるべきか(案2)という相談を受けた。
筆者のまわりでは案2のような構成が主流で案1の構成は見かけたことがなかった。
ただ、AWSは案1の構成もサポートしているし、ネット検索すると案1の構成はいくつかヒットした。
相談を受けた相手からは、「案1で大きなデメリットがないのであれば案1を採用したい」と言われたので、念のためALB 1台 vs ALB 2台の構成について比較検討を行った。
その際に調査した内容を以下に整理する。
ALB 1台 vs ALB 2台の比較
AWSの利用料金
ALBは起動時間に応じた課金と処理内容に応じた課金の2種類の課金が発生する。
処理内容が同じ場合にはALB 1台の方が起動時間に応じた課金が1台分しかかからない分、コストメリットがある。
可用性
ALBはターゲットグループ別にヘルスチェックをする。
そのため、案1のようにALB 1台で複数ターゲットグループのトラフィックをルーティングする構成をとった場合、片方のターゲットグループのヘルスチェックがこけても、もう片方のターゲットグループへのルーティングは止めずに継続してくれるはずでALB 1台の構成でも可用性の点では遜色ない。
拡張性
ALBは同時接続数やトラフィック量に関する上限は公開されておらず、負荷に応じてスケールする仕様となっている。
以下の記事にて、ALBの負荷テストをやってみたら1800Mbpsで頭打ちになったという情報があるので、1800Mbps以上、またはそれに近いトラフィックが見込まれる場合はALBを2台に分けたほうがよいと思われる。
参考:AWS構成パターン(ELB/トラフィック処理性能評価)
監視や問題判別
監視や問題判別で主に利用することになるのはCloudWatchとなる。
CloudWatchのALBの4xxエラー数やリクエスト数等のメトリクスはALBのターゲットグループ別にカウントする仕様となっている。
そのため、案1のようにALB 1台を複数のターゲットグループによってルーティングされるアプリケーションで共用したとしても監視やトラブルシュートに影響は出ないと思われる。
結論
案1のALB 1台の構成で決定的にまずい点は思い当たらない。
1点気をつけるべきはALBへのトラフィック量が1800Mbpsに近いようなトラフィック量を見込こむのであれば1台だとスケールで対応しきれなくなる可能性があること。
そのため、そのような見込みがあるのであれば案2のALB 2台の構成を選んだほうがよい。
その後
相談相手にはAWS基盤で極力リソースを増やしたくないという事情があり、トラフィック量の観点でも問題はないことから、案1のALB 1台の構成を採用することになった。
サービスインから1ヶ月以上経過した現在もALBに起因する問題は発生しておらず筆者としても一安心。