こんにちは。ヤモトです。
今回はApplication Gatewayについての記事の2回目となります。
内容はApplication Gatewayリスナー及びルールの機能である、マルチサイトリスナーとパスベースルールについてお話ししたいと思います。

マルチサイトリスナーについて

• マルチサイトリスナーの概要
  リスナーの種類の1つにアクセス時のURL情報によりバックエンドへのルーティングの振り分けを行うマルチサイトリスナーというものがあります。 ユーザーからのアクセスによる通信の HTTPリクエスト パケット内のURI情報を確認し、そのFQDN情報による振り分けを行うことが出来ます。
  ホスティング構成を取る場合、複数のFQDNに対して同じパブリックIPアドレスをDNSによって紐づけを行い、パブリックIPアドレスにアクセスしてきたトラフィックのパケット内情報をリスナーで確認し、それぞれのバックエンドに振り分ける形になります。
  
  
  
  
  アクセス先のパブリックIPアドレスは同じですが、HTTPリクエスト内のURI情報によって、“catloves.com”にアクセスしたものはWeb Server Aにといった振り分けを行うことができます。
  
  
• Basicリスナーとの設定上の違い
  
  Basicリスナーとマルチサイトリスナーの違いは単一のドメインサイトのみをリッスンするか特定のドメインサイト(ホスト名)をリッスンするかになります。いずれもフロントエンドIPとして設定したパブリックIPアドレスを対象のドメインへDNS登録することが必要ではありますが、Basicリスナーの場合パブリックIPアドレスに直接アクセスしても単一ドメインのみの設定となるのでページを表示させることが可能です。
  マルチサイトリスナー構成の場合、１つのApplication Gatewayに対して複数のドメインサイトを設定するのが前提となりマルチサイトリスナーごとに対応するドメインが決まっているため、ドメインにアクセスしなければバックエンドのサイトを表示させることが出来ないので注意が必要です。
  
  
• 設定の処理順序
  マルチサイトリスナーを複数設定した場合、ポータルで表示されているリスナーの上から順番に評価・処理されます。
  Standard_v2の場合、マルチサイトリスナーの処理がBasicリスナーよりも優先されて処理されるためリスナーを混在させる場合でも種類による順序を気にする必要はありません。
  ※Standard_v1の場合、Basicリスナーがマルチサイトリスナーよりも優先して処理されるためリスナーを混在させる場合はBasicリスナーよりも前にマルチサイトリスナーを設定する必要があります。
  
  
• 構成上の注意
  　複数のサイトやシステムを1個のApplication Gatewayでホスティングさせるマルチサイト構成ですが、1点気を付けなければならないところがあります。それは、ポータルなどでApplication Gatewayの設定を変更した際の接続断です。
  　この接続断の影響はホスティング構成をとっているサイト全体に影響を及ぼすため、設定変更を行う場合は各サイトやシステムの運用担当者と調整しサービス外に設定作業を行うなどの考慮が必要です。
  　インスタンスの数により程度は変わりますが、インスタンスが2個以上であれば処理するインスタンスを切り替えながら設定されるので通信の瞬断で済みます。※瞬断とはいってもエンドユーザーにはほとんどわからないレベルです。しかし、インスタンスが1個のみの場合設定が反映されるまでの間の通信が出来なくなってしまうので注意が必要です。

パスベースルールについて

• パスベースルールの概要
  Application Gatewayのルールの種類はBasicかパスベースの2種類あります。そのうちパスベースについてお話しします。
  パスベースルールはアクセスの際にFQDN以下につくパスによってルーティングを行うものです。
  下記は設定例の構成図になります。
  
  この構成はBasicリスナー配下にパスベースルールが存在する構成になります。アクセス時のPublicIPアドレスは同じですが、“test.com“にアクセスした際のパスにより“http://test.com/dog/”にアクセスしたものはBackend Pool Aのサーバーに, “http://test.com/cat/”アクセスしたものは Backend Pool Bのサーバー にルーティングされます。
  そして、それ以外のパスへアクセスしたものは既定のバックエンドターゲットに指定されたバックエンドプールのサーバーにルーティングされます。
  このパスベースルールによる構成を行う場合は、既定のバックエンドターゲットを必ず設定する必要があります。パス規則に当てはまらない通信をどこにルーティングさせるかなどの一覧化をおすすめいたします。
  
  
• パス規則について
  パス規則で設定できる項目をそれぞれご説明します。
  • ターゲット名
    パス規則の名前になります。(なぜターゲット名なのかはわかりませんが)
    ここで設定した名前がApplication Gatewayの構成情報内部で管理されます。
    
    
  • HTTP設定
    パス規則の設定にマッチングした通信をここで指定したHTTP設定の構成を使用してバックエンドプールにルーティングします。
    
    
  • バックエンドターゲット
    パス規則設定にマッチングした通信をルーティングするバックエンドプールを指定します。
    
    
  • パス
    この設定にマッチングしたものをバックエンドターゲットにルーティングします。
    設定できるパスは必ずスラッシュから始まる必要があり、大文字小文字で区別はされません。
    正規表現のように“*.jpg”途中にアスタリスクを挟むような設定は対応していません。
    Standard_v2より、パス末尾のアスタリスク設定がスラッシュの後ろでなくとも設定できるようになりました。
    詳しくはこのドキュメントをご参照ください。
    

マルチサイトとパスベースルールの組み合わせ

マルチサイトリスナーとパスベースルールを組み合わせることにより１つのApplication Gatewayで複数サイトのホスティング設定とアクセス時のFQDN名とパスによって表示させるサーバーや使用するHTTP設定を細かく設定することが可能です。

１．構成
上の例では１つのApplication Gatewayで２サイトをホスティング構成し、パスによる振り分け設定のあるものと無いものが設定されている例です。
ルーティングの要件が２つあり、まずフロントエンドIPにアクセス後、マルチサイトリスナー設定によりドメイン毎の振り分けがなされます。そしてパスベースルーティング設定がなされているルールの場合はパスによる振り分けがなされます。

２．ルーティング設定
“catloves.com“にアクセスした場合はマルチサイトリスナー１に、”dogloves.com“にアクセスした場合はマルチサイトリスナー２に振り分けられます。
ですので、User Cがアクセスした場合、”マルチサイトリスナー２”を経由し、”Backend Pool C”にルーティングされます。
User Aの場合、”http://catloves.com/cats/”にアクセスしようとしているので、まずマルチサイトリスナー1に振り分けられます。
そしてパス振り分けによりパス規則１によって”Backend PoolA”へと振り分けられます。よって、User Aは”Backend PoolA”にルーティングされます。

まとめ

マルチサイトリスナーとパスベースルールを組み合わせることにより、アクセス時のドメインやパスによって違うサーバーにアクセスさせたり、1個のドメインからパスごとにアクセス先を分けるなど複雑で柔軟な設定が可能です。
マルチサイト構成とパスベースルールを組み合わせることで複雑な振り分けが出来るようになる一方、構成を把握しづらくなりますのでApplication Gatewayを構築する前に振り分け情報などを一覧化しておくことをお勧めいたします…。

次回はHTTP設定及び正常性プローブなどのバックエンド側にかかわる設定部分を記載予定です。