No content

Noriyuki TAKEI ෢Ҫ ٓߦ Information • サイオステクノロジー株式会社 • Microsoft MVP for Microsoft Azure Favorites • Azure • パデル • スキー • ライブ配信 • ⽢いもの • ⾛ること blog https://tech-lab.sios.jp/ core skill Azureによるクラウドネイティブな アプリ開発 Twitter @noriyukitakei

技術ブログ「SIOS Tech.Lab」 世界⼀わかりみの深いApplication Gateway https://tech-lab.sios.jp/archives/30628

ϩʔυόϥϯαʔͷ छྨ

ロードバランサの種類 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セッション クライアント ロードバランサー サーバー クライアント ロードバランサー サーバー

L4のロードバランサー L7のロードバランサー 負荷分散の機能 ✗ ◯ ラウンドロビン、IPアドレスとかTCP ポートによる分散 Cookieとかホスト名など様々な要素で 分散可能 SSL終端 ✗ ◯ L4なのでできない L7なのでもちろん可能 性能 ◯ ✗ 仕組みがシンプルなので負荷分散性能は (⼀般的に)⾼い SSL終端やHTTPリクエストの検証・書 き換えなどの処理が⾼負荷であり、(⼀ 般的に)負荷分散性能は低い 適⽤範囲 ◯ ✗ L4なのでWebアプリケーションのみなら ず、LDAPなど幅広く適⽤可能 HTTPで動作するアプリケーションのみ

Application Gatewayの特徴 Application Gatewayは完全にマネージドされたサービスであり、ユーザーは基 盤のメンテナンスやアップデートの⼼配をせずに、主に設定やルーティングのロ ジックに集中することができます。 フルマネージド トラフィックの需要に応じて⾃動的にスケーリングすることができ、パ フォーマンスの維持とコストの節約を同時に達成できます。 Autoscaling SSL/TLS証明書の管理にAzure Key Vaultを使⽤し、Application Gatewayの SSL終端のセキュリティを向上させるなど、Azureとの⾼い親和性を持っていま す。 Azureとの 親和性

"QQMJDBUJPO(BUFXBZͷ ߏ੒

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アド レスを配置できます。 バックエンド プール

Application Gatewayの構成 仮想ネットワーク Azure https Internet … … フロントエンド ルーティング規則 バックエンドプール バックエンドターゲット リスナー http ルーティング規則 バックエンドターゲット リスナー パブリックIP プライベートIP Application Gateway ユーザー、 アプリ等 ユーザー、 アプリ等 バックエンドプール バックエンドプール

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

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

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

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利⽤時、悪意あるトラフィックを検出したとき エラーページ

リスナーの種類 仮想ネットワーク Azure https Internet フロントエンド ルーティング規則 バックエンドターゲット リスナー XX.XX.XX.XX Application Gateway ユーザー、 アプリ等 バックエンドプール VM1 VM2 hoge.contoso.com https リスナー fuga.contoso.com

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

Application Gatewayがリクエストを分散させるバックエンド を指定します。 バックエンド プール パスによって異なるバックエントにリクエストを振り分けるこ とができる機能です。 パスベースの規則

パスベースの規則 ユーザー バックエンドプール バックエンドプール Application Gateway /images/* /videos/*

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

バックエンドに接続するプロトコルを定義します。「http」「https」の2択です。 例えば、「http」を選べば以下のような経路となり、SSL証明書はApplication Gatewayだけで持てばよいということになります。 ブラウザ→(https)→Application Gateway→(http)→バックエンド バックエンド プロトコル バックエンドに接続するポートを定義します。任意のポート番号を設定出来ます。 バックエンド ポート いわゆる「Cookieパーシステンス」なロードバランサーを実現出来ます。 Application GatewayがブラウザにCookieを発⾏し、そのCookieの値をもとに、同 ⼀ブラウザからのリクエストは同⼀バックエンドに振り分けます。 Cookieベースの アフィニティ この設定を有効にしていると、バックエンドプールからバックエンドが削除されて も、削除されたときに⾏われていた通信が最後まで完了するまで、バックエンドの 切り離しを待ちます。 接続のドレイン URLのロケーションの部分を変換する機能です。 バックエンドパス の オーバーライド

Application Gatewayからバックエンドに送出するホストヘッダーを変更すること が出来ます。 ホスト名の オーバーライド Application Gatewayは何らかの異常が発⽣したバックエンドを振り分け対象から 外すことが可能です。何を持ってして異常と判断するかを細かくカスタマイズが可 能で、その設定が「カスタムプローブ」になります。 カスタムプローブ

接続のドレイン 仮想ネットワーク Azure https Internet フロントエンド ルーティング規則 バックエンドターゲット リスナー XX.XX.XX.XX Application Gateway ユーザー、 アプリ等 バックエンドプール VM1 VM2 ✗ VM2がバックエンドプールから削除 要求されても、「要求のタイムアウ ト」で指定した秒数以内はこの通信 を継続し、この通信が終了したら、 バックエンドプールからVM2が削除 される。

バックエンドパスのオーバーライド Application Gateway ユーザー バックエンド バックエンド パスの オーバーライド ＝ /override/ http://example.com/hoge http://example.com/override/hoge overrideというパスが 追加になっている

ホスト名のオーバーライド (変更なしの場合) Application Gateway バックエンド ホストヘッダー:example.com ホストヘッダー:example.com 同じ値

ホスト名のオーバーライド (バックエンドから取得) Application Gateway バックエンド ホストヘッダー:example.com ホストヘッダー: hoge.azurewebsites.net ホスト名 ＝ hoge.azurewebsites.net

ホスト名のオーバーライド (ホスト名を指定) Application Gateway バックエンド ホストヘッダー:example.com ホストヘッダー: hoge.contoso.com ホスト名 ＝ hoge.contoso.com

カスタムプローブ チェック OK チェック OK チェック NG Application Gatewayのリクエ スト対象から除外される。

カスタムプローブ Application Gateway バックエンド URL メソッド ボディ HTTPリクエスト HTTPレスポンス http[s]://[バックエンドのホスト]/[ヘルスチェックのパス] GET ステータス コード 200 Success Message

success

ステータスコードをチェック可能 レスポンス内に特定の⽂字列が 含まれるかをチェック可能

技術ブログ「SIOS Tech.Lab」 世界⼀わかりみの深いApplication Gateway https://tech-lab.sios.jp/archives/30628

"QQMJDBUJPO(BUFXBZͷ Ձ֨

Application Gatewayの構成要素 Application Gatewayのリソース インスタンス 容量ユニット

Application Gatewayのリソース Azureポータルから作成したApplication Gatewayのリソースそのものです。Azureポータルから以下のように ⾒えるやつです。

Application Gatewayの構成要素 Application Gatewayのリソース インスタンス 容量ユニット

容量ユニット Application Gatewayの課⾦単位 HTTPリクエストが増えるほど 多くの容量ユニットが必要になる 容量ユニットが増えるには ある⼀定のルールがある

容量ユニット 2,500個の永続的な接続 「永続的な接続」とは同時に⾏われるTCP接続を表しま す。つまり、⼀つの容量ユニットでは2,500のTCP接続 を同時に処理でき、それ以上のTCP接続が発⽣すると、 必要となる容量ユニットは増えます。 2.22Mbpsのスループット スループットとは、Application Gatewayが内部で処理 した1秒あたりのバイト数になります。つまり、⼀つの 容量ユニットで処理できるバイト数は1秒あたり 2.22MByteであり、それ以上要求されると、必要とな る容量ユニットは増えます。 1コンピューティングユニット 1秒あたりのTLS接続数、URL書き換え計算、WAFルー ルの処理によってコンピューティングユニットを消費し ます。

Application Gatewayの構成要素 Application Gatewayのリソース インスタンス 容量ユニット

インスタンス Application Gatewayがスケールする単位 容量ユニットはインスタンスの中に 格納される ⾃動スケールと⼿動スケールがある

インスタンスの⾃動スケール Azureポータルから以下のように設定を⾏います。

インスタンスの⾃動スケール ユーザー Application Gatewayのリソース インスタンス 容量ユニット 現在の容量ユニットでは さばききれない リクエストがあると、、、 新たなインスタンスが作成されて そこに新たな容量ユニットが 格納されます。

インスタンスの⼿動スケール Azureポータルから以下のように設定を⾏います。

インスタンスの⼿動スケール ユーザー Application Gatewayのリソース インスタンス 容量ユニット 現在の容量ユニットでは さばききれない リクエストがあると、、、 まだ容量ユニットが格納されていない 空っぽのインスタンスに、 新たな容量ユニットが格納されます。

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円 変動コスト 価格の構成要素

超過コストが発⽣しない⼿動スケーリングの場合 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円

超過コストが発⽣する⼿動スケーリングの場合 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円 容量ユニット(超過分)

超過コストが発⽣する⾃動スケーリングの場合 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円 容量ユニット(超過分)

技術ブログ「SIOS Tech.Lab」 世界⼀わかりみの深いApplication Gateway https://tech-lab.sios.jp/archives/30628

SIOS Tech.Lab https://tech-lab.sios.jp/ 世界⼀わかりみの深い クラウドネイティブ on Azure https://youtube.com/playlist?list=PLbTt_DSTMYgGLUtZ0ewuBwhTBSZnNE2-w 様々なメティアで情報発信しています！！ 是非みてね！！ 技術ブログ YouTube配信

エンジニア募集（プロフェッショナルサービスチーム） エンジニアファーストの環境で、技術⼒を⾼めませんか︖ 変化や進化を楽しみながら、私たちとともに歩んでくれる仲間を募集してい ます︕ OSS ＆ クラウド技術をコアテクノロジーとしたシステム開発 ● 統合認証システム＆クラウド連携 ● OSS＆クラウド基盤導⼊、OSSカスタマイズや開発、OSSサポート ● クラウドネイティブシステム、データ分析基盤、アプリ開発 ● APIエコノミーコンサルティング＆技術⽀援サービス 詳細はこちらのサイトからご覧ください︕ https://tech-lab-engineer.sios.jp/

࠷ޙ·Ͱ͝ਗ਼ௌ௖͖ ͋Γ͕ͱ͏͍͟͝·ͨ͠ʂʂ