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

Adam Schumacher

NGINXaaS for Azureにより、企業は高パフォーマンスのアプリケーションをクラウドで安全に配信できます。NGINX Plusを基盤とするフルマネージドサービスで、2023年1月に一般提供を開始しました。リリース以降、今後も新機能を追加し、NGINXaaS for Azureを継続的に強化していきます。

このブログでは、独自のNGINX Plusインスタンスを導入、保守、更新することなく、NGINX Plusのメリットをさらに活用できる、最新のパフォーマンス機能とセキュリティ機能の一部をご紹介します。NGINXaaS for Azureの概要と包括的な機能については、「F5 NGINXaaS for Azureでクラウド移行を簡素化・迅速化」をご覧ください。

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

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

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

証明書のローテーション

NGINXaaS for AzureでTLS証明書を使用するうえで鍵となるのは、Azure Key Vault（AKV）を利用して証明書を安全に管理することです。AKVは機密性の高い暗号化マテリアルを安全に保管し、Azureポータルを介した鍵マテリアルの偶発的または意図的な漏えいを防ぎながら、NGINXaaS for Azureで証明書を使用できるようにします。

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

HTTP/2プロキシ（およびその他のプロトコルオプション）

目を閉じて、1997年を思い出してみてください。Chumbawambaの「Tubthumping」に合わせて盛り上がり、JNCOのジーンズ（カナダ出身の方ならModrobesでしょうか）を履いていた頃、HTTP/1.1がリリースされました。当時、ほとんどのエンドユーザーはダイヤルアップモデムでインターネットに接続し、Webページを構成する要素は数十個程度にすぎませんでした。ユーザーエクスペリエンスにおいては、レイテンシよりも帯域幅のほうがはるかに大きな懸念事項でした。

25年が経過した現在でも、かなりの数のWebアプリケーションがコンテンツ配信にHTTP/1.1を使用しています。これは問題になる可能性があります。HTTP/1.1は今でも機能しますが、1つの接続で一度に配信できるリソースは1つだけです。一方、最新のWebアプリケーションでは、ユーザーインターフェイスを更新するために数百件ものリクエストが発生する場合があります。

現在、ほとんどのユーザーが利用できる帯域幅は大幅に増えていますが、データ伝送速度（物理的には光速が上限）は、それほど急速には向上していません。そのため、これらすべてのリクエストによる累積レイテンシーが、アプリケーションの体感パフォーマンスに大きな影響を及ぼす可能性があります。最新のブラウザは同じサーバーに対して複数のTCP接続を確立しますが、各接続上のリクエストは依然として順次処理されるため、1つのリソースの処理が遅いと、後続のすべてのリソースも遅延する可能性があります。

HTTP/1.1のみを使用して読み込んだ場合のF5のホームページをご覧ください。

灰色のバーがいくつも表示されているのがわかりますか？これは、セッションの確立を待ったり、1つの低速なリソースによって処理がブロックされたり、新しいTCP接続が利用可能になるのを待ったりすることで、ブラウザが浪費している貴重な時間です。

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

大幅に改善しました。依然として応答の遅いリソースはいくつかありますが、ほかのリクエストを滞らせることはなく、キューイングに起因する遅延の待ち時間も大幅に短縮されています。HTTP/2は、WebブラウザーとサーバーがHTTP/1.1で使い慣れたセマンティクスを維持しながら、アプリケーションの体感パフォーマンス低下の一因に対処する新たな機能（リクエストの優先順位付け、ヘッダー圧縮、リクエストの多重化など）を追加しています。

このような明確な違いを踏まえ、NGINXaaS for Azureでは、クライアントリクエストをHTTP/2経由で処理できるようになりました。クライアント側の接続は、ラウンドトリップ時間が長い場合に影響を受けやすいため、アップストリームサーバーを変更することなく、HTTP/2によるレイテンシ低減のメリットを活かしてトラフィックを配信できます。

Webアプリケーション業界の一部ではそう思いたくないかもしれませんが、HTTP以外にも利用可能なプロトコルの選択肢があることをF5は認識しています。そのため、NGINX gRPCモジュールもNGINXaaS for Azureで利用できるようになりました。エラーのインターセプトやヘッダー操作など、gRPCトラフィックを処理するための複数の設定ディレクティブを提供します。

HTTP/gRPC以外のトラフィック向けに、streamモジュールがNGINXaaS for Azureで利用できるようになりました。このモジュールは、TCPおよびUDPトラフィックのプロキシ処理と負荷分散をサポートします。

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

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

構成について詳しくは、こちらをご覧ください。

容量を拡大（最大160 NCU）

NGINXaaS for Azureは、使用量に応じて1時間単位で計測され、NGINX Capacity Units（NCU）に基づいて月単位で請求されるサービスです。最近、デプロイ容量を80 NCUから160 NCUへと倍増しました。20 NCUの小規模なシステムをデプロイし、ワークロードの増加に応じて最大160 NCUまでスケールアップできます。また、最初から最大160 NCUでデプロイすることも可能です。

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

オンプレミス環境からフルマネージド型クラウドサービスへ構成を容易にリフト＆シフトできるよう、多数のNGINX Plusディレクティブを追加しました。NGINXaaS for AzureでサポートされているすべてのNGINX Plusディレクティブについては、こちらをご覧ください。

今すぐ始める

あらゆる場所で、すべてのアプリとAPIを保護、配信、最適化できるよう、NGINXとF5のテクノロジーの活用方法を継続的に改善、拡充しています。前述の機能をはじめ、NGINXaaS for Azureに追加された新機能により、より多くのAzureユーザーが、追加のVMやコンテナインフラストラクチャを管理する負担なく、NGINX Plusの力を活用して、アプリとAPIに関するさまざまな課題を解決できます。

NGINXaaS for Azureについて詳しくは、製品ドキュメントをご覧ください。NGINXaaS for Azureをお試しになる場合は、Azure Marketplaceにアクセスするか、F5までお問い合わせいただき、ユースケースについてご相談ください。

著者について

Adam Schumacher

Adam Schumacherのその他のブログ記事