ソフトウェア負荷分散に切り替える 5 つの理由

この投稿は、NGINX, Inc. の Floyd Smith 氏と Faisal Memon 氏によるウェビナーを基に作成されています。 このトピックに関する当社の新しい電子書籍はダウンロード可能です。

目次

0:00 はじめに

フロイド・スミス: こんにちは。私たちのプレゼンテーションへようこそ。 私たちは NGINX にいます。今日は私の電子書籍『負荷分散にソフトウェアを使用する 5 つの理由』についてお話します。

本日は私たち二人が発表します。 私は NGINX のテクニカル マーケティング ライター、Floyd Smith です。以前は Apple のシニア テクニカル ライターを務め、テクノロジーのさまざまな側面に関する多数の書籍を執筆してきました。

ファイサル・メモン: こんにちは。私はFaisal Memonです。NGINXでプロダクトマーケティングを担当しています。ここに来て約1年になります。 NGINX に来る前は、Riverbed と Cisco でテクニカル マーケティング エンジニアとして働いていました。 私はC言語での開発からキャリアをスタートしました。シスコのソフトウェア エンジニアとして約8年間その役割を担いました。

1:38 あなたは誰ですか?

フロイド:ウェビナーを開催する前にサインアップを受け付けており、各参加者が提出した役職、所属組織、参加理由を確認できます。

参加している人たちの肩書きを見るのは本当に興味深かったです。 当社にはソリューション アーキテクトという、さまざまな種類のアーキテクトがいます。 Linux 管理者、エンジニアリング責任者、CEO、シニア アジャイル配信マネージャー、DevOps の役職を持つ数名、フル スタック ソフトウェア開発者、エンジニア、科学者、開発者、マーケティング オペレーション マネージャー。

当社には、技術志向を持った優秀な人材が揃っています。 私の感覚では、このウェビナーに参加している人々は、テクノロジーを実際によく理解しており、今日ここで話し合っている問題に直接直面することになると思います。

また、非常に幅広い素晴らしい組織が参加しています。 皆さんの中には、顧客が賢明な決定を下せるようガイドするためにこれに注目している人もいるかもしれませんが、大多数の皆さんはこれを社内で直接扱っているようです。

3:53 ハードウェアからソフトウェアへ

財務報告によると、ハードウェア ADC の市場は縮小傾向にあるため、ハードウェア ADC を販売する企業は、顧客基盤が縮小する中でも顧客 1 人あたりの収益を増やそうとしています。 多くのハードウェア ADC 顧客は、ハードウェア ADC が提供するサービスにこれまで以上に高額な料金を支払っている顧客層がますます狭まり、その層に加わりたくないと思うようになってきています。 彼らは、同じことをソフトウェアでよりうまく実行でき、さらに柔軟性も向上できることに気づき始めています。 肩書きに DevOps が含まれている方は、おそらく私が何を意味しているかお分かりでしょう。

NGINX でよく見られるのは、ハードウェア ADC の契約更新日に達したり、トラフィックが急増して料金が急上昇したりして、必死に契約を解除しようとするケースです。 すると、彼らは物事を非常に迅速に行うよう努めなければなりません。 たいていは成功しますが、ストレスがたまり、計画も予算も立てられません。 このプレゼンテーションの助けを借りて、より計画的なプロセスを開始できます。

ソフトウェアに移行することで多額の費用を節約できるため、予算の問題はそれほど重大ではありませんが、運用上の面倒は膨大です。 早めに始めるだけで、それらを大幅に減らすことができます。

NGINX は、ハードウェア ADC の非常に強力な代替手段です。もともとはC10K 問題を解決するために作成されました。 これは、1 台のコンピューター上で実行されている 1 つの Web サーバーが、10,000 以上の同時接続を処理することを意味します。 NGINX 以前は不可能でした。 人々はウェブサイトを立ち上げ、それが人気を得て、そして崩壊してしまうのです。 これを防ぐのは非常に困難でしたが、NGINX を使用すると、はるかに簡単になりました。

私たちの最初のオープンソースリリースは、NGINX [ソフトウェア]が最初に作成されたロシアで 2004 年に行われました[編集者注 – ここで Floyd は「設立」と書いていますが、NGINX, Inc. は 2011 年に設立されました] 。 サポート付きの商用バージョンである NGINX Plus は 2013 年にリリースされました。

NGINX 社はシリコンバレー (サンフランシスコ) に拠点を置き、開発オフィスはモスクワにあります。 英国にもオフィスがあります。 同社は業界リーダーによるベンチャーキャピタルの支援を受けています。 弊社の顧客数は800社を超え、従業員数も先日100名に達しました。

6:33 世界で最も忙しいサイト向けのトップ Web サーバー

NGINX 上で実行されているサイトは合計 1 億 6,000 万あります。

2つの異なるモードで使用されます。 一部のサイトでは、NGINX をWeb サーバーとして実行していますが、これが本来の目的です。 しかし、多くのサイトでは NGINX をリバース プロキシ サーバーとして実行しています。 ここで、NGINX を現在のアーキテクチャの前にドロップし、NGINX を使用してトラフィックを処理し、トラフィックをアプリケーション サーバーにルーティングします。 これを実行するとすぐに、負荷分散を実行する準備が整います。これが今日お話しする内容です。

最もアクセス数の多い上位 10,000 の Web サイトのうち 51 パーセントが NGINX に移行しました。それはなぜでしょうか? 最もアクセス数の多い Web サイトの利用率が、Web サイト全体よりも高いのはなぜでしょうか?

その理由は、NGINX が非常に忙しい Web サイトに最適なソリューションだからです。 問題のあるビジーな Web サイトを素早く救う方法は、リバース プロキシ サーバーとして NGINX を導入し、その上で負荷分散を実行することです。

時間が経つにつれて、既存のアプリを NGINX に移行するか、新しいアプリを開発して、それらの Web サーバーとしても NGINX を実行できるようになります。 このようにして、Web サーバーを気まぐれに変更しない非常に忙しい人々の間でこの使用法を実現しました。 彼らは他の Web サーバーの使用経験があり、その使い方も知っていますが、NGINX が提供するすべての機能のためにこの変更を行っています。

Amazon Web Services 上の全サイトの 36 パーセントが NGINX を使用しています。これは一種の標準ツールになりつつあります。 現在、多くの場合、NGINX から始めて、プロジェクト全体を通してそれを使い続けます。

弊社をご利用いただいているサイトの一部をご紹介します。 もちろん、NGINX を使用している Web サイトは 1 億 6000 万あるため、すべてを 1 つのスライドに収めることはできませんが、当社のパートナーや友人には、Netflix、Airbnb、Uber、Amazon Web Services (先ほども触れました)、Box、Pinterest、WordPress などがあります。

ウェブ配信を生業とし、それが機能する必要があるこれらの企業はすべて、NGINX に移行しました。

8:48 NGINX が適している場所

NGINX がどこに適合するかを見てみましょう。

右側には、NGINX が Web サーバーとして実行されていることがわかります。 また、Web サーバーとしては、アプリケーション ゲートウェイを使用して、さまざまな種類のアプリケーション サーバーを実行できるようにします。 Web サーバーとしての NGINX は、実行内容に応じて、10,000 程度の同時接続を処理できます。

しかし、NGINX はリバース プロキシ サーバーとしても役立ち、キャッシュ、負荷分散、その他さまざまな機能を利用できます。

9:32 現代のウェブアーキテクチャ

NGINX は、最新の Web アーキテクチャへの移行にも役立ちます。 それは、3 層の J2EE スタイルのアーキテクチャをマイクロサービスに移行することである可能性があります。 HTML や SOAP の複雑なプロトコルが、マイクロサービスの大きな部分を占める REST やメッセージングなどのより軽量なプロトコルに移行する可能性があります。 または、永続的なデプロイメントから、コンテナまたは VM を実行する変更可能なデプロイメントに移行します。

固定された静的なインフラストラクチャの代わりに、通常は自分で所有するサービスがあります。 SDN や NFV、クラウド、特にクラウドなどがあります。 数か月ごとの大規模なリリースではなく、数時間ごとに継続的な配信が行われます。 また、開発グループ、テスト グループ、運用グループがそれぞれのマネージャーを通じて作業するサイロ化されたチームの代わりに、全員が袖をまくり上げてあらゆる問題のいくつかの側面を処理する、責任を共有する DevOps 文化が生まれます。

10:42 DevOps は NGINX でうまく機能します

DevOps 方法論、クラウド デプロイメント、および自動サービス検出” size-full wp-image-46723″ style=”border:2px solid #666666; padding:2px; margin:2px;” />

DevOps のストーリーは NGINX と密接に絡み合っています。多くの DevOps 担当者は NGINX を常用しており、問題のあるデプロイメントに遭遇すると NGINX を導入します。

特定の展開では、アプリのセットアップをまったく変更する必要さえありません。 NGINX をその前にドロップすると、アプリケーション サーバーが処理できる方法でトラフィックがアプリケーション サーバーに送られます。 コードを変更しておらず、パフォーマンスの問題を急いで解決する際にコア機能を危険にさらすこともありません。

DevOps と NGINX がうまく連携する傾向があることの 1 つは、ソフトウェアの負荷分散です。これについては後で説明します。 クラウド展開でも非常にうまく機能しますが、独自のサーバーでも機能します。 さまざまな負荷分散方法を備えています。 ここで、NGINX と NGINX Plus の違いについて説明します。

NGINX のオンザフライ再構成機能は、サービスの検出と稼働時間をサポートします。 サービス検出はマイクロサービスと自動化に不可欠であり、オンザフライ再構成により、サーバーを構成するためにユーザーをサーバーから追い出す必要がなくなり、顧客をオンライン状態に維持する上で大きな利点となります。

アプリケーション ヘルス チェックは、アプリケーション配信の問題を早期に警告するため、問題のあるサーバーが停止してユーザーを混乱させるのではなく、問題のあるサーバーを正常に停止できます。 さらに、強力でカスタマイズ可能な監視機能もあります。 繰り返しになりますが、これにより、問題が発生したときにそれを知らせてくれるので、顧客に影響が及ぶ前に解決することができます。

12:30 NGINX Plus の機能

NGINX Plus には何が含まれていますか?

つまり、オープンソースの NGINX がオリジナル製品であり、NGINX Plus はその上に構築された商用製品です。 NGINX では、少なくとも 70 パーセントの時間をオープンソース側に費やしていますが、それが NGINX Plus の高度な機能の基盤でもあります。

このオープンソース製品には、Web サーバーの中核となるリクエスト ルーティングと、Web サーバーの負荷を最小限に抑え、回線上のトラフィックも最小限に抑える圧縮機能が含まれており、非常に役立ちます。 セキュリティのために SSL をサポートしています。 埋め込みスクリプト言語も 1 つ、実際には 2 つあります。 1 つは私たち独自の NGINX JavaScript モジュール (以前は nginScript と呼ばれていました) で、もう 1 つは Lua です。

部分的にオープンソースの NGINX ですが、NGINX Plus で強化されている機能がいくつかあります。 オープンソースの NGINX でも負荷分散をかなりうまく行うことができますが、NGINX Plus を使用すると、さらに高度な機能をいくつか利用できるようになります。 同様に、オープンソースの NGINX をエッジ キャッシュやメディア ストリーミングに使用することもできます。これは NGINX Plus でさらに効果的に機能します。

NGINX Plus には独自の機能もいくつかあります。 アプリケーションのヘルス監視、監視のための GUI 視覚化、監視と分析、RESTful 構成 API、さらに高度な負荷分散技術がいくつかあります。

NGINX Plus を使用すると、NGINX エンジニアにアクセスして、作業中にサポートを受けることができます。 現在 F5、Citrix、または同様のシステムを使用している場合は、おそらくそのようなサポートに慣れているでしょう。 大規模で混雑した Web サイトでは、わずかなダウンタイムでも多額のコストがかかるため、これは非常に重要です。1 年に 1 回の短時間の停止さえ回避できれば、簡単に元が取れます。

14:41 顧客事例研究 – WordPress.com

切り替えを行った顧客の事例をいくつか見てみましょう。

WordPress.com は F5 の BIG-IP を使用していましたが、サーバーごとに 1 秒あたり 10,000 件を超えるリクエストで負荷分散を行う必要があったため、それを NGINX に切り替えました。これは、NGINX が 10 年以上にわたって解決してきた C10k 問題です。 当時は、サーバーあたり 1 秒あたり 1,000 件のリクエストに制限されていました。 10,000 個以上と比べると、それがどれだけ負担になるかは想像がつくでしょう。

Wordpress.com には複数の F5 BIG-IP システムがあり、データセンターは 10 か所に増える予定でした。 高可用性をサポートするために、基本的にすべてのデータセンターにライブ バックアップを用意するために、10 組の BIG-IP サーバーを検討していました。 とても高価です。 また、構成を変更したときにユーザーが強制終了されないように、オンザフライで再構成する必要もありました。

彼らは、ユーザーのアバターを表示するアプリである Gravatar で NGINX をテストすることから、NGINX への移行を開始しました。 これにより、彼らは NGINX に慣れることができました。その後、F5 サーバーから NGINX に移行し、小さくて予測可能なメモリ フットプリントと小さくて予測可能な CPU フットプリントを実現しました。

現在、36 台の NGINX サーバーで 1 秒あたり 70,000 件を超えるリクエストと 1 秒あたり 15 ギガビット [Gbps] を処理しています。 ピーク時には、サーバーあたり 1 秒あたり 20,000 件のリクエストを処理できます。 また、オンザフライで再構成や更新を行うこともできます。

引用文を見ると、小規模な実装と大規模な実装の費用の違いについて言及しているだけであり、NGINX を使用するとかなりの金額を節約できます。 しかし、サーバーのペアが 10 個になると、その差は一変します。

16:42 顧客事例研究 – Montana Interactive

Montana Interactive は、高可用性の負荷分散に NGINX Plus を選択しました。 実際、多くの政府サービスはオンラインで提供される方が簡単で、安価で、優れています。 自動車課などで予約を取ったことがあるなら、私の言っている意味がわかるでしょう。 これらのウェブサイトは、投票や税金の支払いなどをサポートします。

こうした重要な政府サービスは膨大にあり、モンタナ州は非常に大きな州で、比較的少数の人々が州中に散らばっています。 したがって、住民が政府機関まで車で 6 時間または 8 時間かけて行くよりも、オンラインでサービスを利用できることは非常に重要です。

Montana は当初、オンライン サービスへの移行をかなり積極的に進めていましたが、事業が成長するにつれてセッションの中断に悩まされるようになりました。 税金の支払いのための大規模なアプリのおかげで、四半期ごとに取引トラフィックが急増しました。 大きなフォームに記入している途中で、突然誰かが落とされ、その人が記入したすべての作業が失われてしまうことがありました。 税金の申告やその他の複雑な手続きをする場合、それはかなりストレスになります。

彼らにとっての解決策は、Pound を実行しているサーバーから NGINX Plus にアップグレードし、NGINX Plus をさまざまなハイパーバイザーやデータセンターに配置し、動的なリバース プロキシとして動作させてリクエストをリアルタイムでルーティングし、トラフィック管理を改善することでした。 NGINX Plus に移行した結果、速度、柔軟性、使いやすさが大幅に向上しました。 オンザフライ再構成のメリットを享受し、SSL 処理を NGINX サーバーにオフロードし、ロールベースの管理を使用して運用とセキュリティを改善しました。

Montana Interactive の James Ridle 氏は、NGINX のパワーに驚嘆しました。ベンチマークの結果に彼は驚き、NGINX を使用した同じサーバーで処理できる処理の違いが信じられないほどでした。

18:43 顧客事例研究 – BuyDig.com

これは、顧客にとって大きなメリットがあるもう 1 つのケース スタディです。BuyDig.com は、NGINX によってスケーラビリティとセキュリティを実現した e コマース サイトです。

BuyDig.com には古い .NET アプリがありました。同社はそれを変更したくありませんでしたし、変更する必要もありませんでした。 大規模なDDoS攻撃を受けた後、同社は、パフォーマンス、セキュリティ、スケーラビリティが向上した、高速でフォールト トレラント、かつ構成が簡単なフロントエンドが必要であることに気付きました。

彼らは、Amazon Web Services でホストされているフロントエンド アプリケーション層に NGINX Plus を配置しました。 .NET 上で実行されているバックエンド サービスには変更を加えませんでした。 そして、それはとても大きなことです。変化はありません。小さな変化ではなく、小さな面倒ではなく、小さなリスクではなく、何もないのです。

今では素晴らしいパフォーマンスとセキュリティを実現しています。 NGINX の設定言語を使用してカスタマイズしました。 安全性を維持するために、TLS SNI とカスタマイズ可能なログを使用します。 速度低下やサイトのダウンタイムは一度も発生しておらず、パフォーマンスに非常に満足しています。

これらは、NGINX Plus で実行できることのほんの一例です。

20:10 電子書籍 – 負荷分散にソフトウェアに切り替える 5 つの理由

それでは電子書籍について詳しく見ていきましょう。 まず、電子書籍の内容を簡単に要約します。その後、Faisal が、より技術的な切り替えの理由の最初の 2 つについて説明します。その後、私が引き継ぎます。 リンクがあります。 このプレゼンテーションとウェビナーの録画は、終了後にご利用いただけるようになります。 そのメールが届くまでには、1日ほどかかると思います。

このリンクをクリックすると、この無料電子書籍をダウンロードできる場所に移動します。 理由をあらかじめ述べておきますが、コストを削減し、DevOps の適合性を向上させ、どこにでも展開できるため (オンプレミスのサーバー、クラウド、プライベート クラウドなど、何でも好きな場所に)、迅速に適応でき、奇妙な契約上の制約がないためです。これについては後で詳しく説明します。 さて、コスト削減についてファイサルに話を移したいと思います。

21:22 理由1 – コストを大幅に削減

ファイサル： ありがとう、フロイド。 5 つの理由のうちの 1 つ目は、ソフトウェア アプリケーションの配信に NGINX Plus に移行することでコストを大幅に削減できることです。

90 年代半ばを振り返ると、Web サイトを拡張する唯一の方法は、より大きなサーバーを購入することでしたが、これは非常に高価で、単一のサーバーが単一障害点であったため、信頼性も低かったです。

F5 が初めて BIG-IP をリリースしたのはこの頃で、これにより Web サイト所有者に異なるアーキテクチャが提供され、より大きなサーバーを購入する代わりに、BIG-IP を使用して一連の安価なサーバーの負荷を分散できるようになりました。 つまり、巨大なサーバー 1 台を購入するよりも BIG-IP と安価なサーバーを購入する方が安く済むため、コストが削減され、単一障害点が排除されるため冗長性も得られます。

これは素晴らしい建築物でした。革命的で、当時は唯一の選択肢でしたが、過去 20 年間で多くのことが変化しました。 大きな変化の 1 つは、サーバーのコストが大幅に下がったことです。 最近では、サンフランシスコ ベイエリアでは、1 か月分のレンタル料金以下でかなり強力なサーバーを購入できます。

2 番目の大きな変化は、F5 BIG‑IP や Citrix NetScaler から得られるのと同じ機能を提供する NGINX などのオープン ソース ソフトウェアが登場したことです。 オープンソースの場合、高価な大型アプライアンスと同様の機能を無料で手に入れることができます。 フロイドは先ほど、NGINX を使用している Web サイトが 1 億 6,000 万以上あると指摘しました。上位 10,000 のサイトを見ると、その半分以上が NGINX 上で実行されています。

つまり、F5 と比較して必要なすべての機能を備えているだけでなく、他の商用製品と同様に拡張性と信頼性も備えたこのオープン ソース ソフトウェアが実現しました。

23:19 NGINX Plus と F5 BIG-IP

今年初めにベンチマークとコスト分析を行いましたが、その抜粋を以下に示します。 これは、市販のコモディティ ハードウェア上で実行されている NGINX Plus ソフトウェアを比較したものです。 この場合は Dell が提供しており、これを F5 BIG-IP のさまざまなモデルと比較しています。

この特定の例は、エントリー レベルの F5 BIG-IP である 2000S です。 Dell サーバー上の 2 つの異なるサイズの NGINX Plus と比較しました。 1 つは F5 BIG‑IP よりもわずかにパフォーマンスが低いもの (下部にパフォーマンス メトリックが表示されます)、もう 1 つはパフォーマンスがほぼ 2 倍です。

右側の列を見ると、NGINX Plus は 2000S のパフォーマンスを 2 倍にしており、ハードウェアのコストと 1 年間のメンテナンス サポートを含めて、1 年目に 78% の節約が実現しています。 そして、これらのコスト削減は 5 年目まで継続されます。 5年後でも、Dell サーバーを使用した NGINX Plus の総所有コストは F5 よりも 58% 安くなります。

24:37 NGINX Plus と Citrix NetScaler

Citrix NetScaler と同様のコスト比較を行いました。 ここでは、エントリーレベルの NetScaler、MPX‑5550 Enterprise Edition を比較します。

Citrix のライセンスでは、キャッシュやコンテンツ圧縮などの基本機能が必要な場合は、ライセンスを Enterprise Edition ライセンスにアップグレードする必要があります。 NGINX では、オープンソースと NGINX Plus の両方でコンテンツのキャッシュと圧縮が追加料金なしで含まれています。 ここで比較しているのは、Citrix NetScaler の Enterprise Edition です。これは、NGINX Plus で提供される機能と同等の機能を提供するためであり、Citrix NetScaler を NGINX Plus に置き換えた場合、F5 の場合と同じコスト削減がここでも見られます。

期待どおりの機能とパフォーマンスをすべて手に入れることができますが、1 年目は 89% 安く済みます。 5年目まで、ハードウェアのコスト（この場合はコモディティ Dell サーバー）と NGINX Plus ソフトウェアのサブスクリプションのコストの両方で 75% 節約できます。

重要な指標であり、ハードウェア ベンダーがよく話題にするのが、1 秒あたりの SSL トランザクション数、つまり 1 秒あたりに確立できる新しい SSL 接続の数です。 これらのプラットフォームでは、その数値は通常ハードウェアによって加速されるため、NetScaler と F5 BIG-IP には SSL トランザクションを加速するための専用のハードウェアがあり、これによりこれらのプラットフォームのコストが上昇します。

私たちが目にしているのは、ソフトウェア ソリューション（ハードウェア アクセラレーションを使用せず、CPU の処理能力のみを使用する）でも、カスタム ハードウェアに対応できるということです。 ハードウェア アクセラレーション ソリューションから得られるパフォーマンスを維持しながら、大幅なコスト削減を実現します。

これが理由 1 です。NGINX Plus に移行することで、多くのコストを節約できます。 しかし、それはお金だけの問題ではありません。

26:52 理由その2 – DevOps にはソフトウェア アプリケーションの配信が必要

ソフトウェア ベースのソリューションでは柔軟性も大幅に向上します。ソフトウェア ベースのロード バランサーに切り替える 2 番目の理由は、DevOps に移行する場合、アプリケーション配信用のソフトウェアが本当に必要になるからです。

F5 と NetScaler では、これらのアプライアンスは通常、集約ポイントとして大規模企業内に導入されます。 そのため、無関係なトラフィックが大量に通過することになります。 同じ F5 BIG-IP で、ネットワーク ファイアウォールの負荷分散、企業の電子メール サーバーの負荷分散、複数の異なるバックエンド エンタープライズ アプリケーションの負荷分散、さらにはフロントエンド エンタープライズ アプリケーションの負荷分散を行うこともできます。 マイクロサービス アーキテクチャにおける負荷分散 API である可能性があります。 つまり、多くのものの負荷分散が可能になります。

表面的には、これは非常にシンプルで、すべてを F5 経由で実行するだけなので、優れたアーキテクチャのように見えます。 これは長い間機能していましたが、特に 2000 年代初頭はプライベート データ センターが中心で、企業が依存するすべてのアプリケーションをオンプレミス データ センターから実行していました。 しかし、ここ数年で状況は変わり、現在ではほとんどのものがクラウドに移行されています。

クラウドとは、単に Amazon 内でフロントエンドの Web アプリケーションをホストするだけではなく、オンプレミスの CRM システムやオンプレミスの電子メール サーバーではなく、Salesforce や Office 365 などを使用することも意味します。 したがって、これらすべての機能を備えたデバイスを持つことは、今日人々が実際に実行しているものに対しては過剰である可能性があります。

この集約によって生じる 2 番目の問題は、これらのアプライアンスが非常に厳重にロックダウンされるようになることです。 F5 の設定を間違えると、企業ネットワーク全体がダウンする可能性があるため、変更を躊躇するようになります。 負荷分散電子メール サーバー、ネットワーク ファイアウォールなどが考えられます。 したがって、構成はリスクの高いものとなり、変更は厳しく制限され、厳重にロックダウンされる必要があります。

変更を加えたい人は、通常、IT チケットを提出する必要があります。これには、組織や、要求された変更に対する組織の優先順位に応じて、数時間、数日、または数週間かかる場合があります。

このように極度にロックダウンされたハードウェアを使用すると、DevOps への移行が非常に困難になります。 DevOps を実行して自動化に向かうと、継続的インテグレーションへと進み、コードをより頻繁にリリースする方向へと進みます。 また、変更を加えるたびに IT チケットを提出しなければならない場合、その取り組みは阻害され、失敗に終わります。

多くの組織で見られるのは、アプリケーションの責任者であり、DevOps やアジャイル開発に移行したいと考えている人たちが、毎回チケットを提出しなければならない状況に対処できないということです。これは、DevOps やアジャイルの取り組みの妨げになるからです。 そのため、オープンソースの NGINX を導入し、F5 BIG-IP をそれに接続することがあります。その NGINX インスタンスは DevOps チームまたはアプリケーション チームによって管理されるため、自動化や変更を手間をかけずに行うことができます。 つまり、これは企業の IT ポリシーを回避する一種の方法です。 そして、当然のことながら、多くのお客様が一度試してみると、より高度な機能とサポートを得るために NGINX Plus に移行し始めます。

NGINX は、現在の F5 をそのまま維持できるモデルも含め、柔軟でさまざまな展開モデルをサポートしています。 NGINX Plus を使用すると、フロントエンドの Web アプリケーション、API、マイクロサービスの負荷分散と配信を補完およびオフロードし、F5 を維持して企業の電子メール サーバーのネットワーク負荷分散を実行できます。 ネットワーク サービスとネットワーク負荷分散が必要ない場合は、F5 を NGINX Plus に置き換えて、単一のソリューションにすることもできます。

当社は、組織が DevOps、継続的デリバリー、自動化へと移行できるよう、さまざまな展開モデルをサポートしています。

理由3については、フロイドに返します。

31:59 理由その3 – 1つのADCでどこにでも展開

フロイド:ありがとう、ファイサル。

NGINX を使用すると、1 つの ADC ソリューションをどこにでも展開できます。 「どこでも」とはどういう意味ですか? つまり、オンプレミス サーバー、パブリック クラウド、プライベート クラウド、ハイブリッド クラウドがすべて 1 つのソリューションで動作するということです。 そこには実用的な側面と建築的な側面があります。

まず、社内サーバーを使用していてクラウドを使用していない場合は、これまで述べたことはすべて当てはまります。 柔軟性の向上、機能の充実、コストの削減を目的として NGINX および NGINX Plus に移行する人の多くは、まさにその状況にあります。つまり、社内サーバーにデプロイしているのです。

クラウドを使用している場合、または今後クラウドの使用を検討している場合、NGINX とハードウェア ADC を比較することはできません。ハードウェア ADC を Amazon のデータセンターに移動することはできません。 ハードウェア ADC はここでは役に立ちません。

現在、ハードウェア ADC 開発者はソフトウェア ベースのソリューションをいくつか提供していますが、場合によっては、開発にはそれらを使用することのみを推奨しています。 これはハードウェア ADC の代替ではありません。シンプルさや「壊れていないものは直す必要はない」という利点は、クラウドに移行すると失われてしまいます。

NGINX と NGINX Plus では、アプリケーション アーキテクチャは配信プラットフォームから独立しています。 一部のクラウド プロバイダーは、API を介して連携できるサービスをますます追加し始めています。 開発中は、何かを実行する方法について心配する必要がないため、これは非常に便利です。API を使用して、負荷分散、キャッシュ、その他の機能を処理できます。 しかし、規模が大きくなると、取引ごとに少額を支払うことになります。

そうですね、何千、何万、何十万もの取引を行っていると、突然、その数字が加算され始めます。 課金は非常にわかりにくく、特に常に変化するトラフィックに基づいているため、予測が困難です。

NGINX または NGINX Plus ベースのアプローチを使用する場合、基本的にどのプラットフォームでも同じことを実行し、別のクラウド プロバイダーに移行したり社内に戻ったりしてもほとんど違いはありません。

実際に、社内サーバーとクラウド間で負荷分散を行っているお客様もいらっしゃいます。 それで、それはどのように見えるのでしょうか? 彼らは、80 ～ 90 パーセントの時間、自社のニーズを満たすのに十分な社内サーバーを保有しています。 スケールアップが必要になったとき、新しいサーバーを購入したり接続したりする必要はなく、クラウドにスケールアップするだけです。

クラウドは通常、オンプレミスのサーバーよりも低速であり、すべてが負荷分散されているため、社内サーバーのみを使用している場合にドロップされるセッションのみがクラウドに送信されます。 待ち時間はわずかに長くなりますが、処理され、キューに入れられたり、ドロップされたりすることはありません。

トラフィックの急増など、緊急時にのみクラウドの料金を支払うことになるため、経済的にも優れています。 これは、ニュース報道や、製品が好評を博した場合、または継続的にビジネス プランを超えているが、まだ社内でスケールアップしていない場合、または、たまたま休日で、年に数週間しか必要としないサーバーを 2 倍に増やす価値がなく、クラウドにスケールアップすることで対応できる場合などに発生する可能性があります。 NGINX を使用すると、これらすべてを柔軟に、さらには自動的に実行できます。

35:42 理由その4 – 変化する需要に素早く適応する

NGINX を使用すると、アプリケーションに対する変化する要求に迅速に対応できます。 高可用性のためにサーバーをすぐに追加したり、サーバー ペアを追加したりする必要がある場合、ハードウェアの注文、配送、受領、テスト、iRules やそれらに必要なソフトウェア構成の実行を待つことはできません。iRules も独自のものであり、iRules が必要になるのは F5 サーバーがある場合のみです。 それは大学を卒業してすぐに雇われるようなスキルセットではありません。 iRules 担当者が退職した場合、別の担当者を見つけるのは困難になります。

構成の変更に関しては、ネットワーク運用部門が変更を承認するまで待つことができないことがよくあります。 変更内容を、それほど緊急でない内容と一緒にキューに入れるのは望ましくありません。

NGINX を使用すると、新しいプロジェクトの承認にかかるオーバーヘッドが大幅に削減されます。 NGINX と NGINX Plus を使用すると、2,000 ドルや 3,000 ドルかかるサーバーの場合でも、余分なハードウェアをクローゼット内に保管しておくことができます。 ハードウェア ADC に数万ドルかかる場合、そうすることはできません。

こうした柔軟性、冗長性、必要なときに必要なことを実行する能力は、NGINX の中心的な機能であり、NGINX を使用する人々が私たちをとても気に入っている理由の 1 つです。

37:08 理由その5 – 人工的なパフォーマンス制約がない

最後に、NGINX では、パフォーマンスに対する人為的またはコンタクト主導の制約はありません。 NetScaler Enterprise Edition の場合、そのサーバーのスループットの契約上の制限は 0.5 Gbps です。 まあ、企業の状況ではそれはばかげています。 業界標準のハードウェア上で実行される同等の NGINX セットアップは 20 Gbps をサポートします。 これは Citrix 制限の 40 倍です。

もう 1 つは、Citrix 番号が契約上の制約であることです。 それを超過すると、支払い条件が突然大幅に延長されます。 20 Gbps は当社からの推奨値です。 つまり、その領域に入ると、パフォーマンスが少し低下していることに気づき始め、別のサーバーを導入して負荷分散を行うことが賢明だと考えるようになるということです。 しかし、あなたには柔軟性があり、決めるのはあなたです。 予算が突然減ることはありません。

Citrix の場合、一時停止の標識にぶつかるようなものです。 そのようなシナリオでは、ビジネスの増加は悪いニュースになる可能性があります。 顧客が 1 人増えるだけでも多額の費用がかかりますが、顧客が数人増えるだけでも、上限を超えてしまうため多額の費用がかかります。 NGINX を使用すると、ビジネスが拡大するのは良いことであり、顧客ベースの増加による収益の増加に伴ってコストも着実に増加します。

こうした上限を超えてしまい、突然予算を超過してしまったという緊急の電話が頻繁にかかってきます。 そして、大きな変化を起こさなければ、予算内に戻ることはできないでしょう。 その後、彼らは急いで NGINX に移行し、良い状況に戻らなければなりません。 そして、NGINX で大幅にコストを節約できたため、結局は予算を下回る結果になることがよくあります。

しかし、そんな頭痛は誰が必要とするのでしょうか? 突然、ひどい予算とパフォーマンスの矛盾に遭遇したとき、不安や恐怖感を感じることはありませんか? 早期に NGINX に切り替えると、その問題から完全に解放されます。

40:00 リソース

• ケーススタディ – WordPress.com/Automattic の NGINX
• ケーススタディ – Montana Interactive が NGINX Plus でアプリのパフォーマンスと顧客サービスを改善
• ケーススタディ – Buydig.com がコードを 1 行も変更せずに Microsoft .NET アプリを拡張および保護する方法
• 電子書籍 – 負荷分散にソフトウェアに切り替える 5 つの理由
• ブログ – NGINX Plus と F5 BIG-IP: 価格と性能の比較
• ブログ – NGINX Plus と Citrix NetScaler: 価格と性能の比較
• NGINX Plus 無料トライアル