ソフトウェアロードバランシングに切り替えるべき5つの理由

NGINX | 2016年10月13日

この記事は、NGINX, Inc.のFloyd SmithとFaisal Memonによるウェビナーを基に編集したものです。このトピックに関する新しいeBookは、こちらからダウンロードできます。

0:00	はじめに
1:38	対象となる方
3:53	ハードウェアからソフトウェアへ
6:33	世界で最もアクセスの多いサイトを支える主要Webサーバー
8:48	NGINXの位置付け
9:32	最新のWebアーキテクチャ
10:42	DevOpsとNGINXの優れた親和性
12:30	NGINX Plusの機能
14:41	お客様事例 – WordPress.com
16:42	お客様事例 – Montana Interactive
18:43	お客様事例 – BuyDig.com
20:10	eBook – ロードバランシングをソフトウェアに移行すべき5つの理由
21:22	理由 #1 – コストを大幅に削減
23:19	NGINX PlusとF5 BIG‑IPの比較
24:37	NGINX PlusとCitrix NetScalerの比較
26:52	理由 #2 – DevOpsにはソフトウェアによるアプリケーションデリバリが必要
31:59	理由 #3 – 1つのADCをあらゆる環境に導入
35:42	理由 #4 – 変化する需要に迅速に対応
37:08	理由 #5 – 人為的なパフォーマンス制約がない
40:00	リソース

0:00 はじめに

Floyd Smith：こんにちは。プレゼンテーションへようこそ。NGINXから、私のeBook「ロードバランシングをソフトウェアに切り替える5つの理由」についてご紹介します。

本日は2名でプレゼンテーションを行います。私はNGINXのテクニカルマーケティングライター、Floyd Smithです。以前はAppleでシニアテクニカルライターを務め、テクノロジーのさまざまな分野に関する書籍を多数執筆してきました。

Faisal Memon：こんにちは、Faisal Memonです。NGINXでプロダクトマーケティングを担当しており、入社して約1年になります。NGINXに入社する前は、RiverbedとCiscoでテクニカルマーケティングエンジニアを務めていました。キャリアのスタートはC言語による開発で、その後Ciscoでソフトウェアエンジニアを約8年間務めました。

1:38 自己紹介

Floyd: ウェビナーの開催前に参加登録を受け付けており、皆さまが入力した役職、所属組織、参加理由を確認できます。

参加者の役職を拝見すると、実に興味深い顔ぶれでした。ソリューションアーキテクトをはじめ、さまざまな分野のアーキテクト、Linux管理者、エンジニアリング責任者、CEO、シニアアジャイルデリバリーマネージャー、DevOps関連の役職の方々、フルスタックソフトウェア開発者、エンジニア、科学者、開発者、マーケティングオペレーションマネージャーが参加されています。

技術志向のさまざまな方々にご参加いただいています。このウェビナーに参加されている皆さまは、実際にテクノロジーを扱っており、本日取り上げる課題に直接直面している方々だと感じています。

また、実に多種多様な組織の方々にご参加いただいています。お客さまが適切な判断を下せるよう助言するためにご覧になっている方もいらっしゃるかもしれませんが、大半の方は社内でこの問題に直接取り組んでいるようです。

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

財務報告によると、ハードウェアADC市場は縮小しています。そのため、ハードウェアADCの販売事業者は、顧客基盤が縮小するなかでも、顧客1社あたりの収益を増やそうとしています。多くのハードウェアADCユーザーは、こうしたサービスにますます高額な費用を支払う、縮小し続ける顧客層にとどまりたくないと考え始めています。そして、ソフトウェアなら同じことをより効果的に実現でき、さらに柔軟性も高められると気づき始めています。肩書にDevOpsと付く方なら、おそらくお分かりでしょう。

NGINXでよく目にするのは、ハードウェアADCの契約更新日を迎えたり、トラフィックが急増して料金が突然跳ね上がったりしたことで、契約から抜け出そうと慌てるケースです。その結果、非常に短期間で対応しなければならなくなります。たいていは移行に成功しますが、ストレスが大きく、計画にも予算にもない対応となります。このプレゼンテーションを参考にすることで、より計画的にプロセスを開始できます。

ソフトウェアへの移行によって大幅なコスト削減が見込めるため、予算上の問題はそれほど深刻ではありません。しかし、運用面の負担は非常に大きくなります。早めに着手するだけで、その負担を大幅に軽減できます。

NGINXは、ハードウェアADCに代わる非常に堅牢な選択肢です。もともとは、C10K問題を解決するために開発されました。これは、1台のコンピューター上で稼働する1台のWebサーバーが、10,000件以上の同時接続を処理するという課題です。NGINXが登場する以前は不可能でした。Webサイトを公開して人気が高まると、サーバーがダウンしてしまうことがありました。これを防ぐのは極めて困難でしたが、NGINXによってはるかに容易になりました。

最初のオープンソース版は、NGINX ［ソフトウェア］が開発されたロシアで2004年にリリースされました［編集者注：Floydはここで「設立」と述べていますが、NGINX, Inc.が設立されたのは2011年です］。サポート付きの商用版であるNGINX Plusは、2013年にリリースされました。

NGINX社はシリコンバレー（サンフランシスコ）に本社を置き、モスクワに開発拠点を構えています。英国にもオフィスがあります。業界をリードするベンチャーキャピタルから出資を受けています。お客さまは800社を超え、先日、従業員数が100人に達しました。

6:33 世界で最もアクセスの多いサイトを支える主要Webサーバー

NGINX上で稼働しているサイトは、合計1億6,000万に上ります。

NGINXは、2つの異なるモードで使用されます。一部のサイトでは、本来の用途であるWebサーバーとしてNGINXを実行しています。一方、多くのサイトでは、NGINXをリバースプロキシサーバーとして実行しています。これは、現在のアーキテクチャの前段にNGINXを配置し、トラフィックを処理してアプリケーションサーバーにルーティングする構成です。この構成にすると、今回取り上げる負荷分散の実現に向けた第一歩となります。

アクセス数上位10,000サイトのうち、51%がNGINXに移行しています。では、なぜでしょうか。Webサイト全体と比べて、アクセス数の多いサイトでNGINXの利用率がさらに高いのはなぜでしょうか。

その理由は、NGINXがアクセスの非常に多いWebサイトに最適なソリューションだからです。問題が発生している高トラフィックのWebサイトを迅速に立て直すには、NGINXをリバースプロキシサーバーとして導入し、その上で負荷分散を実行する方法があります。

時間をかけて既存のアプリをNGINXに移行することも、新しいアプリを開発する際にNGINXをWebサーバーとして使用することもできます。このようにして、非常に多忙で、気まぐれにWebサーバーを変更することのない人々にもNGINXが利用されるようになりました。こうした人々は、ほかのWebサーバーを使った経験があり、その使い方も熟知しています。それでもNGINXに移行するのは、NGINXがもたらすさまざまなメリットがあるからです。

Amazon Web Services上の全サイトの36%がNGINXを使用しています。NGINXは標準的なツールになりつつあります。現在では、NGINXから始め、プロジェクト全体を通じて使い続けるケースが多く見られます。

こちらは、NGINXを利用しているサイトの一例です。もちろん、NGINXを利用するWebサイトは1億6,000万に上るため、すべてを1枚のスライドに収めることはできませんが、パートナーや友人には、Netflix、Airbnb、Uber、先ほどご紹介したAmazon Web Services、Box、Pinterest、WordPressなどがあります。

Web配信を事業とし、確実な稼働が不可欠なこれらの企業は、すべてNGINXに移行しています。

8:48 NGINXの位置付け

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

右側では、NGINXがWebサーバーとして稼働しています。Webサーバーとして、アプリケーションゲートウェイを使用することで、さまざまな種類のアプリケーションサーバーと連携して動作できます。WebサーバーとしてのNGINXは、用途にもよりますが、およそ10,000件の同時接続を処理できます。

一方、NGINXはリバースプロキシサーバーとしても有用で、キャッシュ、負荷分散をはじめとするさまざまな機能を利用できます。

9:32 モダンWebアーキテクチャ

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もサポートしています。さらに、組み込みスクリプト言語を2つ用意しています。1つは独自のNGINX JavaScript module［旧称nginScript］、もう1つはLuaです。

一部はオープンソース版NGINXでも利用でき、NGINX Plusではさらに強化されている機能がいくつかあります。オープンソース版NGINXでも十分なロードバランシングが可能ですが、NGINX Plusでは、より高度な機能も利用できます。同様に、オープンソース版NGINXはエッジキャッシュやメディアストリーミングにも使用できますが、NGINX Plusではさらに優れた性能を発揮します。

NGINX Plusには、独自の機能もいくつかあります。アプリケーションの健全性監視、監視情報のGUIによる可視化、モニタリングと分析、RESTful構成API、さらに高度な負荷分散手法などです。

NGINX Plusでは、業務を進める際にNGINXのエンジニアによるサポートを受けられます。現在F5、Citrix、または同様のシステムを使用している場合は、こうしたサポートに慣れていることでしょう。わずかなダウンタイムでも多額の損失につながる大規模でアクセスの多いWebサイトでは、このサポートが極めて重要になる場合があります。年に一度でも短時間の停止を回避できれば、費用を十分に回収できる可能性があります。

14:41 お客様事例 – WordPress.com

切り替えを行ったお客さまの事例をご紹介します。

WordPress.comはF5のBIG‑IPを使用していましたが、サーバー1台あたり毎秒10,000件を超えるリクエストの負荷分散が必要だったため、NGINXに移行しました。これは先ほど触れたC10k問題であり、NGINXは10年以上にわたってこの問題を解決してきました。当時は、サーバー1台あたり毎秒1,000件のリクエストに制限されていました。毎秒10,000件以上の場合と比べて、どれほど大きな負担だったかは容易に想像できます。

Wordpress.comは複数のF5 BIG‑IPシステムを使用しており、データセンターを10拠点に増やす予定でした。高可用性を確保するため、つまり各データセンターに稼働中のバックアップを用意するには、BIG‑IPサーバーが10ペア必要になると見込まれていました。これは非常に高額です。また、設定変更時にユーザーを切断しないよう、稼働中に再設定できる機能も必要でした。

まず、ユーザーのアバターを表示するアプリであるGravatarでNGINXをテストし、移行に着手しました。これによりNGINXに習熟した後、F5サーバーからNGINXへ移行し、メモリとCPUのフットプリントを小さく予測可能な範囲に抑えられるようになりました。

現在では、36台のNGINXサーバーで毎秒70,000件を超えるリクエストと15ギガビット毎秒［Gbps］のトラフィックを処理しています。サーバー1台あたり毎秒20,000件のリクエストをピーク時に処理でき、稼働中でも再構成や更新が可能です。

見積もりを見ると、ここで述べているのは小規模な導入における費用の差にすぎませんが、それでもNGINXによって大幅なコスト削減が可能です。しかし、サーバーを10ペアに増やすと、その差は歴然とします。

16:42 お客様事例 – Montana Interactive

Montana Interactiveは、高可用性を実現するロードバランシングにNGINX Plusを採用しています。実際、多くの行政サービスはオンラインで提供する方が、より簡単かつ低コストで、利便性も高まります。自動車管理局などでオンライン予約をしたことがあれば、その意味がお分かりになるでしょう。こうしたWebサイトでは、投票や納税などの手続きを行えます。

こうした必要不可欠な行政サービスは非常に多岐にわたります。また、モンタナ州は非常に広大で、比較的少ない人口が州内各地に分散しています。そのため、住民が行政機関まで6時間も8時間も車で移動せずに済むよう、サービスをオンラインで利用できることが非常に重要です。

モンタナ州は当初、オンラインサービスへの移行を積極的に進めていましたが、サービスの拡大に伴い、セッション切断の問題が発生するようになりました。大規模な税金支払いアプリの利用により、四半期ごとにトランザクショントラフィックが急増していたためです。長いフォームへの入力中に突然セッションが切断され、それまでの作業がすべて失われることもありました。納税手続きなど、手間のかかる処理の途中でこのような事態が起きれば、大きなストレスになります。

同州が採用した解決策は、Poundを実行するサーバーからNGINX Plusへアップグレードし、異なるハイパーバイザーやデータセンターにNGINX Plusを配置して、リクエストをリアルタイムでルーティングする動的リバースプロキシとして運用することでした。これにより、トラフィック管理が向上しました。NGINX Plusへの移行後、速度、柔軟性、使いやすさが大幅に向上しました。また、稼働中の再構成が可能になり、SSL処理をNGINXサーバーにオフロードしたほか、ロールベースの管理によって運用とセキュリティを改善しました。

Montana InteractiveのJames Ridle氏は、NGINXの性能に驚嘆しました。ベンチマーク結果は衝撃的で、同じサーバーでもNGINXを使用することで処理能力にこれほどの差が生まれるとは、にわかには信じられないほどでした。

18:43 お客様事例 – BuyDig.com

こちらも、お客さまに大きなメリットをもたらした事例です。eコマースサイトのBuyDig.comは、NGINXによってスケーラビリティとセキュリティを実現しました。

BuyDig.comでは、古い.NETアプリを使用していました。変更は望んでおらず、実際に変更する必要もありませんでした。大規模なDDoS攻撃を受けたことで、パフォーマンス、セキュリティ、スケーラビリティに優れ、高速で耐障害性があり、設定しやすいフロントエンドが必要だと認識しました。

Amazon Web Servicesでホストされているフロントエンドアプリケーション層にNGINX Plusを導入しました。.NET上で稼働するバックエンドサービスには一切変更を加えていません。これは非常に大きな意味を持ちます。変更が小さかった、手間やリスクがわずかだったということではなく、まったくなかったのです。

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

以上は、NGINX Plusで実現できることのほんの一例です。

20:10 eBook – ロードバランシングをソフトウェアに切り替えるべき5つの理由

それでは、eBookの内容を詳しく見ていきましょう。まず、eBookの概要を簡単にご紹介します。続いてFaisalが、より技術的な内容である切り替えの最初の2つの理由について説明し、その後は再び私が引き継ぎます。リンクも用意されています。このプレゼンテーションとウェビナーの録画は、終了後にご覧いただけるようになります。ご案内メールの送信には1日ほどかかる見込みです。

こちらのリンクから、この無料eBookのダウンロードページにアクセスできます。切り替える理由をあらかじめ簡単にご紹介すると、コスト削減、DevOpsとの親和性向上、あらゆる環境へのデプロイ（自社のオンプレミスサーバー、クラウド、プライベートクラウドなど、希望する任意の環境）、迅速な適応、そして不合理な契約上の制約がないことです。これらについては後ほど詳しく説明します。それでは、コスト削減についてFaisalからご説明します。

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

Faisal: ありがとうございます、Floyd。5つの理由のうち1つ目は、ソフトウェアによるアプリケーションデリバリーをNGINX Plusに移行することで、コストを大幅に削減できることです。

1990年代半ばを振り返ると、Webサイトをスケールさせる唯一の方法は、より大規模なサーバーを購入することでした。しかし、これは非常に高額なうえ、その1台のサーバーが単一障害点にもなるため、信頼性にも欠けていました。

ちょうどこの頃、F5はBIG‑IPを初めてリリースし、Webサイト運営者に従来とは異なるアーキテクチャを提供しました。より大規模なサーバーを購入する代わりに、BIG‑IPを使用して複数の低価格なサーバー間で負荷を分散できるようになったのです。BIG‑IPと低価格なサーバーを組み合わせる方が、1台の巨大なサーバーを購入するよりも安価なため、コストを削減できます。また、単一障害点が解消されるため、冗長性も確保できます。

これは優れたアーキテクチャでした。当時としては画期的で、事実上ほかに選択肢はありませんでした。しかし、この20年間で多くのことが変わりました。大きな変化の1つは、サーバーの価格が劇的に下がったことです。今では、かなり高性能なサーバーでも、ここサンフランシスコ・ベイエリアの家賃1か月分より安く購入できます。

2つ目の大きな変化は、F5 BIG‑IPやCitrix NetScalerと同等の機能を提供するNGINXのようなオープンソースソフトウェアが登場したことです。オープンソースなら、こうした高価な大型アプライアンスと同様の機能を無料で利用できます。先ほどFloydが指摘したように、NGINXを使用しているWebサイトは1億6,000万を超えています。また、上位10,000サイトに目を向けると、その半数以上がNGINX上で稼働しています。

このように、現在では、F5と比較して必要な機能をすべて備えているだけでなく、他の商用製品と同等の拡張性と信頼性を持つオープンソースソフトウェアを利用できます。

23:19 NGINX PlusとF5 BIG‑IPの比較

今年初めにベンチマークとコスト分析を実施しました。ここでは、その一部をご紹介します。Dellが提供する市販の汎用ハードウェア上で稼働するNGINX Plusソフトウェアと、F5 BIG‑IPの各種モデルを比較しています。

この例で取り上げるのは、F5 BIG‑IPのエントリーレベルモデルである2000Sです。これを、Dellサーバー上で稼働する2つの異なる構成のNGINX Plusと比較しました。一方はF5 BIG‑IPをわずかに下回るパフォーマンス（下部にパフォーマンス指標が表示されています）で、もう一方は約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のどちらにも、コンテンツキャッシュと圧縮が追加料金なしで含まれています。そのため、ここではNGINX Plusが提供する機能とより同等に比較できるCitrix NetScalerのEnterprise Editionを対象としています。Citrix NetScalerをNGINX Plusに置き換えることで、F5の場合と同様のコスト削減が見込めます。

期待される機能とパフォーマンスをすべて同等に得ながら、1年目のコストを89%削減できます。5年目の時点でも、ハードウェア（この場合は汎用Dellサーバー）の費用とNGINX Plusソフトウェアのサブスクリプション費用を合わせて75%削減できます。

重要な指標の1つであり、ハードウェアベンダーが頻繁に取り上げるのが、1秒あたりのSSLトランザクション数、つまり1秒間に確立できる新規SSL接続数です。これらのプラットフォームでは通常、この処理をハードウェアで高速化します。そのため、NetScalerとF5 BIG‑IPにはSSLトランザクションを高速化する専用ハードウェアが搭載されており、プラットフォームのコスト上昇につながっています。

ソフトウェアソリューションでも、ハードウェアアクセラレーションを使用せず、CPUの処理能力だけで専用ハードウェアに匹敵する性能を発揮できることがわかっています。ハードウェアアクセラレーションを利用するソリューションと同等の性能を維持しながら、コストを大幅に削減できます。

つまり、理由その1は、NGINX Plusへの移行によって大幅なコスト削減が可能になることです。しかし、メリットはコストだけではありません。

26:52 理由#2 – DevOpsにはソフトウェアによるアプリケーションデリバリーが必要

ソフトウェアベースのソリューションには高い柔軟性もあります。ソフトウェアベースのロードバランサーに切り替える2つ目の理由は、DevOpsへ移行する場合、アプリケーションデリバリにソフトウェアが不可欠だからです。

F5とNetScalerのアプライアンスは、大企業では通常、集約ポイントとして導入されます。そのため、関連性のない多様なトラフィックが同じアプライアンスを経由します。1台の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ポリシーによる制約を回避する方法の1つです。そして多くのお客さまは、これを試した後、より高度な機能とサポートを利用するためにNGINX Plusへ移行し始めます。

NGINXは、現在のF5をそのまま維持する構成を含め、柔軟で多様な導入モデルに対応しています。F5で社内メールサーバーのネットワーク負荷分散を継続しながら、NGINX Plusで外部向けWebアプリケーション、API、マイクロサービスの負荷分散と配信を補完し、処理をオフロードできます。ネットワークサービスやネットワーク負荷分散が不要な場合は、F5をNGINX Plusに置き換えて、単一のソリューションに統合することもできます。

組織のDevOps、継続的デリバリー、自動化への移行を支援するため、さまざまな導入モデルをサポートしています。

理由その3については、Floydに説明を戻します。

31:59 理由#3 – 1つのADCであらゆる環境に導入

Floyd:ありがとうございます、Faisal。

NGINXなら、1つのADCソリューションであらゆる環境に導入できます。「あらゆる環境」とは何でしょうか。オンプレミスサーバー、パブリッククラウド、プライベートクラウド、ハイブリッドクラウドのすべてを、1つのソリューションで運用できるということです。これには、実用面とアーキテクチャ面の両方があります。

まず、社内サーバーを使用し、クラウドを利用していない場合にも、これまで説明してきた内容がそのまま当てはまります。柔軟性の向上、機能の拡充、コスト削減を目的にNGINXやNGINX Plusへ移行する多くの方が、まさにこの状況にあり、社内サーバーに導入しています。

今後クラウドを利用する場合、または利用を検討する場合、NGINXとハードウェアADCでは比較になりません。ハードウェアADCをAmazonのデータセンターに移行することはできず、クラウド環境では役に立ちません。

ハードウェアADCの開発元もソフトウェアベースのソリューションを提供していますが、場合によっては開発用途での使用のみを推奨しています。これはハードウェアADCの代替にはなりません。シンプルさや「問題がなければ変えない」という点でメリットがあるように見えても、クラウドへの移行を検討すると、そのメリットは失われます。

NGINXとNGINX Plusを使用すれば、アプリケーションアーキテクチャをデリバリープラットフォームから独立させることができます。一部のクラウドプロバイダーは、APIを介して連携できるサービスを次々と追加しています。開発時には、実装方法を気にすることなく、プロバイダーのAPIを利用して負荷分散やキャッシュなどの機能を処理できるため、非常に便利です。しかし、規模を拡大すると、トランザクションごとに少額の料金が発生します。

ところが、トランザクション数が数千、数万、数十万と増えるにつれ、料金はあっという間に膨らみ始めます。特に、常に変動するトラフィックに基づいて課金されるため、料金体系は非常に分かりにくく、予測も困難です。

NGINXまたはNGINX Plusをベースとしたアプローチを採用すれば、基本的にどのプラットフォームでも同じ方法で対応でき、別のクラウドプロバイダーへ移行する場合も、オンプレミスへ戻す場合も、ほとんど違いはありません。

実際に、社内サーバーとクラウドにまたがって負荷分散を行っているお客さまもいます。具体的には、通常の80～90%の時間帯に必要な処理能力をまかなえるだけの社内サーバーを用意します。その後、スケールアップが必要になった場合でも、新しいサーバーを購入したり接続したりする必要はなく、クラウドへと拡張するだけです。

通常、クラウドはオンプレミスのサーバーより低速です。すべてが負荷分散されるため、社内サーバーだけを使用していた場合に切断されるセッションのみがクラウドに送られます。レイテンシーは若干長くなりますが、セッションは処理され、キューに入れられたり切断されたりすることはありません。

コスト面でも大きなメリットがあります。トラフィックの急増など、緊急時に限ってクラウドの利用料金を支払えばよいためです。トラフィックの急増は、報道で取り上げられたり、製品が高く評価されたりした場合に発生することがあります。また、事業計画を継続的に上回る需要があるものの、それに対応するための社内サーバーの増強がまだ済んでいない場合もあります。あるいは、年末年始など、年に数週間しか必要としないサーバーを2倍に増やすよりも、クラウドへスケールアウトする方が合理的な場合もあります。NGINXを使用すれば、こうした対応をすべて柔軟に、さらには自動的に行うことができます。

35:42 理由 #4 – 変化する需要に迅速に対応

NGINXを使用すれば、アプリケーションに対する変化する要求に迅速に対応できます。サーバーや高可用性を確保するためのサーバーペアを早急に追加する必要がある場合、ハードウェアの発注、配送、受領、テストを待ち、その後にiRulesやその他の必要なソフトウェア設定を行う余裕はありません。また、iRulesは独自仕様であり、必要になるのはF5サーバーを使用している場合に限られます。大学を卒業した人材から、このスキルを持つ人を簡単に採用できるわけではありません。iRulesの担当者が退職すると、後任を見つけるのは非常に困難です。

構成を変更する際、ネットワーク運用部門の承認を待っていられないことも少なくありません。緊急性の低い案件と同じキューに入れられ、変更が後回しになるのは避けたいものです。

NGINXなら、新規プロジェクトの承認に伴う負担を大幅に軽減できます。2,000ドルや3,000ドル程度のサーバーであれば、NGINXとNGINX Plus用の予備ハードウェアを保管しておくことも可能です。しかし、数万ドル以上するハードウェアADCでは、そうはいきません。

このような柔軟性と冗長性、そして必要なときに必要なことを実行できる能力は、NGINXの中核的な特長であり、多くのユーザーから高く評価されている理由の1つです。

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

最後に、NGINXには、人為的な制約や契約に起因するパフォーマンス上の制約はありません。NetScaler Enterprise Editionでは、そのサーバーのスループット上限が契約上0.5 Gbpsに制限されています。エンタープライズ環境としては、あまりに非現実的な制限です。一方、業界標準のハードウェアで稼働する同等のNGINX構成は、20 Gbpsをサポートします。これはCitrixの上限の40倍です。

もう1つの違いは、Citrixの数値が契約上の制約である点です。この数値を超えると、支払額が突然かつ大幅に増加します。一方、20 GbpsはF5が推奨する目安です。この水準に達すると、パフォーマンスが多少低下し始める可能性があるため、サーバーを追加して負荷を分散することを検討できます。ただし、柔軟に判断でき、決定するのはお客さまです。予算が突然圧迫されることはありません。

Citrixでは、まるで一時停止標識に行く手を阻まれるようなものです。この場合、ビジネスの拡大が悪い知らせになりかねません。顧客が1社増えただけでも、あるいは数社増えただけでも、上限を超えて多額のコストが発生する可能性があります。一方、NGINXを使用している場合、ビジネスの拡大は良い知らせです。顧客基盤の拡大によって収益が増えるのに伴い、コストも緩やかに増加します。

こうした上限を超え、突然予算オーバーになった方から、緊急のご相談をいただくことがよくあります。大幅な変更を行わなければ、予算内に戻すことはできません。そのため、急いでNGINXに移行して状況を立て直す必要があります。NGINXによって大幅にコストを削減でき、結果的に予算を下回るケースも少なくありません。

しかし、わざわざそのような頭痛の種を抱える必要があるでしょうか。予算とパフォーマンスの深刻なトレードオフに突然直面したときの不確実性や不安も同様です。早い段階でNGINXに切り替えれば、こうした悩みから完全に解放されます。