grasys blog

NGINX PlusのLB機能:アクティブヘルスチェック&セッション維持

こんにちはtsunodaです。
先日、東京エレクトロンデバイス(TED)様、F5ネットワークスジャパン合同会社様のご協力の元、NGINX Plus の機能検証を実施させていただきました。

どんな検証をしたのかの一覧紹介ブログはこちら

今回はその中から、ロードバランサ機能のアクティブヘルスチェックとセッション維持についてご紹介します。
掘り掘りその2。

NGINX Plus とは

NGINX Plusは、オープンソース版のNGINXに様々な機能を拡張し搭載した商用版ソフトウェアです。
NGINX Plusとは

NGINX Plusのインストール方法や基本的なロードバランサ設定については掘り掘りその1でご紹介させていただきました。
今回は、アクティブヘルスチェックと、セッション維持についてご紹介します。

アクティブヘルスチェック

アップストリームサーバの正常性を色々な条件でチェックできます。
この機能を使用することで、さまざまな問題を検出して回避することができ、アプリケーションの信頼性を大幅に向上させることができます。
設定はこんな感じ↓

server {
  location / {
    proxy_pass http://backend;
    health_check interval=2s
      fails=2
      passes=5
      uri=/
      match=healthcheck;
  }
}

match healthcheck {
  status 200;
  header Content-Type = "text/html";
  body ~ "Welcome to nginx!";
}

この場合、2秒毎にuri/に対してGET要求を実施します。
正常とみなされる条件として、5回連続してチェックに合格する必要があります。(passes=5の部分)
2回連続して失敗すると不健全と見なされます。(fails=2の部分)
応答内容はmatchブロックと一致している必要があります。
この場合、ステータスコードは200、ヘッダーのContent-Typeはtext/html、bodyは文字列Welcome to nginx!
となります。

何度チェックをパスする必要があるのか、
何回までなら異常と認めず失敗できるのか、
期待される結果は何か、などを設定できます。
より複雑なロジックについてはmatchブロックによって設定可能で、こういった機能はサーバの健全性を常に保証できるようにできます。

セッション維持

Cookieパラメータをstickyディレクティブで使用することにより、そのCookieを追跡し、後続の要求を同じサーバに送信し続けます。
設定は簡単でこんな感じ↓

upstream backend {
  zone backend 64k;
  server <backend_server1の内部IP>;
  server <backend_server2の内部IP>;

  sticky cookie aaa expires=1h;
}

aaaという名前のCookieを作成および追跡します。
有効期限はこの設定だと1時間です。(分も可能です、expire=3mなど)
また、明示的にドメインを指定することも可能で、HTTPS経由でのみの送信もでき、どのパスで有効にするかも設定可能です。↓

upstream backend {
  zone backend 64k;
  server <backend_server1の内部IP>;
  server <backend_server2の内部IP>;

  sticky cookie 
         aaa
         expires=1h
         domain=.example.com
         httponly
         secure
         path=/;
}  

この設定だと、aaaというCookieの作成および追跡、ドメインはexample.com1時間で期限切れになり、HTTPS経由のみで送信でき、全てのパスで有効という設定になります。

接続しに行っているサーバが落ちたらどうなるの?
はい、気になったので試しました。
例えばサーバA、Bがあるとします。
NGINXのCookieはサーバA、Bそれぞれに応じたCookie(固定値)が応答されます。
サーバAのCookieを持ったクライアントからのリクエストでも、サーバAがダウンしている場合、
NGINXはリクエストをサーバBに転送し、この時にNGINXはクライアントへサーバBのCookieを応答します。
クライアントがサーバBのCookieを持ってNGINXにリクエストを送っている場合、
サーバAが復旧してもサーバBにリクエストは転送されるのです。

まとめ

設定のやり方、意味を理解すれば結構応用が効きそうですね!
アクティブヘルスチェックはプロセス監視だけでなく、ソースサーバを監視するためにも有用だと感じました。
しかもサービスによってソースサーバの監視方法を独自に、比較的自由に設定できるのは利点かなと思います。
セッション維持の設定も入れることでより安定したサービス提供も可能ですね。
クラウドを使用していると、そのクラウドのロードバランサを使用することが多いですが、マルチクラウドやオンプレ環境で有用である機能もあり、うまく組み合わせられる場面はあるなと思います。
NGINX Plus ロードバランサ機能

« TED×grasys×F5 ブログ一覧 »
4月27日 NGINX Plusの検証をした! (grasys)
6月02日 grasys×F5×TEDが徹底解析!NGINX Plusの仕組みがよくわかる! (TED様)
6月09日 NGINX Plusのインストール方法とLBの基本設定 (grasys)
6月16日 NGINX PlusでJWT認証をやってみた! (TED様)


株式会社grasys(グラシス)は、技術が好きで一緒に夢中になれる仲間を募集しています。

grasysは、大規模・高負荷・高集積・高密度なシステムを多く扱っているITインフラの会社です。Google Cloud (GCP)、Amazon Web Services (AWS)、Microsoft Azureの最先端技術を活用してクラウドインフラやデータ分析基盤など、ITシステムの重要な基盤を設計・構築し、改善を続けながら運用しています。

お客様の課題解決をしながら技術を広げたい方、攻めのインフラ技術を習得したい方、とことん技術を追求したい方にとって素晴らしい環境が、grasysにはあります。
お気軽にご連絡ください。


採用情報
お問い合わせ