クラウドがよく分かる！お役立ちコラム

オートスケール機能と負荷分散サービスAzure Application Gateway

この記事は約16分で読めます。

• #導入・構築方法
• #オートスケール
• #Azure Application Gateway

Webシステムの可用性を高める仕組み

オートスケールと負荷分散

インターネット上でWebサービスを提供する上で重要なのが可用性ですが、どんなに高スペックのインスタンスを用意しても、大量のアクセスやトラフィックへの処理を1つのインスタンスでこなすのは無理があります。サイズや数によって課金されるクラウドが殆どですので、スモールスタート・ミニマム運用をしたいのが本音だと思います。
そこで昨今用いられるのがインスタンスのオートスケール機能と負荷分散サービスです。

オートスケール

負荷に応じて自動的にインスタンスのスペックを増設したり、物理的に数を増やしたりしてくれる機能です。

「アクセスが増えたりトラフィックが増えたときに備えてスペックを確保するとコスト面でメリットがでない」現場で聞かれるのはこういった声が多いのです。

そんな声に答えてくれるのがオートスケールです。このオートスケール、負荷分散と同時に使われるケースがとても多いです。

負荷分散

同じ機能を持つインスタンスが複数ある際に、クライアントとインスタンスの間に入り、インスタンスへのアクセスを分散してくれる機能です。ロードバランサーと呼ばれ馴染みがある方も多いと思います。

オートスケールと同時に使われることが多いというのは、インスタンスが自動で増えた際に、そのインスタンスへのアクセスの分散も行ってくれる機能として切り離せない機能となっているからです。

WAFとの関係

アクセスやトラフィックに応じてオートスケールしたり負荷分散するということは、自然とWebサービスとの組み合わせが多くなります。
Webサービスを使うということは自然とWAFを使うこともあり、同時に組み合わせて構成されることが多いです。

詳しくは高い防御システムWAFの概要とAzureでの利用方法をご参照ください。

Azure Application Gatewayとは

WebサイトやWebアプリケーションをAzure上で運用する場合、Webサーバーをインターネットへ直接公開するのではなく、その手前にアクセスを制御する仕組みを配置することがあります。
その代表的なサービスの一つが、Azure Application Gatewayです。

Application Gatewayは、HTTP/HTTPS通信を対象としたレイヤー7（L7）のロードバランサーで、主に次の機能を備えています。

• 負荷分散： 複数のWebサーバーに通信を振り分ける
• URL・ホスト名によるルーティング： 通信内容に応じて接続先を振り分ける
• SSL/TLS終端： 暗号化通信をApplication Gatewayで処理する
• WAF： SQLインジェクションやクロスサイトスクリプティング（XSS）など、Webアプリケーションを狙った攻撃に備える

例えば、企業が公開しているWebシステムでアクセスが集中した場合、Application GatewayがWebサーバーへの通信を振り分けることで、1台のサーバーにアクセスが集中することを防ぎます。

Application Gatewayの導入ではシステム全体の設計が重要

実際のシステム構築では「Application Gatewayを導入すればよい」という単純な話ではありません。
どこにApplication Gatewayを配置するのか、Webサーバーをどのように構成するのか、WAFをどこで適用するのか、Azure Front Doorなど他のサービスと組み合わせるのかなど、システム全体を考えて設計する必要があります。

---

実際のWebシステムを構築・運用する際に、Application Gatewayがどのような課題の解決に役立つのか、具体的な活用例を交えて紹介します。

Application Gatewayで解決できる課題

Application Gatewayは、特に以下のような課題を解決したい場合に利用されます。

• Webサーバーを複数台構成にしたい
• 1台のWebサーバーにアクセスを集中させたくない
• Webサーバーの障害時にもサービスを継続したい
• URLによって処理するサーバーを変更したい
• Webサーバーの前段にWAFを配置したい
• Webサーバーを直接インターネットに公開したくない
• SSL/TLS証明書の管理をWebサーバーから分離したい

例えば、アクセス数の増加によってWebサーバー1台では処理しきれなくなった場合、Webサーバーを2台、3台と増やす方法があります。
しかし、Webサーバーを増やしただけでは、利用者からのアクセスを適切に振り分けることができません。
そこでApplication GatewayをWebサーバーの前段に配置します。
Application Gatewayがアクセスを振り分けることで、複数のWebサーバーを利用できます。

活用例1：Webサーバー2台構成で可用性を高める

例えば、企業が運営するWebシステムで、これまで1台のWebサーバーでサービスを提供していたとします。
この構成では、Webサーバーに障害が発生すると、Webサイトそのものが利用できなくなります。

そこでWebサーバーを2台に増やし、Application Gatewayを配置します。
通常時はWeb01とWeb02へアクセスを分散します。
さらにApplication Gatewayではバックエンドの正常性を確認するヘルスプローブを利用できるため、障害が発生したサーバーを負荷分散の対象から外す構成が可能です。

このように、Application Gatewayは「アクセスを分散する」だけではなく、Webサービスの可用性を高めるためにも利用できます。

活用例2：URLによって接続先を変更する

Application Gatewayの大きな特徴の一つが、HTTP/HTTPSのリクエスト内容を利用したルーティングです。
例えば、1つのドメインで複数のシステムを提供している場合、以下のような振り分けができます。

https://example.jp
→ /api/* → APIサーバー
→ /admin/* → 管理用サーバー
→ その他 → Webサーバー

これにより、WebサイトとAPIなどを別々のサーバーで運用する構成を作れます。

また、ホスト名を条件にして、以下のように振り分けることもできます。

www.example.jp → Webサーバー
api.example.jp → APIサーバー
admin.example.jp → 管理サーバー

単純なIPアドレスやポート番号による負荷分散ではなく、Webアプリケーションの構造に合わせて通信を制御できる点がApplication Gatewayの特徴です。

活用例3：WAFを組み合わせてサイトを保護する

WAFを組み合わせるメリット

インターネットに公開するWebサイトでは、負荷分散だけでなく、Webアプリケーションを狙った攻撃への対策も重要になります。
Application GatewayにはWAF（Web Application Firewall）機能を組み合わせることができ、次のようなメリットがあります。

• Webアプリケーションへの攻撃を検知・防御
  WebサイトへのHTTP/HTTPS通信を検査して、SQLインジェクションやクロスサイトスクリプティング（XSS）などの攻撃を検知・防御できます。

• アプリケーションを変更せずに攻撃対策を追加
  Webアプリケーションの脆弱性対策は、本来アプリケーション側でも実施する必要があります。
  しかし、実際の運用では、利用しているCMSやフレームワーク、プラグインなどのすべてを常に最新の状態に保つことが難しいケースもあります。
  そこでWAFをWebアプリケーションの手前に配置することで、アプリケーションそのものを変更することなく、Webサイトに対する攻撃を検知・遮断できるというメリットがあります。

• 複数のWebサーバーへの通信を一元管理
  特に、複数のWebサーバーを運用している場合、各サーバーで個別にセキュリティ対策を行うのではなく、Application Gateway + WAFを入口に配置することで、Webサーバーへの通信を一元的に検査できます。
  例えばWeb01、Web02の2台構成であれば、どちらのサーバーにリクエストが振り分けられた場合でも、その前段でWAFによる検査を行えます。

【実例】WAFの運用で直面した誤検知

一方で、WAFを導入すればすべての通信を自動的に安全に処理できる、というわけではありません。
WAFの運用で特に難しいのが誤検知への対応です。

WAFは、HTTPリクエストのURL、パラメータ、Cookie、POSTデータなどをルールに基づいて検査します。
そのため、攻撃ではない正常なリクエストであっても、攻撃パターンに似た文字列が含まれていると、WAFによってブロックされることがあります。

• 検索機能が使えなくなったケース
  検索機能があるWebサイトで、ユーザーが検索欄に入力した特殊な記号や文字列が、SQLインジェクションやXSSのパターンと似ていると判断され、正常な検索処理までブロックされてしまった。

• CMSやWebアプリケーションの一部機能が使えなくなったケース
  管理画面やAPIで使用している特殊な形式のパラメータがWAFのルールに該当し、Webサイト自体は正常に動作しているのに、WAFを有効にした途端、特定の機能が使えなくなった。

誤検知が発生した場合の対応

このような場合に、すべてのWAFルールを無効にしたり、WAFそのものを停止したりするのは適切な対応とはいえません。
まずWAFのログを確認し、

• どのリクエストがブロックされたのか
• どのWAFルールが検知したのか
• どのURL・パラメータが原因だったのか
• 本当に攻撃なのか、正常な通信なのか

を確認します。
正常な通信であることが確認できた場合には、影響範囲を限定して例外設定を行うなど、WAFの防御機能を維持しながらアプリケーションを正常に動作させるための調整を行います。
ここがWAF運用の難しいところです。

継続的なチューニングが必要

WAFの運用では「検知を増やせばよい」というものではなく、「攻撃をブロックしながら、正常なユーザーの通信は止めない」というバランスが重要になります。
そのため、WAFは導入して終わりではなく、Webアプリケーションの仕様やアクセスログ、WAFログを確認しながら継続的にチューニングしていくことが重要です。

Application Gatewayの導入が最適とは限らない

ここはAzureの設計で非常に重要なポイントです。
Application Gatewayには多くの機能がありますが、すべてのWebサイトに必要というわけではありません。

例えば、Webサーバーが1台だけで、アクセス数も少なく、WAFや高度なルーティングも必要ないシステムにApplication Gatewayを導入すると、構成が複雑になり、コストも増える可能性があります。

逆に、

• Webサーバーを複数台にしたい
• 可用性を高めたい
• WAFを導入したい
• URLによって接続先を変更したい
• Webサーバーを直接公開したくない
• 将来的にサーバーを増やしたい

という要件がある場合は、Application Gatewayが有力な選択肢になります。

重要なのは、「Application Gatewayを使うかどうか」ではなく、「Webシステム全体としてどのような構成が最適なのか」という視点で判断することです。

Application Gatewayの設計

Application GatewayはAzure Portalから作成するだけであれば、それほど難しいサービスではありません。
しかし、本番環境では単純に作成して終わりではありません。
例えば、

• VNet・サブネット設計
• Webサーバーの配置
• NSGの設計
• バックエンドのヘルスチェック
• SSL/TLS証明書
• WAFポリシー
• URLルーティング
• ログ監視
• 障害発生時の動作
• コスト

などを事前に検討する必要があります。
特に既存システムへ導入する場合は、現在のネットワーク構成やWebサーバーの設定を確認したうえで、サービス停止を最小限に抑えながら移行することも重要です。

---

ジードでは、Azureのサービス単体ではなく、Webサーバー・ネットワーク・セキュリティ・監視・アプリケーションまで含めたインフラ構成を検討しています。

「Application Gatewayを導入したい」というご相談だけでなく、

「今の構成にApplication Gatewayは必要なのか？」
「Application GatewayとFront Doorのどちらを使えばいいのか？」
「既存のWebシステムをAzureへ移行したい」

といった段階からご相談いただけます。
ご検討中の方は、お問い合わせフォームよりお気軽にご相談ください。

Application Gatewayの構築手順

1. アプリケーションゲートウェイの作成

2. バックエンド ターゲットの追加

バックエンドサーバーとして使用する2つのVMを作成し、バックエンドプールに追加します。
アプリケーションが分散されることを確認したいため、Windowsサーバー上にIISをインストールして、自身のVM名を表示するようにします。

※今回myVM, myVM2というWindows仮想マシンを用意していますが、作成方法については割愛します。

3. アプリケーションゲートウェイのテスト