NGINX Plus R16リリースのお知らせ

Liam Crillyプロダクトマネジメント担当シニアディレクター

[ngx_snippet name=’table-style-blog’]
NGINX Plus Release 16（R16）の提供を開始しました。今回のリリースは、NGINXの技術ビジョンを推進するうえで、特に重要なリリースの1つです。R16により、NGINX Plusはすべてのアプリケーションに対応する、単一で柔軟に拡張可能なイングレス／エグレス層として機能するようになりました。これにより、ロードバランサー、APIゲートウェイ、WAFの機能を、あらゆるクラウドに展開できる単一のソフトウェアパッケージに統合できます。

現在、F5がお話を伺う多くの企業では、これらの各コンポーネントを導入していますが、多くの場合、ベンダーはそれぞれ異なります。そのため、運用チームは個々のポイントソリューションを別々に管理する必要があり、コストと複雑さが増大します。また、ホップが増えるたびに遅延や障害点も増えるため、パフォーマンスと信頼性も低下します。

NGINX Plus R16の新機能により、インフラストラクチャの統合と簡素化に着手し、レガシーアプリケーションとモダンアプリケーションの両方に対応する、柔軟に拡張可能なイングレス／エグレス層の構築を進められます。NGINX Plus R16には、新しいクラスタリング機能、強化されたUDPロードバランシング、DDoS緩和機能が搭載されており、高価なF5 BIG-IPハードウェアやその他のロードバランシングインフラストラクチャを、より包括的に置き換えられます。また、グローバルレート制限への新たな対応により、NGINX Plusは多くのAPIゲートウェイソリューションに代わる軽量な選択肢となります。さらに、Random with Two Choicesロードバランシングへの新たな対応により、NGINX PlusはKubernetesなどのスケールアウト環境や分散環境で、マイクロサービスのトラフィックをロードバランシングするための最適な選択肢となります。

NGINX Plus R16の新機能の概要

NGINX Plus R16の新機能は次のとおりです。

• クラスター対応のレート制限 – NGINX Plus R15では、状態共有モジュールを導入し、NGINX Plusクラスター全体でデータを同期できるようにしました。本リリースでは、状態共有をレート制限機能にも拡張し、NGINX Plusクラスター全体に適用するグローバルレート制限を指定できるようになりました。グローバルレート制限はAPIゲートウェイにとって重要な機能であり、NGINX Plusで特に広く利用されているユースケースです。
• クラスター対応のキーバリューストア – NGINX Plus R13では、キーバリューストアを導入しました。これは、たとえば動的なIPアドレス拒否リストの作成やHTTPリダイレクトの管理に使用できます。このリリースでは、キーバリューストアをクラスター全体で同期できるようになり、新たにtimeoutパラメーターが追加されたため、個々のキーバリューペアを自動的に削除できます。新しい同期機能により、キーバリューストアを動的なDDoS緩和、認証済みセッショントークンの配布、分散コンテンツキャッシュ（CDN）の構築に使用できるようになりました。
• Random with Two Choicesロードバランシング – ロードバランサーをクラスタ化する場合、個々のバックエンドサーバーに意図せず過剰な負荷をかけないロードバランシングアルゴリズムを使用することが重要です。Random with Two Choicesロードバランシングは、スケールアウトしたクラスターで極めて高い効率を発揮し、NGINX Ingress Controller for Kubernetesの次期リリースではデフォルトの方式となる予定です。
• UDPロードバランシングの強化 – NGINX Plus R9で、UDPロードバランシングを初めて導入しました。この初期実装は、サーバーとのやり取りごとにクライアントから単一のUDPパケットを受信することを前提としたUDPアプリケーション（DNSやRADIUSなど）に限定されていました。NGINX Plus R16では、クライアントからの複数のUDPパケットを処理できるため、OpenVPN、Voice over IP（VoIP）、仮想デスクトップインフラストラクチャ（VDI）など、より複雑なUDPプロトコルをサポートできます。
• AWS PrivateLinkのサポート – AWS PrivateLinkは、Virtual Private CloudへのセキュアなVPNトンネルを構築するためのAmazonのテクノロジーです。このリリースでは、AWS PrivateLinkデータセンター内のトラフィックについて、認証、ルーティング、負荷分散、フローの最適化が可能になりました。この機能は、新たにサポートされたPROXY protocol v2を基盤としています。

その他の機能強化には、OpenID Connectの不透明セッショントークンのサポート、Encrypted Session動的モジュール、NGINX JavaScriptモジュールのアップデートなどが含まれます。NGINX Plus R16はNGINX Open Source 1.15.2をベースとしており、オープンソースリリースの全機能を搭載しています。

NGINX Plus R16の開発中には、大幅な機能強化も複数実施し、NGINX Plusの主要なユースケースである公式のNGINX Ingress Controller for Kubernetesに追加しました。

NGINX Plus R16をはじめ、NGINXに関するあらゆる情報をNGINX Conf 2018でご紹介します。新機能を詳しく解説する専用セッションやデモを実施し、エキスパートも会場でご質問にお答えします。

動作に関する重要な変更

• 統合されたNGINX Plus APIに置き換えられ、非推奨となっていたUpstream Conf APIとStatus APIは削除されました。2017年8月、NGINX Plus R13では、アップストリームグループの動的な再構成とメトリクスの監視に対応する、まったく新しいNGINX Plus APIが導入され、それまでこれらの機能を実装していたUpstream Conf APIとStatus APIに置き換わりました。当時お知らせしたとおり、非推奨となったAPIはその後も長期間にわたり利用可能で、サポートも継続されていましたが、その期間は終了しました。構成にupstream_confディレクティブまたはstatusディレクティブ、あるいはその両方が含まれている場合は、R16へのアップグレード時に、これらをapiディレクティブに置き換える必要があります。新しいNGINX Plus APIへの移行に関するガイダンスやサポートについては、F5のブログに掲載されている移行ガイドをご覧いただくか、サポートチームにお問い合わせください。
• サポート終了OSバージョンのサポートを終了 – Ubuntu 17.10 (Artful)、FreeBSD 10.3、FreeBSD 11.0では、NGINX Plusはサポートされなくなりました。サポート対象プラットフォームの詳細については、NGINX Plusおよびダイナミックモジュールの技術仕様をご覧ください。
• The NGINX New Relicプラグインが更新されました。新しいNGINX Plus APIを使用するようになり、現在はオープンソースプロジェクトとして公開されています。更新されたプラグインはR13以降のすべてのバージョンのNGINX Plusで動作しますが、NGINX, Inc.によるサポートおよびメンテナンスは終了しています。

新機能の詳細

クラスター対応のレート制限

NGINX Plus R15では、クラスター内のすべてのNGINX Plusノード間で実行時の状態を共有できるzone_syncモジュールが導入されました。

最初に同期された機能は、sticky‑learnセッション維持です。NGINX Plus R16では、状態共有がレート制限機能にも拡張されました。クラスターに導入すると、リクエストがクラスター内のどのメンバーノードに到達したかにかかわらず、NGINX Plusは受信リクエストに一貫したレート制限を適用できるようになりました。一般に「グローバルレート制限」と呼ばれる、クラスター全体への一貫したレート制限の適用は、APIゲートウェイのユースケースで特に重要です。クライアントが指定されたレート制限を超えないようにしながら、サービスレベル契約（SLA）に従ってAPIを提供できます。

NGINX Plusの状態共有では、プライマリノードは必要なく、使用もしません。すべてのノードが対等なピアとして、フルメッシュトポロジーでデータを交換します。NGINX Plusの状態共有クラスターは、次の3つの要件を満たす必要があります。

• すべてのクラスターノード間のネットワーク接続
• 同期されたクロック
• 次のスニペットのように、すべてのノードでzone_syncモジュールを有効にする設定

stream {    resolver 10.0.0.53 valid=20s;

    server {
        listen 10.0.0.1:9000;
        zone_sync;
        zone_sync_server nginx-cluster.example.com:9000 resolve;
    }
}

The zone_sync directive enables synchronization of shared memory zones in a cluster. The zone_sync_server directive identifies the other NGINX Plus instances in the cluster. NGINX Plus supports DNS service discovery so cluster nodes can be identified by hostname, making the configuration identical on all nodes. Note that this is a minimal configuration, without the necessary security controls for production deployment. For more details, see the NGINX Plus R15 announcement and the reference documentation for the zone_sync module.

この設定をすべてのノードに適用した後は、新しいsyncパラメーターをlimit_req_zoneディレクティブに追加するだけで、クラスター全体にレート制限を適用できます。以下の設定では、クライアントのIPアドレスに基づき、NGINX Plusが各クライアントに対して1秒あたり100リクエストのレート制限を適用します。

limit_req_zone $remote_addr zone=per_ip:1M rate=100r/s sync; # Cluster-aware
server {
    listen 80;
    location / {
        limit_req zone=per_ip; # Apply rate limit here
        proxy_pass http://my_backend;
    }
}

さらに、状態共有クラスタリングソリューションは、ネットワークのレジリエンスを確保するためのkeepalivedベースの高可用性ソリューションとは独立しています。そのため、この高可用性ソリューションとは異なり、状態共有クラスターは複数の物理拠点にまたがって構成できます。

クラスター対応キーバリューストア

NGINX Plus R13では、軽量なインメモリキーバリューストアがネイティブNGINXモジュールとして導入されました。このモジュールはNGINX Plusに同梱されているため、シンプルなデータベースストレージを必要とするソリューションを、追加のソフトウェアコンポーネントをインストールせずに構成できます。さらに、キーバリューストアはNGINX Plus APIを介して制御されるため、RESTインターフェースからエントリを作成、変更、削除できます。

NGINX Plusのキーバリューストアのユースケースには、動的なIPアドレスの拒否リスト登録、動的な帯域幅制限、認証トークンのキャッシュなどがあります。

NGINX Plus R16では、キー・バリューストアがクラスターに対応し、エントリがクラスター内のすべてのノード間で同期されるようになりました。これにより、NGINX Plusのキー・バリューストアを使用するソリューションを、アクティブ／パッシブ、アクティブ／アクティブ、広域分散など、あらゆる種類のクラスター環境に導入できます。

他のクラスター対応機能と同様に、状態共有用に（syncパラメーターをkeyval_zoneディレクティブに追加するだけで、キーバリューストアの同期を設定できます。対象となるのは、zone_syncディレクティブとzone_sync_serverディレクティブを使用して）すでに構成されているクラスターです。

キー・バリュー・ストアに追加する各キー・バリュー・ペアにタイムアウト値を設定できるよう、機能も拡張されました。このようなエントリは、指定したタイムアウト期間が経過すると自動的に期限切れとなり、キー・バリュー・ストアから削除されます。同期されたキー・バリュー・ストアを構成する場合、timeoutパラメーターは必須です。

動的DDoS防御にNGINX Plusのキー・バリューストアを使用

NGINX Plusの新しいクラスタリング機能を組み合わせることで、DDoS攻撃から保護する高度なソリューションを構築できます。NGINX Plusインスタンスのプールをアクティブ／アクティブクラスターとして展開する場合や、広域ネットワーク全体に分散して配置する場合、悪意のあるトラフィックはいずれのインスタンスにも到達する可能性があります。このソリューションでは、同期されたレート制限とキーバリューストアを使用し、以下のようにDDoS攻撃へ動的に対応して、その影響を軽減します。

• クラスター対応のレート制限により、どのNGINX Plusノードがリクエストを受信したかにかかわらず、1秒あたり100件を超えるリクエストを送信するクライアントを検出します。
• クライアントがレート制限を超えると、NGINX Plus APIの呼び出しによって、そのIPアドレスが「sin bin」キーバリューストアに追加されます。sin binはクラスター全体で同期されます。
• 「sin bin」に登録されたクライアントからの以降のリクエストには、どのNGINX Plusノードが受信したかにかかわらず、非常に低い帯域幅制限が適用されます。帯域幅を制限しても、DDoS緩和策が実施されていることがクライアントに明確に伝わらないため、リクエストを即座に拒否するよりも適しています。
• 10分後、クライアントは自動的にsin binから削除されます。

以下の設定は、この動的DDoS緩和ソリューションを簡略化して実装した例です。

limit_req_zone   $remote_addr zone=per_ip:1M rate=100r/s sync; # Cluster-aware rate limitlimit_req_status 429;

keyval_zone zone=sinbin:1M timeout=600 sync; # Cluster-aware "sin bin" with 
                                             # 10-minute TTL
keyval $remote_addr $in_sinbin zone=sinbin;  # Populate $in_sinbin with 
                                             # matched client IP addresses

server {
    listen 80;
    location / {
        if ($in_sinbin) {
            set $limit_rate 50; # Restrict bandwidth of bad clients
        }

        limit_req zone=per_ip;            # Apply the rate limit here
        error_page 429 = @send_to_sinbin; # Excessive clients are moved to 
                                          # this location
        proxy_pass http://my_backend;
    }

    location @send_to_sinbin {
        rewrite ^ /api/3/http/keyvals/sinbin break; # Set the URI of the 
                                                    # "sin bin" key-val
        proxy_method POST;
        proxy_set_body '{"$remote_addr":"1"}';
        proxy_pass http://127.0.0.1:80;
    }

    location /api/ {
        api write=on;
        # directives to control access to the API
    }
}

2つの選択肢によるランダム負荷分散

アプリケーション配信環境とAPI配信環境のいずれにおいても、スケールアウトまたは分散されたロードバランシング層でクライアントリクエストを受信し、共有アプリケーション環境に転送する構成が一般的になりつつあります。複数のロードバランサーが同じバックエンドサーバー群にリクエストを転送する場合は、個々のバックエンドサーバーに意図せず負荷が集中しないロードバランシング方式を使用することが重要です。

アクティブ／アクティブ構成でデプロイされたNGINX Plusクラスターや、複数のエントリーポイントを持つ分散環境は、一般的なシナリオです。このような環境では、各ロードバランサーがバックエンドサーバーに送信されたすべてのリクエストを完全には把握できないため、従来の負荷分散方式では対応が難しくなる場合があります。

コンテナ化されたクラスター内の負荷分散には、スケールアウトされたアクティブ／アクティブ構成のデプロイと同じ特性があります。Ingressリソースの複数のインスタンスを含むレプリカセットにデプロイされたKubernetes Ingressコントローラーも、クラスター内の各サービスを提供するPodに負荷を効果的に分散するという課題に直面します。

Random with Two Choicesロードバランシングのメリットを活用できるクラスタートポロジー

ワークロードのばらつきは、分散ロードバランシングの有効性に大きく影響します。各リクエストがバックエンドサーバーに同じ負荷をかける場合、各サーバーが過去のリクエストにどれだけ迅速に応答したかを測定することは、次のリクエストの送信先を決定するうえで効果的です。NGINX Plus独自のLeast Timeロードバランシング方式は、まさにこの方法で送信先を決定します。しかし、バックエンドサーバーにかかる負荷が変動する場合（たとえば、読み取り操作と書き込み操作の両方が含まれる場合）、過去のパフォーマンスは将来のパフォーマンスを予測する指標としては不十分です。

分散環境で負荷を分散する最も簡単な方法は、バックエンドサーバーをランダムに選択することです。時間の経過とともに負荷は平均化されますが、これは大まかな手法であり、個々のサーバーにトラフィックが一時的に集中する可能性があります。

ランダム負荷分散を少し応用したシンプルな方法でありながら、負荷分散の改善効果が実証されているのが、2台のバックエンドサーバーをランダムに選び、負荷が低い方にリクエストを送信する方法です。ランダムに選んだ2台を比較する目的は、最適な判断でなくても、不適切な負荷分散を避けることにあります。負荷が高い方のバックエンドサーバーを避けることで、各ロードバランサーは独立して動作しながら、個々のバックエンドサーバーへのトラフィックの急増を回避できます。その結果、この方法では、ランダム負荷分散の利点と計算効率を維持しつつ、負荷を明らかにより適切に分散できます。

NGINX Plus R16では、RandomとRandom with Two Choicesという2つの新しい負荷分散方式が導入されています。後者では、選択された2つのバックエンドのどちらにリクエストを送信するかを決定するために、NGINX Plusが比較する負荷指標を指定することもできます。次の表に、使用可能な指標を示します。

* 時間ベースのメトリクスはすべてNGINX Plusでのみ利用できます

次のスニペットは、random twoディレクティブを使用したRandom with Two Choicesロードバランシング設定の簡単な例です（HTTP、Stream）。

upstream my_backend {    zone my_backend 64k;
    server 10.0.0.1;
    server 10.0.0.2;
    server 10.0.0.3;
    #...
    random two least_time=last_byte; # Choose the quicker response time from two random choices
}

server {
    listen 80;
    location / {
        proxy_pass http://my_backend; # Load balance to upstream group
    }
}

Random with Two Choices方式は、複数のロードバランサーが同じバックエンド群にリクエストを転送する分散環境にのみ適している点に注意してください。NGINX Plusを単一ホストにデプロイする場合や、アクティブ／パッシブ構成でデプロイする場合は使用しないでください。このような場合、単一のロードバランサーですべてのリクエストを把握できるため、Round Robin、Least Connections、Least Timeの各方式が最適な結果をもたらします。

強化されたUDPロードバランシング

NGINX Plus R9では、UDPトラフィックのプロキシ処理と負荷分散がサポートされ、DNS、syslog、NTP、RADIUSなどの一般的なUDPアプリケーションの前段にNGINX Plusを配置して、アプリケーションサーバーの高可用性とスケーラビリティを実現できるようになりました。初期実装の対象は、サーバーとのやり取りごとにクライアントから単一のUDPパケットを受信するUDPアプリケーションに限定されていました。

NGINX Plus R16では、複数の受信パケットがサポートされるため、より複雑なUDPアプリケーションのプロキシ処理と負荷分散が可能です。これには、OpenVPN、VoIP、仮想デスクトップソリューション、Datagram Transport Layer Security（DTLS）セッションが含まれます。さらに、単純か複雑かを問わず、あらゆるUDPアプリケーションに対するNGINX Plusの処理も大幅に高速化されています。

NGINX Plusは、広く利用されている4つのWebプロトコル（UDP、TCP、HTTP、HTTP/2）を、同一インスタンス上で同時に負荷分散できる唯一のソフトウェアロードバランサーです。

PROXY Protocol v2のサポート

NGINX Plus R16では、PROXY protocol v2（PPv2）ヘッダーのサポートと、ヘッダー内のカスタムtype-length-value（TLV）値を検査する機能が追加されました。

PROXYプロトコルは、NGINX PlusやAmazonのロードバランサーなどのレイヤー7プロキシが、別のレイヤー7プロキシ群またはNATデバイスの背後にあるアップストリームサーバーへ接続情報を伝達するために使用されます。プロキシが接続を中継すると、送信元IPアドレスやポートなどの接続情報が失われる場合があり、また、この情報の伝達にHTTPヘッダーの挿入を常に利用できるとは限らないため、PROXYプロトコルが必要です。以前のバージョンのNGINX PlusはPPv1ヘッダーをサポートしていましたが、NGINX Plus R16ではPPv2ヘッダーのサポートが追加されました。

Amazon Network Load BalancerでのPPv2の使用

PPv2ヘッダーのユースケースの1つに、Amazon Network Load Balancer（NLB）によって中継される接続があります。この接続は、ロードバランサー上のプライベートIPアドレスから発信されたように見える場合があります。NLBは各接続の先頭に、クライアント接続の実際の送信元IPアドレスとポートを識別するPPv2ヘッダーを付加します。実際の送信元は、$proxy_protocol_addr変数から取得できます。また、realipモジュールを使用して、NGINXの内部送信元変数を上書きし、PPv2ヘッダーの値に置き換えることができます。

AWS PrivateLinkでのPPv2の使用

AWS PrivateLinkは、Virtual Private Cloud（VPC）へのセキュアなVPNトンネルを作成するためのAmazonのテクノロジーです。一般に、Provider VPCで稼働するプロバイダーサービスを公開し、1つ以上のClient VPCから利用できるようにするために使用されます。プロバイダーサービスへの接続は、Provider VPCで稼働するNLBから開始されます。

多くの場合、プロバイダーサービスは各接続の接続元を把握する必要があります。しかし、PPv2ヘッダー内の送信元IPアドレスはクライアントVPC内のルーティング不能な内部アドレスに対応しているため、実質的に意味がありません。AWS PrivateLink NLBは、PPv2 TLVレコード送信元VPC IDを使用してヘッダーに0xEAを追加します。

NGINX PlusはPPv2 TLVレコードを検査し、$proxy_protocol_tlv_0xEA変数を使用してAWS PrivateLink接続の送信元VPC IDを抽出できます。これにより、AWS PrivateLinkデータセンター内のトラフィックを認証、ルーティング、制御できます。

NGINX Plus R16のその他の新機能

OpenID Connectの不透明なセッショントークン

The NGINX Plus OpenID Connectリファレンス実装が拡張され、不透明なセッショントークンをサポートするようになりました。このユースケースでは、JWT IDトークンはクライアントに送信されません。代わりにNGINX Plusのキーバリューストアに保存され、ランダムな文字列がクライアントに送信されます。クライアントがこのランダムな文字列を提示すると、JWTに交換され、検証されます。キーバリューストアのエントリにタイムアウト値を設定し、クラスター全体で同期できるようになったため、このユースケースはプロトタイプ／実験段階から本番環境対応へとアップグレードされました。

暗号化セッション動的モジュール

The Encrypted Sessionコミュニティモジュールは、MAC付きAES‑256に基づくNGINX変数の暗号化と復号をサポートします。現在、NGINX Plusリポジトリで、サポート対象のNGINX Plus用ダイナミックモジュールとして提供されています。

NGINX JavaScriptモジュールの機能強化

R16のNGINX JavaScriptモジュールでは、JavaScript言語のサポート範囲がさまざまな面で拡張されています。HTTP JavaScriptモジュールが簡素化され、各リクエストに関連付けられたリクエスト属性とレスポンス属性の両方に、単一のオブジェクト（r）からアクセスできるようになりました。以前は、リクエスト（req）オブジェクトとレスポンス（res）オブジェクトが別々に存在していました。この簡素化により、HTTP JavaScriptモジュールは、単一のセッション（s）オブジェクトを使用するStream JavaScriptモジュールと一貫した仕様になります。この変更には完全な後方互換性があり、既存のJavaScriptコードはそのまま動作します。ただし、この簡素化を活用できるように既存のJavaScriptコードを変更し、今後作成するコードでもこの方式を使用することを推奨します。

JavaScript言語のサポートに、以下が追加されました。

• 文字列メソッド：bytesFrom()、padStart()、padEnd()
• 追加のメソッド：getrandom()、getentropy()
• 2進数リテラル

JavaScriptモジュールの変更点の全一覧については、変更履歴をご覧ください。

新しい「$ssl_preread_protocol」変数

新しい「$ssl_preread_protocol」変数を使用すると、TCP（ストリーム）プロキシでトラフィックを転送する際に、SSL/TLSとその他のプロトコルを区別できます。この変数には、クライアントがサポートする最上位のSSL/TLSプロトコルバージョンが格納されます。これは、たとえばSSL/TLSサービスとSSHサービスを同じポートで実行して、ファイアウォールの制限を回避する場合に役立ちます。

詳細については、F5のブログ記事「同一ポートでのSSLプロトコルと非SSLプロトコルの実行」をご覧ください。

Kubernetes Ingress Controllerの機能強化

NGINX Plusは幅広い環境でトラフィックを管理できます。重要なユースケースの1つは、Kubernetes向けIngressロードバランサーとしての利用です。NGINXは、NGINX Plusを自動的に構成するIngressコントローラーソリューションを開発しており、この統合はすべてのNGINX Plusサブスクライバーを対象にフルサポートされています。（すべてのNGINX Open SourceユーザーとNGINX Plusのお客さまは、GitHubでオープンソース実装を確認できます。また、正式リリースも定期的に提供されます。）

NGINX Plusは、KubernetesトラフィックのSSL終端、ルーティング、負荷分散を実行できます

NGINX Plus R16の開発において、公式のNGINX Ingress Controller for Kubernetesに重要な機能強化が複数追加されました。

• Prometheusのサポートにより、ユーザーはNGINXおよびNGINX PlusのメトリクスをKubernetes上のPrometheusに直接エクスポートできます。
• Helmチャートのサポートにより、Ingressコントローラーのインストールと管理が簡素化されます。
• gRPCトラフィックの負荷分散をサポートすることで、gPRCベースのアプリケーションの高可用性とスケーラビリティを実現します。（リリース1.2.0で追加）
• Kubernetes Podのアクティブヘルスチェックにより、Podの障害やネットワーク接続の障害を迅速に検出できます。
• マルチテナント対応のマージ可能な構成により、関心事を分離できます。運用部門がフロントエンドリスナーとSSL構成を引き続き管理しながら、各チームは同じWebアプリケーションの異なるパスを個別に管理できます。
• きめ細かなJWT認証により、パス単位でリッチアプリケーションの認証をより詳細に制御できます。
• 構成テンプレートの直接管理により、NGINX構成に対するカスタム変更の開発とテストが大幅に容易になります。

NGINX Ingress Controllerは、ConfigMaps（NGINX構成を埋め込むため）を使用するか、ベーステンプレートを編集することでさらに拡張できます。これにより、Kubernetes上で実行されるアプリケーションのトラフィック管理ポリシーを作成する際に、NGINXのすべての機能を利用できます。

詳細については、ブログ記事「NGINX Ingress Controller for Kubernetes Release 1.3.0の発表」をご覧ください。

NGINX Plusへのアップグレードまたはお試し

NGINX Plus R16には、クラスタリング機能の追加、グローバルレート制限、新しい負荷分散アルゴリズム、および複数のバグ修正が含まれています。NGINX Plusをご利用の場合は、できるだけ早くR16へアップグレードすることを強く推奨します。これにより、複数の修正と改善が適用されるほか、サポートチケットを起票する必要が生じた際に、NGINX, Inc.がより円滑にサポートできるようになります。

アップグレードを実行する前に、このブログ記事で説明している新機能と「動作の変更点」をよくご確認ください。

まだNGINX Plusをお試しでない場合は、ぜひご利用ください。Webアクセラレーション、負荷分散、アプリケーションデリバリーに加え、強化された監視・管理APIを備え、充実したサポートを受けられるWebサーバーとしても活用できます。今すぐ30日間の無料トライアルを開始できます。NGINX Plusがアプリケーションのデリバリーとスケーリングにどのように役立つか、ぜひお確かめください。

著者について

Liam Crillyプロダクトマネジメント担当シニアディレクター

Liam Crillyのその他のブログ記事