2016年8月、Amazon Web Services（AWS）は、HTTPおよびHTTPSトラフィックのレイヤー7負荷分散に対応するApplication Load Balancerを導入しました。この新製品には、AWSの既存のレイヤー4およびレイヤー7ロードバランサーであるElastic Load Balancerにはなかった複数の機能が追加されました。Elastic Load Balancerは、正式にClassic Load Balancerへと名称変更されました。
その1年後、AWSはNetwork Load Balancerをリリースしました。これにより、レイヤー4の負荷分散が強化され、AWS上で高可用性と拡張性を備えたアプリケーションを運用するユーザーは、以下の選択肢を利用できるようになりました。
- NGINX Open SourceとNGINX Plus
- Classic Load Balancer
- Application Load Balancer（ALB）
- Network Load Balancer（NLB）
本記事では、ALBの機能を確認し、その料金と機能をNGINX Open SourceおよびNGINX Plusと比較します。
注記 –
サポート対象機能に関する情報は2020年7月時点のものであり、変更される場合があります。NGINX PlusとClassic Load Balancer（旧称Elastic Load BalancerまたはELB）の直接比較、および両者を併用する方法については、以前のブログ記事をご覧ください。高可用性のNGINX Plus環境でNLBを使用する方法については、以前のブログ記事をご覧ください。
Application Load Balancerの機能
ALBは、Classic Load BalancerやNLBと同様に、AWSと緊密に統合されています。AmazonはALBをレイヤー7ロードバランサーと説明していますが、スタンドアロンのレイヤー7リバースプロキシおよびロードバランサーが提供できる幅広い機能、チューニング、直接制御のすべてを備えているわけではありません。
ALBは、Classic Load Balancerにはない次の機能を提供します。
- コンテンツベースルーティング。ALBは、リクエストURL、
Hostヘッダー、および標準HTTPヘッダーとカスタムHTTPヘッダー、HTTPメソッド、クエリパラメーター、送信元IPアドレスなどのリクエスト内のフィールドに基づくコンテンツベースルーティングをサポートします。（ALBドキュメントの「Classic Load Balancerから移行するメリット」を参照してください。） - コンテナベースのアプリケーションをサポート。 ALBでは、AmazonのEC2 Container Service（ECS）でホストされるコンテナに対する既存のサポートが強化されています。
- より多くのメトリクス マイクロサービス単位でメトリクスを収集できます。
- WebSocketのサポート ALBは、クライアントとサーバー間の永続的なTCP接続をサポートします。
- HTTP/2のサポート ALBはHTTP/2をサポートします。HTTP/2は、SSL/TLSで保護されたコンテンツを配信する際の優れた選択肢です。
（ALBとClassic Load Balancerの機能を詳しく比較するには、AWSドキュメントの「製品の比較」を参照してください。）
ALBは、Classic Load Balancerの限られた機能に悩まされていたAWSユーザーにとって大幅なアップデートであり、Webアプリケーションへのトラフィックを保護、最適化、制御する必要がある高度なユーザーの要件にもある程度対応しました。ただし、専用リバースプロキシ（NGINXなど）やロードバランサー（NGINX Plusなど）が備えるすべての機能を提供しているわけではありません。
AWS上のトラフィック制御を改善するアプローチ
Amazon ALBを使用する代わりに、AWS上にNGINX Open SourceまたはNGINX Plusをデプロイして、トラフィックの制御と負荷分散を行うことができます。また、Classic Load BalancerまたはNetwork Load Balancerをフロントエンドとしてデプロイすることで、複数のアベイラビリティーゾーンにわたる高可用性を実現できます。次の表では、ALB、NGINX、NGINX Plusがサポートする機能を比較しています。
注：以下の表の情報は2020年7月時点のものであり、変更される場合があります。
| Amazon ALB | NGINX Open Source | NGINX Plus | |
|---|---|---|---|
| 負荷分散の 方式と機能 | Round_robin方式とleast_outstanding_requests方式、Cookieベースのセッション永続化、重み付けされたターゲットグループ、スロースタート | 重み付けされたアップストリームサーバーに対応する複数の負荷分散方式（ラウンドロビン、最小接続数、ハッシュ、IPハッシュ、ランダムなど） | NGINX Open Sourceと同じ機能に加え、最小時間方式、より多くのセッション永続化方式、スロースタート |
| キャッシュ | ❌ ロードバランサーでのキャッシュは非対応 | ✅ 静的ファイルのキャッシュと動的（アプリケーション）キャッシュ | ✅ 静的および動的キャッシュに加え、高度な機能 |
| ヘルスチェック | アクティブ（非同期チェックで返されたステータスコードを確認し、障害が発生したサーバーを特定） | パッシブ（クライアントリクエストへのレスポンスを確認し、障害が発生したサーバーを特定） | アクティブとパッシブの両方。アクティブチェックはALBよりも高機能で、詳細に設定可能 |
| 高可用性 | ALBインスタンスを複数のアベイラビリティーゾーンにデプロイしてHAを実現可能。ただし、リージョンをまたぐデプロイは不可 | NLBによるアクティブ／アクティブHAとElastic IPアドレスによるアクティブ／パッシブHA | NGINX Open Sourceと同じ機能に加え、すべてのNGINX Plusインスタンス間でシームレスなHAを実現する組み込みのクラスタ状態共有 |
| IPスイートの全プロトコルへの対応 | ❌ HTTPとHTTPSのみ | ✅ TCPとUDPにも対応（パッシブヘルスチェックを使用） | ✅ TCPとUDPにも対応（アクティブおよびパッシブヘルスチェックを使用） |
| ロードバランサーインスタンスあたりの複数アプリケーション | ✅ | ✅ | |
| コンテンツベースルーティング | ✅ リクエストURL、Hostヘッダー、および標準／カスタムHTTPヘッダー、メソッド、クエリパラメーター、送信元IPアドレスなどのリクエストフィールドに基づく | ✅ ALBと同じ要素に加え、Cookie、およびインラインJavaScriptエンジンとしてNGINX JavaScriptモジュールを使用した動的計算に基づく | ✅ NGINX Open Sourceと同じ要素に加え、JWTクレームとキー／バリューストア内の値に基づく |
| コンテナ化されたアプリケーション | Amazon ID、ECSコンテナインスタンス、Auto Scalingグループ、AWS Lambda関数への負荷分散が可能 | 手動設定または設定テンプレートが必要 | SRVレコードを含むDNSを使用した自動設定。主要なレジストリサービスに対応 |
| ポータビリティ | ❌ すべての環境（開発、テスト、本番）をAWS上に配置する必要あり | ✅ どの環境も任意のデプロイプラットフォームに配置可能 | |
| SSL/TLS | ✅ SNIをサポートする複数のSSL/TLS証明書 ❌ SSL/TLSアップストリームの検証は非対応 | ✅ SNIをサポートする複数のSSL/TLS証明書 ✅ SSL/TLS暗号スイートを自由に選択可能 ✅ SSL/TLSアップストリームの完全な検証 | |
| HTTP/2とWebSocket | ✅ | ✅ | |
| 認証機能 | – OIDC、SAML、LDAP、AD IdPの認証オプション – AWS CognitoおよびCloudFrontとの統合 | 複数の認証オプション | |
| 高度な機能 | ❌ 最低限のAPI | ✅ オリジンサーバー機能、優先順位付け、レート制限など | ✅ NGINX Open Sourceと同じ機能に加え、RESTful API、キー／バリューストア |
| ログ記録とデバッグ | ✅ Amazonバイナリログ形式 | ✅ カスタマイズ可能なログファイルと複数のデバッグインターフェース | ✅ 完全にカスタマイズ可能なログファイルと複数のデバッグインターフェース。NGINXによる包括的なサポート |
| 監視ツール | ✅ Amazon CloudWatchとの統合 | ✅ NGINX Controller*およびその他のサードパーティ製ツール | ✅ NGINX Controllerおよびその他のサードパーティ製ツール。より多くの統計情報をレポート |
| 公式テクニカルサポート | ✅ 追加料金で利用可能 | ❌ コミュニティサポートのみ | ✅ 料金に含まれ、NGINXが直接提供 |
| 無料利用枠 | ✅ 最初の750時間 | ✅ 常時無料 | ✅ 30日間のトライアルサブスクリプション |
* NGINX Controllerは現在、F5 NGINX Management Suiteです。
もちろん、ロードバランシングの選択肢は、機能のチェックリストではなく、高度なセキュリティ、最大限の可用性、完全な制御を確保しながら、アプリケーションを問題なく提供するために必要な能力に基づいて評価することが重要です。
トラフィック急増への対応
AmazonのClassic Load Balancer（旧ELB）は、トラフィックの急増への対応に課題がありました。ロードバランサーインスタンスは、その時点のトラフィック量に応じて自動的にサイジングされていたため、トラフィックが急増した際、ELBが対応して追加容量をデプロイするまでに数分以上かかることがありました。ユーザーは、トラフィックの急増に備えて追加リソースを事前にリクエストするために、「プレウォーミング」と呼ばれる、フォームを使用した手動プロセスに頼らざるを得ませんでした。ALBはNGINXをベースとしているため、ALBインスタンスははるかに多くのトラフィックを処理できますが、トラフィックの急増に応じてスケーリングイベントが発生する場合があります。さらに、トラフィックが急増すると、Load Balancer Capacity Unit（LCU）の消費量が自動的に増加し、その結果、コストも高くなります。
ロードバランシングプロキシを自社でデプロイしてスケーリングすれば、キャパシティとコストを完全に制御できます。NGINXとNGINX Plusは標準のAmazonインスタンス内にデプロイされます。また、サイジングガイドでは、キャパシティが異なる各インスタンスタイプで見込まれるピークパフォーマンスの目安を確認できます。NGINX Plusの料金はインスタンスサイズを問わず同一であるため、トラフィックの急増に備えて余剰キャパシティを確保してもコスト効率に優れています。さらにキャパシティが必要になった場合も、フォームへの入力なしでインスタンスを迅速に追加できます。
ヘルスチェックによる障害サーバーの検出
Amazon ALBをテストした結果、「パッシブ」ヘルスチェックは実装されていないことが示されています。非同期テストによって、想定されるステータスコードがサーバーから返されていないことが確認された時点で、初めてそのサーバーが障害状態にあると検出されます。
このことは、インスタンスのクラスターを負荷分散するALBインスタンスを作成して確認しました。ヘルスチェックの間隔を最小値の5秒、失敗回数のしきい値を最小値の2回に設定し、ALBに継続的にリクエストを送信しました。いずれかのインスタンスを停止すると、ヘルスチェックがそのインスタンスの停止を検出するまでの数秒間、一部のリクエストに対してALBから「502 Bad Gateway」エラーが返されました。NGINXとNGINX Plusの両方でサポートされているパッシブヘルスチェックにより、この種のエラーがエンドユーザーに表示されるのを防止できます。
ALBのヘルスチェックでは、HTTPステータスコード（例：200 OKまたは404 Not Found）を調べることによってのみ、インスタンスの正常性を判断できます。このようなヘルスチェックは信頼性に欠けます。たとえば、一部のWebアプリケーションでは、サーバーが生成したエラーをユーザー向けのわかりやすいページに置き換えます。また、Webページの本文でのみ報告されるエラーもあります。
NGINX Plusは、パッシブヘルスチェックとアクティブヘルスチェックの両方をサポートしています。アクティブヘルスチェックはALBよりも高機能で、ステータスコードだけでなく、レスポンス本文との照合も可能です。
料金
最後に、ALBを導入する際の最大の懸念事項はコストです。ロードバランシングの費用は、Amazonの請求額のかなりの部分を占める可能性があります。
AWSでは、料金の決定に複雑なアルゴリズムを使用しています。毎月管理する新規接続数、同時接続数、データ量を正確に把握し（これらの予測は非常に困難です）、Amazonと同じ方法でLCUを計算できない限り、毎月Amazonから届く請求書に不安を感じることになるでしょう。
NGINX Plus on AWSなら、コストを完全に予測できます。固定の時間単位料金とAWSホスティング料金で、フルサポート付きの、はるかに強力な負荷分散ソリューションをご利用いただけます。
まとめ
NGINX Plusは、実績のあるレイヤー7ロードバランシングソリューションであり、レイヤー4ロードバランシング機能も備えています。Amazon独自のClassic Load BalancerまたはNLBと組み合わせて効果的に利用できます。
AWS環境では、すでに広く利用されているNGINXとNGINX Plusを、今後もさらにご活用いただくことをお勧めします。まだNGINX Plusをご利用でない場合は、今すぐ30日間の無料トライアルを開始するか、ユースケースについてご相談ください。
著者について
関連するブログ記事
チュートリアル：NGINXを使用してアプリケーション向けにOpenTelemetryを構成する
OpenTelemetryを使用してNGINXサーバーの状態と健全性をより明確に把握することで、問題のトラブルシューティングを行い、Webアプリケーションのパフォーマンスを向上できます。
AkitaのNGINX Plus認定モジュールでAPIエンドポイントの問題を特定・修正
Akita SoftwareのAPIオブザーバビリティ向け新しいNGINX Plus Certified Moduleを活用して、APIエンドポイントの問題をより迅速に特定し、修正できます。
JavaプロジェクトをスキャフォールディングしてKubernetesネイティブアプリを構築する方法
Red HatのシニアプリンシパルデベロッパーアドボケイトであるDaniel Oh氏が、Javaプロジェクトをゼロから構築するためのひな形を作成し、Kubernetesネイティブアプリケーションとしてビルドする方法を解説します。
F5 NGINXaaS for Azureのご紹介：Microsoft Azureでネイティブに利用できるSaaS型ロードバランシング
NGINXaaS for Azureは、NGINX PlusをAzureネイティブのSaaSとして利用できるサービスです。NGINXの設定を容易にリフト＆シフトできるため、クラウド導入とモダンアプリの展開を加速できます。
SELinuxでNGINXおよびNGINX Plusを使用する
Red Hat Enterprise Linux（RHEL）および関連ディストリビューションでSecurity-Enhanced Linux（SELinux）を有効にすると、デフォルト設定によりNGINXとNGINX Plusの一部の操作が制限されます。この記事では、すべての機能を利用できるようにSELinuxの設定を変更する方法について説明します。
NGINX PlusによるAWS Auto Scalingグループの負荷分散
新しいnginx-asg-sync統合ソフトウェアにより、NGINX PlusはAWS Auto Scalingグループの負荷を直接分散できるため、クラウドでの負荷分散がさらに柔軟になります