Partager via

内部サーバーで負荷分散を実現する方法

  • Article

このポストは、10 月 31 日に投稿された How to Load-Balance Internal Servers の翻訳です。

編集メモ : 今回は、Windows Azure 顧客アドバイス チームのプログラム マネージャーを務める Chris Clayton の投稿をご紹介します。

私は 2009 年から Windows Azure の仕事に携わっており、この間、大企業や中小企業の多数のお客様に向けたソリューション構築の支援も手掛けてきました。そうした中、ソリューションが進化するにつれて内部サーバーの負荷分散を行う必要に迫られることが度々ありました。この記事を執筆している今の時点では、Windows Azure には負荷分散に対応する組み込み型ソリューションはありませんが、パブリック エンドポイント用アクセス制御リスト (ACL、英語) を導入することで、標準でサポートされている Windows Azure のサービスやコンポーネントでこの問題に対応できるようになります。

ここでは仮想マシン上で実行中の、ASP.NET Web API で外部に面している内部サービスのファサードとして機能している 1 組の Internet Information Services (IIS) サーバーの負荷分散を実行する場合について説明します。負荷分散を行うパブリック エンドポイントを作成してそれぞれの IIS サーバーで共有すると、すべてのパブリック エンドポイントにアクセスする Windows Azure の標準ロード バランサーを使用して、サーバー間ですべてのクエリの負荷分散を実行できます。

インターネットに接続しているだれもが私のサービスにアクセスできるようになってしまうのではないかと心配していましたが、ACL をエンドポイントに適用すると、私のクラウド サービスへのアクセスを制限できるようになります。下の図のように、ACL を使用すると、負荷分散対象のエンドポイントに対するアクセスを、クラウド サービス内からのクエリのみ許可するように制限できます。

これは本当に素晴らしい機能で、とても簡単に使用することができました。この機能を導入した場合の影響として考えられるメリットとデメリットをここでご紹介します。

メリット

  • パートナーのソリューションを使用せずに、負荷分散に対応した ASP.NET Web API 層を実現できました。
  • マイクロソフトがサポートするサービスや機能を使用したため、サポート対象の構造で狙いどおりのことを達成できました。
  • 私のソリューションについて製品チームと議論したところ、製品チームは現在この機能を提供していないため、現時点ではサポート対象の実装であることに同意しました。

デメリット

  • Windows Azure のクラウド サービスで作成可能なパブリック ポートの数は現在 25 個ですが、この機能はそのうちの 1 つとして数えられます。
  • 単一のクラウド サービスからの通信はすべて、同一のパブリック IP アドレスから行われます。このため、全クライアントの通信量の合計が、TCP の 64 KB の通信制限を受けることになります。この制限は、同一の送信元ポートと送信元 IP アドレスから同一の送信先ポートと送信先 IP アドレスへの通信に適用されます。
  • ACL はサービスとしてのインフラストラクチャ (IaaS) のソリューションのみがサポート対象となっているため、プラットフォームとしてのサービス (PaaS) のソリューションでは使用できません。

軽減策

どのソリューションにもそれぞれデメリットがありますが、通常何らかの工夫をすれば、そのデメリットを軽減することができます。最初の 2 つのデメリット (パブリック ポートの最大数、クラウド サービス 1 つに対し単一の IP アドレスが割り当てられることなど) は、クラウド サービスに適用される制限に由来するものですが、検討した結果、これは複数のクラウド サービスにまたがる複数の仮想マシンに展開できるということに気が付きました。仮想ネットワークを使用することによってこれを分割し、通信能力を維持することができます。ただし、この場合は ACL で IP アドレスの構成を追加する必要があります。

段階的な解決策

ここでは、私が実際に 2 台の仮想マシンに負荷分散ソリューションをセットアップした時の方法をご説明します。

まず IIS で完全に構成済みの 2 台の仮想マシンを用意し、ACL がそれぞれに割り当てられた負荷分散対象のエンドポイントを Windows PowerShell で作成しました。

クラウド サービスのダッシュボード ビューで仮想マシンを表示すると、許可する必要のあるパブリック IP アドレスがすぐにわかります。下のダッシュボードの画像を見ると、私のクラウド サービスの IP アドレスは 137.135.81.135 であることがわかります。

Windows PowerShell を開き、Windows Azure モジュールのコマンドレットを利用して下記のコマンドを実行します。これらのコマンドを実行すると、各仮想マシンに 80 番ポートをリッスンするエンドポイントが新たに作成されます。また、私のクラウド サービスの IP アドレス (137.135.81.135) へのアクセスを制限するように ACL が設定されます。

自分のサービスに対して負荷分散が正しく動作しているかをテストするために、既定の IIS ページを変更して、仮想マシンの名前を表すテキストを表示しました。その後、クラウド サービスの外側から仮想マシンへのアクセスを試したところ、ACL が正常に動作していることを確認できました。

次に、リモート デスクトップを使用してクラウド サービス内の仮想マシンに接続し、同じテストを実施すると、今度は Web サイトと仮想マシンの名前が表示されました。

ページの内容を定期的に強制更新していると、ロード バランサーが要求を処理する際に仮想マシン名が変化することに気付きました。

Windows Azure で利用可能な既存のサポートされているサービスを組み合わせることにより、内部 IaaS 仮想マシンで負荷分散機能を実装することができました。このソリューションは、先ほど述べたように不完全な点も存在しますが、さまざまな状況で非常に有効であると私は考えています。

皆様のご意見をお伺いできればと思うので、どうぞお気軽に Chris Clayton 宛に電子メールをお寄せください。