Azure Web Appsを利用するにはSNATに気をつけたい
Azureを利用する際に非常に重要なポイントとしてSNATポートの枯渇があります。
※Azureに限らずだとは思いますが・・・
特にWeb AppsについてはこのSNATポート枯渇の制限にハマりやすいかと思いますので、その制限についての詳細と回避するための方法について記載していきたいと思います。
そもそもSNATとは？
簡単に説明させていただくと、Private IPしか付与されていないサーバ等からPublicのサービスにアクセスする際にPublic IPに変換してNATすることをSNATと言います。
この通信の際に利用されるのephemeralなポートがSNATポートになります。
ではWeb AppsではどのようにこのSNATポートが枯渇されるのでしょうか。
Web Appsの内部構造とSNATの関係性について
Web Appsをすでにご利用されている方が多いと思いますので
本構成についてはご存知かと思いますが、Web Appsを作成する際にApp Serviceを作成します。これによりWeb Apps（ワーカーインスタンス）はこれはスタンプというユニット内にデプロイされます。
※App Service Environmentは少々異なる
ワーカーインスタンス自身にはPublic IPが付与されておらず、外部のリソースへアクセスするためにはスタンプのLoadbalancerを介してSNATを行い通信が実施されます。
SNATとApp Serviceの関係について詳細に知りたい方は、以下のサイトを参照ください。
App ServiceのSNATの制限値と超えた場合の挙動
上記のサイトにも記載がありますが、Web AppsのインスタンスごとにSNATポートの数は128までは保証されております。それを超える場合はスタンプ内で空いているポートからベストエフォートで割り当てが実施される場合があります。
では？この制限を超えた場合にどのような挙動になるのでしょうか・・・？
結論：外部との通信ができなくなる！
恐ろしいですね。いきなり通信が詰まってしまい正常に動作していたと思ったら
死に始めるような挙動になります。通信がうまく行くときもあれば、いかないときもあるなど・・・・
ではこのSNATポート枯渇にならないために必要なこととは何でしょうか？
- Modify the application to reuse connections
コネクションの再利用をする。アプリ側でHttpClientを使い回すことでしょうかね - Modify the application to use connectionpooling
DBなどでアクセスする際にConnection Poolingできますがこの設定をしておく
確かPHPのLarabelはDefaultでPoolingしないようになっていた気がするので注意が必要ですね！ - Modify the application to use less aggressive retry logic
リトライ処理を実装と記載があります。ですがSNATポート枯渇している際にリトライしていたらどんどんつまりそうで根本的な解決にはならない気もしますが - Use keepalives to reset the outbound idle timeout
キープアライブの設定でアイドルタイムアウトのリセットを行う - Ensure the backend services can return response quickly.
バックエンドのサービスでレスポンスが早く返るか確認する。
通信が滞留する分SNATポートを保持し続ける時間も長くなるので大切ですね - Scale out the App Service plan to more instances
App Service Planのスケールアウトを行う。確かにインスタンスあたりで制限があるので増やせばその分SNATポートも増えます。ですがSNATポートが滞留するアプリ実装になっていれば増やしても根本的な解決にはならないし費用面が上がってしまします・・・ - Use App Service Environment, whose worker instance can have more SNAT ports, due to its smaller instances pool size.
App Service Environmentを利用するとありますが、確かにApp Service Environmentを利用すると、占有できるため利用できるSNATポートが増えますがその分構成が少々複雑になるのと価格が上がる懸念があります。 - A load test should simulate real world data in a steady feeding speed.
これは対策というよりも、リリース前の基本かと思いますが実際のデータでロードテストをすることも必要かと思います。
ここまでつらつらと対策と書いてきました。もちろんSNATポートを過度に利用しないためのアプリ側の実装等ももちろん大切ですが、そもそもSNATポートを利用しなければこんな問題には当たらないかと思います。
次の章でその方法について触れたいと思います。
SNATポートを利用しないためには？
SNATポートをそもそも利用しない方法として、3つのキーワードがあります。
- App Service Region VNet Integration
- Private Link
- Service Endpoint
この3つのキーワードでピンと来る方もいらっしゃるかもしれませんが・・・
そうです！そもそもPublic IPに変換してアクセスしなければいいんです！！！
※長々と書いてきましたがここがポイント
App Serviceの機能として、VNet Integrationがあります。
これはGatewayが必要なIntegrationと不要なRegion Integrationがあるのですが
今回はRegion Integrationを利用する必要があります。
※App Service PlanのPremiumV2のプランのみ
Region IntegrationはVNet内のリソースへのアクセスはもちろんサービスエンドポイントやPrivate Link経由にて各種Azureサービスへアクセスすることができます。
Azure SQL DatabaseやMySQL、Postgress、Storageなど様々なサービスでPrivate LinkまたはService Endpointの対応がされております。
これらのサービスへアクセスする際は、この機能を利用してVNet Integrationしたサブネットから内部的にアクセスすることでSNATポートを利用せずアクセスすることが可能になります！！！
またアプリでセッション管理等でCache for Redisを利用されるケースが多いと思われますが、このサービスについてはそもそもVNet内にPremium Plan以上でデプロイできるため内部的にアクセスすることが可能です。
まとめ
SNATポートを枯渇させないために、アプリ側の実装等気をつけるポイントはありますが、そもそもSNATポートを枯渇させないためにAzureの構成としてPrivate LinkやService Endpointをうまく利用することで解決することもできます。
これを機に構成を今一度見直す参考になれば良いと思っております。
最後になりますが、Web Apps自体でこのSNATポートの利用状況を確認できるページが追加されています。
仮にSNATポートの枯渇が疑われる場合は、本画面から現在利用されているSNATポートの数について確認していただければと思います。
今回はApp Serviceについてフォーカスしましたが、その他AzureサービスでもこのSNATポートについては気をつけて設計していただくのが予期しないエラーを回避する１つのポイントになるかと思います。
まあ偉そうに書いてますが、当の本人も１回このポイントを踏んでしまってるんですがね・・・
記載に不備があれば私自身も勉強になるためご指摘いただければと思います。
Azure SQL Database Serverlessってなんぞ？
様々なタイプのSQL Databaseが存在してきていますが、今回Azure SQL Database ServerlessについてPickupしてみたいと思います。
個人的にもいろんなタイプがあって、よくわからなくなってきたのでこのタイミングで整理したいと思って書きました。（笑）
公式ドキュメントは以下。
ここで振り返りますが、現時点(2019/10/26)で以下のタイプのSQL Databaseがあります。ここ2年でだいぶ進化してきましたね。No.4のインスタンスプールについてはまだ知見がないため概要は記載してないです・・・あと間違っていたら指摘ください。
| # | 種類 | 概要 |
|---|---|---|
| 1 | Single Database | SQL Serverで管理される単一DB(一般的なRDB) |
| 2 | Elastic Pool | DTUを共有できるタイプのDB |
| 3 | Managed Instance | VNet内にデプロイ可能なプライベートなDB |
| 4 | Managed Instance Pool | ??? |
| 5 | Serverless | 今回記載するDB！！！ |
表でまとめましたが、ではこれまでのSQL Databaseと比べどのような部分が利点なのか整理していきましょう。個人的にはざっと以下の3点かなと思ってます。
- 設定したスペック内で自動でスケーリング
- 費用は実際に利用したCPUおよびメモリ
- ユーザセッションが無い場合は自動停止
設定したスペック内で自動でスケーリング
最大の特徴になるのが自動でスケーリングしてくれる点だと思ってます。
最小仮想Coreと最大仮想Coreを設定し、その間で自動でスケーリングしてくれます。
最小仮想Coreで設定したCore数に関しては必ず確保されます。そして利用形態に応じて内部で最大仮想Core数までスケーリングされます。
ただし１点注意があります・・・
記載している通り必ず内部的にプロビジョニングされているのは、最小仮想Coreで設定した分です。仮に利用が増えスケーリングする際は、最大仮想Core数までリソースを確保しようとします。これがうまく行けば良いですが、仮にプロビジョニングされているサーバの近くでリソースが確保できない場合、、、スケーリングまでに待ちが発生するか、再配置等が実施されるのでは無いかと思っております。
この点を考えると、Serverless以外のタイプであれば事前に指定したスペックでプロビジョニングされているので問題にはならないですね！
この点はServerlessタイプを利用するかどうかの判断ポイントになるのでは無いでしょうか。
費用は実際に利用したCPUおよびメモリ
これまでのSQL DatabaseはDTUベースなら事前にDTUを設定、vCoreベースに関しても事前に設定したvCoreで課金が行われます。
そのため実際に消費しているリソースと設定したスペックに差があればあるだけ、もったいない現象になっておりました！まあクラウドなんで、定期的に見直しできるんですけどね！
それを解決してくれたのが、Serverless!!!
起動している時は実際に利用したCPU、メモリあとはストレージの費用がかかってきます。後述しますが、停止も可能なためその際はストレージのみの費用になります。
非常に効率的にSQL Databaseを利用できるようになりますね！
ユーザセッションが無い場合は自動停止
ユーザセッションが 0であり、ユーザのワークロードで利用しているCPUが0の場合自動停止の設定が可能です。
条件に当てはまってから自動停止になるまでの時間も設定可能です。
またもちろん自動停止機能自体もOffにすることも可能です。
開発環境等で利用する場合、夜なんかは利用者がいないため自動停止機能をONにしておけば利用料が抑えられますね。
再開の条件ですが、いくつかありますがログイン操作等のリクエストがあった際に再開されます。最初のリクエストはおそらくエラーでアクセスできませんが、その数分後からアクセス可能になるかと思います。
自動停止になる条件や、再開の条件については公式サイトを確認してみてください。
つらつらと長く書いてしまいましたが、ユースケースによっては非常に利用するのがありだなと思えるサービスだと思います。上記の通りとりあえず開発環境のSQL Databaseに関してはSingleやElastic PoolタイプではなくServerlessにすぐ変えるべきかなと思いました。
Azure 踏み台サービス Azure Bastionがプレビューに！！！
ついにAzureから、PaaSサービスにてAzure Bastionがリリースされましたね。
企業内でサーバ管理をするとなると、必須で利用されていると思われる踏み台サーバですがついにManagedなサービスが出てきました。
今回リリースされたAzure Bastionの特徴を見て見ましょう。
現在のプレビュー中の情報からは以下4点の特徴があります。
- サーバにPublic IPの付与がいらない
- Azure Portalからssh or RDP接続が可能
- 通信プロトコルは、ssl(443ポート)で暗号化されている
- VNet内にAzure Bastionサービスをデプロイすることで、VNetないのサーバへアクセス可能
引用：https://azure.microsoft.com/ja-jp/services/azure-bastion/
続きを読むAzure Data Factoryを監視する様々な方法。。。
久しぶりに記事を更新します。。。
Azure Data Factoryについて記載したいと思います。
Azure Data Factoryはご存知のかたも多いかと思いますが。ハイブリッドデータ統合サービスになります。
この単語だけ聞いてもよくわからないかと思いますが、端的に言うと様々なデータソースから、いろんなAzureサービスへのデータ連携のパイプラインが簡単に作れます！
下図のように、ブラウザをUIとしてドラッグ＆ペーストでパイプラインを作成していきます。
詳しくは、公式サイトで確認いただく方が良いと思います。
続きを読むApplication Gateway+Web Apps構成がAzure Portalのみで設定可能に！
簡単にWebアプリケーションをデプロイできる、Web Appsですがセキュリティ対策が気になるところかと思います。
セキュリティ担保のために、仮装アプライアンスを導入するためにIaaSを立てるのも・・・
こういった場合に、救世主になるのがApplication Gatewayかと思います。
本機能は、SSL終端の機能やWAFの機能を備えております。
全部PaaSで構築したい！となると、Application GatewayとWeb Appsの構成が簡単にできるかと思います。
これまでは、PowerShellを利用してしか本構成を設定できなかったのですがAzure Portal上からも設定可能になっておりました。（※アナウンスは特になし？）
Application GatewayのBackend Poolの設定画面になります。
上記の通り、App Service等プルダウンが登場しております。
Targetで「App Service」を選択し、振り分けたいWeb Appsを選択します。
またこれだけでは完了ではありません。
よく見ると注意書きが出ております。
「Http settings and probes needs to be created with proper settings」
→Httpとprobeの設定を適切にしてね！という注意書きが・・・
適切にってなんだよと思いながらも、下記の設定をしました。
■Http Settings
「Use for App Service」にチェックを入れて保存します。
■Health probes
「Pick host name from backend http settings」を選択し保存します。
以上で設定は終わりです。
Application Gatewayはデフォルトで、正常性プローブを送信してくれるのですが、
Web Appsを構築する場合は、追加で設定しないといけないみたいですね。
あとは、Application GatewayのNSGの送信・受信規則などが問題ないか確認しアクセスすれば！Application Gateway経由にて、Web Appsが利用可能になるかと思います。
Azure Functions （python）でTimer Triggerを作成
Azure Functions はご存知でしょうか。
サーバレスにてAPIや、cronでコードを実行させたりと様々な機能が存在します。
Azure Functionsでできること。(2018年3月1日現在)
- タイマーベースの処理
- Azureサービスのイベント処理
- SaaSイベント処理
- サーバレスWebアプリケーションアーキテクチャ
- サーバレスモバイルバックエンド
- リアルタイムストリーム処理
- リアルタイムボットメッセージング
以前はAzureサービスのイベント処理などしかできなかった気がするのですが
どんどんとUpdate されています。
また今回のカッコで記載してますが、python等の言語も最近サポートされてきました。
他にはnode.jsもあったかな！
pythonを利用して、APIも実装できるのですがそれはまたの機会に。
さて前置きが長くなりましたが、本題に移ります。
Azure Functions でTimer Triggerを作ろうと思った場合、普通には作成できません。
少しコツがいります。。。これも今後Updateされていくかと思いますが。
１．関数の作成を選択し、Experimental Language Supportを選択
２．HTTP triggerを選択しpython で作成する
下図からわかると思いますが、Timer Triggerの方にはpythonが出てきません...
３．作成した関数の「統合」でHTTP triggerを削除する
４．新しいトリガーからTimerを選択し、保存する
以上で作成できました。このように一旦作成してから変更しないみたいです。
画面だけ見ると、作成できないように思えてしまいますね。
今回は下記の海外のBlogを参照しました。
次回は実際にAzure Functions でのAPIや今回のTimer tigger等を記事にできればと思います。
参考サイト：Running Python on Azure Functions — Time Trigger, External Libraries
LinuxからAzure CLI 2.0を実行する！
Azure環境に作成したLinuxサーバ内から、Azureのリソースにアクセスし操作したい場面があるかもしれません。
例えば...Linux環境にスクリプトを用意しておき、ジョブサーバからキックさせる等。
その場合はLinuxサーバにAzure CLI 2.0をインストールして操作します！
インストールの方法は以下がわかりやすいと思います。（英語ですが・・・）
インストールができたとして、次にLinuxサーバ等からAzureリソースへアクセスするためには、az loginコマンドを実行する必要があります。
- ワンタイムパスワードによるログイン：対話式
- ユーザ名、パスワードを指定してログイン：非対話式
- サービスプリンシパルを発行およびパスワード（client secre）によるログイン：非対話式
- サービスプリンシパルを発行およびpemファイル（client certificate）によるログイン：非対話式
上記の2番の、ユーザ名、パスワードを指定してログインする方法には注意点があります。Azureへのログインを2段階認証がONになっている場合、パスワードを同時に指定できません。そのためシェル等から実行する際は、エラーが発生します。
スクリプトから実行する際は、3番か、4番での実行方式を検討してみてください。
