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

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