ブログ

catch-img

NGINX ロードバランサーの導入シナリオ

本内容は「NGINX Load Balancing Deployment Scenarios」ブログを翻訳したものです。

NGINX Plusがロードバランサーやアプリケーションデリバリーコントローラー(ADC)として使用されるケースが増えており多くのユースケースが存在します。この記事では最も一般的なシナリオについて説明します。

<目次>

目次[非表示]

  1. 1.はじめに
  2. 2.シナリオ1:NGINX Plus ですべての負荷分散を行う
  3. 3.シナリオ2:従来のロードバランサーと並べてNGINX Plusを利用する
  4. 4.シナリオ3:従来のロードバランサーの後ろにNGINX Plusを置く
  5. 5.ハードウェアロードバランサーで多数のアプリケーションを制御する場合の課題
  6. 6.複数のプロキシ レイヤーを使用することが理にかなっている理由
  7. 7.まとめ

はじめに

多くの企業がアプリケーションを公開する際に、ハードウェアロードバランサーからNGINX Plus に移行しようとしています。これには様々な要因が考えられます。


  • アプリケーションチームに運用を任せるため
  • 仮想基盤やクラウド環境に移行するため
  • ハードウェアロードバランサーとは連携が難しいDevOpsツールを採用するため
  • 柔軟性を備えたスケールアウトできるインフラ環境を作るため

等がそれにあたります。

この記事を読んでいる皆様がロードバランサーを新規に導入する場合、NGINX Plusはアプリケーションにとって理想的なプラットフォームと言えるでしょう。すでにハードウェアロードバランサーを導入している既存の環境にNGINX Plusを追加する場合は、NGINX Plusを並列または連携して導入することができます。

シナリオ1:NGINX Plus ですべての負荷分散を行う

最も単純な導入シナリオは、NGINX Plus がすべての負荷分散を担当するというものです。NGINX Plus は最初のロードバランサーである場合もあれば、従来のハードウェアベースのロードバランサーの置き換えの場合もあるでしょう。クライアントは リバースプロキシとして動作するNGINX Plusに接続し、NGINX Plusはバックエンドのサーバ群へリクエストを負荷分散します。

このシナリオには、管理するプラットフォームが1つだけであるという単純さに利点があり、以下にご紹介する導入シナリオが辿り着く最終形と言ってよいかもしれません。

SSL/TLS が使用されている場合、NGINX PlusはバックエンドサーバからSSL/TLS 処理をオフロードすることが可能です。これにより、バックエンドサーバのリソースが解放されるだけでなく、SSL/TLS 処理を一元化することで SSL/TLS セッションを再利用することができます。SSL/TLS セッションの作成は、SSL/TLS 処理の中で最も CPU を消費するため、再利用を増やすことでパフォーマンスの向上や改善につながります。

NGINX OSS と NGINX Plus はどちらも静的/動的コンテンツのキャッシュとして使用でき、NGINX Plus においてはキャッシュをパージ(削除)する機能を備えています。これは特に動的コンテンツに有効です。

さらに、NGINX Plus はアクティブヘルスチェック、セッションパーシステンス、リクエストレート制限、レスポンスレート制限、コネクション数の制限などオープンソースにはないADC 機能を有しています。図にあるような冗長化(HA)構成を組むにはNGINX Plusのクラスタリング機能で実現することができます。(訳者注:オープンソース版のNGINXにはこれらの機能はありません。)​​​​​​

シナリオ2:従来のロードバランサーと並べてNGINX Plusを利用する

2つ目のシナリオは、従来のハードウェアロードバランサーで既存のアプリケーションの負荷分散を継続し、NGINX Plusで今後追加するアプリケーションの負荷分散を行うというものです。

このシナリオは、ハードウェアロードバランサーと NGINX Plusの両方が存在するデータセンターを想定しています。または、ハードウェアロードバランサーがこれまでのデータセンターにあり、NGINX Plus が新しいデータセンターまたはクラウドに導入されるといった場合に当てはまります。

NGINX Plus とハードウェアロードバランサーは並列なので、NGINX Plus の観点からは、最初のシナリオと非常によく似ています。

クライアントは NGINX Plus に直接接続し、NGINX Plus はSSL/TLS処理をオフロード、静的/動的コンテンツをキャッシュ、その他の高度な ADC 機能を実行します。
冗長化(HA)が必要な場合は、前述のシナリオ1で説明した方法が使えます。

この方法を採用するのは、その企業がより最新のソフトウェアベースのプラットフォームに移行したいものの、従来のハードウェアロードバランサーを総入れ替えすることはできないという場合です。新しいアプリケーションを NGINX Plus の後ろに置いてソフトウェアベースのプラットフォームを立ち上げておき、徐々にレガシーアプリケーションをハードウェアロードバランサーから NGINX Plus側に移行していくことができます。

シナリオ3:従来のロードバランサーの後ろにNGINX Plusを置く

シナリオ2と同様に、NGINX Plus は従来のハードウェアベースのロードバランサーを使用する環境に追加されますが、ここでは従来のロードバランサーの後ろに位置します。ハードウェアベースのロードバランサーはクライアントのリクエストを受け取り、 NGINX Plusのインスタンスプールに負荷分散します。その後、NGINX Plus が実際のバックエンドサーバ群へ負荷分散します。このシナリオでは、NGINX Plus がすべてのアプリケーショントラフィックの負荷分散とキャッシュを担当します。

NGINX Plusインスタンスはハードウェアロードバランサーによって負荷分散されています。ハードウェアロードバランサーにNGINX Plusインスタンスのヘルスチェックを実行させ、ダウンしているインスタンスにトラフィックを送信させないことで高可用性(HA)を実現します。

ハードウェアロードバランサーで多数のアプリケーションを制御する場合の課題

この方法(訳者注:シナリオ3)で NGINX Plus を導入する理由は複数考えられます。
一つは、企業の構造的なものです。ロードバランサーを共有するようなマルチテナント環境では、そのロードバランサーはネットワークチームによって管理されています。アプリケーションチームは、ロードバランサーに自分の担当するアプリケーション固有の設定を追加したいと考えるでしょうが、実際のマルチテナンシーは複雑で、別のアプリケーションに対する影響を完全に分離することはできません。ロードバランサーを自由に設定変更できるよう解放した場合、片方のチームが別のチームに影響を与えるような設定変更を行ってしまう可能性があります。

そのようなことが起こらないよう、ネットワークチームはハードウェアロードバランサーを自分たちで運用し続けます。そうなると、アプリケーションチームは構成を変更する度に、ネットワーク チームに設定変更をリクエストしなければなりません。さらにチーム間で設定の競合が発生しないように、ネットワークチームは利用可能な ADC 機能を制限することがあります。これは、ハードウェアロードバランサーが持っている機能のすべては使えないことを意味します。

複数のプロキシ レイヤーを使用することが理にかなっている理由

この問題の解決策の 1 つは、NGINX Plus のような小規模なロードバランサーをアプリケーションチーム毎に割り当てて、自分たちで運用できる環境を作ることです。ロードバランサーは互いに分離されているため、他のチームに影響を与えるリスクもなくそれぞれが必要とするすべての機能を最大限に活用できます。アプリケーションチームに1台ずつハードウェアアプライアンスを提供するのはコストがかかりすぎますが、 NGINX Plus のようなソフトウェアベースのロードバランサーならば運用とコストの両面で最適な方法と言えます。

ハードウェアロードバランサーはそのまま残り、ネットワーク チームが管理を継続しますが、複雑なマルチテナントの問題やアプリケーションロジックに対応する必要はありません。彼らの唯一の仕事は、NGINX Plusインスタンスにリクエストを届けるだけであり、NGINX Plusが適切なバックエンドサーバーにリクエストを転送します。このような方法でネットワーク的な運用とアプリケーションの柔軟なコントロールを両立することが可能です。

まとめ

ソフトウェアベースのロードバランサーのメリットは、多くの環境やシナリオに適用できます。ITの世界は明らかにソフトウェアベースのプラットフォームに移行しています。NGINX Plusを使えば、今あるものをすべて入れ替える必要はありません。将来のアーキテクチャに移行する際に、既存の環境または新しい環境に NGINX Plus を採用することをお勧めします。​​​​​​​

より多くの情報が必要な場合は、以下のサイトを参照いただくか弊社までお気軽にお問い合わせください。
https://docs.nginx.com/nginx/

​​​​​​​

BIG-IPのリプレースについてはこちらから

CONTACT

ITインフラに関してお悩みの方は
お気軽にご相談ください

ご不明な点はお気軽に
お問い合わせください。
ITインフラに関するお役立ち資料は
こちらよりダウンロードできます。

人気記事ランキング

タグ一覧