f:id:tarutaru_pyorne:20210609131846p:plain

はじめに

Azureコンテナソリューショングループ）土居です。
我々の部署ではAzureにフォーカスをあてクラウドネイティブ関連の技術を追求しお客様をサポートしていきます。その一環としてAzureに関して日々ブログで技術紹介していきますので宜しくお願いします。

今回はApp Serviceの連載第三弾目では、App Serviceのフロントエンドにおける接続パターンをまとめましたので是非参考にしてもらえればと思います。

App Serviceのフロントエンド接続パターン

App Serviceはデフォルトでインターネット経由でどこからでも直接アクセスできますが、アプリケーションの要件としてネットワークトラフィックを制御したいケースは多く存在すると思います。まず真っ先に考える要件は以下と思います。

外部公開（インターネット公開）
内部公開（プライベート公開）
両方公開（インターネットとプライベート両方で公開する）

両方公開はちょっと特殊な例かと思いますが、例えばApp Serviceでホストしているアプリケーションにおいて一般ユーザー向けのサイトはインターネットからアクセスし、管理者向けのサイトはプライベートからアクセスするといった事が考えられます。

そして次に考えられるのがリージョン冗長や拡張性などの要件になります。

BCPやサービス継続性などを考慮し、予めApp Serviceを２つのリージョンに配置してロードバランサーなどで分散処理を行う
App Service単独でのスケールアウト（P3V3で最大8コア、32GBメモリ）やスケールアップ（P3で最大30、Isolatedで最大100）よりも拡張性を持たせたい

最後にWAFを利用するかどうかを検討します。

AzureのWAFサービスを利用して、アプリケーションをセキュアに保護する

もちろんセキュアコーティングを徹底すればWAFサービスを利用しなくてもインジェクション攻撃をある程度防ぐことは可能でしょうが、OSSなどの利用機会も増えている昨今でその実装調査や脆弱性の確認などはかなり大変になると思います。
しかし内部公開のみが前提のアプリケーションの場合は、社内管理端末など既に信頼された環境下からのアクセスに限られる場合も多いので、そのような場合にはWAFの導入は必ずしも必須な要件にはなってこない事もあります。

上記をフローチャートにまとめてみました。
尚、今回はApp Service EnvironmentやAPI Managementを使った接続については対象外としてます。

f:id:tarutaru_pyorne:20210430113152p:plain — フロントエンド接続パターンのフローチャート

Azure Front Doorとアクセス制御

f:id:tarutaru_pyorne:20210430113156p:plain — Azure Front Doorとアクセス制御

【メリット】

Front Doorがグローバルレベルサービスのため、複数リージョンでの冗長化に対応できる
L7トラフィックレベルで動作するロードバランサーとWAFサービスが利用できる
コンテンツキャッシュ（CDN相当）など機能が豊富
類似サービスであるApplication Gatewayと比較した場合、以下の利点がある
固定インスタンス料金の割合が少なく、安価にすむケースが多い
スケールアウトの設定等を考慮しなくてよい
アクセス制御を使ってFrontDoor経由以外のアクセスを拒否できる

【デメリット】

高額になりやすい
複数リージョン構成の設計は複雑化しやすい（特にバックエンド）

Traffic Manager 統合

f:id:tarutaru_pyorne:20210430113200p:plain — Traffic Manager統合

【メリット】

DNSレベルで動作する負荷分散サービスを利用できる
重み付けなど複数のルーティング手法を利用できる
安価である
Azure以外の外部アプリケーションとの連携など、ハイブリッドな構成も可能

【デメリット】

WAFやSSL終端の機能はないため、アプリケーション、App Service側で実装する必要がある
複数リージョン構成の設計は複雑化しやすい（特にバックエンド）

Application Gatewayとサービスエンドポイントの併用（パブリック）

f:id:tarutaru_pyorne:20210430113204p:plain — Application Gatewayとサービスエンドポイントの併用（パブリック）

【メリット】

L7トラフィックレベルで動作するロードバランサーとWAFサービスが利用できる
サービスエンドポイントを利用し、Application Gateway経由以外のアクセスを拒否できる
複数のApp Serviceでの冗長化・負荷分散が可能（スケールアウト、スケールアップでは対応できないケース）

【デメリット】

高額になりやすい
Application Gatewayのスケールアウト、ゾーン配置などの設計も行う必要がある

デフォルト

f:id:tarutaru_pyorne:20210430113209p:plain — デフォルト

【メリット】

App Service内部構造として、フロントエンドにロードバランサー（L7）があり以下機能は単体で実現できる
1. SSL終端
2. 2.セッションアフィニティ
3. 負荷分散（ただし、アルゴリズムはラウンドロビン一択）
フロントエンドはMicrosoftが管理しているためFrontDoorやAppGWのようにユーザー側で細かな設定ができるわけではない。フロントエンドのパフォーマンスもMicrosoft依存となる。
App Service単体でスケールアウト（最大100）が可能であり上記負荷分散と連動している。
シンプルで低コスト

【デメリット】

WAFの機能がないためアプリケーション側で対策を実行しないといけない
複数のApp Serviceで冗長化する構成はできない

Application Gatewayとサービスエンドポイントの併用（プライベート）

f:id:tarutaru_pyorne:20210430113215p:plain — Application Gatewayとサービスエンドポイントの併用（プライベート）

【メリット】

L7トラフィックレベルで動作するロードバランサーとWAFサービスが利用できる
サービスエンドポイントを利用し、Application Gateway経由以外のアクセスを拒否できる
複数のApp Serviceでの冗長化・負荷分散が可能（スケールアウト、スケールアップでは対応できないケース）

【デメリット】

VNet外のクライアントがアクセスする場合は、プライベートDNSに名前解決をするためDNSフォワーダー（サーバ）が別途必要
高額になりやすい
閉域で信頼されたデバイスからのアクセスを前提としていた場合はWAFは必須ではない可能性もある

プライベートエンドポイント

f:id:tarutaru_pyorne:20210430113220p:plain — プライベート

【メリット】

App Service内部構造として、フロントエンドにロードバランサー（L7）があり以下機能は単体で実現できる
1. SSL終端
2. セッションアフィニティ
3. 負荷分散（ただし、アルゴリズムはラウンドロビン一択）
フロントエンドはMicrosfotが管理しているためFrontDoorやAppGWのようにユーザー側で細かな設定ができるわけではない。フロントエンドのパフォーマンスもMicrosoft依存となる。
App Service単体でスケールアウト（最大100）が可能であり上記負荷分散と連動している。
シンプルで低コスト
プライベートエンドポイントを設定すれば自動的にパブリックからのアクセスはできなくなる

【デメリット】