Upgrade to Pro — share decks privately, control downloads, hide ads and more …

世界一わかりみの深いApplicationGateway/wakarimiappilicati...

 世界一わかりみの深いApplicationGateway/wakarimiappilicationgateway

本資料は、Azureが誇るL7のロードバランサーであるAzure Application Gatewayをわかりみ深く説明します。

Azure Application Gatewayはかなり高機能なL7レイヤーのロードバランサーです。代表的な特徴は以下の通りです。

- もちろんマネージド。セキュリティパッチ当てたりなどの運用は一切不要である。
- 負荷に応じて柔軟にスケールする。
- SSLの終端を行うことができる。
- WAF(Web Application Firewall)によって高いセキュリティを確保できる。
- Azureの各種サービスと密な連携が可能である(例えばApp Serviceの前段に配置することも簡単にできる)

そんなApplication Gatewayですが、なかなかにその概念や設定が難しかったり、料金体系が複雑であったりします。

今回は、そんなApplication Gatewayをわかりみ深く解説し、これからApplication Gatewayを導入する方々のお力に慣れればと思います。

Noriyuki TAKEI

September 19, 2023
Tweet

More Decks by Noriyuki TAKEI

Other Decks in Technology

Transcript

  1. Noriyuki TAKEI ෢Ҫ ٓߦ Information • サイオステクノロジー株式会社 • Microsoft MVP

    for Microsoft Azure Favorites • Azure • パデル • スキー • ライブ配信 • ⽢いもの • ⾛ること blog https://tech-lab.sios.jp/ core skill Azureによるクラウドネイティブな アプリ開発 Twitter @noriyukitakei
  2. ロードバランサの種類 syn syn syn + ack syn + ack ack

    ack HTTP Request HTTP Request HTTP Response HTTP Response syn + ack ack HTTP Request syn syn + ack ack HTTP Request syn HTTP Response HTTP Response L4の場合 L7の場合 1本目のTCPセッション 2本目のTCPセッション クライアント ロードバランサー サーバー クライアント ロードバランサー サーバー
  3. L4のロードバランサー L7のロードバランサー 負荷分散の機能 ✗ ◯ ラウンドロビン、IPアドレスとかTCP ポートによる分散 Cookieとかホスト名など様々な要素で 分散可能 SSL終端

    ✗ ◯ L4なのでできない L7なのでもちろん可能 性能 ◯ ✗ 仕組みがシンプルなので負荷分散性能は (⼀般的に)⾼い SSL終端やHTTPリクエストの検証・書 き換えなどの処理が⾼負荷であり、(⼀ 般的に)負荷分散性能は低い 適⽤範囲 ◯ ✗ L4なのでWebアプリケーションのみなら ず、LDAPなど幅広く適⽤可能 HTTPで動作するアプリケーションのみ
  4. Application Gatewayの構成 Application Gatewayの⼊り⼝になります。パブリックIPとプライベートIPの2タ イプを提供し、ユーザーはこれらを介して仮想マシンやApp Serviceにアクセスで きます。特に、パブリックIPは公開エンドポイントとしてインターネット上でアク セスが可能となります。 フロントエンド 後述するルーティング規則とフロントエンドを結びつける構成要素です。リスナー

    はHTTPのスキーム(HTTP or HTTPS)やホスト名などで構成されており、 例えば、XXX.XXX.XXX.XXXというパブリックIPを持つフロントエンドと、HTTPS のスキームをもつリスナーを結びつけると、「https://XXX.XXX.XXX.XXX」とい うURLを持つロードバランサーが構成されます。 リスナー フロントエンド+リスナーの組み合わせで作成されたURLで受信したHTTPリク エストを、どのバックエンド(Application GatewayからHTTPリクエストを受け 付けてHTTPレスポンスを⽣成し、Application Gatewayに返すサーバー)に流す のかというルール決めを⾏う構成要素です。 ルーティング規則 バックエンドを配置するための構成要素です。VMやApp Service、IPアド レスを配置できます。 バックエンド プール
  5. Application Gatewayの構成 仮想ネットワーク Azure https Internet … … フロントエンド ルーティング規則

    バックエンドプール バックエンドターゲット リスナー http ルーティング規則 バックエンドターゲット リスナー パブリックIP プライベートIP Application Gateway ユーザー、 アプリ等 ユーザー、 アプリ等 バックエンドプール バックエンドプール
  6. 簡単な実例 仮想ネットワーク Azure https Internet フロントエンド ルーティング規則 バックエンドターゲット リスナー 203.0.113.1

    Application Gateway ユーザー、 アプリ等 バックエンドプール VM1 VM2 https://203.0.113.1というURLでリクエストを受け付けて、2台のVM(VM1とVM2)にリクエストを分散させる 構成を考えてみます。以下のような構成になります。
  7. 仮想ネットワーク Azure フロントエンド プロトコル … フロントエンド ルーティング規則 バックエンドプール リスナー パブリックIP

    プライベートIP Application Gateway フロントエンド ポート … エラーページ バックエンド設定 バックエンドポート カスタムプローブ … 参照 VM IPアドレス … バックエンドプール VM IPアドレス … バックエンドターゲット バックエンドプール パスベースの規則 ルール ルール ルール 詳細な構成
  8. 仮想ネットワーク Azure フロントエンド プロトコル … フロントエンド ルーティング規則 バックエンドプール リスナー パブリックIP

    プライベートIP Application Gateway フロントエンド ポート … エラーページ バックエンド設定 バックエンドポート カスタムプローブ … 参照 VM IPアドレス … バックエンドプール VM IPアドレス … バックエンドターゲット バックエンドプール パスベースの規則 ルール ルール ルール
  9. Application Gateway⾃⾝に付与するIPアドレスになります。先程も説明したよう に「パブリックIP」「プライベートIP」を付与することが可能です。Application GatewayのURLが「https://xx.xx.xx.xx/」だとすると、「xx.xx.xx.xx」の部分で す。 フロントエンドIP HTTPもしくはHTTPSが選択可能です。Application GatewayのURLが 「https://xx.xx.xx.xx/」だとすると、「https」の部分です。 プロトコル

    Application GatewayのURLのポートは80、443以外にも任意のポートを指定する ことが出来ます。 ポート 「Basic」「マルチサイト」の2つがあります。「マルチサイト」にすると、URLの ホスト名の部分は異なるけれど、同じルーティング設定を共有することが出来ます。 リスナーの種類 以下の場合に、エラーページを表⽰します。 • HTTPリクエストをルーティングするバックエンドが落ちているとき • WAF利⽤時、悪意あるトラフィックを検出したとき エラーページ
  10. リスナーの種類 仮想ネットワーク Azure https Internet フロントエンド ルーティング規則 バックエンドターゲット リスナー XX.XX.XX.XX

    Application Gateway ユーザー、 アプリ等 バックエンドプール VM1 VM2 hoge.contoso.com https リスナー fuga.contoso.com
  11. 仮想ネットワーク Azure フロントエンド プロトコル … フロントエンド ルーティング規則 バックエンドプール リスナー パブリックIP

    プライベートIP Application Gateway フロントエンド ポート … エラーページ バックエンド設定 バックエンドポート カスタムプローブ … 参照 VM IPアドレス … バックエンドプール VM IPアドレス … バックエンドターゲット バックエンドプール パスベースの規則 ルール ルール ルール
  12. 仮想ネットワーク Azure フロントエンド プロトコル … フロントエンド ルーティング規則 バックエンドプール リスナー パブリックIP

    プライベートIP Application Gateway フロントエンド ポート … エラーページ バックエンド設定 バックエンドポート カスタムプローブ … 参照 VM IPアドレス … バックエンドプール VM IPアドレス … バックエンドターゲット バックエンドプール パスベースの規則 ルール ルール ルール
  13. バックエンドに接続するプロトコルを定義します。「http」「https」の2択です。 例えば、「http」を選べば以下のような経路となり、SSL証明書はApplication Gatewayだけで持てばよいということになります。 ブラウザ→(https)→Application Gateway→(http)→バックエンド バックエンド プロトコル バックエンドに接続するポートを定義します。任意のポート番号を設定出来ます。 バックエンド ポート

    いわゆる「Cookieパーシステンス」なロードバランサーを実現出来ます。 Application GatewayがブラウザにCookieを発⾏し、そのCookieの値をもとに、同 ⼀ブラウザからのリクエストは同⼀バックエンドに振り分けます。 Cookieベースの アフィニティ この設定を有効にしていると、バックエンドプールからバックエンドが削除されて も、削除されたときに⾏われていた通信が最後まで完了するまで、バックエンドの 切り離しを待ちます。 接続のドレイン URLのロケーションの部分を変換する機能です。 バックエンドパス の オーバーライド
  14. 接続のドレイン 仮想ネットワーク Azure https Internet フロントエンド ルーティング規則 バックエンドターゲット リスナー XX.XX.XX.XX

    Application Gateway ユーザー、 アプリ等 バックエンドプール VM1 VM2 ✗ VM2がバックエンドプールから削除 要求されても、「要求のタイムアウ ト」で指定した秒数以内はこの通信 を継続し、この通信が終了したら、 バックエンドプールからVM2が削除 される。
  15. バックエンドパスのオーバーライド Application Gateway ユーザー バックエンド バックエンド パスの オーバーライド = /override/

    http://example.com/hoge http://example.com/override/hoge overrideというパスが 追加になっている
  16. カスタムプローブ Application Gateway バックエンド URL メソッド ボディ HTTPリクエスト HTTPレスポンス http[s]://[バックエンドのホスト]/[ヘルスチェックのパス]

    GET ステータス コード 200 <!DOCTYPE html> <html lang="en"> <head> <meta charset="UTF-8"> <title>Success Message</title> </head> <body> <h1>success</h1> </body> </html> ステータスコードをチェック可能 レスポンス内に特定の⽂字列が 含まれるかをチェック可能
  17. 容量ユニット 2,500個の永続的な接続 「永続的な接続」とは同時に⾏われるTCP接続を表しま す。つまり、⼀つの容量ユニットでは2,500のTCP接続 を同時に処理でき、それ以上のTCP接続が発⽣すると、 必要となる容量ユニットは増えます。 2.22Mbpsのスループット スループットとは、Application Gatewayが内部で処理 した1秒あたりのバイト数になります。つまり、⼀つの

    容量ユニットで処理できるバイト数は1秒あたり 2.22MByteであり、それ以上要求されると、必要とな る容量ユニットは増えます。 1コンピューティングユニット 1秒あたりのTLS接続数、URL書き換え計算、WAFルー ルの処理によってコンピューティングユニットを消費し ます。
  18. Application Gatewayのリソースを削除しない限り、たとえ接続が なくても、発⽣し続けるコストです。例えば東⽇本リージョンです と、2023年7⽉16⽇時点では、1時間あたり41.9181円のコストが 発⽣します。つまり1ヶ⽉稼働させていると以下になります。 41.9181円/時間 × 24時間 × 30⽇

    = 約30,181円 固定コスト 容量ユニットに発⽣するコストです。例えば東⽇本リージョンです と、2023年7⽉16⽇時点では、⼀つの容量ユニットが1時間稼働す ると、1.1564円のコストが発⽣します。10個の容量ユニットが1ヶ ⽉稼働すると以下になります。 1.1564円/容量ユニット時間 × 10 × 24時間 × 30⽇ = 約8,326円 変動コスト 価格の構成要素
  19. 超過コストが発⽣しない⼿動スケーリングの場合 Application Gatewayのリソース インスタンス 容量ユニット • スケーリングは⼿動 • インスタンス数は6で固定 •

    ある特定の⽉に平均88.8Mbpsのデータを受信 前提条件 料⾦試算 必要な容量ユニット: 88.8Mbps ÷ 2.22Mbps/容量ユニット = 40容量ユニット 60容量ユニット(現在動いている分) > 40容量ユニット(必要な分) 固定コスト: 41.9181円/時間 × 24時間 × 30 = 約30,181円 変動コスト: 1.1564円/容量ユニット時間 × 60容量ユニット × 24時間 × 30 = 約49,965円 合計: 固定コスト+変動コスト = 約80,146円
  20. 超過コストが発⽣する⼿動スケーリングの場合 Application Gatewayのリソース インスタンス 容量ユニット • スケーリングは⼿動 • インスタンス数は3で固定 •

    ある特定の⽉に平均88.8Mbpsのデータを受信 前提条件 料⾦試算 必要な容量ユニット: 88.8Mbps ÷ 2.22Mbps/容量ユニット = 40容量ユニット 30容量ユニット(現在動いている分) < 40容量ユニット(必要な分) 固定コスト: 41.9181円/時間 × 24時間 × 30 = 約30,181円 変動コスト: 1.1564円/容量ユニット時間 × 40容量ユニット × 24時間 × 30 = 約33,304円 合計: 固定コスト+変動コスト = 約63,485円 容量ユニット(超過分)
  21. 超過コストが発⽣する⾃動スケーリングの場合 Application Gatewayのリソース インスタンス 容量ユニット • スケーリングは⾃動 • 最⼩インスタンス数は3で固定 •

    ある特定の⽉に平均75.48Mbpsのデータを受信 前提条件 料⾦試算 必要な容量ユニット: 75.48Mbps ÷ 2.22Mbps/容量ユニット = 34容量ユニット 30容量ユニット(現在動いている分) < 34容量ユニット(必要な分) 固定コスト: 41.9181円/時間 × 24時間 × 30 = 約30,181円 変動コスト: 1.1564円/容量ユニット時間 × 34容量ユニット × 24時間 × 30 = 約28,308円 合計: 固定コスト+変動コスト = 約58,489円 容量ユニット(超過分)
  22. エンジニア募集(プロフェッショナルサービスチーム) エンジニアファーストの環境で、技術⼒を⾼めませんか︖ 変化や進化を楽しみながら、私たちとともに歩んでくれる仲間を募集してい ます︕ OSS & クラウド技術をコアテクノロジーとしたシステム開発 • 統合認証システム&クラウド連携 •

    OSS&クラウド基盤導⼊、OSSカスタマイズや開発、OSSサポート • クラウドネイティブシステム、データ分析基盤、アプリ開発 • APIエコノミーコンサルティング&技術⽀援サービス 詳細はこちらのサイトからご覧ください︕ https://tech-lab-engineer.sios.jp/