NGINX ブログの読者であれば、 NGINX Open Sourceがかなり人気があることは既にご存知でしょう。 しかし、無料だからという理由だけではありません (無料であることも素晴らしいことですが)。NGINX Open Source が人気なのは、安定性、軽量性、開発者の Swiss Army Knife™ として知られているからです。
Web サーバー、リバース プロキシ、API ゲートウェイ、Ingress コントローラー、キャッシュのいずれが必要な場合でも、フロッピー ディスクからインストールできるほど軽量な NGINX が役立ちます。 しかし、NGINX オープンソース ユーザーから、欠けているものが 1 つあると聞きました。 エンタープライズサポート。 そのため、私たちは新しいオープン ソース サブスクリプションで、これら (およびその他の機能) を導入できることを嬉しく思っています。
オープン ソース サブスクリプションは、次の内容が含まれる新しいバンドルです。
NGINX オープンソースは信頼性に定評があり、コミュニティは素晴らしいサポートを提供していますが、場合によってはそれ以上のものが必要になります。 オープンソース サブスクリプションにより、F5 は NGINX オープンソースに次のようなエンタープライズ サポートを追加します。
次に、エンタープライズ サポートを利用するメリットのいくつかについて詳しく見ていきましょう。
オープンソース ソフトウェア (OSS)に共通する脆弱性は、共通脆弱性識別子 (CVE) とバグに対処するのにかかる時間です。 実際、NGINX オープンソースのフォークのパッチ適用には数週間、あるいは数か月かかることもあります。 たとえば、2022 年 10 月 19 日に CVE-2022-41741 と CVE-2022-41742 の修正を発表しましたが、対応する Ubuntu と Debian のパッチは 2022 年 11 月 15 日まで提供されませんでした。
オープンソース サブスクリプションのお客様は、パッチや修正プログラム、CVE のプロアクティブな通知などにすぐにアクセスできます。
ソフトウェアのサプライ チェーンの問題を懸念する企業や政府が増えており、その多くがソフトウェア部品表 (SBOM) を構築する慣行に従っています。 SBOM コンセプトが成熟するにつれて、規制当局は「合理的に正当化される定期的なサイクル」でのパッチ適用を要求し始めており、通常のパッチ サイクル外で発見された重大な脆弱性に対しては、タイムリーなパッチを適用するようになっています。
オープンソース サブスクリプションを使用すると、特にセキュリティ面に関して、デューデリジェンス、トレーサビリティ、および関連規制への準拠を実証することで、NGINX オープンソース インスタンスが組織の OSS ソフトウェア要件を満たしていることを確認できます。
適切なサポートを受けるには、構成ファイルを共有する必要があります。 ただし、コミュニティのメンバーやフォーラムで構成を共有すると、組織がセキュリティの脆弱性 (または侵害) にさらされることになります。 Stack Overflow で共有された NGINX コードを 1 つだけシンプルにすれば、悪意のある人物にアプリやアーキテクチャを悪用する方法を知らせてしまう可能性があります。
オープン ソース サブスクリプションにより、F5 のセキュリティ エキスパート チームに直接アクセスできるようになり、構成の機密性が確保されます。 詳細については、 NGINX オープンソース サポート ポリシー。
注記: オープンソース サブスクリプションには、 NGINX から直接取得した NGINX オープンソースの安定版およびメインライン バージョンの Linux パッケージのサポートが含まれています。他のベンダーによってカスタマイズおよび配布されたパッケージをどのようにサポートできるかを検討していますので、コメントでどのディストリビューションが重要であるか教えてください。
オープンソース サブスクリプションを使用すると、追加費用なしでNGINX Plusにアクセスできます。 サブスクリプションでは、ビジネス ニーズに応じて、NGINX Open Source または NGINX Plus をいつ使用するかを選択できます。
NGINX オープンソースは、多くのアプリ配信ユースケースに最適であり、特にWeb サービス、コンテンツキャッシュ、基本的なトラフィック管理に優れています。 NGINX Open Source を他のユースケース向けに拡張することもできますが、これにより安定性とレイテンシの問題が発生する可能性があります。 たとえば、エンドポイントの変更を検出するために Lua スクリプトを使用するのが一般的です (Lua ハンドラーがリクエストをルーティングするアップストリーム サービスを選択するため、NGINX 構成をリロードする必要がなくなります)。 ただし、Lua は変更を継続的にチェックする必要があるため、リソースを消費し、結果として受信リクエストの処理時間が長くなります。 これにより、タイムアウトが発生するだけでなく、複雑さが増し、リソース コストが高くなります。
NGINX Plus は高度なユースケースに対応し、ロード バランシング、 API ゲートウェイ、 Ingress コントローラーなどのすぐに使用できる機能を提供します。 多くのお客様は、稼働時間、可用性、セキュリティ、および ID に関連する厳しい要件を持つビジネス クリティカルなアプリと API に NGINX Plus を選択しています。
スケールアップ時に問題が発生すると、顧客(社内外の両方)が直接影響を受けるため、稼働時間と可用性はミッションクリティカルなアプリや API にとって非常に重要です。
NGINX Plus を使用すると次のことが可能になります。
非機能要件をトラフィック管理戦略に組み込むことで、それらの要件をアプリからオフロードできます。 これによりエラーが削減され、開発者はコア要件の作業に集中できるようになります。
NGINX Plus を使用すると、次の方法でセキュリティを強化できます。
大規模な NGINX フリートの管理は困難な場合があります。 NGINX オープンソースを使用すると、組織内に数百 (場合によっては数千!) のインスタンスが存在する可能性があり、CVE、構成の問題、期限切れの証明書に関連する多くの複雑さとリスクが生じる可能性があります。 そのため、オープンソース サブスクリプションにはNGINX Management Suite Instance Managerが含まれており、これにより、NGINX オープンソース、NGINX Plus、NGINX App Protect WAF インスタンスのすべてを一元的にインベントリできるため、NGINX フリートを簡単に構成、保護、監視できます。
Instance Manager を使用すると、Kubernetes を含むあらゆる環境でインスタンスの正確な数を取得できます。 インスタンス マネージャーを使用すると、次のことが可能になります。
期限切れの証明書は、侵害の原因として悪名高いものとなっています。 インスタンス マネージャーを使用して、NGINX インスタンスとそのクライアント間の安全な通信を確保します。 インスタンス マネージャーを使用すると、すべてのインスタンス上の SSL/TLS 証明書を追跡、管理、展開したり(期限切れの証明書を見つけて更新するなど)、暗号化キーを定期的に (またはキーが侵害されたときに) ローテーションしたりできます。
NGINX インスタンスから取得できるデータの量は膨大になる可能性があります。 Instance Manager は、そのデータとサードパーティ ツールを最大限に活用できるように、貴重な NGINX メトリクスを収集し、API 経由でよく使用される監視、可視性、アラート ツールに転送するのに役立つイベントとメトリクス データを提供します。さらに、NGINX App Protect が追加された場合など、アプリと API の保護に関する独自の厳選された洞察を得ることができます。
新しいオープン ソース サブスクリプションの使用を開始することにご興味がある場合は、今すぐお問い合わせいただき、使用事例についてご相談ください。
NGINX Plus で実現できるユースケースを詳しく見てみましょう。
NGINX Management Suite インスタンス マネージャーの詳細については、以下をご覧ください。
「このブログ投稿には、入手できなくなった製品やサポートされなくなった製品が参照されている場合があります。 利用可能な F5 NGINX 製品およびソリューションに関する最新情報については、 NGINX 製品ファミリーをご覧ください。 NGINX は現在 F5 の一部です。 以前の NGINX.com リンクはすべて、F5.com の同様の NGINX コンテンツにリダイレクトされます。"