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

本ブログ記事は、NGINX,Inc.ブログ記事「Load Balancing AWS Auto Scaling Groups with NGINX Plus」を翻訳した内容になります。

URL：https://www.nginx.com/blog/load-balancing-aws-auto-scaling-groups-nginx-plus/

クラウドの最も有益な機能の1つは、コンピューティングインスタンスの数を自動的にスケーリングする機能です。AWS Auto Scalingを使用すると、Auto Scalingグループ内のEC2インスタンスの数を、スケジュールまたはリクエスト数に基づいて手動または自動で変更できます。Auto Scalingは、現在のワークロードのインスタンス数を適切な数に調整することで、コストを削減します。さらに、Auto Scalingは失敗したインスタンスを再起動し、アプリケーションの可用性を与えます。

Auto Scalingを使用する場合は、負荷分散が重要です。AWSは、Auto Scalingグループのインスタンスのロードバランシングを提供します。これは、AWSサービスのロードバランサ（Elbu Load Balancer（ELB））（正式にはクラシックロードバランサ、アプリケーションロードバランサ（ALB））はAuto Scalingと統合されています。NGINX Plusは、AWSを含むあらゆるクラウド環境に高度なクラウドロードバランシングを提供し、AWS Auto Scaling グループをサポートします。

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

NGINX Plusは、ELBおよびALBには欠けている複数の高度な機能を提供します。
AWSロードバランサ（特にALB）の価格設定モデルは複雑で、コストを予測することは困難です。NGINX Plusのプライシングは、当社から直接NGINX Plusサブスクリプションを購入するか、または事前構築されたNGINX PlusインスタンスをAWS Marketplaceから実行され、設定された
時間単価で請求される為、コスト予測も容易です。
NGINX Plusはプラットフォーム固有のAPIに結びついていないため、複数のクラウドプラットフォーム間でロードバランシング設定を再利用できます。

NGINX PlusがAWSの組み込みソリューションとどのように比較され、どのように連携しているかを確認するには、ELBとALBのブログ記事をご覧ください。

このブログ記事では、NGINX PlusをロードバランシングAuto Scaling グループに
設定する2つの方法を示し、各方法を使用することが理に適った時を説明します：

このブログ記事を読んだら、AWSにNGINX Plusを導入して、Auto Scalingグループの高度な負荷分散を提供する準備が整います。

サンプルAWSオートスケーリング環境

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

/ backend-oneへのリクエストは、バックエンド1に行きます。
/ backend-twoのリクエストは、バックエンド2に行きます。

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

スケーリングイベントにレスポンスしてNGINX Plusの設定を更新する別の方法は、外部のサービスレジストリを使用することです。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;
   }
}

このresolverディレクティブは、NGINX Plusが内部ELBインスタンスのDNS名を解決するために使用するDNSサーバを定義します。ここでは、AWS DNSサーバのIPアドレスです。
2つのupstreamブロックを作成します。1つは、サービスに対応する自動スケーリンググループごとに1つ、バックエンド1とバックエンド2です。Auto Scalingグループは、トラフィックを負荷分散するELBのDNS名で識別します。
このresolveパラメータを使用して、名前を定期的に再解決するようにNGINX Plusに指示します。頻度は、前項で説明したリゾルバ指示に有効なパラメータによって設定されます。ここでは、ELBのIPアドレスが頻繁に変更されるため、10秒に設定します。
zoneディレクティブは解決されたIPアドレスを格納する（ここでは64キロバイトまで）のメモリを割り当てます。
serverポート80でリッスンする仮想サーバを定義します。locationブロックは、NGINX Plusに、バックエンド1 Auto ScalingグループのELBに/バックエンド1のリクエストを渡し、バックエンド2 Auto ScalingグループのELBに/バックエンド2をリクエストします。

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

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

次の方法はELBに依存せず、結果としてこれらの欠点もありません。

統合ソフトウェア（nginx-asg-sync）でのNGINX Plusの使用

この方法では、NGINX Plusとともに追加の統合ソフトウェア（nginx-asg-sync）をインストールします。ソフトウェア（nginx-asg-sync）はAuto Scalingグループを常に監視します。スケーリングイベントが発生したことを確認すると、バックエンドインスタンスをNGINX Plus設定に追加または削除します。図に示すように、nginx-asg-syncは、AWS Auto Scaling APIを使用してAuto Scalingグループの変更について学習します。

統合ソフトウェアを使用するには、以下のステップを実行します。

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

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

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

IAMロールを作成し、定義済みのAmazonEC2ReadOnlyAccessポリシーをそのロールに添付します。このポリシーは、EC2 APIへの読み取り専用アクセスを許可します。
NGINX Plusインスタンスを起動するときに、このIAMロールをインスタンスに追加します。

ステップ2 – 統合ソフトウェア（nginx-asg-sync）を
インストールする

統合ソフトウェア(nginx-asg-sync)をインストールするには、オペレーティングシステム用のパッケージを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を設定する

統合ソフトウェア(nginx-asg-sync)は、オンザフライの再構成およびライブアクティビティモニタリング API を使用してNGINX Plusの設定を更新します。ソフトウェアが正常に動作するためには、これらのAPIを設定し、必要な上流グループを宣言する必要があります。

オンザフライでの再構成とライブアクティビティの監視のためのAPIエンドポイントを設定します。統合ソフトウェアは、これらのエンドポイントを使用して、上流グループからバックエンドインスタンスを追加および削除します。
upstream 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つの上流グループ（バックエンド1とバックエンド 2）を宣言しています。ただし、nginx-aws-syncによってサーバーが追加されるため、ここでは上流グループにサーバーを追加しません。このstateディレクティブは、動的に構成可能なサーバーのリストが格納されているファイルの名前を指定し、NGINX Plusの再起動後も運用を持続できるようにします。
serverポート80でリッスンする仮想サーバを定義します。ELBの例とは対照的に、NGINX Plusは/ backend-oneの リクエストをバックエンド1グループのインスタンスに直接渡し、/ backend-twoを直接2つのグループのバックエンドインスタンスににリクエストします。
2番目の仮想サーバーはポート8080でリッスンし、NGINX Plus APIを構成します。
- オンザフライAPIは、127.0.0.1：8080 / upstream_confにあります。
- status APIは127.0.0.1:8080/statusにあります

ステップ4 – 統合ソフトウェア（nginx-asg-sync）を設定する

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

region: us-west-2
upstream_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

このregionキーは、アプリケーションを配備するAWSリージョンを定義します。
upstream_conf_endpointそしてstatus_endpointキーはステップ3で設定されたnginxのプラスAPIエンドポイントで定義します。
このsync_interval_in_secondsキーは同期間隔を定義します。nginx-asg-syncは、5秒ごとに更新をスケーリングします。
このupstreamsキーは、上流グループのリストを定義します。
上流グループごとに以下を指定します。
- name – ステップ3のupstreamブロックで指定した名前。
- 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を持つリクエストをバックエンド1グループのインスタンスに配布し、/ backend-2 URIを使用してバックエンド2グループのインスタンスにリクエストします。

Auto Scalingグループの規模を拡大すると、NGINX Plusがどのように新しいインスタンスを取得するのかがわかります。まず、NGINX Plusインスタンスのポート8080の/status.htmlにあるライブアクティビティ監視ダッシュボードにアクセスします。[Upstream]タブでは、Auto Scalingグループのインスタンスが表示されます。

次に、Auto Scalingグループの容量を変更して、バックエンド1グループを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を設定する方法はどれですか？表は、2つを簡単に比較しています：

	ELBの前にNGINX Plusを配置して利用	NGINX Plusと統合ソフトウェアを利用
利点	シンプルな構成と追加のソフトウェアのインストールは不要です。	ELBメソッドによる制限なしで、すべてのNGINX Plus 機能が利用出来ます。
短所	サポートされているプロトコルを含め、使用できるNGINX Plusの機能の数を制限されます。ランニングコストと待ち時間が増加します。	統合ソフトウェアのインストールと構成が必要です。
概要	欠点が許容できる場合は、この方法を使用してください。	NGINX Plusの機能を最大限に活用するには、この方法を使用します。

概要

AWS Auto Scalingは、アプリケーションインスタンスの数をリクエストレベルに合わせて調整できるという利点があります。NGINX Plusは、AWS Auto Scalingグループと共に使用できる高度なロードバランシング機能を提供します。

AWS Auto ScalingグループでNGINX Plusを試してみてください。無料の30日間のトライアルを今すぐ開始するか、デモをご希望の場合はお問い合わせください。

NGINX Blog

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

サンプルAWSオートスケーリング環境

ELBの前でNGINX Plusを使用する