2025年までには楽になろう…
アプリケーションデリバリーコントローラーとしての
NSX Advanced Load Balancer 後編
前編のポストでは、ロードバランサーとアプリケーションデリバリーコントローラーの歴史的な違い、より洗練されたUIによりアプリケーションデリバリーコントローラーとしての特性を与えられている NSX Advanced Load Balancer の位置づけとその構成要素、オブジェクトモデルについてご紹介いたしました。後編では前編で説明したPool Groupという概念をどのように利用できるのか？実際のUse Caseを想定しながら設定例を踏まえてご紹介したいと思います。
Use Case 1 : Blue/Green デプロイメント（Pool Group Priority）
仮にアプリケーションの更改方法としてBlue/Green デプロイメントでのデリバリーを選択したいと想定します（Blue/Green デプロイメントについては前編を参照）。その場合、Virtual Service （以降VS）を作成する際に指定するサーバーPoolをPool Groupで構成することを選択し、
Pool Group Memberに指定するGroup間でPriority付けを行います。この例ではBlueアプリケーションをAPP1-POOL（Priority 10）にし、GreenアプリケーションをAPP2-POOL（Priority 5）で設定するイメージです。
するとVSからみたオブジェクトはこのような関係性になります。
この状態にてクライアントからVSにアクセスを行うとAPP1-POOLに紐付いたサーバー内だけで負荷分散が行われます。
この状態では、APP2-POOL及びそこに紐付いたサーバーへはトランザクションが転送されることはなく、APP1-POOL内のサーバーに全損障害が発生した場合、もしくは管理者によりPool Groupに対するPriorityの付替えが行われた時にのみAPP2-POOLが利用されることになります。
この仕組みによりBlue/Green デプロイメントにおける新旧アプリケーションの切り替え、および問題発生時のロールバックは非常にシンプルにかつ即座に対応することが可能となっています。とても簡単ですね。
Use Case 2 : 特定フローへの制御 （Request Policy）
次に、Blue/Green デプロイメントの切り替え判断前に開発者の試験端末だけ新バージョンのアプリケーションに振り分けたい、もしくは新バージョンのアプリケーションをデリバリーした後に特定の端末やOSにだけ不具合が発生してしまったのでその通信だけを別のPoolに振り分けたい、などのケースを想定します。
前編でご紹介したとおりNSX Advanced Load Balancer はユーザー毎のトランザクションを可視化し、問題のある通信フローをナローダウンすることを得意とするUIをご提供しています。さらにそのトランザクションにおけるHeader情報の可視化なども提供可能なので、
これらのツールを利用して特定のPoolに渡したいトランザクションの特徴を探しだしたならば、それを元にRequest Policyを定義します。ここでは「User-Agent内にUbuntuの文字列を見つけたならば、」「負荷分散に利用するPoolはXXXにしなさい」というルールの例ですが、その際の設定はこのようなシンプルな手順だけで実現可能です。
このような設定を入れることによりVSからみたオブジェクトとPool選定はこのような関係性になります。
このPolicyにマッチしたクライアントからのリクエストは指定したPool（この例ではNewApp-POOL）に紐付いたServerだけに転送されます。
Request Policyを設定すると、ルールにヒットするセッションに関してはPool Group 選定のPriorityルールの前段でこのポリシーに対応した判断と転送が実行されているのがポイントです。たいへん柔軟ですね。
Use Case 3 : カナリアリリースデプロイメント（Pool Member Ratio）
次は、アプリケーションの更改方法としてカナリアリリースデプロイメントでのデリバリーを選択したいと想定します（カナリアリリースデプロイメントについてはやはり前編を参照）。その場合は、VSを作成する際に指定するPool Groupに対してアサインする複数のPool Memberを同一のPriorityで設定し、その後Ratioで配分を指定します。
この例では現行バージョンのアプリケーションをAPP1-POOL（Ratio 9）にし、新しいアプリケーションをAPP2-POOL（Ratio 1）で設定しているイメージです。
こうするとVSからみたオブジェクトはこのような関係性になります。
この状態にてクライアントからVSにアクセスを行うと9：1の割合でAPP1-POOLとAPP2-POOLのサーバー間で負荷分散が行われます。
ほんとに9：1になってるの？と疑わしければ、
そんな観点で可視化、確認することもできたりします。なんと気の利いていることでしょう。
今回ご紹介したPool Group とGroup Membership、Request Policyは、NSX Advanced Load Balancer においては非常に基本的な構成概念で、製品プレゼンなどではあまり触れられず、マニュアル上でもサラリと記載がされているだけなので、この基本的な部分をお客様にご紹介することも重要と考え、資料を描き下ろしてみました。エッセンスはこのBlogでご紹介いたしましたが、Full Versionをご覧いただきたい方はこちらからダウンロードいただけますので参考にしていただければと思います。
アプリケーションのデリバリー方法ごとにおけるNSX ALBの設定方法について
まとめ
アプリケーションデリバリーコントローラーもL4/7ロードバランサーも、大きく区分けると“ロードバランサー”であります。ただしここまでご紹介してきた通り、大きな心労をともなうアプリケーションの更改という作業を少しでも楽にする気遣いに溢れているUIや可視性は、いままでネットワークチームとアプリケーション開発チームの間で双方からのプレッシャーを一身に受けてきたロードバランサーとしての鬱屈とそれをバネにした進化として感じとることができます。実際ここまでご紹介した各種機能群自体は、同等のことが実現出来る？出来ない？で言えば、従来型のLBソリューションでも 「がんばればできる」事が多いです。ただしこの「がんばれば」の壁に潜むギャップは実運用、耐障害性の観点では小さいように見えて非常に大きな壁となって立ちはだかります。
「アプリケーションデリバリーコントローラーなんて小賢しい、ロードバランサーはロードバランサーだ…」などと思っていてNSX ALBのご紹介をする際には、Elastic なScale-Outだ、GSLBだ、WAFだ、、、とついつい大技に頼ったご紹介をしてしまいがちでしたが、今回のような構築、運用時における基本的なメリットをお伝えしきれていなかったことをお客さまからのリクエストにより気づかせていただいた、という自戒の念とともにBlogにてまとめてみました。（神は細部に宿る、というやつですね…）
ネットワークチームとアプリケーション開発チームの橋渡しを華麗に行う、マルチクラウドに対応可能な現代の“アプリケーションデリバリーコントローラー“、皆さま、ぜひお試しあれ。
〜お知らせ〜
※VMwareでは、各種製品をクラウド上でご評価いただくHands-on Labs（HOL） という仕組みを無償でご提供しています。
今回ご紹介した各種ソリューションへの最初の一歩の入り口としてぜひご活用ください。
おすすめのHOLメニューはこちらから ( http://labs.hol.vmware.com/HOL/catalogs/catalog/1212 )
- HOL-2037-01-NET – VMware NSX Advanced Load Balancer (Avi Networks) – Getting Started
- HOL-2037-91-NET – VMware NSX Advanced Load Balancer (Avi Networks) Lightning Lab
- HOL-2037-02-NET – VMware NSX Advanced Load Balancer (Avi Networks) – Global Server Load Balancing
