NGINX Full Version

最適なロードバランサー リバースプロキシの選択方法

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でスケーラブルな高可用性アプリケーションを実行するユーザーには、次の選択肢が提供されています。

このブログでは、ALBの機能とオープンソース版のNGINXおよびNGINX Plusとの比較をまとめています。

注:

Application Load Balancerの機能

ALBは、Classic Load BalancerやNLBと同様に、AWSと緊密に統合されます。Amazonの説明では、ALBはレイヤー7ロードバランサーとして機能します。しかし、スタンドアロンのレイヤー7リバースプロキシおよびロードバランサーのように、包括的な機能、詳細な調整、直接的な制御を提供するものではありません。

ALBは、Classic Load Balancerでは提供されない以下の機能を提供します。

(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 OK404 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日間の無料トライアル版をお試しいただけます。また、何かご相談あれば、いつでもご相談ください