公開日：2022年12月2日最終更新日: 2023年1月25日
インターネット上でWebサービスを提供する上で重要なのが可用性です。どんなに高スペックのインスタンスを用意しても、大量のアクセスやトラフィックへの処理を1つのインスタンスでこなすのは無理があります。
そこで昨今用いられるのがインスタンスのオートスケール機能と負荷分散サービスです。なかでもAzureで用いられる負荷分散サービスがAzure Application Gatewayです。
今回はクラウドサービスで可用性を担保する上での基本と、Azureではどのように実現しているかについて解説いたします。
目次 ＜Contents＞
Azure Application Gatewayの概要と利用方法
オートスケールと負荷分散
オートスケールとは、負荷に応じて自動的にインスタンスのスペックを増設したり、物理的に数を増やしたりしてくれる機能です。
冒頭でも説明した通り、高スペックのインスタンスを1つだけ用意するというのはクラウドサービスを運用していく上ではあまり好ましくありません。サイズや数によって課金されるクラウドが殆どですので、スモールスタート・ミニマム運用をしたいのが本音だと思います。
「アクセスが増えたりトラフィックが増えたときに備えてスペックを確保するとコスト面でメリットがでない」現場で聞かれるのはこういった声が多いのです。そんな声に答えてくれるのがオートスケールです。このオートスケール、負荷分散と同時に使われるケースがとても多いです。
負荷分散は同じ機能を持つインスタンスが複数ある際に、クライアントとインスタンスの間に入り、インスタンスへのアクセスを分散してくれる機能です。ロードバランサーと呼ばれ馴染みがある方も多いと思います。
オートスケールと同時に使われることが多いというのは、インスタンスが自動で増えた際に、そのインスタンスへのアクセスの分散も行ってくれる機能として切り離せない機能となっているからです。
WAFとの関係
アクセスやトラフィックに応じてオートスケールしたり負荷分散するということは、自然とWebサービスとの組み合わせが多くなります。Webサービスを使うということは自然とWAFを使うこともあり、同時に組み合わせて構成されることが多いです。
詳しくは高い防御システムWAFの概要とAzureでの利用方法をご参照ください。
Azure Application Gatewayとは
従来型の負荷分散を提供するロードバランサーはOSI参照モデルのレイヤー4（トランスポート層）で動作し、送信元IPアドレスとポート番号に基づくトラフィックを送信先IPアドレスとポート番号に分散（ルーティング）します。
Azure Application GatewayはOSI参照モデルのレイヤー7（アプリケーション層）で動作し、URIパスやホストヘッダーなど、HTTP要求の追加属性に基づいて分散できます。
例えばApplication Gateway配下のインスタンスが画像専用プール（images）と動画専用プール（video）で分かれている時に、着信URLに「/images」が含まれている場合、画像専用プールにルーティングすることで機能的に最適化された負荷分散を実現します。
その他機能については公式ドキュメントを参照ください。
参考：Azure Application Gateway の機能
価格は利用時間と処理したトラフィック量による従量課金制です。 公式ドキュメントにもチュートリアルがありますが、簡単にAzureのポータル画面での利用・設定方法を紹介します。
参考：
Application Gateway の価格
クイック スタート:Azure Application Gateway による Web トラフィックのルーティング – Azure portal
1. アプリケーション ゲートウェイの作成
1Azure Portalの「リソースの作成」をクリックします。
2「ネットワーキング」から「Application Gateway」をクリックします。
3「基本」タブで以下設定を入力していきます。
- リソースグループ：既存のものを選択します（なければ「新規作成」で作成）。
- アプリケーションゲートウェイ名：任意の名称
4アプリケーションゲートウェイ用とバックエンドサーバー用に2つのサブネットを作成します。
「仮想ネットワークの構成」で「新規作成」をクリックして作成ウィンドウで、以下を入力します。
| 名前 | 任意の名称 | アドレス範囲 |
|---|---|---|
| サブネット名1つ目 | 任意（初期値default） | 10.0.0.0/24 |
| サブネット名2つ目 | 任意 | 10.0.1.0/24 |
入力後「OK」をクリックします。
5基本タブ画面に戻ったら「次：フロントエンドの数」をクリックし、「フロントエンドIPの種類：パブリック」になっていることを確認します。
「パブリックIPアドレス」として「新規追加」をクリックし、任意のアドレス名を入力し「OK」をクリックします。
下部の「次：バックエンド」をクリックします。
6「バックエンドプールの追加」をクリックし、以下を入力します。
- 名前：任意の名称
- ターゲットを持たないバックエンドプールを追加します：はい（後ほどターゲットを追加）
入力後に「追加」をクリックして、「次：構成」をクリックします。
7「ルーティング規則の追加」をクリックし、以下を入力します。
- ルール名：任意の名称
- 優先度：1～20000の間で指定（1が優先度最高）
- リスナー名：任意の名称
- フロントエンドIP：パブリック
8「バックエンドターゲット」タブをクリックします。
バックエンドターゲットで作成した「myBackendPool」を選択、バックエンド設定の「新規追加」をクリックします。
9バックエンド設定名として任意の名前を入力します。
「追加」をクリックして、ルーティング規則の追加に戻ります。
10「ルーティング規則の追加」 ウィンドウで 「追加」をクリックしてルーティング規則を保存し、「構成」タブに戻ります。
「構成」に戻ったら、「次：タグ」をクリックします。
11タグを追加してリソースを分かりやすく分類できます。
必要なければ「次：確認および作成」をクリックします。
12設定した内容が表示されますので、確認して「作成」をクリックしデプロイします。
その後、「デプロイが完了しました」と表示されれば成功です。
2. バックエンド ターゲットの追加
バックエンドサーバーとして使用する2つのVMを作成し、バックエンドプールに追加します。
アプリケーションが分散されることを確認したいため、Windowsサーバー上にIISをインストールして、自身のVM名を表示するようにします。
※今回myVM, myVM2というWindows仮想マシンを用意していますが、作成方法については割愛します。
1「すべてのリソース」をクリックし、作成した「myAppGateway」をクリックします。
左側のメニューで「バックエンドプール」を選択し、「myBackendPool」をクリックします。
2「ターゲットの種類」の下のドロップダウンで「仮想マシン」を選択し、「ターゲット」で、myVMに関連付けられているネットワーク インターフェイスをドロップダウンから選択します。
3myVM2についても同じ手順を繰り返し、「保存」を選択して完了です。
3. アプリケーション ゲートウェイのテスト
1アプリケーションゲートウェイが正常に動作しているかテストします。
作成した「myAppGateway」の概要から「フロントエンドパブリックIPアドレス」をコピーします。
2コピーしたアドレスをブラウザのURL欄に入力すると、作成したVMの名前が表示されます。
何度か更新をかけると、myVM, myVM2 と表示が変わり、分散されているのが分かります。
3今回はVMが2つのみですが、オートスケールの構成でアプリケーションゲートウェイの機能を十分に活用することができます。
Azureでは「仮想マシンスケールセット」というサービスで提供されているのでこちらをお試しください。
まとめ
Azure Application Gatewayを利用したオートスケールと負荷分散について、サービスの利用・設定方法をお伝えいたしました。
リリースしたサービスの負荷を予測するのは難しいことですが、紹介した機能を使えば、スモールスタート、ミニマム運用が可能になることがご理解いただけたかと思います。
Azureでの利用も意外と簡単で、モダナイズされたWebサービスを提供する上で抑えておくべき領域であると言えるでしょう。
お客様が運営するクラウドの監視・保守・運用業務を、ジードが代行いたします。
お客様のご要望に沿って、適切なクラウド選定から設計・構築までを行います。
Azure上で、AI ＋ 機械学習、分析、ブロックチェーン、IoTを開発します。