NGINX PlusによるAWS Auto Scalingグループの負荷分散

Michael Pleshakov

クラウドの特に有用な機能の1つは、コンピューティングインスタンスの数を自動的にスケーリングできることです。AWS Auto Scalingを使用すると、Auto Scaling group内のEC2インスタンス数を、スケジュールや需要に応じて手動または自動で変更できます。Auto Scalingは、現在のワークロードに適した数にインスタンス数を調整することで、コスト削減に役立ちます。また、障害が発生したインスタンスを再起動するため、アプリケーションのレジリエンスが向上します。

Auto Scalingを使用する際、負荷分散は極めて重要です。AWSは、内蔵のロードバランサー（現在の正式名称がClassic Load BalancerであるElastic Load Balancer（ELB）と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サブスクリプションをF5から直接購入する場合も、AWS Marketplaceで構築済みのNGINX Plusインスタンスを実行する場合も同様です。後者には、所定の時間単価で料金が発生します。
3. NGINX Plusはプラットフォーム固有のAPIに依存しないため、複数のクラウドプラットフォームで負荷分散設定を再利用できます。

NGINX PlusとAWSの組み込みソリューションの比較、および両者の連携方法については、以下のブログ記事をご覧ください：ELB、ALB。

このブログ記事では、NGINX PlusでAuto Scalingグループの負荷分散を構成する2つの方法と、それぞれの方法が適しているケースについて説明します。

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

このブログ記事を読むことで、Auto Scalingグループに高度な負荷分散を提供するために、AWS上へNGINX Plusをデプロイする準備が整います。

AWS Auto Scaling環境のサンプル

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

• Requests for /backend‑oneへのリクエストはBackend Oneに送信されます。
• リクエストの送信先：/backend‑two はBackend Twoです。

アプリケーションのAuto Scalingグループを自動または手動でスケーリングする場合、アプリケーションインスタンス数の変更を反映するために、ロードバランサーの設定を更新する必要があります。AWSの組み込みロードバランサーでは、この更新が自動的に行われます。NGINX Plusでは、前述のいずれかの方法（ELBの前段にNGINX Plusを配置する方法、またはNGINX Plusと統合ソフトウェアを使用する方法）で、スケーリングイベントを設定に反映させる必要があります。

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

ELBの前段でNGINX Plusを使用

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

この場合、NGINX Plusは1つ以上のELBに対するプロキシ兼ロードバランサーとして機能します。NGINX Plusは高度なルーティング機能を使用し、リクエストURIに基づいて適切なELBにリクエストを転送します。次に、ELBはAuto Scalingグループ内のいずれかのインスタンスにリクエストを渡します。この構成では、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;
    }
}

• The resolverディレクティブでは、NGINX Plusが内部ELBインスタンスのDNS名を解決する際に使用するDNSサーバーを定義します。ここでは、AWS DNSサーバーのIPアドレスを指定しています。
• サービスであるBackend OneとBackend Twoに対応するAuto Scalingグループごとに、2つの「upstream」ブロックを作成します。各Auto Scalingグループは、そのグループへのトラフィックを負荷分散するELBのDNS名で識別します。「resolve」パラメーターを使用して、NGINX Plusがこの名前を定期的に再解決するように指定します。再解決の頻度は、前の箇条書きで説明した「valid」パラメーターで「resolver」ディレクティブに設定します。ELBのIPアドレスは頻繁に変更される可能性があるため、ここでは10秒に設定します。「zone」ディレクティブは、解決されたIPアドレスを保存するためのメモリ（ここでは最大64 KB）を割り当てます。
• ポート80でリッスンする仮想serverを定義します。locationブロックでは、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グループに対してupstreamブロックを作成します。スケーリングイベントに応じて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でリッスンする仮想serverを定義します。ELBの例とは異なり、NGINX Plusは/backend‑oneへのリクエストをBackend Oneグループのインスタンスに直接渡し、/backend‑twoへのリクエストをBackend Twoグループのインスタンスに直接渡します。
• ポート8080でリッスンする2つ目の仮想サーバーを定義し、そのサーバーにNGINX Plus APIを設定します。
  • on-the-fly APIは次のアドレスで利用できます。127.0.0.1:8080/upstream_conf
  • ステータスAPIは次のアドレスで利用できます：127.0.0.1:8080/status

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

統合ソフトウェアは、aws.yamlファイル（/etc/nginxフォルダー内）で設定します。このアプリケーションでは、次のように設定します。

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リージョンは、regionキーで定義します。
• The upstream_conf_endpointキーとstatus_endpointキーでは、ステップ3で設定したNGINX Plus APIエンドポイントを定義します。
• The sync_interval_in_secondsキーでは同期間隔を定義します。nginx-asg-syncは5秒ごとにスケーリングの更新を確認します。
• The upstreamsキーでは、アップストリームグループのリストを定義します。各アップストリームグループには、以下を指定します。
  • name – 手順3でupstreamブロックに指定した名前。
  • autoscaling_group – 対応するAuto Scalingグループの名前。
  • port – バックエンドサービスを公開するポート。
  • kind – NGINX Plusがバックエンドアプリケーションに負荷分散するトラフィックのプロトコルです。ここではhttpです。アプリケーションがTCP/UDPを使用する場合は、代わりにstreamを指定します。

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

$ sudo restart nginx-asg-sync

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

上記の手順では、アプリケーションのAuto Scalingグループを負荷分散するようにNGINX Plusを設定しました。これでテストできます。NGINX Plusは、URIが「/backend‑one」のリクエストをBackend Oneグループのインスタンスに、URIが「/backend‑two」のリクエストを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を構成するには、どちらの方法が適しているのでしょうか。次の表で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日間の無料トライアルを開始するか、ユースケースについてお問い合わせください。

著者について

Michael Pleshakov

Michael Pleshakovのその他のブログ記事