ロードバランサーの「見えない課金」をハックせよ：ALB/NLBのLCUと性能の深淵
SREの現場にいると、月末のAWS利用料明細を見て「なぜこんなに高いのか？」と頭を抱えるエンジニアに遭遇します。特にロードバランサー（ALB/NLB）は、設定一つでコストが数倍に跳ね上がることもあれば、逆に最適化次第でパフォーマンスを劇的に改善できる「インフラの急所」です。
今日は、教科書的なマニュアルには書かれていない、ロードバランサーの性能とコストを支配する「LCU」の正体と、現場での実践的な設計戦略について深掘りしていきましょう。
—
1. LCUという「見えざる指針」を解読する
AWSのALB（Application Load Balancer）の料金体系を語る上で避けて通れないのが LCU (Load Balancer Capacity Unit) です。これは、トラフィックを処理するための「リソース消費量」を定数化したものですが、実は以下の4つの次元で構成されています。
1. 新規接続数: 1秒あたりの接続回数。
2. アクティブ接続数: 同時接続中の数。
3. 処理帯域幅: GB単位のデータ転送量。
4. ルール評価数: 複雑なパスルーティングの数。
「なんとなくALBを置いておく」ことが一番の無駄です。特に、Keep-Aliveの設定が甘いと「新規接続数」が跳ね上がり、気づかないうちにLCUを爆食いします。
現場のTips：Connection Keep-Aliveの重要性
ブラウザやAPIクライアントが毎回新しいTCPハンドシェイクを行うと、ALBは「新規接続」として課金対象にします。バックエンドのWebサーバーだけでなく、ALBのタイムアウト値とクライアント側の設定を合わせることが重要です。
# Pythonのrequestsで接続を使い回す例
import requests
# Sessionオブジェクトを使うことで、TCP接続を保持し、LCUの「新規接続数」を抑制する
session = requests.Session()
adapter = requests.adapters.HTTPAdapter(pool_connections=10, pool_maxsize=100)
session.mount('https://', adapter)
response = session.get('https://api.example.com/data')—
2. ALB vs NLB：パフォーマンスの境界線
「とりあえずALB」という思考停止は危険です。
- ALB (L7): ヘッダーベースのルーティングや、WAFとの統合が強み。しかし、HTTP/HTTPSの終端処理（TLSオフロード）が必要なため、CPUリソースを食い、LCU課金が発生する。
- NLB (L4): IPアドレスとポートのみで判断するため、超高速。TLSオフロードをしない限り、処理コストが非常に低い。
パフォーマンス追求のアーキテクチャ
もし、APIサーバーがすでにgRPCを使っていたり、TLSパススルーが必要な場合は、NLBを選択すべきです。NLBはLCUの代わりに「NLB容量ユニット（NLCU）」で計算され、純粋なスループット勝負ではALBを圧倒します。
もしALBでコストが天井知らずなら、フロントにCloudFrontを置くことを検討してください。CloudFrontはエッジでキャッシュするため、ALBへのクエリを劇的に減らし、結果としてLCU消費を抑えることができます。
—
3. 実践：ロードバランサーのデバッグと監視
トラブルシューティングの際、パケットがどこで詰まっているかを知るために「アクセスログ」は必須です。特に注目すべきは target_processing_time です。
ログ解析のためのコマンド例
ALBのログから、バックエンドのレスポンスが遅いリクエストを抽出して特定します。
# ログファイルから、バックエンド処理時間が1秒を超えている行を抽出
# $14はtarget_processing_time
awk '$14 > 1.0 {print $0}' /var/log/alb-logs/*.log | head -n 10また、クライアント側で curl を使って、接続のどこに時間がかかっているかを確認する癖をつけておきましょう。
# DNSルックアップからTLSハンドシェイクまでの時間を計測
curl -o /dev/null -s -w \
"DNS: %{time_namelookup}s\nConnect: %{time_connect}s\nTTFB: %{time_starttransfer}s\nTotal: %{time_total}s\n" \
https://api.example.com/v1/resource—
4. コスト最適化のためのチェックリスト
最後に、明日からの運用で即座に適用すべき「コスト最適化・性能向上」のためのチェックリストを共有します。
1. 接続の維持: クライアント・バックエンド間で Keep-Alive を有効にしているか？（HTTP/2への移行を推奨）
2. ルール評価数の削減: ALBのリスナールールが複雑すぎないか？（ワイルドカードや正規表現はコスト増）
3. 不要なALBの撤去: 開発環境や検証環境で、使われていないALBが放置されていないか？（これが一番多い「死に金」です）
4. 固定IPの検討: NLBが必要かどうかの判断基準の一つとして、静的IPが必要な要件がある場合はNLBへ移行する。
最後に：クラウドは「エンジニアの腕」を試すステージ
クラウドネットワークは、単なるインフラではなく、ビジネスの成長速度に直結する「動的なパイプライン」です。LCUがなぜ増えているのか、なぜパケットがドロップするのか。その問いに対する答えは、必ずパケットの挙動とログの中にあります。
泥臭いログ解析と、冷徹なコスト計算。この両輪を回すことで、あなたの設計するインフラはより強く、そして賢いものに進化するはずです。
何か技術的な壁にぶつかったら、まずは tcpdump を回し、パケットに語りかけることから始めてみてください。それが、真のSREへの第一歩です。
コメント