クラウド

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日間のトライアルをお試しください。

高可用性AWSロードバランサーとして、NGINX Plusを導入する

※本記事はNGINX,Inc.のブログ記事「Deploying NGINX Plus as a Highly Available AWS Load Balancer」を和訳した内容となります。
【URL】
https://www.nginx.com/blog/nginx-plus-highly-available-aws-load-balancer/

ロードバランサーは、多くの場合Webアプリケーションへの単一の入口として機能し、アプリケーション配信基盤の重要なコンポーネントとなります。 つまり、ロードバランサーのダウンタイムは、アプリケーションのダウンタイムを意味します。 ダウンタイムとそれに伴う利用者の不満を最小限に抑えるために、ロードバランサーを高可用性(以下HAと表記)を担保して展開する必要があります。

 

このブログ記事では、AWS用ロードバランサーとしてNGINX Plus の高可用性を実現するために使えるいくつかの方法を比較します。オンプレミス展開で提供するkeepalivedベースの高可用性ソリューションは、すでに精通されているかもしれません。ただし、一般的なAWSやクラウド環境では、ネットワーク制限により、クラウド上でkeepalivedベースのソリューションを使用できません。とはいうものの、AWSではNGINX Plusの高可用性を実現するための他のオプションを提供しています。たとえば、導入ガイドに記載されているように、オンプレミスのkeepalivedソリューションをAWSで動作するように変更することができます。

 

高可用Active – Active構成のNGINX PlusとAWS ネットワークロードバランサー(以下NLBと表記)を組み合わせたソリューションもあります。 この記事で論じる方法は、コミュニティ版のNGINXとNGINX Plusの両方に当てはまりますが、簡潔にするために、以下、ブログではNGINX Plusだけ取りあげます。 以下の表では、この記事で説明する4つの方法をまとめています。

  • このブログ記事は、NGINX PlusのAWSロードバランサーとしての側面、NGINX Plusの高可用性を実現することに重点を置いています。他のAWSのトピックスの詳細については、以下を参照してください。
  • AmazonEC2にNGINX Plus AMIをインストールする(英語)
  • AWS上のNGINX PlusとAmazon Elastic Load Balancing(英語)
  • Amazonで正しいロードバランサーを選択する:AWSアプリケーションロードバランサー(英語)
  • NGINX Plus with AWS Cloudクイックスタート(英語)
  • NGINX Plusを使用したAWS Auto Scalingグループのロードバランシング(英語)
  • AWSパフォーマンスをもっと早くするための5つのヒント(英語)

ELBを使用したNGINX Plusの高可用性

AWSの基本的な組み込みロードバランサであるELB(Elastic Load Balancer、正式にはクラシックロードバランサと呼ばれています)は、機能は限られていますが、高可用性を実現します。このため、図に示すように、ELBを活用してNGINX Plusの可用性を高めることができます。

すべてのNGINX Plusインスタンス間でトラフィックを負荷分散するようにELBを設定します(アプリケーションインスタンスへのトラフィックをロードバランシングします)。NGINX Plusインスタンスの1つに障害が発生すると、ELBはそれを検出し、障害インスタンスへのトラフィック送信を中止します。ELBがNGINX Plusインスタンスの障害を迅速に検出できるようにするには、ELBヘルスチェックを構成することが重要です。

ELBはActive-Activeの高可用構成を提供します。つまり、すべてのNGINX Plusインスタンスが稼働し、共有するトラフィックを受信することを意味します。StandbyのNGINX Plusインスタンスをデプロイしないことで、全体的なコストが削減されます。 ただし、HTTPロードバランサーとして配置されたELBは、HTTP / 2またはWebSocketプロトコルをサポートしていません。

これらのプロトコルをNGINX Plusで使用する必要がある場合は、ELBをTCP(HTTPではなく)ロードバランサーとして配置する必要があります。

このケースでクライアントのIPアドレスをELBからNGINX Plusに渡す必要がある場合は、ELBとNGINX Plusの両方でプロキシプロトコルも設定する必要があります。

NGINX Plusの高可用構成にELBを使用する場合、いくつかの欠点があります。

  • ELBは静的IPアドレスを公開しませんが、これは、一部のアプリケーションにとって重要な要件です。
  • ELBはロードバランシングを一段追加するので、複雑さとコストを増加
    させます。
  • ELBはUDPをサポートしていないため、UDPトラフィックの負荷分散にNGINX Plusを使用することはできません。
  • ELBはすぐに拡張できないため、トラフィックが急増すると、トラフィックが落ちる可能性があります。
  • ELBのIPアドレスはDNS CNAMEレコードを使用して公開されます。

つまり、すべてのDNSをRoute 53に委任しない限り、ルートドメイン(example.comなど)をCNAMEにマップすることはできません。

 

新しいネイティブのAWSロードバランサー、Application Load Balancer(ALB)も同様の方法で使用できます。ELBよりも多くの機能と柔軟性がありますが、上記の欠点も同じくあてはまります。

Route53を使用したNGINX Plusの高可用性

ELB同様、Route 53も図に示すように、 Active-Active構成のNGINX Plus導入を可能にします。

ELB同様、Route 53も図※に示すように、 Active-Active構成のNGINX Plus導入を可能にします。 ホストされたゾーンを作成し、レコードを追加して、すべてのNGINX Plusインスタンスにトラフィックをルーティングできるようにします。NGINX Plusインスタンスに対する、Route 53 のヘルスチェック設定を確認してください。NGINX Plusインスタンスの1つが停止した場合、Route 53はそのインスタンスに関連付けられたレコードをDNSクエリへの応答から除外します。ただし、クライアントと中間DNSサーバーは、正式なDNSサーバーによって設定された各レコードの有効期間(TTL)値に従ってレコードをキャッシュします。TTLの有効期限が切れるまではレコードを更新しないので、権限のあるサーバーが応答からNGINX Plusインスタンスのレコードを削除したときにも、すぐには通知しません。この問題を回避するには、NGINX Plusレコードには、最小TTL値を設定する必要があります。

詳細な手順については Route 53 導入ガイド(英語)を参照してください。

Active-Active構成に加えて、Route 53では、AWS ドキュメンテーションで説明されているように、Active-Passive構成またはさらに複雑なフェールオーバーの組み合わせを作成できます。 また、このブログの記事で説明されている他の方法を用いて、Route 53を使用することも可能です。 

ELBまたはRoute53を使わないNGINX Plusの高可用性

いくつかの理由から、NGINX Plusの高可用性を実現するために、ELBまたはRoute 53に頼りたくないかもしれません。1つの代替案は、Active-Passive構成でNGINX Plusを導入し、AWSのElastic IPアドレス機能を使用することです。ここでは、NGINX Plusの固定IPアドレスを公開し、プライマリ(ActiveまたはMaster)NGINX Plusインスタンスに関連付けます。スタンバイモードまたはバックアップモードの2番目のNGINX Plusインスタンスはトラフィックを処理しませんが、マスターNGINX Plusインスタンスに障害が発生したときには、引き継ぐ準備ができています。引継ぎ(フェイルオーバー)の間、Elastic IPアドレスは第2のインスタンスに再度割り当てられ、第2のインスタンスがマスターとみなされます。

Elastic IPアドレス方式の弱点は次の通りです。

  • バックアップインスタンスは、ほとんどの時間使用されていないため、導入コストが増加します。
  • 一般的なオンプレミス構成とは対照的に、固定IPアドレスの再関連付けは即時ではありません。テストでは、IPアドレスを新しいマスターインスタンスに再関連付けするまでに最大6秒かかりました。
  • この構成は、マスターのNGINX Plusインスタンスの正常性を監視し、マスター障害時にElastic IPアドレスを再関連付けするためのソフトウェアをインストールして、適切に構成する必要があるため、ELBまたはRoute 53の方法よりも複雑です。

 

NGINX, Inc.は、Elastic IPアドレスを使用する2つのソリューションを提供しており、それらはマスターNGINX Plusインスタンスの状態を監視する方法と、Elastic IPアドレスを再関連付けする方法で異なります。

  • keepalivedベースのソリューション

導入ガイドで説明しているように、keepalivedベースのソリューションをオンプレミス展開に変更し、AWSでElastic IPアドレスの再関連付けをサポートすることができます。オンプレミスのHA構成と同様、バックアップのNGINX Plusインスタンス上のkeepalivedデーモンは、マスターインスタンスの正常性を監視します。オンプレミスのソリューションとの違いは、マスター障害時にkeepalivedがカスタムスクリプトを起動して、Elastic IPアドレスを再関連付けするAWS APIを呼び出すことです。このソリューションは、NGINX Plusサポート契約の対象外であることにご注意ください。

  • AWS Lambdaベースのソリューション

Lamba機能を使用してNGINX Plusマスターインスタンスの正常性を監視し、マスター障害時にはElastic IPアドレスを再関連付けします。
このソリューションに関しては、NGINXのプロフェッショナル・サービスチームによるソリューションの導入、設定、さらにサポートをご提供しています。
また、高可用性Active-Active構成のNGINX Plusと AWS Network Load Balancer (NLB)を組み合わせたソリューションもあります。

まとめ

高可用性は、AWSロードバランサーには非常に重要です。このブログ記事で説明してきたように、AWSではNGINX Plusの高可用性を実現するための方法を複数用意しています。 ELBまたはRoute 53に基づく方法はよい出発点です。固定IPアドレスが必要な場合は、keepalivedまたはAWS Lambdaに基づくElastic IPを使う方法をご利用ください。

AWS上でNGINX Plusを使うのは初めてですか? ぜひ、30日間無料でお試しください。利用可能なAMIへのリンクについては、Amazon EC2上でのNGINX PlusAMIのインストールを参照して下さい。

NGINX PlusとAWSネットワークロードバランサーで実現する、All Active構成での高可用性ソリューション

※本記事はNGINX,Inc.のブログ記事「Deploying NGINX Plus and AWS Network Load Balancer in an All-Active, Highly Available Solution」を和訳した内容となります。
【URL】
https://www.nginx.com/blog/deploying-nginx-plus-and-aws-network-load-balancer-in-an-all-active-highly-available-solution/

NGINXは、Amazon Web Services(以下AWS)向けに、新たに推奨の高可用性(HA)ソリューションを発表しました。このソリューションでは、新しいAWSネットワークロードバランサー(AWS NLB)を利用して、AWS上のWebアプリケーションのパフォーマンス、信頼性、スケーラビリティーを向上させます。

AWSのアプリケーション展開の規模は急速に拡大しています。以下は、Amazonの主要な
リソースです。:

 

また、NGINXでも、AWSに関する幅広いリソースを準備しています。

AWS NLBは、基本的なレイヤ4ロードバランシングに、迅速で効果的なソリューションを提供します。 NGINXは、AWSの新機能とNGINX Plusとの統合性に対し、またAWS上でNGINX Plusの可用性を大きく高めてくれる推奨ソリューションとして、とても感銘を受けています。 このインテグレーション事例の紹介として、AWS NLBとNGINX Plusを組み合わせるための導入ガイドを以下に公開しています。

 参考:導入ガイド 

このリソースは、AWSの大規模な導入は始めての方にも、経験豊かなプロの方にも非常に役立ちます。導入ガイドの手順に沿って利用すると、さまざまなアプリケーション導入の課題を処理するソリューションを作成できます。

  • 新しいAWS NLBによるレイヤ4の高速ロードバランシング
  • AWS Elastic IPアドレスのサポート
  • NGINX Plusインスタンスでの高可用、All-Activeのレイヤ7ロードバランシング。 NGINX Plusは、コンテンツベースのルーティング、高度なロードバランシングアルゴリズム、キャッシング、リアルタイムの設定変更、セッション・パーシステンス(セッション永続性)、アプリケーション認識のヘルスチェックをサポート。
  • アプリケーションコードを効率的に実行するために、オープンソースのNGINXソフトウェアを実行する複数のサーバーインスタンス。
  • AWSオートスケーリング、サーキットブレーカーパターンなどのサポート。

このAWS上の新しいロードバランシングソリューションは、NGINX Plusを使って、パワーと高度な機能を提供します。AWS NLBに従い、基本的なレイヤ4ロードバランシングを処理します。残りのソリューションにNGINX Plusを活用することで、比較的安価に、堅牢なロードバランシングソリューションをAWS上に作成できます。

 

このソリューションは、オンプレミス(ベアメタル、コンテナ、または仮想マシン)およびその他のクラウド環境に展開され、高可用性を誇る一連のNGINX Plusロードバランシングソリューションに加わるものです。そのアーキテクチャは、Google Cloud Engine(GCE)向けに all-activeかつ高い可用性を実現している、NGINX Plusベースのロードバランシングアーキテクチャに似ています。またGCEではレイヤ4ロードバランシングにGoogle Cloud Engine(GCE)ネットワークロードバランサを使っています。 NGINX Plusをお試しいたいただくには、今すぐ無料の30日間のトライアルを開始するか、当社までご連絡ください。それから、導入ガイドのステップバイステップの手順に従って、AWS NLBとNGINX Plusを設定してください。