マルチクラウド時代に求められるロードバランサーの条件とは

組織はクラウドファーストを掲げて積極的にクラウドを活用しています。今後のクラウド戦略のポイントは、「どのクラウドを使うか」から、「複数のクラウドをどう使うか」というマルチクラウドにシフトすることが予想されます。また、オンプレミスのプライベートクラウドと組み合わせたハイブリッドクラウドに重きを置く組織も多いと思います。具体的には、オンプレミスの vSphere 基盤をパブリッククラウドに拡張し、仮想マシンやストレージ、ネットワークをハイブリッド化するようなモデルケースがあります。ハイブリッド・マルチクラウド環境では、アプリケーションの特性に合わせて、最適な場所でアプリケーションを実行できるメリットがあります。一方、複数のクラウドやアプリケーションを管理しなければならない状態が運用のサイロ化と複雑化を招き、全体最適が困難になるケースも散見されます。本ブログでは、アプリケーション配信基盤であるロードバランサーに焦点を当て、マルチクラウド時代に求められる条件について考察します。

真のマルチクラウド対応のロードバランサーが必要な背景

組織がアプリケーションを提供する場所として、従来のデータセンターだけではなく、パブリッククラウドを併用したり、複数のクラウドにまたがったりすることも珍しくありません。また、アプリケーション開発の現場も大きく変化しています。モノリシックなアプリケーションをマイクロサービス化するために、コンテナ基盤へ移行する流れは顕著です。さらに、アジャイル開発や DevOps、CI/CD の採用により、アプリケーション開発とリリースサイクルが迅速化しています。このようなアプリケーションを取り巻く環境の変化に対して、ロードバランサーも適応する必要があるのではないでしょうか。

ロードバランサーの種類は、メーカーが開発する物理/仮想アプライアンス型と、クラウド事業者が提供するサービス型に分類できます。それぞれ、どのような特徴があるのかを考えてみたいと思います。

従来のアプライアンス型ロードバランサーは、長年培ってきた豊富な機能はありますが、クラウドで期待すべき自動化や伸縮性に必ずしも対応できていません。一方、クラウド事業者がサービス提供するロードバランサーは、自動化や伸縮性に優れていますが、複雑なトラフィック制御に必要な機能が足りなかったり、単一のクラウドでしか利用できなかったりする制限があります。そこで VMware は両方のロードバランサーのいいとこ取りができないかを考えたのです。

マルチクラウドを追求した VMware の仮想ロードバランサー

VMware が提供する NSX Advanced Load Balancer（以下 NSX ALB）は、マルチクラウド時代に誕生したソフトウェア型ロードバランサーです。最大の特徴は、コントロールプレーンとデータプレーンを完全に分離したアーキテクチャを採用していることです。

データプレーンは、Active/Active 構成にすることでパフォーマンスや耐障害性を高めたり、サービスの需要に合わせて柔軟にスケーリングをしたり、オンプレミス・クラウドを問わず様々な環境にデプロイしたりできます。

コントロールプレーンでは、データプレーンのライフサイクル管理やポリシーの集中制御、トラフィックの分析・可視化、様々なサービスとのオーケストレーション（自動化）、セルフヒーリング（自動回復）などを提供します。

先進的なアーキテクチャのみならず、L4/L7 負荷分散や GSLB、WAF、Container Ingress などエンタープライズグレードの豊富な機能を実装しています。特に GSLB の重要性について補足します。組織がハイブリッド・マルチクラウドを採用する理由の一つに、複数環境における BCP/DR 対策が挙げられます。そこで GSLB を活用することで、災害対策発動時にユーザのアクセスを災対サイトへ素早く切り替えることが可能になります。VMware の DR ソリューションと GSLB を組み合わせた事例をこちらのブログで詳しく紹介しておりますのでご覧ください。

これらのことから、従来の仮想アプライアンスに欠けているクラウドネイティブ機能とクラウド事業者のサービスに足りない高度な機能、あらゆる場所で動かせる可搬性を兼ね備えているのが NSX ALB の強みです。

マルチクラウドの課題

ロードバランサーの観点から、マルチクラウドで想定される課題を掘り下げてみたいと思います。

課題① クラウド間のキャパシティ可搬性の欠如

一般的には、オンプレミスやクラウド間でロードバランサーのキャパシティ（ライセンス）を柔軟に移行できません。クラウドで新たにロードバランサーを導入する場合、追加コストが発生します。

課題② 複数クラウドによる運用管理の複雑化

オンプレミスやクラウド環境ごとに異なるロードバランサーを個別管理する方法では、運用管理の複雑化とサイロ化を招き、全体最適が困難です。

課題③ クラウド間で一貫性のない機能とサービス

環境ごとに異なるロードバランサーを調達する場合、全体のサービスレベルを合わせるのが困難です。たとえば、セキュリティや可用性、運用管理性を高めるためには、環境ごとに異なる製品やサービスを複数組み合わせる必要があります。このようなアプローチでは、ポリシーの一貫性が損なわれ、運用負荷とコストが上昇します。

NSX ALB のマルチクラウド対応

マルチクラウドでロードバランサーを運用する場合、可搬性や運用管理性、一貫性に課題があるとお伝えしました。NSX ALB のマルチクラウド対応のキーワードは「アプリケーションデリバリーの抽象化」です。クラウドごとのアーキテクチャや管理インタフェース、ポリシーの違いを吸収し、共通化する仕組みを作り上げます。

このアプローチが、マルチクラウドの課題をどのように解決できるかを紹介します。

ソリューション① クラウド間の柔軟なキャパシティ可搬性

NSX ALB コントローラにはライセンスのキャパシティをプールする仕組みがあります。サービス需要やクラウド戦略に合わせて、管理者はキャパシティを柔軟に移行できます。こうして、オンプレミスへの投資を保護しながら、シームレスで一貫性のあるクラウド移行を実現します。

ソリューション② 複数クラウドにおける運用管理の一元化

オンプレミスとクラウドの運用管理を一元化することで効率化を図り、全体最適が可能になります。

ソリューション③ クラウド間で一貫性のある機能とサービス

NSX ALB では、セキュリティや可用性、運用管理性を高めるための機能をオールインワンで提供しています。複数クラウドにまたがって展開されるロードバランサーのサービスレベルを統一できるのです。さらに、同じソフトウェアで提供されるので、ポリシーの一貫性が担保されます。

アプリケーションデリバリーの抽象化を支える技術要素

ここからは、NSX ALB がアプリケーションデリバリーを抽象化する仕組みを紹介します。従来の仮想アプライアンスを複数のクラウドにデプロイする方法とは何が違うのでしょうか。決定的な違いは、NSX ALB コントローラのオーケストレーション機能です。仮想基盤の管理ソフトウェア（vCenter や NSX Manager 等）やパブリッククラウドと、API 連携できる機能が組み込まれています。それにより、様々なクラウドで利用する場合でも、NSX ALB コントローラは単一の管理ポイントとして、クラウドごとのアーキテクチャやポリシーの違いを吸収してくれます。つまり管理者は、NSX ALB コントローラにアクセスすることで、個々のクラウドの違いを意識せずに、任意の環境にアプリケーションサービス構成したり、ロードバランサーを運用管理したりできます。

実際にアプリケーションサービスを構成するまでの流れを説明します。ポイントは、オンプレミスでもクラウドでも、同じ方法でやれることです。以下の図では、AWS 環境に仮想ロードバランサーをデプロイし、仮想サービスを構成するまでの流れを3ステップで表現されています。

最初に、AWS のアクセスキーやシークレットアクセスキー、IAM ロール等の認証情報をNSX ALB コントローラに登録します。コントローラと AWS 間の認証が成功すると、API 経由で AWS リージョンや VPC、AZ やサブネットなどの情報がコントローラへ共有されます。

続いて、コントローラにて、アプリケーションサービスを構成する場所（VPC やサブネット等）や仮想ロードバランサーのインスタンスタイプを定義します。ここまでが初期設定の範囲です。

最後に、アプリケーションサービスを構成します。コントローラにて「何のアプリケーションをどのサーバに振り分けるか」を宣言します。具体的には、仮想サービスやサーバプールを設定します。すると、コントローラは AWS の API エンドポイントに対して、仮想ロードバランサーの立ち上げと設定を指示します。AWS 側では、指定したインスタンスタイプの仮想ロードバランサーがデプロイされ、適切なサブネットに配置され、仮想サービスが設定されます。Elastic IP の割り当てや Route53 への DNS 登録、セキュリティグループの適用も自動化されます。

このように、オーケストレーション機能が組み込まれることで、管理者が手動で行っていた作業は大幅に削減されます。従来の仮想アプライアンスのように、AWS のコンソール画面にログインしてマーケットプレイスから仮想マシンをデプロイしたり、ライセンスを割り当てたり、コンフィグを作成して投入したりする作業は不要になります。

マルチクラウドで LB as a Service の実現

オーケストレーションがもたらす自動化によって、ロードバランサーで行なうオペレーションの敷居を下げることができます。たとえば、アプリケーション担当者（LOB）がインフラチームに依頼していたロードバランサーの設定について、自分達で実施できるようになります。いうなれば、ロードバランサーのセルフサービス化です。アプリケーションチームの開発スピード向上とインフラチームの運用負荷軽減を同時に実現できるため、Win-Win な関係を築けるのではないでしょうか。

まとめ

NSX ALB のマルチクラウドに対するコミットは、オンプレミスとクラウドで仮想ロードバランサーを動かせるレベルに留まりません。アプリケーションデリバリーの抽象化により、オンプレミス・クラウド横断で一貫性のあるアプリケーションサービスと運用管理性を提供し、従来のオペレーションを変革する潜在能力があります。次世代のロードバランサーとして、NSX ALB をぜひご検討ください。

– – – – – – – – – – – – – – – – – – – – – – – – – – – – – – – – – – – – – – – – – – – –– – – – – – – – –

〜お知らせ①〜

NSX ALB をハイブリッド・マルチクラウドで簡単にご利用いただけるように、デザインガイドと設定ガイドを日本語で作成しました。単一のコントローラから、あらゆる環境にロードバランサーを簡単にデプロイできることを実感していただけると思います。ぜひ、ご活用ください！

〜お知らせ②〜

VMwareでは、各種製品をクラウド上でご評価いただくHands-on Labs（HOL）という仕組みを無償でご提供しています。今回ご紹介した各種ソリューションへの最初の一歩の入り口としてぜひご活用ください。

おすすめのHOLメニューはこちらから