NGINXの製品担当バイスプレジデントとして、私はお客さまやユーザーの皆さまと頻繁にお話ししています。プラットフォーム運用チーム、Kubernetesアーキテクト、アプリケーション開発者、CISO、CIO、CTOなど、皆さまと同じような立場の方々と対話を重ねてきました。その中で、NGINXの製品、価格設定、ライセンスモデルについて、強みと弱みの両面を含む率直なご意見を伺いました。
私たちが得た最も重要な学びは、「NGINXを世界の中心に据える」というアプローチでは、ユーザーのニーズに十分応えられないということです。私たちは、NGINXをアプリケーションのデプロイに関わるあらゆる要素の統合管理プレーン、つまり「プラットフォーム」にすることを目指して製品を開発してきました。しかし、その目標に向けた従来の製品の一部は、利用や導入があまり進んでいないことも認識していました。皆さまからは、NGINXは自社開発かどうかを問わず、既存のプラットフォームに不可欠なコンポーネントではあるものの、NGINX自体がプラットフォームなのではない、というご意見をいただきました。そのため、他のコンポーネントとの連携を強化し、透明性の高い価格体系と利用量モデル（ここが重要です）のもとで、製品のデプロイ、管理、セキュリティ確保を容易にする必要がありました。そしてもちろん、そのすべてをAPI経由で実行できるようにする必要もありました。
根底にあるメッセージは明快でした。特定の方法を押し付けることなく、NGINXを既存のワークフロー、ツールチェーン、プロセスに容易に統合できるようにすることです。皆さまの声を受け止めました。2024年には、データプレーンとセキュリティのユースケースの構成および管理に対して、より柔軟でシンプル、反復可能、かつスケーラブルなアプローチを採用します。
そうしたご要望はもっともです。皆さまを取り巻く環境は変化し、今も変わり続けています。クラウドからハイブリッド、マルチクラウド、さらにマルチクラウドとハイブリッドを組み合わせた構成へと、さまざまな段階を経て移行してきました。また、VMからKubernetesへ、APIからマイクロサービスやサーバーレスへと変化しています。多くの組織がシフトレフトを進めた結果、複雑さが増しています。より多くのチームがより多くのツールを利用するようになり、管理性、可観測性、堅牢なセキュリティへの要求も高まっています。これらはすべて、数時間、数日、数週間ではなく、数分でスケールアウトできなければならないアプリを支えるものです。さらに、最新の変化を加速させる人工知能（AI）が、従来のアプリケーションおよびインフラストラクチャアーキテクチャに大きな負荷をかけています。
今後のNGINX製品リリースで対応予定の課題
NGINX製品の基盤は常に堅牢で、実環境で十分に検証され、高いパフォーマンスを発揮してきました。一方で、NGINXのあらゆる側面を利用、管理、可視化する方法は、時代の変化に追いついていませんでした。これを改善するため、新製品の提供開始と多数の新機能の追加を迅速に進めています。詳細は、2月6日～8日に開催されるF5のカンファレンス「AppWorld 2024」で発表する予定です。今後の製品リリースで対応を予定している具体的な課題をご紹介します。
課題1：多様なデプロイ環境により、モダンアプリの管理が困難
現在、CIOやCTOは、多種多様なアプリケーション導入形態から選択できます。これにより、パフォーマンス、機能、レジリエンスの面で選択肢が大幅に広がるという利点があります。一方で、その多様性は複雑化や無秩序な拡大を招くという課題もあります。たとえば、AWSで稼働するアプリケーションの管理には、Azure Cloudで稼働するアプリケーションを管理する場合とは異なる構成、ツール、組織内に蓄積された暗黙知が必要です。
コンテナによってアプリケーションデプロイの大部分が標準化された一方で、コンテナより下位のレイヤー（またはコンテナに出入りする部分）は、依然として環境ごとに異なります。事実上の標準となっているコンテナオーケストレーションプラットフォームとして、Kubernetesにはこのプロセスを統一することが期待されていました。しかし、Amazon EKS、Azure Kubernetes Service (AKS)、Google Kubernetes Engine (GKE)にデプロイした経験があれば、これらがまったく同じではないことがわかります。
このように多種多様な環境でNGINX製品を管理するには、多大な運用リソースが必要となり、無駄も生じるという声がお客さまから寄せられています。率直に言えば、サーバーレス環境でアプリケーションを起動し、Kubernetes環境でスケールアップしながら、開発用にクラウド上で小規模な社内デプロイメントを維持するような動的環境では、年間ライセンスに基づく価格モデルは成り立ちません。
課題2：多様な環境で稼働し、複数のライセンスタイプにまたがるアプリのセキュリティ確保は困難
多様な環境が複雑に入り組んでいると、モダンアプリのデプロイ先を把握して監視し、適切なセキュリティ対策を適用することが難しくなります。たとえば、NGINX Plusをグローバルロードバランサーとして、NGINX Open Sourceをさまざまなマイクロサービス向けにデプロイし、それぞれを異なるクラウドや異なる種類のアプリケーション上で実行している場合があります。さらに、プライバシー、データ保護、トラフィック管理に関する要件もそれぞれ異なる可能性があります。
構成の組み合わせが増えるたびに、セキュリティ上の新たな課題が生じます。標準化された包括的なソリューションがないため、運用が複雑になり、設定ミスが発生する可能性も高まります。率直に言えば、どのNGINXソリューションにどの種類のセキュリティを適用できるのかを分かりにくくしてしまったことで、F5もこの複雑さを増す一因となっています。
F5はその課題を理解しています。お客さまには、NGINXを活用するすべてのアプリケーションを一元的に保護する方法が必要です。この統合セキュリティソリューションは、大半のユースケースに対応し、クラウド、オンプレミス、サーバーレスをはじめとするあらゆる環境で、同じツール、ダッシュボード、運用プロセスを展開できる必要があります。また、NGINXコミュニティの集合知と、F5が有するグローバルトラフィックに関するかつてない規模の可視性を活用し、よりインテリジェントなセキュリティアプローチへ移行することも重要だと認識しています。
課題3：モダンアプリのコスト管理は複雑で、無駄が生じる
シフトレフトが進む中、あらゆる組織が、チケットを起票したりSlackでメッセージを送ったりすることなく、開発者や実務担当者がより効率的に業務を遂行できる環境を整えたいと考えています。しかし、現実は異なります。Kubernetesやサーバーレスをはじめ、分散アプリケーションや、オンプレミス、クラウド、マルチクラウド環境にまたがるアプリケーションを管理する仕組みによって、複雑さはある程度抽象化されました。ただし、こうした進展は主にコンテナとアプリケーションの内部に限られています。ネットワーク、セキュリティ、オブザーバビリティといったアプリケーション周辺のレイヤーや、CI/CDには十分に波及していません。
これまでの課題でもこうした問題に触れてきましたが、要点は明確です。複雑さは、作業時間や負担の増大、セキュリティの低下、レジリエンスへの影響という大きなコストをもたらします。複雑化し続けるシステムの維持は本質的に難しく、多くのリソースを必要とします。さらに、価格体系やライセンスの複雑さが新たな悩みの種となります。NGINXは、誤って契約量を超過したユーザーに「トゥルーアップ」で負担を強いるような企業ではありません。
しかし、SaaS、API、マイクロサービスが普及した現在、年間契約やユーザー単位、サイトライセンス単位ではなく、利用量に応じて支払えることが求められます。テクノロジーインフラストラクチャとアプリケーションポートフォリオ全体で、すべてのNGINX製品とサービスに適用できる、利用量に基づくわかりやすい料金体系が必要です。また、チームが運用するあらゆるオープンソースモジュールについて、必要な部分にのみ料金を支払い、サポートとセキュリティを組み込める仕組みも求められます。
そのためには、NGINX製品のパッケージ体系と価格設定を一部見直す必要があります。最終的なソリューションには、他のSaaSと同様に、シンプルで透明性が高く、利用した分だけ支払う仕組みが不可欠です。皆さまの声は届いています。上記3つの課題すべてに対応する優れたソリューションを現在準備しています。
App World 2024にご参加ください
これらの注目すべき最新情報については、AppWorld 2024でご紹介します。また、今後12か月にわたり、長期計画とロードマップに沿ってソリューションの一部を順次提供していく予定です。
この取り組みにぜひご参加いただき、今後の展開を詳しくご紹介するAppWorldをご覧ください。早期割引料金は1月21日までご利用いただけます。詳細は、AppWorld 2024登録ページをご確認ください。また、2月6日の夜には、サンノゼのF5オフィスで、NGINXのリーダーやコミュニティの皆さまとともに、NGINXの未来を展望し、交流を深めながら、定番のピザとノベルティを楽しむイベントを開催します。ぜひご参加ください。登録方法と詳細は、イベントページをご覧ください。
来月、サンノゼで皆さまにお会いできることを楽しみにしています！
関連するブログ記事
チュートリアル：NGINXを使用してアプリケーション向けにOpenTelemetryを構成する
OpenTelemetryを使用してNGINXサーバーの状態と健全性をより明確に把握することで、問題のトラブルシューティングを行い、Webアプリケーションのパフォーマンスを向上できます。
AkitaのNGINX Plus認定モジュールでAPIエンドポイントの問題を特定・修正
Akita SoftwareのAPIオブザーバビリティ向け新しいNGINX Plus Certified Moduleを活用して、APIエンドポイントの問題をより迅速に特定し、修正できます。
JavaプロジェクトをスキャフォールディングしてKubernetesネイティブアプリを構築する方法
Red HatのシニアプリンシパルデベロッパーアドボケイトであるDaniel Oh氏が、Javaプロジェクトをゼロから構築するためのひな形を作成し、Kubernetesネイティブアプリケーションとしてビルドする方法を解説します。
F5 NGINXaaS for Azureのご紹介：Microsoft Azureでネイティブに利用できるSaaS型ロードバランシング
NGINXaaS for Azureは、NGINX PlusをAzureネイティブのSaaSとして利用できるサービスです。NGINXの設定を容易にリフト＆シフトできるため、クラウド導入とモダンアプリの展開を加速できます。
SELinuxでNGINXおよびNGINX Plusを使用する
Red Hat Enterprise Linux（RHEL）および関連ディストリビューションでSecurity-Enhanced Linux（SELinux）を有効にすると、デフォルト設定によりNGINXとNGINX Plusの一部の操作が制限されます。この記事では、すべての機能を利用できるようにSELinuxの設定を変更する方法について説明します。
NGINX PlusによるAWS Auto Scalingグループの負荷分散
新しいnginx-asg-sync統合ソフトウェアにより、NGINX PlusはAWS Auto Scalingグループの負荷を直接分散できるため、クラウドでの負荷分散がさらに柔軟になります