Amazon で適切なロードバランサーを選択する: AWS アプリケーションロードバランサーと NGINXプラス
2016 年 8 月、Amazon Web Services (AWS) は、HTTP および HTTPS トラフィックのレイヤー 7 負荷分散用のApplication Load Balancer を導入しました。 この新製品には、AWS の既存のレイヤー 4 およびレイヤー 7 ロードバランサーである Elastic Load Balancer に欠けていた機能がいくつか追加され、正式に Classic Load Balancer に名前が変更されました。
1 年後、AWS はレイヤー 4 の負荷分散を改善するNetwork Load Balancer をリリースしました。これにより、AWS で可用性が高くスケーラブルなアプリケーションを実行するユーザーの選択肢は次のようになります。
この記事では、ALB の機能をレビューし、その価格と機能を NGINX Open Source および NGINX Plus と比較します。
注記 –
- サポートされている機能に関する情報は 2020 年 7 月時点のものですが、変更される可能性があります。
- NGINX Plus と Classic Load Balancer (旧称 Elastic Load Balancer または ELB) の直接比較、およびこれらを一緒に使用する方法については、以前のブログ投稿をご覧ください。
- 高可用性 NGINX Plus デプロイメントに NLB を使用する方法については、以前のブログ投稿を参照してください。
アプリケーション ロード バランサーの機能
ALB は、Classic Load Balancer や NLB と同様に、AWS に緊密に統合されています。 Amazon はこれをレイヤー 7 ロードバランサーと説明していますが、スタンドアロンのレイヤー 7 リバース プロキシおよびロードバランサーが提供できる幅広い機能、チューニング、直接制御は提供していません。
ALB は、Classic Load Balancer にはない次の機能を提供します。
- コンテンツベースのルーティング。 ALB は、リクエスト URL、
ホストヘッダー、標準およびカスタム HTTP ヘッダーとメソッド、クエリ パラメーター、ソース IP アドレスを含むリクエスト内のフィールドに基づくコンテンツ ベースのルーティングをサポートします。 ( ALB ドキュメントの「Classic Load Balancer から移行する利点」を参照してください。) - コンテナベースのアプリケーションのサポート。 ALB は、Amazon の EC2 Container Service (ECS) でホストされているコンテナに対する既存のサポートを改善します。
- より多くのメトリック。 マイクロサービスごとにメトリクスを収集できます。
- WebSocket サポート。 ALB は、クライアントとサーバー間の永続的な TCP 接続をサポートします。
- HTTP/2 サポート。 ALB は、SSL/TLS で保護されたコンテンツを配信する際の優れた代替手段である HTTP/2 をサポートしています。
(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 月時点のものですが、変更される可能性があります。
| アマゾンALB | NGINX オープンソース | NGINX プラス | |
|---|---|---|---|
| 負荷分散 方法と特徴 |
ラウンドロビンとleast_outstanding_requestsメソッド、Cookie ベースのセッション永続性、重み付けされたターゲット グループ、スロー スタート |
重み付けされた上流サーバーによる複数の負荷分散方法（ラウンドロビン、最小接続、ハッシュ、IPハッシュ、ランダムなど） | NGINX Open Source と同じ機能に加え、最小時間方式、より多くのセッション持続方式、スロースタート機能も搭載 |
| キャッシング | ❌ ロードバランサーでのキャッシュはサポートされていません | ✅ 静的ファイルキャッシュと動的（アプリケーション）キャッシュ | ✅ 静的および動的キャッシュと高度な機能 |
| 健康診断 | アクティブ（非同期チェックで返されたステータス コードをチェックして、障害が発生したサーバーを識別します） | パッシブ（クライアント要求への応答をチェックして障害が発生したサーバーを識別する） | アクティブとパッシブの両方 – アクティブチェックはALBよりも豊富で、より構成可能です。 |
| 高可用性 | HAのために複数のアベイラビリティゾーンにALBインスタンスをデプロイすることはできますが、リージョンをまたいでデプロイすることはできません。 | NLB を使用したアクティブ アクティブ HAとElastic IP アドレスを使用したアクティブ パッシブ HA | NGINX Open Source と同じ機能に加え、すべての NGINX Plus インスタンスでシームレスな HA を実現する組み込みのクラスタ状態共有機能を搭載 |
| IPスイートのすべてのプロトコルをサポート | ❌ HTTP と HTTPS のみ | ✅ TCPとUDPもパッシブヘルスチェック付き | ✅ TCP と UDP もアクティブおよびパッシブのヘルスチェック付き |
| ロードバランサインスタンスごとに複数のアプリケーション | ✅ | ✅ | |
| コンテンツベースのルーティング | ✅ リクエスト URL、ホストヘッダー、標準およびカスタム HTTP ヘッダー、メソッド、クエリ パラメータ、ソース IP アドレスなどのリクエスト フィールドに基づきます。 |
✅ ALBと同じ要素に基づき、さらにクッキーと、インラインJavaScriptエンジンとしてNGINX JavaScriptモジュールを使用した動的計算も追加 | ✅ NGINX Open Sourceと同じ要素に基づき、さらにJWTクレームとキーバリューストア内の値も追加 |
| コンテナ化されたアプリケーション | Amazon ID、ECSコンテナインスタンス、Auto Scalingグループ、AWS Lambda関数に負荷分散できます。 | 手動設定または設定テンプレートが必要 | SRVレコードを含むDNSを使用した自動構成。主要なレジストリサービスと連携 |
| ポータビリティ | ❌ すべての環境（開発、テスト、本番）はAWS上に存在する必要があります | ✅ あらゆる環境をあらゆる展開プラットフォーム上に配置可能 | |
| TLS/SSL のセキュリティ | ✅ 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 コントローラー* およびその他のサードパーティツール | ✅ NGINX コントローラーおよびその他のサードパーティツール。報告される統計情報の拡張セット |
| 公式テクニカルサポート | ✅ 追加料金がかかります | ❌ コミュニティサポートのみ | ✅ 価格に含まれており、NGINXから直接提供されます |
| 無料枠 | ✅ 最初の750時間 | ✅ 常に無料 | ✅ 30日間のトライアルサブスクリプション |
* NGINX コントローラーは、 F5 NGINX Management Suite になりました。
もちろん、負荷分散の選択は、機能チェックリストではなく、高いセキュリティ、最大限の可用性、完全な制御を備え、アプリケーションを完璧に提供するために必要な機能を評価することによって評価する必要があります。
トラフィック急増への対応
Amazon の Classic Load Balancer (旧 ELB) は、トラフィックの急増に対する応答が不十分でした。 ロード バランサ インスタンスは現在のトラフィック レベルに合わせて自動的にサイズ設定され、スパイクが発生したときに ELB が応答して追加の容量を展開するまでに数分かかることがありました。 ユーザーは、トラフィックの急増に先立って追加のリソースを要求するために、手動のフォームベースのプロセスに頼る必要がありました（「事前ウォーミング」と呼ばれます）。 ALB は NGINX をベースとしているため、ALB インスタンスはより多くのトラフィックを処理できますが、トラフィックの急増に応じてスケーリング イベントが発生する場合があります。 さらに、トラフィックの急増により、ロード バランサ容量ユニット (LCU) の消費量が自動的に増加し、結果としてコストが高くなります。
負荷分散プロキシを自分で導入および拡張すれば、容量とコストを完全に制御できます。 NGINX と NGINX Plus は標準の Amazon インスタンス内にデプロイされており、当社のサイジング ガイドでは、さまざまな容量のインスタンス タイプの潜在的なピーク パフォーマンスの目安が示されています。 NGINX Plus の価格はすべてのインスタンス サイズで同じであるため、スパイクに対応するために余剰容量を展開してもコスト効率がよく、さらに容量が必要になったときにフォームに記入することなく、すぐに追加のインスタンスを展開できます。
ヘルスチェックによる障害サーバーの検出
Amazon ALB のテストでは、「パッシブ」ヘルスチェックは実装されていないことがわかりました。 非同期テストによって、サーバーが予期されたステータス コードを返していないことが検証された場合にのみ、サーバーが失敗したと検出されます。
インスタンスのクラスターを負荷分散する ALB インスタンスを作成することで、このことが分かりました。 最小 5 秒間隔のヘルスチェックと、最小しきい値 2 回の失敗チェックを設定し、ALB にリクエストのストリームを一定量送信しました。 インスタンスの1つを停止すると、ALBはいくつかのリクエストに対して 502 悪い ゲートウェイ ヘルスチェックによってインスタンスがダウンしていることが検出されるまで、数秒間エラーが発生し続けました。 パッシブ ヘルス チェック (NGINX と NGINX Plus の両方でサポート) により、これらのタイプのエラーがエンド ユーザーに表示されないようになります。
ALBのヘルスチェックは、HTTPステータスコード（ 200OKまたは404見つかりません）。 このようなヘルス チェックは信頼性が低く、たとえば、一部の Web アプリケーションではサーバーで生成されたエラーがユーザー フレンドリなページに置き換えられ、一部のエラーは Web ページの本文でのみ報告されます。
NGINX Plus はパッシブ ヘルス チェックとアクティブ ヘルス チェックの両方をサポートしており、後者は ALB よりも強力で、応答の本文とステータス コードとを照合できます。
価格
最後に、ALB を導入する場合に直面する最大の問題はコストです。 負荷分散は、Amazon の請求額の大きな部分を占める可能性があります。
AWS は複雑なアルゴリズムを使用して価格を決定します。 毎月の新規接続数、同時接続数、管理するデータ量を正確に把握し (予測するのは非常に困難です)、Amazon と同じ方法で LCU 計算を実行できない限り、毎月の Amazon の請求書に恐怖を感じることになるでしょう。
AWS 上の NGINX Plus は完全な予測可能性を提供します。 固定の時間単位の料金と AWS ホスティング料金を支払うだけで、フルサポート付きの非常に強力な負荷分散ソリューションを手に入れることができます。
結論
NGINX Plus は、レイヤー 4 のロード バランシング機能も備えた、レイヤー 7 ロード バランシングの実績あるソリューションです。 これは、Amazon 独自の Classic Load Balancer または NLB と連携して機能します。
すでに非常に人気のあるソリューションである NGINX と NGINX Plus を AWS 環境で継続して使用し、さらに拡大していくことを推奨します。 まだ NGINX Plus ユーザーでない場合は、今すぐ30 日間の無料トライアルを開始するか、弊社にお問い合わせの上、ユースケースについてご相談ください。
「このブログ投稿には、入手できなくなった製品やサポートされなくなった製品が参照されている場合があります。 利用可能な F5 NGINX 製品およびソリューションに関する最新情報については、 NGINX 製品ファミリーをご覧ください。 NGINX は現在 F5 の一部です。 以前の NGINX.com リンクはすべて、F5.com の同様の NGINX コンテンツにリダイレクトされます。"