NGINX Plus

NGINX Plusを使用した3つのクラウドアーキテクチャー

※本記事はNGINX,Inc.のブログ記事「3 Cloud Architectures with NGINX Plus」を和訳した内容となります。
【URL】
https://www.nginx.com/blog/cloud-architectures/

クラウドへの移行をご検討中でしょうか?クラウドへの移行には、多くのメリットと同時に、いくつかデメリットもあります。一部の企業では、会社のファイアウォール外にデータをホストすることは契約違反です。でも、ほとんどの場合では、自分のハードウェアを管理する必要がないという利点の重みは、絶対的なコントロールを失うといった欠点をはるかに上回っています。最近の調査によると、このことはIT責任者にとって、ますます明らかになりつつあるようです。今後2年間で、エンタープライズのIT支出の3分の1ががクラウドに向かうことが予測されている(英語ページ)のです。

クラウドへの移行を検討している場合、またはそうでない場合でも、今はアプリケーションのアーキテクチャーについて考え始めるのによい時期です。よく知られた問題を抱えたまま、盲目的にアプリケーションをクラウドに移行させるよりは、この新しいタイプの環境でよりスムーズに動作するよう、アプリケーションスタックを更新してはどうでしょうか?アプリケーション・デリバリー戦略は、再評価プロセスを開始するのに最適なスタート地点です。優れたアプリケーション配信は、あなたに忠実なお客様を得るか、競合他社の新しいお客様にしてしまうかの違いを生むのです。

オンプレミスでアプリケーションをホストする場合、ハードウェアのアプリケーション デリバリー コントローラー(以下ADCと表記)を使う可能性が高いはずです。ハードウェアADCはオンプレミス環境ではうまくいくかもしれませんが、クラウドにハードウェアを置くことはできません。
従来のハードウェアADCベンダーのほとんどは、自社製品の仮想バージョンを持っていますが、
クラウドに移行するなら、クラウドを念頭に置いて作られた最新のADCを試してみてはいかがでしょうか。

NGINX Plusは、現代のWebから誕生した、エンタープライズグレードのソフトウェアのADCです。NGINX Plusは軽量で、アプリケーションを完璧に届けるために必要なすべての機能を備え、
使いもしない機能にコストを強いることもありません。NGINX PlusはハードウェアADCのコストのほんの一部分で利用でき、機能を遅くする帯域幅やSSLの制限はありません。

クラウドコンピューティングの調査を始めるための参考に、NGINX Plusの機能を活用した、
いくつかのクラウドアーキテクチャーをご紹介します。

シンプルクラウドバースト

一度にすべてをクラウドに移行することが危険すぎるようであれば、より混乱しにくい方法として
ハイブリッド展開を考えてみてください。このタイプの構成では、オンプレミスとクラウドサービスの両方を使って、アプリケーションを提供します。

NGINX Plusの最小時間ロードバランシング・アルゴリズム(英語ページ)を使用すると、すべての
オンプレミスサーバーがビジー状態のときに、トラフィックがクラウドに送信される
「クラウドバースト」構成を構築できます。

 

ローカルサーバーがすべてビジー状態のとき、NGINX Plusはクラウドにトラフィックを送信します。

最小時間アルゴリズムでは、NGINX Plusは、各サーバーに対して2つの数値(現在のアクティブな接続数と、過去のリクエストに対する加重平均した応答時間)を数学的に結合し、最小値だったサーバーにリクエストを送ります。
最小時間だと、ローカルサーバーの応答が速いため、そちらに多くのリクエストを送信する傾向が
あります。ローカルサーバーにリクエストを送り続けて、ネットワークの余分なレイテンシーの分を含めてもなお、クラウドサーバーがローカルサーバーよりも迅速に応答する点まで行くと、
NGINX Plusはクラウドサーバーへリクエストを振り向け始めます。ローカルサーバーの負荷が
再び
小さくなると、NGINX Plusは、ほとんどのリクエストの振り向け先をローカルサーバーに戻します。

 

ローカル・ロードバランシング

多くのパブリッククラウドベンダーは、世界中に地域ごとのデータセンターを持ち、そのいずれか、またはすべてにアプリケーションをホストすることができます。たとえば、Amazon Web Services、北米、南米、ヨーロッパ、アジアに9つのデータセンターあります。
フォールトトレランスのために、クラウドベンダーは各地域のデータセンターに「可用性ゾーン」を設定しています。可用性ゾーンには、独立した電源、ネットワーキング、冷却装置などを備え、物理​​的に分離されたハードウェアのラックがあります。たとえば電力を失うなどして、ある可用性ゾーンに障害が発生した場合、稼働中の可用性ゾーンが代わりを務めることができます。
可用性ゾーンをまたいでアプリケーションを複製することで、アプリケーションの可用性を
高めることが可能です。
可用性ゾーンをまたいでアプリケーションを複製することにより、高可用性を実現

上記のクラウドアーキテクチャ図では、クラウドベンダーのネイティブなロードバランサー
(Amazon Web Servicesの
ELB、Google Cloud Platformのロードバランサー、またはMicrosoft AzureのAzure Traffic Manager)がトラフィックをさまざまな可用性ゾーンに分散しています。
それぞれの可用性ゾーン内で、NGINX Plusはアプリケーションサーバーへの負荷分散を行います。NGINX Plusの背後にあるアプリケーションは、モノリスでも、マイクロサービスベースの
アプリケーション、またはそれらの中間のものでも構いません。

 

グローバル・ロードバランシング

アプリケーションを複数の可用性ゾーンにまたがって複製することで、地域内での高可用性が
実現します。次のステップは、複数の地域でアプリケーションをホストすることです。
アプリケーションをユーザーの近くに移動すると、ネットワークのレイテンシーの
影響が軽減され、全体的なユーザーエクスペリエンスが向上します。グローバルに分散されたアプリケーションを構築するには多くの方法があります。
一般的な方法の一つは、地理的な位置情報ベースのDNS(GeoDNS)ソリューションを使うことです。GeoDNSソリューションを使うと、ドメインの権威DNSサーバーがクライアントの応答を形成するとき、クライアントの位置を考慮して、最も近いデータセンターにクライアントを送信します。

NGINX PlusとGeoDNSは、グローバルに分散したアプリケーションを構成します

AmazonのRoute 53など、利用可能なGeoDNSソリューションはたくさんあります。
それらをNGINX Plusと組み合わせることで、グローバルに分散した、スケーラブルな
アプリケーションを作成できます。
上記の図では、GeoDNSはカリフォルニアのユーザーを
米国西部データセンターに誘導し、
ニューヨークのユーザーは
米国東部データセンターに誘導しています。各データセンター内で、
NGINX Plusは入ってくるトラフィックをアプリケーションサーバーに分散します。

 

結論

クラウドへの移行を検討している場合は、アプリケーション・デリバリー戦略も再考することが
理にかなっています。ハードウェアADCは、オンプレミス構成ではうまくいくかもしれませんが、
クラウドアーキテクチャの一部にすることはできません。大部分のハードウェアADCベンダーは
自社アプライアンスの仮想バージョンを提供していますが、不必要に高価で、クラウドでは
必要のない機能にコストを支払うことになります。さらに、仮想バージョンは通常、一部の
クラウドしかサポートされませんが、NGINX Plusなら、クラウドを選ばず実行できます。

NGINX Plusは、クラウド上で動作するように設計されたソフトウェアADCです。
仮想ハードウェアADCのコストのほんの一部で利用できますが、実際に必要とされるすべての機能を備えています。

クラウドアーキテクチャでNGINX Plusがどう最適なのか、ご自分で確認されたいですか?
すぐに
無料の30日間のトライアルをお試しください。

ホワイトペーパー「ロードバランシングをソフトウェアに切り替える 5つの理由」

現代のITインフラ担当者は、ベアメタル、クラウド、コンテナなど様々な環境が混在する中、急激なトラフィックの増加やアプリケーションの迅速な展開といったWebサービスの課題に頭を悩ませています。Webの先進的な企業では、ハードウェアベースのアプリケーション デリバリー コントローラー(ADC)から、ソフトウェアベースのWebサーバーやロードバランサー、キャッシュサーバーに移行することでこの課題を解決しています。


現代のITシステムが求める高い柔軟性やスピード、コストパフォーマンスを満たすには、ソフトウェアが圧倒的に優位です。 このebookでは、IT責任者、ネットワーク担当者、アプリケーション開発者が、ハードウェアADCからソフトウェアソリューションに移行することで得られるメリットと優位性、ビジネスへの影響について、以下の5つの観点から解説します。


■目次■

1. 機能や性能を損なうことなくコストを劇的に削減します 

2. DevOpsへの移行にはソフトウェアベースのアプリケーションデリバリーが必要です

3. 1つのADCソリューションで、ベアメタル、クラウド、コンテナなど、どこにでも展開します 

4. アプリケーションへのニーズの変化に素早く対応します 

5. 性能に対して、意図的に制限を課したり、契約で制限を設けたりすることはありません


ダウンロード

コメントを残す

*