NGINX Plus を使用した AWS Auto Scaling グループの負荷分散

クラウドの最も有益な機能の 1 つは、コンピューティング インスタンスの数を自動的に拡張できることです。 AWSで 自動スケーリングEC2インスタンスの数を変更することができます。 自動スケーリング グループスケジュールまたは需要に基づいて、手動または自動で実行します。 Auto Scaling は、インスタンスの数を現在のワークロードに適した数に調整することでコストを削減します。 さらに、Auto Scaling は失敗したインスタンスを再起動するため、アプリケーションの復元力が向上します。

Auto Scaling を使用する場合、負荷分散は非常に重要です。 AWS は、組み込みのロードバランサー(Elastic Load Balancer (ELB)、現在は正式に Classic Load Balancer と呼ばれています) と Application Load Balancer (ALB) を Auto Scaling と統合することで、Auto Scaling グループのインスタンスの負荷分散を実現します。 NGINX Plus は、 AWS を含むあらゆるクラウド環境に高度なクラウド負荷分散を提供し、AWS Auto Scaling グループをサポートします。

組み込みの AWS クラウド ロードバランサーの代替または追加として NGINX Plus を選択する主な理由は 3 つあります。

1. NGINX Plus は、ELB や ALB にはない複数の高度な機能を提供します。
2. AWS ロードバランサー (特に ALB) の料金モデルは複雑で、コストを予測することが困難です。 NGINX Plus の料金は、NGINX Plus サブスクリプションを当社から直接購入する場合でも、 AWS Marketplaceから構築済みの NGINX Plus インスタンスを実行する場合でも、設定時間単位で課金されるので簡単です。
3. NGINX Plus はプラットフォーム固有の API に縛られないため、複数のクラウド プラットフォーム間で負荷分散構成を再利用できます。

NGINX Plus と AWS 組み込みソリューションの比較 (および連携) については、 ELBとALBに関するブログ投稿をお読みください。

このブログ記事では、Auto Scaling グループの負荷を分散するように NGINX Plus を構成する 2 つの方法を示し、それぞれの方法をどのような場合に使用するのが適切かを説明します。

1. ELB の前で NGINX Plus を使用する
2. NGINX, Inc. が提供する統合ソフトウェアで NGINX Plus を使用する

このブログ投稿を読んだ後、Auto Scaling グループに高度な負荷分散を提供するために、AWS に NGINX Plus をデプロイする準備が整います。

サンプルAWS Auto Scaling環境

サンプル アプリケーション環境を使用して、NGINX Plus を使用して Auto Scaling グループの負荷を分散する 2 つの方法を説明します。 バックエンド Web アプリケーションは、バックエンド 1 とバックエンド 2 の 2 つのサービスで構成されており、それぞれポート 80 で公開されています。 各サービスには、複数のアプリケーション インスタンスの Auto Scaling グループが存在します。 ロード バランサは、リクエスト URI に基づいてクライアント リクエストを適切なバックエンドにルーティングします。

• /backend‑oneへのリクエストは Backend One に送られます。
• /backend‑twoへのリクエストは Backend Two に送られます。

アプリケーションの Auto Scaling グループを（自動または手動で）スケーリングする場合、ロードバランサーの構成を更新して、アプリケーション インスタンスの新しい数を反映する必要があります。 組み込みの AWS ロードバランサーはこれを自動的に実行します。 NGINX Plus の場合、上記のいずれかの方法 (ELB の前にある NGINX Plus、または統合ソフトウェアを備えた NGINX Plus) を使用して、スケーリング イベントを構成に伝播する必要があります。

スケーリング イベントに応じて NGINX Plus 構成を更新するもう 1 つの方法は、外部サービス レジストリを使用することです。 NGINX Plus は、 ConsulなどのDNS インターフェースを提供するサービス検出システムとの統合をサポートしています。 このブログ記事では、外部システムに依存せず、セットアップと使用が簡単なソリューションに焦点を当てています。

ELB の前で NGINX Plus を使用する

すでに Auto Scaling グループと ELB を使用している場合、NGINX Plus の高度な機能をアプリケーションに導入する最も簡単な方法は、次の図に示すように、NGINX Plus を ELB クラウド ロードバランサーの前に配置することです。

この場合、NGINX Plus は 1 つ以上の ELB のプロキシ/ロードバランサとして機能します。 NGINX Plus は、高度なルーティング機能を使用して、リクエスト URI に基づいて適切な ELB にリクエストを転送します。その後、ELB はリクエストを Auto Scaling グループ内のインスタンスの 1 つに渡します。 この構成では、ELB がスケーリングのサポートを提供します。

NGINX Plus の設定は次のとおりです。

resolver 169.254.169.253 valid=10s;
upstream backend-one {
    zone backend-one 64k;
    server DNS-name-of-ELB-for-Backend-One resolve;
}

upstream backend-two {
    zone backend-two 64k;
    server DNS-name-of-ELB-for-Backend-Two resolve;
}

server {
    listen 80;

    location /backend-one {
        proxy_set_header Host $host;
        proxy_pass http://backend-one;
    }

    location /backend-two {
        proxy_set_header Host $host;
        proxy_pass http://backend-two;
    }
}

• リゾルバディレクティブは、NGINX Plus が内部 ELB インスタンスの DNS 名を解決するために使用する DNS サーバーを定義します。 ここでは AWS DNS サーバーの IP アドレスです。

• サービス (Backend One と Backend Two) に対応する各 Auto Scaling グループに 1 つずつ、合計 2 つのアップストリームブロックを作成します。 Auto Scaling グループは、そのグループへのトラフィックを負荷分散する ELB の DNS 名によって識別されます。

  解決パラメータを使用して、NGINX Plus に定期的に名前を再解決するように指示します。頻度は、前の項目で説明したリゾルバディレクティブの有効なパラメータによって設定されます。 ここでは、ELB の IP アドレスは頻繁に変更されるため、10 秒に設定します。

  ゾーンディレクティブは、解決された IP アドレスを格納するためのメモリ (ここでは最大 64 KB) を割り当てます。

• ポート 80 でリッスンする仮想サーバーを定義します。 ロケーションブロックは、NGINX Plus に、 /backend-oneへのリクエストを Backend One Auto Scaling グループの ELB に渡し、 /backend-twoへのリクエストを Backend Two Auto Scaling グループの ELB に渡すように指示します。

ご覧のとおり、この方法は、特に ELB をすでに使用している場合、セットアップと使用が簡単です。 ただし、いくつかの欠点もあります。

• 制限された負荷分散オプション。 NGINX Plus はリクエストをバックエンド インスタンスに直接渡すのではなく、ELB に渡すため、負荷分散を行うのは ELB です。 このため、NGINX Plus のより高度な負荷分散アルゴリズムとセッション永続性オプションを利用することはできません。
• 冗長性。 NGINX Plus は負荷分散が可能なため、ELB は冗長化されています。ELB を使用するのは、Auto Scaling とネイティブに統合されているからです。
• プロトコルのサポートが制限されています。 NGINX Plusとは異なり、ELB は WebSocket と UDP をサポートしていません。

次の方法は ELB に依存しないため、これらの欠点はありません。

統合ソフトウェアでNGINX Plusを使用する

この方法では、NGINX Plus とともに追加の統合ソフトウェアをインストールします。 ソフトウェア ( nginx-asg-sync ) は、Auto Scaling グループを継続的に監視します。 スケーリング イベントが発生したことが確認されると、NGINX Plus 構成からバックエンド インスタンスが追加または削除されます。 ご覧のとおり、 nginx-asg-sync はAWS Auto Scaling API を介して Auto Scaling グループの変更を学習します。

統合ソフトウェアを使用するには、次の手順を実行します。

1. AWS APIへのアクセスを設定する
2. 統合ソフトウェアをインストールする
3. NGINX Plus を構成する
4. 統合ソフトウェアを構成する

この手順では、バックエンドの Auto Scaling グループがすでに存在していることを前提としています。 また、NGINX Plus が Amazon Linux AMI 上で実行されていることを前提としています。

ステップ 1 – AWS API へのアクセスを設定する

Auto Scaling API との通信は認証されるため、 nginx-asg-syncの資格情報を提供する必要があります。 AWS は IAM ロールを使用して認証情報を処理します。そのため、NGINX Plus インスタンスを起動する前に、そのインスタンスのロールを作成する必要があります。 詳細な手順については、AWS ドキュメントの「Amazon EC2 の IAM ロール」を参照してください。

1. IAM ロールを作成し、事前定義されたAmazonEC2ReadOnlyAccessポリシーをそれにアタッチします。 このポリシーは、EC2 API への読み取り専用アクセスを許可します。
2. NGINX Plus インスタンスを起動するときに、この IAM ロールをインスタンスに追加します。

ステップ2 – 統合ソフトウェアをインストールする

統合ソフトウェアをインストールするには、 nginx-asg-sync GitHub リポジトリからオペレーティング システム用のパッケージをダウンロードし、NGINX Plus が実行されているインスタンスにインストールします。

• Amazon Linux、CentOS、RHEL の場合:

  $ sudo rpm -i package-name.rpm
  

• Ubuntuの場合:

  $ sudo dpkg -i package-name.deb
  

完全なインストール手順については、GitHub のドキュメントを参照してください。

ステップ3 – NGINX Plusを構成する

統合ソフトウェアは、動的再構成とライブ アクティビティ監視API を使用して NGINX Plus 構成を更新します。 ソフトウェアが適切に動作するには、これらの API を構成し、必要なアップストリーム グループを宣言する必要があります。

• オンザフライ再構成とライブ アクティビティ監視用に API エンドポイントを構成します。 統合ソフトウェアはこれらのエンドポイントを使用して、アップストリーム グループからバックエンド インスタンスを追加および削除します。
• 各 Auto Scaling グループに対してアップストリームブロックを作成します。 nginx-asg-sync はスケーリング イベントに応じてサーバーを自動的に追加および削除するため、ブロック内にサーバーを定義しないでください。

次の例は、単純な Web アプリケーションの構成を表しています。

upstream backend-one {    zone backend-one 64k;
    state /var/lib/nginx/state/backend-one.conf;
}

upstream backend-two {
    zone backend-two 64k;
    state /var/lib/nginx/state/backend-two.conf;
}

server {
    listen 80;

    status_zone backend;

    location /backend-one {
        proxy_set_header Host $host;
        proxy_pass http://backend-one;
    }

    location /backend-two {
        proxy_set_header Host $host;
        proxy_pass http://backend-two;
    }
}

server {
    listen 8080;

    root /usr/share/nginx/html;

    location = / {
        return 302 /status.html;
    }

    location = /status.html {}

    location /status {
        access_log off;
        status;
    }

    location /upstream_conf {
        upstream_conf;
    }
}

• ELB の例と同様に、Auto Scaling グループに対応する 2 つのアップストリーム グループ ( backend-oneとbackend-two )を宣言します。 ただし、ここでは、サーバーはnginx‑aws‑syncによって追加されるため、アップストリーム グループにサーバーを追加しません。 stateディレクティブは、動的に構成可能なサーバーのリストが保存されるファイルに名前を付け、NGINX Plus の再起動後も保持できるようにします。
• ポート 80 でリッスンする仮想サーバーを定義します。 ELB の例とは対照的に、NGINX Plus は/backend‑oneへのリクエストを Backend One グループのインスタンスに直接渡し、 /backend‑twoへのリクエストを Backend Two グループのインスタンスに直接渡します。

• ポート 8080 でリッスンする 2 番目の仮想サーバーを定義し、その上で NGINX Plus API を構成します。

  • オンザフライAPIは127.0.0.1:8080/upstream_confで利用可能です。
  • ステータスAPIは127.0.0.1:8080/statusで利用可能です。

ステップ4 – 統合ソフトウェアを構成する

統合ソフトウェアは、 /etc/nginxフォルダー内のaws.yamlファイルで構成されます。 私たちのアプリケーションでは、次の構成を定義します。

region: us-west-2upstream_conf_endpoint: http://127.0.0.1:8080/upstream_conf
status_endpoint: http://127.0.0.1:8080/status
sync_interval_in_seconds: 5
upstreams:
 - name: backend-one
   autoscaling_group: backend-one-group
   port: 80
   kind: http
 - name: backend-two
   autoscaling_group: backend-two-group
   port: 80
   kind: http

• リージョンキーは、アプリケーションをデプロイする AWS リージョンを定義します。
• upstream_conf_endpointキーとstatus_endpointキーは、ステップ 3で設定した NGINX Plus API エンドポイントを定義します。
• sync_interval_in_secondsキーは同期間隔を定義します。nginx -asg-sync は5 秒ごとにスケーリング更新をチェックします。

• アップストリームキーはアップストリーム グループのリストを定義します。 各アップストリーム グループに対して以下を指定します。

  • name – ステップ 3 でアップストリームブロックに指定した名前。
  • autoscaling_group – 対応する Auto Scaling グループの名前。
  • port – バックエンド サービスが公開されるポート。
  • kind – NGINX Plus がバックエンド アプリケーションに負荷分散するトラフィックのプロトコル (ここではhttp )。 アプリケーションが TCP/UDP を使用する場合は、代わりにstreamを指定します。

aws.yamlファイルを編集したら、ソフトウェアを再起動します。

$ sudo restart nginx-asg-sync

負荷分散とスケーリングのテスト

上記の手順では、アプリケーションの Auto Scaling グループの負荷を分散するように NGINX Plus を設定しました。 今、それをテストすることができます。 NGINX Plus は、 /backend‑one URI を持つリクエストを Backend One グループのインスタンスに配布し、 /backend‑two URI を持つリクエストを Backend Two グループのインスタンスに配布します。

Auto Scaling グループをスケールするときに、NGINX Plus が新しいインスタンスをどのように選択するかを確認できます。 まず、NGINX Plus インスタンスのポート 8080 の/status.htmlからアクセスできるライブ アクティビティ監視ダッシュボードにアクセスします。 Upstreamタブには、Auto Scaling グループ内のインスタンスが表示されます。

ここで、Auto Scaling グループの容量を変更して、Backend One グループを 3 インスタンスから 5 インスタンスにスケールアップします。 新しいインスタンスが起動されると、 nginx-asg-sync はそれらを NGINX Plus 構成に追加します。 すぐに新しいインスタンスがダッシュボードに表示されます。

NGINX Plus の高可用性を実現する

これまでのところ、NGINX Plus のインスタンスは 1 つだけ起動されています。 ただし、高可用性を確保するには、NGINX Plus 自体の Auto Scaling グループを作成し、NGINX Plus インスタンスの前で ELB を使用することをお勧めします。 ELB の代わりに、 Route 53 を使用してトラフィックを NGINX Plus インスタンスにルーティングすることもできます。 ELB を使用したデプロイメントの図は次のようになります。

正しい方法を選択する

では、Auto Scaling グループの負荷を分散するように NGINX Plus を構成するには、どの方法が最適ですか? 次の表は、両者を簡単に比較したものです。

まとめ

AWS Auto Scaling を使用すると、需要のレベルに合わせてアプリケーションインスタンスの数を調整できるという利点があります。 NGINX Plus は、AWS Auto Scaling グループと組み合わせて使用できる高度な負荷分散機能を提供します。

AWS Auto Scaling グループで NGINX Plus をお試しください。30日間の無料トライアルを開始するか、お問い合わせの上、ユースケースについてご相談ください。