⚖️

ALBとCLB、似て非なる2つのロードバランサーの違いを理解しよう

に公開

ALBとCLBの違いを理解しよう!

こんにちは!今回はAWSのロードバランサーであるALB(Application Load Balancer)とCLB(Classic Load Balancer)の違いについて掘り下げていきます。

こんな方におすすめ

  • 昔CLBを使っていて、最近ALBに移行した方
  • CLBを使っているレガシーシステムの移行を検討している方
  • ALBを使い始めてなんとなく違和感を感じている方
  • AWSのロードバランサーの仕組みをもっと知りたい方

ここがポイント!

ALBはCLBのバージョンアップ版や単なる機能強化版と思われがちですが、実は基本的な挙動が大きく異なります。この違いを知らないと、特にインターネット向けのサービスで一定以上のアクセス数があるケースでは、適切なチューニングができず苦労することになるかも...。

最も重要な違いは次の点です:

CLBはバッファリングプロキシとして動作するのに対し、ALBはエンドツーエンドの透過型プロキシとして動作する

これが何を意味するのか、詳しく見ていきましょう!

CLBの挙動を理解する

CLBの特徴をシンプルに言うと:

  • CLBとターゲット(Webサーバーなど)間のコネクションは、クライアントとは独立して管理されている
  • CLBはバックエンドのサーバーに投機的にTCP接続を行う
  • CLB自体がバッファとして機能してくれる

つまりCLBの場合、クライアントとバックエンドサーバー間の通信を完全に分離し、両者の間でバッファとして動作してくれるんです。

しかし、いかんせんCLBは古い技術で、AWSの新しいサービスであるALBに移行することが推奨されています。WebSocketやHTTP/2、WebSocketなどの新しいプロトコルはサポートしていませんし、今から利用する動機はほとんどありません。

ALBの挙動を理解する

一方、ALBの特徴はこんな感じです:

  • ALBは基本的に透過型プロキシとして動作する
  • クライアント-ALB間のコネクションとALB-バックエンド間のコネクションは密接に関連している
  • ALBにはバッファリングを有効にする設定が存在しない

公式ドキュメントで明確に言及されているわけではありませんが、実務経験から見るとALBはエンドツーエンドの透過型プロキシとして振る舞うことが分かっています。

AWS公式のQ&Aサイトでも次のような回答があります:

「リクエストバッファリングで問題が発生したのは、ALBの背後にあるnginxがバッファリングを有効にしていたからで、ALB自体はそのようなバッファリングを実行しませんでした。」Is ALB doing request buffering or not?

「遅いクライアント問題」に注目しよう

バッファリングの有無がなぜ重要かというと、インターネット上のクライアントとの通信速度が不安定だからなんです。これは「遅いクライアント問題」と呼ばれます。

具体例を見てみましょう:

あなたのWebアプリケーションが処理を100msで完了し、10KBのJSONレスポンスを返すとします。でも、不安定なモバイル回線を使っているユーザーがいて、そのユーザーは10KBの受信に1秒かかってしまいます。

  • CLBを使用している場合:CLBがバッファとして機能するため、Webサーバーは100msで処理を完了し、CLBにレスポンスを返し、すぐに次のリクエストを受け付けられます
  • ALBを使用している場合:クライアントの受信が完了するまで接続を維持する必要があり、サーバーは約900msの間、余分に待たなければなりません

これは大きな違いですよね!多数のクライアントが接続する環境では、この差がサーバーのスケーリング要件に大きく影響します。

どうすればいい?ALBでのバッファリング戦略

ALBを使いながらも効率的なシステム構成にするには、以下の方法があります:

1. nginxなどのWebサーバーでバッファリングを設定する

ALBの「内側」にバッファを設けることで、アプリケーションサーバー(ap層)はnginxにレスポンスを返した後、すぐに次のリクエストを処理できるようになります。アプリケーションサーバーの前段にnginxを配置するのは一般的な構成ですね!

このような構成にすることで、アプリケーションサーバはnginxにレスポンスを返した後、すぐに次のリクエストを処理できるようになります。

fastcgi_buffering on;          # バッファリングを有効にする(default: on)
fastcgi_buffers 16 16k;        # バッファの数とサイズ
fastcgi_buffer_size 32k;       # ヘッダー用バッファサイズ
fastcgi_busy_buffers_size 64k; # クライアントに送信中に使えるバッファサイズ

レスポンスサイズに対して十分な量のバッファを確保することが重要です。こうすることで、Web層(nginx)とアプリケーション層の責務を分離できます:

  • Web層:横方向のスケーラビリティ(大量の接続維持)
  • アプリケーション層:縦方向のスケーラビリティ(処理能力)

2. CloudFrontを使ってALBの前にバッファを設ける

ALBの「外側」にCloudFrontを配置する方法です。

面白いのは、キャッシュを有効にする必要がない点です。CloudFrontディストリビューションとALB間の接続は、クライアントとの接続よりもはるかに高速なため、CloudFront自体がバッファとして機能します。

もちろん、キャッシュ可能なコンテンツがあれば、キャッシュを有効にすることでさらにALBとWebサーバーの負荷を軽減できますが、キャッシュなしでも十分にバッファリング効果は得られます。web層の役割をCloudFrontが担っているわけですね。

まとめ:CLBとALBで変わるスケーリング戦略

同じWebアプリケーションでも、CLBとALBのどちらを使うかによって最適なスケーリング戦略は大きく変わります。

  • CLBの場合:CLB自体がバッファとして機能するため、Webサーバー層のスケーリングを抑えられる
  • ALBの場合:適切なバッファリング戦略(nginxの活用やCloudFrontの配置)が必要になる

最近ALBに移行して「なんかパフォーマンスが変わった気がする」と感じていたら、この記事で紹介した違いが関係しているかもしれません。自分のシステム構成を見直して、最適なチューニングを検討してみてください!

ALBのこういった挙動はドキュメントされていないため、今後のAWSのアップデートで仕様が変わる可能性もあります。注意深く挙動を監視し、必要に応じて設定を見直すことが重要です。

また2025年現在、CLBは新規利用非推奨です。しかし、CLBの挙動を理解しておくことは、特にレガシーシステムや移行プロジェクトにおいて重要です。ALBの特性を活かした設計を心がけましょう!ワークロードによってはNLBという選択肢があることも忘れずに。

Discussion