NGINX で Azure アプリのパフォーマンスとセキュリティを向上

NGINXaaS for Azure を使用すると、企業はクラウドで高性能なapplicationsを安全に提供できます。 NGINX Plus を搭載した、2023 年 1 月に一般提供が開始されたフルマネージド サービスです。 リリース以来、そして今後も、新機能を追加することで、NGINXaaS for Azure を強化し続けます。

このブログでは、独自の NGINX Plus インスタンスを展開、保守、更新することなく、NGINX Plus のメリットをさらに享受できる最新のパフォーマンスとセキュリティ機能の一部を紹介します。 NGINXaaS for Azure とその包括的な機能に関する一般的な情報については、 「F5 NGINXaaS for Azure によるクラウド移行の簡素化と加速」をお読みください。

図1: Azure 向け NGINXaaS の概要

mTLS によるアップストリーム トラフィックの保護

リバース プロキシでは、パブリック インターネット上のクライアント側トラフィックを暗号化するために SSL/TLS が必要ですが、サーバー側で認証して機密性を確保するには相互 TLS (mTLS) が不可欠になります。 ゼロトラストへの移行に伴い、上流のサーバートラフィックが変更または傍受されていないことを確認することも必要になります。

図 2: NGINXaaS を使用した mTLS

NGINXaaS for Azure は、SSL/TLS 証明書を使用してアップストリーム トラフィックを保護するNGINX ディレクティブをサポートするようになりました。 これらのディレクティブを使用すると、アップストリーム トラフィックを mTLS 経由で暗号化したままにできるだけでなく、アップストリーム サーバーが信頼できる証明機関からの有効な証明書を提示していることを確認することもできます。

証明書のローテーション

NGINXaaS for Azure で TLS 証明書を使用する際の重要な部分 (しゃれを意図しています) は、Azure Key Vault (AKV)を使用してそれらの証明書を安全に管理することです。 AKV は機密性の高い暗号化マテリアルを安全に保ち、Azure ポータルを通じてキー マテリアルが誤ってまたは意図的に公開されるのを防ぎながら、NGINXaaS for Azure がそれらの証明書を使用できるようにします。

図3: Azure Key Vault を使用した証明書のローテーション

NGINXaaS for Azure では、AKV で証明書が更新されるたびに、NGINX デプロイメントを通じて証明書を自動的にローテーションできるようになりました。新しいバージョンの証明書は、4 時間以内にデプロイメントにローテーションされます。

HTTP/2 プロキシ (および追加のプロトコル オプション)

目を閉じて 1997 年を思い出してください。 私たちは、JNCO ジーンズ (カナダの皆さんには Modrobes を着せてあげてください) を着て、Chumbawamba と一緒に Tubthumping をしていたのですが、HTTP/1.1 がリリースされました。 当時、ほとんどのエンドユーザーはダイヤルアップモデム経由でインターネットにアクセスし、Web ページには数十個の要素しか含まれておらず、ユーザーエクスペリエンスに関しては、遅延よりも帯域幅の方がはるかに大きな懸念事項でした。

25 年経った今でも、Webapplicationsのかなりの部分は、コンテンツを配信するために HTTP/1.1 を使用しています。 これは問題になる可能性があります。 HTTP/1.1 は引き続き機能しますが、一度に 1 つの接続につき 1 つのリソースしか配信できません。 一方、最新の Web アプリでは、ユーザー インターフェイスを更新するために何百ものリクエストが行われる場合があります。

ほとんどのユーザーは、かなり広い帯域幅を自由に使えるようになっていますが、データ転送速度（光の基本速度によって制限される）はそれほど速く進歩していません。 したがって、これらすべてのリクエストの累積的なレイテンシは、applicationの認識されるパフォーマンスに大きな影響を与える可能性があります。 最新のブラウザは同じサーバーに対して複数の TCP 接続を開きますが、それらの接続上の各リクエストは依然として連続的であるため、1 つの遅いリソースが、その背後にある他のすべてのリソースを遅延させる可能性があります。

HTTP/1.1 のみを使用して読み込まれた F5 のホームページを見てみましょう。

図4: F5.com は HTTP/1.1 経由でアクセスされます

灰色のバーが見えますか? これは、セッションの確立を待ったり、単一の低速リソースをブロックしたり、新しい TCP 接続が利用可能になるのを探したりする際に、ブラウザが無駄にしている貴重な時間です。

HTTP/2 を有効にしてもう一度試してみましょう。

図5: 同じリクエストですが、HTTP/2 を使用しています

ずっと良くなりました。 まだ遅いリソースがいくつかありますが、他のリクエストを遅らせることはなく、キュー関連の遅延を待つ時間が大幅に短縮されています。 HTTP/2 は、Web ブラウザーとサーバーが HTTP/1.1 から使い慣れているのと同じセマンティクスを維持しながら、applicationパフォーマンスが低いと感じられるいくつかの理由に対処するための新しい機能 (リクエストの優先順位付け、ヘッダーの圧縮、リクエストの多重化など) を追加しています。

このような明確な違いを考慮して、NGINXaaS for Azure では、 HTTP/2経由でのクライアント要求の処理がサポートされるようになりました。 クライアント側の接続はラウンドトリップ時間が長くなると影響を受ける可能性が高くなるため、アップストリーム サーバーを変更せずに、HTTP/2 のレイテンシ削減の利点を活用してトラフィックを配信できます。

Webapplication業界の一部の人々が信じたがっているかもしれないことに反して、HTTP 以外にも利用可能なプロトコル オプションがあることを私たちは認識しています。 このため、NGINX gRPC モジュールも Azure 用の NGINXaaS で利用できるようになりました。 エラーインターセプト、ヘッダー操作など、gRPC トラフィックを操作するためのいくつかの構成ディレクティブを提供します。

非 HTTP/gRPC トラフィックの場合、ストリーム モジュールがAzure 用の NGINXaaS で利用できるようになりました。 このモジュールは、TCP および UDP トラフィックのプロキシと負荷分散をサポートします。

レイヤー4およびレイヤー7の負荷分散のサポート

NGINXaaS for Azure は、レイヤー 4 TCP/UDP とレイヤー 7 HTTP/HTTP の両方のクラウド ネイティブ ロード バランサーとして機能できるようになりました。 なぜこれが重要なのでしょうか? NGINXaaS for Azure を使用すると、2 つの異なるサービスまたはロード バランサーをデプロイする代わりに、単一のロード バランサーをデプロイし、両方のレイヤーで同時に機能するように構成できるため、クラウド アーキテクチャが簡素化され、コストが削減されます。

設定については、こちらで確認できます。

大容量（最大 160 NCU）

NGINXaaS for Azure は、時間単位で計測され、 NGINX 容量ユニット (NCU)で毎月課金される消費ベースのサービスです。 最近、導入能力が 80 NCU から 160 NCU に倍増しました。 顧客は 20 個の NCU の小規模なシステムを導入し、ワークロードが増加した場合は最大 160 個の NCU まで拡張できます。 さらに、顧客は開始時に最大 160 個の NCU を導入するオプションも利用できます。

NGINX Plus ディレクティブの追加

オンプレミスから完全に管理されたクラウド サービスへの簡単なリフト アンド シフト構成エクスペリエンスを提供するために、多くの NGINX Plus ディレクティブを追加しました。 NGINXaaS for Azure でサポートされているすべての NGINX Plus ディレクティブについては、こちらを参照してください。

今すぐ始めましょう

NGINX と F5 のテクノロジーを使用して、あらゆる場所のあらゆるアプリと API を保護、配信、最適化する方法を常に改善し、拡張しています。 NGINXaaS for Azure に前述の機能やその他の新機能が追加されたことで、より多くの Azure ユーザーが、追加の VM やコンテナー インフラストラクチャを管理するオーバーヘッドなしで、NGINX Plus のパワーを活用して、さまざまなアプリや API の問題を解決できるようになります。

NGINXaaS for Azure について詳しく知りたい場合は、製品ドキュメントを参照することをお勧めします。 NGINXaaS for Azure を試してみたい場合は、 Azure Marketplaceにアクセスするか、弊社にお問い合わせの上、ユースケースについてご相談ください。