NGINX Plus

高可用性AWSロードバランサーとして、NGINX Plusを導入する

※本記事はNGINX,Inc.のブログ記事「Deploying NGINX Plus as a Highly Available AWS Load Balancer」を和訳した内容となります。
【URL】
https://www.nginx.com/blog/nginx-plus-highly-available-aws-load-balancer/

ロードバランサーは、多くの場合Webアプリケーションへの単一の入口として機能し、アプリケーション配信基盤の重要なコンポーネントとなります。 つまり、ロードバランサーのダウンタイムは、アプリケーションのダウンタイムを意味します。 ダウンタイムとそれに伴う利用者の不満を最小限に抑えるために、ロードバランサーを高可用性(以下HAと表記)を担保して展開する必要があります。

 

このブログ記事では、AWS用ロードバランサーとしてNGINX Plus の高可用性を実現するために使えるいくつかの方法を比較します。オンプレミス展開で提供するkeepalivedベースの高可用性ソリューションは、すでに精通されているかもしれません。ただし、一般的なAWSやクラウド環境では、ネットワーク制限により、クラウド上でkeepalivedベースのソリューションを使用できません。とはいうものの、AWSではNGINX Plusの高可用性を実現するための他のオプションを提供しています。たとえば、導入ガイドに記載されているように、オンプレミスのkeepalivedソリューションをAWSで動作するように変更することができます。

 

高可用Active – Active構成のNGINX PlusとAWS ネットワークロードバランサー(以下NLBと表記)を組み合わせたソリューションもあります。 この記事で論じる方法は、コミュニティ版のNGINXとNGINX Plusの両方に当てはまりますが、簡潔にするために、以下、ブログではNGINX Plusだけ取りあげます。 以下の表では、この記事で説明する4つの方法をまとめています。

  • このブログ記事は、NGINX PlusのAWSロードバランサーとしての側面、NGINX Plusの高可用性を実現することに重点を置いています。他のAWSのトピックスの詳細については、以下を参照してください。
  • AmazonEC2にNGINX Plus AMIをインストールする(英語)
  • AWS上のNGINX PlusとAmazon Elastic Load Balancing(英語)
  • Amazonで正しいロードバランサーを選択する:AWSアプリケーションロードバランサー(英語)
  • NGINX Plus with AWS Cloudクイックスタート(英語)
  • NGINX Plusを使用したAWS Auto Scalingグループのロードバランシング(英語)
  • AWSパフォーマンスをもっと早くするための5つのヒント(英語)

ELBを使用したNGINX Plusの高可用性

AWSの基本的な組み込みロードバランサであるELB(Elastic Load Balancer、正式にはクラシックロードバランサと呼ばれています)は、機能は限られていますが、高可用性を実現します。このため、図に示すように、ELBを活用してNGINX Plusの可用性を高めることができます。

すべてのNGINX Plusインスタンス間でトラフィックを負荷分散するようにELBを設定します(アプリケーションインスタンスへのトラフィックをロードバランシングします)。NGINX Plusインスタンスの1つに障害が発生すると、ELBはそれを検出し、障害インスタンスへのトラフィック送信を中止します。ELBがNGINX Plusインスタンスの障害を迅速に検出できるようにするには、ELBヘルスチェックを構成することが重要です。

ELBはActive-Activeの高可用構成を提供します。つまり、すべてのNGINX Plusインスタンスが稼働し、共有するトラフィックを受信することを意味します。StandbyのNGINX Plusインスタンスをデプロイしないことで、全体的なコストが削減されます。 ただし、HTTPロードバランサーとして配置されたELBは、HTTP / 2またはWebSocketプロトコルをサポートしていません。

これらのプロトコルをNGINX Plusで使用する必要がある場合は、ELBをTCP(HTTPではなく)ロードバランサーとして配置する必要があります。

このケースでクライアントのIPアドレスをELBからNGINX Plusに渡す必要がある場合は、ELBとNGINX Plusの両方でプロキシプロトコルも設定する必要があります。

NGINX Plusの高可用構成にELBを使用する場合、いくつかの欠点があります。

  • ELBは静的IPアドレスを公開しませんが、これは、一部のアプリケーションにとって重要な要件です。
  • ELBはロードバランシングを一段追加するので、複雑さとコストを増加
    させます。
  • ELBはUDPをサポートしていないため、UDPトラフィックの負荷分散にNGINX Plusを使用することはできません。
  • ELBはすぐに拡張できないため、トラフィックが急増すると、トラフィックが落ちる可能性があります。
  • ELBのIPアドレスはDNS CNAMEレコードを使用して公開されます。

つまり、すべてのDNSをRoute 53に委任しない限り、ルートドメイン(example.comなど)をCNAMEにマップすることはできません。

 

新しいネイティブのAWSロードバランサー、Application Load Balancer(ALB)も同様の方法で使用できます。ELBよりも多くの機能と柔軟性がありますが、上記の欠点も同じくあてはまります。

Route53を使用したNGINX Plusの高可用性

ELB同様、Route 53も図に示すように、 Active-Active構成のNGINX Plus導入を可能にします。

ELB同様、Route 53も図※に示すように、 Active-Active構成のNGINX Plus導入を可能にします。 ホストされたゾーンを作成し、レコードを追加して、すべてのNGINX Plusインスタンスにトラフィックをルーティングできるようにします。NGINX Plusインスタンスに対する、Route 53 のヘルスチェック設定を確認してください。NGINX Plusインスタンスの1つが停止した場合、Route 53はそのインスタンスに関連付けられたレコードをDNSクエリへの応答から除外します。ただし、クライアントと中間DNSサーバーは、正式なDNSサーバーによって設定された各レコードの有効期間(TTL)値に従ってレコードをキャッシュします。TTLの有効期限が切れるまではレコードを更新しないので、権限のあるサーバーが応答からNGINX Plusインスタンスのレコードを削除したときにも、すぐには通知しません。この問題を回避するには、NGINX Plusレコードには、最小TTL値を設定する必要があります。

詳細な手順については Route 53 導入ガイド(英語)を参照してください。

Active-Active構成に加えて、Route 53では、AWS ドキュメンテーションで説明されているように、Active-Passive構成またはさらに複雑なフェールオーバーの組み合わせを作成できます。 また、このブログの記事で説明されている他の方法を用いて、Route 53を使用することも可能です。 

ELBまたはRoute53を使わないNGINX Plusの高可用性

いくつかの理由から、NGINX Plusの高可用性を実現するために、ELBまたはRoute 53に頼りたくないかもしれません。1つの代替案は、Active-Passive構成でNGINX Plusを導入し、AWSのElastic IPアドレス機能を使用することです。ここでは、NGINX Plusの固定IPアドレスを公開し、プライマリ(ActiveまたはMaster)NGINX Plusインスタンスに関連付けます。スタンバイモードまたはバックアップモードの2番目のNGINX Plusインスタンスはトラフィックを処理しませんが、マスターNGINX Plusインスタンスに障害が発生したときには、引き継ぐ準備ができています。引継ぎ(フェイルオーバー)の間、Elastic IPアドレスは第2のインスタンスに再度割り当てられ、第2のインスタンスがマスターとみなされます。

Elastic IPアドレス方式の弱点は次の通りです。

  • バックアップインスタンスは、ほとんどの時間使用されていないため、導入コストが増加します。
  • 一般的なオンプレミス構成とは対照的に、固定IPアドレスの再関連付けは即時ではありません。テストでは、IPアドレスを新しいマスターインスタンスに再関連付けするまでに最大6秒かかりました。
  • この構成は、マスターのNGINX Plusインスタンスの正常性を監視し、マスター障害時にElastic IPアドレスを再関連付けするためのソフトウェアをインストールして、適切に構成する必要があるため、ELBまたはRoute 53の方法よりも複雑です。

 

NGINX, Inc.は、Elastic IPアドレスを使用する2つのソリューションを提供しており、それらはマスターNGINX Plusインスタンスの状態を監視する方法と、Elastic IPアドレスを再関連付けする方法で異なります。

  • keepalivedベースのソリューション

導入ガイドで説明しているように、keepalivedベースのソリューションをオンプレミス展開に変更し、AWSでElastic IPアドレスの再関連付けをサポートすることができます。オンプレミスのHA構成と同様、バックアップのNGINX Plusインスタンス上のkeepalivedデーモンは、マスターインスタンスの正常性を監視します。オンプレミスのソリューションとの違いは、マスター障害時にkeepalivedがカスタムスクリプトを起動して、Elastic IPアドレスを再関連付けするAWS APIを呼び出すことです。このソリューションは、NGINX Plusサポート契約の対象外であることにご注意ください。

  • AWS Lambdaベースのソリューション

Lamba機能を使用してNGINX Plusマスターインスタンスの正常性を監視し、マスター障害時にはElastic IPアドレスを再関連付けします。
このソリューションに関しては、NGINXのプロフェッショナル・サービスチームによるソリューションの導入、設定、さらにサポートをご提供しています。
また、高可用性Active-Active構成のNGINX Plusと AWS Network Load Balancer (NLB)を組み合わせたソリューションもあります。

まとめ

高可用性は、AWSロードバランサーには非常に重要です。このブログ記事で説明してきたように、AWSではNGINX Plusの高可用性を実現するための方法を複数用意しています。 ELBまたはRoute 53に基づく方法はよい出発点です。固定IPアドレスが必要な場合は、keepalivedまたはAWS Lambdaに基づくElastic IPを使う方法をご利用ください。

AWS上でNGINX Plusを使うのは初めてですか? ぜひ、30日間無料でお試しください。利用可能なAMIへのリンクについては、Amazon EC2上でのNGINX PlusAMIのインストールを参照して下さい。

ホワイトペーパー「ロードバランシングをソフトウェアに切り替える 5つの理由」

現代のITインフラ担当者は、ベアメタル、クラウド、コンテナなど様々な環境が混在する中、急激なトラフィックの増加やアプリケーションの迅速な展開といったWebサービスの課題に頭を悩ませています。Webの先進的な企業では、ハードウェアベースのアプリケーション デリバリー コントローラー(ADC)から、ソフトウェアベースのWebサーバーやロードバランサー、キャッシュサーバーに移行することでこの課題を解決しています。


現代のITシステムが求める高い柔軟性やスピード、コストパフォーマンスを満たすには、ソフトウェアが圧倒的に優位です。 このebookでは、IT責任者、ネットワーク担当者、アプリケーション開発者が、ハードウェアADCからソフトウェアソリューションに移行することで得られるメリットと優位性、ビジネスへの影響について、以下の5つの観点から解説します。


■目次■

1. 機能や性能を損なうことなくコストを劇的に削減します 

2. DevOpsへの移行にはソフトウェアベースのアプリケーションデリバリーが必要です

3. 1つのADCソリューションで、ベアメタル、クラウド、コンテナなど、どこにでも展開します 

4. アプリケーションへのニーズの変化に素早く対応します 

5. 性能に対して、意図的に制限を課したり、契約で制限を設けたりすることはありません


ダウンロード

コメントを残す

*