2016年8月、Amazon Web Services(AWS)は、レイヤー7で動作してHTTP/HTTPSトラフィックのロードバランシングを実行するApplication Load Balancerをリリースしました。レイヤー4とレイヤー7のロードバランサーとしてAWSが以前から提供していたElastic Load Balancerは、正式にClassic Load Balancerという名前に変更されました。Application Load Balancerには、旧製品にはない機能がいくつか追加されています。
その1年後、AWSはレイヤー4のロードバランシングを改善するためのNetwork Load Balancerをリリースしました。つまり、AWSでスケーラブルな高可用性アプリケーションを実行するユーザーには、次の選択肢が提供されています。
- オープンソース版NGINXおよびNGINX Plus
- Classic Load Balancer
- Application Load Balancer (ALB)
- Network Load Balancer (NLB)
このブログでは、ALBの機能とオープンソース版のNGINXおよびNGINX Plusとの比較をまとめています。
注:
- サポートされる機能は2020年7月時点の情報であり、今後変更される可能性があります。
- NGINX PlusとClassic Load Balancer(旧称Elastic Load Balancer(ELB))の直接比較、およびこれら2つの併用については、こちらのブログ(英語)をご覧ください。
- NGINX Plusの高可用性デプロイメント向けにNLBを使用する場合の情報については、こちらのブログ(英語)をご覧ください。
Application Load Balancerの機能
ALBは、Classic Load BalancerやNLBと同様に、AWSと緊密に統合されます。Amazonの説明では、ALBはレイヤー7ロードバランサーとして機能します。しかし、スタンドアロンのレイヤー7リバースプロキシおよびロードバランサーのように、包括的な機能、詳細な調整、直接的な制御を提供するものではありません。
ALBは、Classic Load Balancerでは提供されない以下の機能を提供します。
- コンテンツベースのルーティング:ALBは、リクエスト内のURL、
Host
ヘッダー、リクエスト内のフィールド(標準およびカスタムのHTTPヘッダーとメソッド、クエリーパラメーター、送信元IPアドレスなど)に基づくコンテンツベースのルーティングをサポートします。(ALBのドキュメントの「Benefits of migrating from a Classic Load Balancer(Classic Load Balancerから移行する利点)」セクション(英語)をご覧ください。) - コンテナー化されたアプリケーションのサポート:ALBでは、AmazonのEC2 Container Service(ECS)でホストされるコンテナーに対するこれまでのサポートが改善されています。
- 多数のメトリクス:マイクロサービスごとにメトリクスを収集できます。
- WebSocketのサポート:ALBは、クライアントとサーバでTCPの持続的接続をサポートします。
- HTTP/2のサポート:ALBはHTTP/2をサポートします。これは、SSL/TLSにより保護されたコンテンツのデリバリーで、優れた代替の選択肢となります。
(ALBとClassic Load Balancerの詳細な機能比較については、AWSのドキュメントの「Product comparisons(製品比較)」セクション(英語)をご覧ください。)
Classic Load Balancerの機能が制限されていたために苦労していたAWSユーザーにとって、ALBは重要なアップデートとなりました。また、Webアプリケーションへのトラフィックの保護、最適化、制御を必要とする高度なユーザーの要件にも、ある程度対応しました。ただし、専用のリバースプロキシ(NGINXなど)やロードバランサー(NGINX Plusなど)で提供される包括的な機能は依然として提供されていません。
関連情報:リバースプロキシサーバとは?(用語集)>>
関連情報:リバースプロキシとロードバランサーの違いとは?(用語集)>>
NGINX Plusはどのように役立ちますか?
AWSでのトラフィック制御でより望ましいアプローチとは
トラフィックの制御やロードバランシングのため、Amazon ALBを使用する代わりに、AWSにオープンソース版のNGINXまたはNGINX Plusをデプロイすることができます。また、Classic Load BalancerまたはNetwork Load Balancerをフロントエンドとしてデプロイし、複数のアベイラビリティゾーンにわたって高可用性を実現することも可能です。次の表は、ALB、NGINX、NGINX Plusでサポートされる機能を比較しています。
注:次の表は2020年7月時点の情報であり、今後変更される可能性があります。
Amazon ALB | オープンソース版のNGINX | NGINX Plus | |
---|---|---|---|
ロードバランシングのメソッドと機能 | Round_robin メソッドおよびleast_outstanding_requests メソッド(Cookieベースのセッション維持、加重ターゲットグループ、スロースタートを含む) |
複数のロードバランシングメソッド(ラウンドロビン、最小接続、ハッシュ、IPハッシュ、ランダムを含む)を使用 | オープンソース版NGINXと同様の機能に加え、さらに、最小時間メソッド、プラスいくつかのセッション維持メソッド、スロースタートなどが使用可 |
キャッシング | ❌ ロードバランサーでのキャッシングはサポートされない | ✅ 静的ファイルキャッシングと動的(アプリケーション)キャッシング | ✅ 静的/動的キャッシングと高度な機能 |
ヘルスチェック | アクティブ(非同期チェックで返されたステータスコードをチェックすることによって、障害が発生したサーバーを特定) | パッシブ(クライアントリクエストへの応答をチェックすることによって、障害が発生したサーバーを特定) | アクティブとパッシブの両方 – アクティブチェックは、ALBよりも多機能で詳細な構成が可能 |
高可用性 | HAの複数のアベイラビリティゾーンにALBインスタンスをデプロイできるが、リージョン全体にはデプロイできない | NLBを使用したアクティブ/アクティブHAおよびElastic IPアドレスを使用したアクティブ/パッシブHA | オープンソース版NGINXと同様の機能。さらに、すべてのNGINX Plusインスタンス全体でシームレスなHAを実現する組み込みクラスター状態を共有 |
IPスイートのすべてのプロトコルのサポート | ❌ HTTPとHTTPSのみ | ✅ TCPとUDPもサポート。パッシブヘルスチェックを使用 | ✅ TCPとUDPもサポート。アクティブおよびパッシブヘルスチェックを使用 |
ロードバランサーインスタンスごとに複数のアプリケーション | ✅ | ✅ | |
コンテンツベースのルーティング | ✅ リクエスト内のURL、Host ヘッダー、フィールド(標準およびカスタムのHTTPヘッダー、メソッド、クエリーパラメーター、送信元IPアドレスなど)に基づく |
✅ ALBと同じ要素に加えて、インラインJavaScriptエンジンとしてNGINX JavaScriptモジュールを使用したCookieおよび動的計算に基づく。 | ✅ オープンソース版のNGINXと同じ要素に加えて、キーバリューストアのJWTクレームおよび値に基づく。 |
コンテナー化されたアプリケーション | Amazon ID、ECSコンテナーインスタンス、Auto Scalingグループ、AWS Lambda関数へのロードバランシングが可能 | 手動の構成または構成テンプレートが必要 | DNSを使用した自動構成(SRV レコードを含む)。主要なレジストリーサービスと連携 |
移植性 | ❌ すべての環境(開発、テスト、本番)は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と同じ。さらに、RESTful API、キーバリューストア |
ロギングとデバッグ | ✅ Amazonバイナリログ形式 | ✅ カスタマイズ可能なログファイルと複数のデバッグインターフェイス | ✅ 完全にカスタマイズ可能なログファイルと複数のデバッグインターフェイスをNGINXで完全にサポート |
監視ツール | ✅ Amazon CloudWatchと統合 | ✅ NGINX Controllerおよびその他のサードパーティツール | ✅ NGINX Controllerおよびその他のサードパーティツール、報告される統計情報を拡充 |
正式なテクニカルサポート | ✅ 追加料金が必要 | ❌ コミュニティサポートのみ | ✅ 価格に含まれ、NGINXが直接提供 |
無料利用枠 | ✅ 最初の750時間 | ✅ 常に無料 | ✅ 30日間の無料トライアル |
機能の比較表は、あくまでも参考資料としてお使いください。高度なセキュリティ、高い可用性、完全な制御性など、より最適なアプリケーションデリバリーを実現するために、必要な機能を選択いただくことが重要だと考えています。
トラフィックスパイクの処理
AmazonのClassic Load Balancer(従来のELB)では、トラフィックスパイクの処理が不十分であることが問題となっていました。ロードバランサーのインスタンスは、現在のトラフィックレベルに合わせて自動的にサイズ調整されます。トラフィックスパイクが発生した場合には、ELBが応答して追加の容量をデプロイするのに数分かかることがあります。トラフィックスパイクが起こる前に、ユーザーがフォームベースの手動プロセスで追加のリソースを要求する必要がありました(「暖気申請」と呼ばれます)。ALBはNGINXに基づくため、ALBのインスタンスはより多くのトラフィックを処理できます。ただし、依然としてトラフィックスパイクに応答するスケーリングイベントが発生することがあります。さらに、トラフィックスパイクによって自動的にLCU(Load Balancer Capacity Unit)の使用量が増加し、結果的にコストが高くなります。
ロードバランシングプロキシを独自にデプロイしてスケーリングする場合には、容量とコストを完全に制御できます。NGINXとNGINX Plusは標準のAmazonインスタンス内にデプロイされます。NGINXのサイジングガイド(英語)を参考にすることで、容量が異なるインスタンスタイプの潜在的なピークパフォーマンスを把握できます。NGINX Plusの料金はすべてのインスタンスサイズで同一であるため、スパイクに対応するため余剰の容量をデプロイする場合にも高い費用対効果が得られます。より多くの容量が必要になった場合にも、追加コストや面倒な手続きがないため、追加のインスタンスを迅速にデプロイできます。
ヘルスチェックによるサーバ障害の検出
NGINXによるAmazon ALBのテストでは、「パッシブ」ヘルスチェックが実装されていないことが示されました。サーバで障害が発生したことが検出されるのは、予期されたステータスコードをサーバが返さないことが非同期テストで確認された場合のみです。
インスタンスのクラスターをロードバランシングするALBインスタンスを作成したところ、この問題が明らかになりました。ヘルスチェックを最低5秒の頻度で実行し、チェックの失敗の最小しきい値を2回とするように構成して、リクエストをALBに送信しました。インスタンスの1つを停止した場合、ヘルスチェックによりインスタンスの停止が検出されるまでの数秒間にわたって、ALBはいくつかのリクエストに対して502
Bad
Gateway
エラーを返しました。NGINXならびにNGINX Plusのパッシブヘルスチェック機能では、このようなタイプのエラーがエンドユーザーに表示されないように設定できます。
ALBのヘルスチェックの場合は、HTTPステータスコード(200
OK
、404
Not
Found
など)の確認によってのみインスタンスの状態を判断できます。例えば、一部のWebアプリケーションはサーバが生成したエラーをユーザーフレンドリーなエラーページに置き換えており、一部のエラーはWebページの本文でのみ報告されます。
さらに、NGINX Plusではパッシブヘルスチェックとアクティブヘルスチェックの両方をサポートしています。アクティブヘルスチェックでは、コンテンツ内容やステータスコードの確認が可能です。
価格
最後に、ALBのデプロイではコストが最大の問題となります。Amazonからの課金では、ロードバランシングが大きな部分を占める可能性があります。
AWSでは、価格設定に複雑なアルゴリズムが使用されています。そのため、新しい接続数、同時接続数、毎月管理するデータ量(これは予測が非常に困難です)を正確に把握しており、Amazonと同様にLCUの計算を実行できる場合を除いて、Amazonからの毎月の請求が多額に上ることが予想されます。
AWSでNGINX Plusを使用することで、完全な予測可能性を実現できます。1時間単位の固定コストとAWSホスティング料金で、完全にサポートされた非常に強力なロードバランシングソリューションを利用できます。
まとめ
NGINX Plusは、実績のあるレイヤー7ロードバランシングソリューションであり、レイヤー4のロードバランシング機能も備えています。Amazon独自のClassic Load BalancerやNLBとも円滑に連携します。
AWS環境でのNGINXやNGINX Plusの使用は、すでに多くの導入実績があり、今後も継続・拡大して使用いただけるよう支援していきます。NGINX Plusにご興味をお持ちいただいた場合は、30日間の無料トライアル版をお試しいただけます。また、何かご相談あれば、いつでもご相談ください。