ワタシハ Azure Functions チョットデキル

Editor's Notes

• #12: Azure Functions をコントロールするために必要なこと ・ メッセージングサービスの使い分け ・ 内部の仕組みを理解すること　 ・ 無ければ作ってしまう
• #18: 障害児の戻りの矢印はなくす
• #21: サーバーレスの冪等性の考え方 https://medium.com/@tsuyoshiushio/serverless-idempotency-with-azure-functions-23ed5da9d428 何故、上記のことが必要になってくるのか？ ・大きなコードはタイムアウトしてしまう（Consumption plan の functions は 10 分が最大） ・ステートレスで冪等性　（クラウドは、いつ落ちるかわからない。それを前提にした設計が良い。つまりリトライを可能にする、ステートレスは並列実行、スケールしやすくなる） ・失敗を前提（問題が発生することを前提としたコードを書くことで、） ・非同期によって、スケール、突発的な需要変動に対応できる（リソースレベリングのパターン） -> サーバーレスの魅力：サーバーのインフラのおもりをすることなく、コードだけに集中して、スケールし、
• #26: Queue: 非同期の信頼あるメッセージングのため。速度は速くない（アプリを障害に強くスケールするようにする） Publish-Subscribe: 同報通信もしくは、プッシュ型の早いメッセージング（ローレイテンシー）
• #27: エンタープライズ向け非同期メッセージ送信 Queue及びPublish – Subscribe メッセージサイズ 256K まで 順番保証あり ユースケース： 金融機関システムのメッセージング
• #29: https://medium.com/@jeffhollan/in-order-event-processing-with-azure-functions-bb661eb55428
• #30: 視線誘導上、 SignalR のロゴは最後に出す
• #31: ディシジョンフローにする。（写真参照）
• #34: 言葉を読んでみる。 意味の塊で文章を作る。息継ぎのところで改行をする
• #35: Function App 作成の要求 ARM がリクエストを Geo-Master に送信 Geo-Master が適切な Scale Unit を選んでリクエストを転送 Scale Unit が Function App を割り当てる
• #36: Function App 作成の要求 ARM がリクエストを Geo-Master に送信 Geo-Master が適切な Scale Unit を選んでリクエストを転送 Scale Unit が Function App を割り当てる
• #37: サポートサーバの用途は、冗長性やスケールのためのインスタンスになっている。
• #39: Fig 1. 先にプロビジョンされたプールが存在する Fig 2. App Service Plan で、２つのサーバーを割り当てる Fig 3. 2 つのワーカーを追加する。ワーカーは既にプレプロビジョンされて、ウオームアップされている。 　　　あとはアプリをWorker にデプロイするのみ。デプロイできたら、ワーカーはローテーションに入り、Front End が 　　　トラフィックをアロケートする。このプロセスは数秒かかる。 Fig 4. 複数のApp Service Plan を示している。これは複数の顧客が含まれている
• #40: ポイント: Function App は、Azure File をローカルのように使う（だから、Node.js の時にたくさんファイルがあると速度が遅くなる) Azure File の性能要件を調査する API Controller は Geo-Master の extension. Geo-Master は Scale Unit にマネージメントオペレーションを委譲する。 　　　　　 Function App を作ることや、アプリケーションのリスタートなども。 Publishers : Application デプロイ用の API 。コンテンツは、 Blob にストアーされて、ファイルサーバーにマップされる。Publisher は、顧客に 　　　　　　　　　FTP アクセスを提供する。コンテンツとログについて。アプリケーションのデプロイは複数の方法がある。WebDeploy (Visual Sutido) GitHub 等をつかった、Continous Deployment ほかにも Run from Zip デプロイもある SQL Azure : Function App のメタデータを保持する。どの Function App がどの Scale Unit に割り当てられているか？が保存されている。 　　　　　　　　　　また、アプリケーションのランタイム情報も保持している Data Role : Function App の設定情報は、SQL Database に存在するが、そのキャッシュレイヤー DataRole は、Front End と同じところに存在する。 Blob Storage の部分は以前は、Azure File だったが、SMB Share とカスタムファイルシステムドライバに変更された。Azure File よりこちらのほうがずっと高速である。
• #42: 複数のFunction App は、1 つの App Service Plan に割り当てられる。 App Service Plan に含まれるすべての‘Function App は、App Service Plan で割り当てられたすべてのワーカー（サーバー）で実行される。 複数のコンピュートリソースが App Service Plan に割り当てられたところを想像しよう App Service Plan は 10 のコンピュートリソースがある。 Function App が 50 あるとする。 50 のすべてが最初のサーバーから、10番目のサーバーすべてでで起動する。 この状態で、App Service Plan がより多くのリクエストをうけて、CPUとメモリを改善したいためにスケールしたとしても、スケールしたところで 動いているAPPの数は同じになるので、性能は改善されない。 その代わりに、 50 のアプリを分割する ・ 40 の low-volume アプリケーション　は１つの App Service Plan にわりあてて、1つのコンピュートリソースを確保する ・ 5 の mid-to-low volume のアプリケーション　を　２個目の App Service Plan それは、１つのコンピュートリソースを確保する ・負荷の高い 5つのアプリケーションは、それぞれ別の App Service Plan にわりあてる。App Service Plan をスケール In/Out すると 　CPU / Memory の利用状況の改善になる。 　こうすると、効率的にリソースを割り当てて、別々にスケールアウトできるようになる。 他の方法としては、Per-App スケールという方法がある。先ほどと同じの５０の Function App の例で考える。　一つの App Service Plan を作る。 ・ 40 の low-volume の Function App は、 最大 1 つのサーバーで動くように制限する ・5つの mid-to-low は、最大２つのサーバーに ・ 5つのハイボリュームのFunction App は、最大 10 のサーバーの制限をつける App Service Plan は、最小のサーバーから初めて、オートスケールに茂登枝く。　結果として、インスタンスのサーバーが起動する Application Slot の注意 アプリケーションスロットは、デフォルトでは新しい、 Function App を同じ App Service Plan で動かしているのと等しい。 しかし、同じ App Service Plan の　すべての Function App はすべてのサーバーで動くため、負荷テストを、ステージングスロットにかけると、 本番の方にも影響がでることになる。 それを避けるためには次のようにする。 ・　新しい App Service Plan をスロットように作る。両方の App Service Plan は同じリージョンであること ・　ステージングのスロットを新しい App Service Plan にする ・ 負荷テストをする ・ スワップ可能になったら、ステージングスロットの　App Service Plan をもとにもどす ・ スワップする ノーダウンタイムデプロイメント ・スワップを使う ・スワップは再起動とかおこなわないので、ウォームアップが必要なら、ステージングでやっておくとよい ・コントローラーが Front-end ロードバランサーに通知して、トラフィックがリダイレクトされる Scale Unit ネットワークコンフィグレーション ・ App Service の Scale Unit は、 Cloud Service にデプロイされる。 ・ Scale Unit は、 一つの Virtual IP を持つそれは世界に公開される。VIP は、 Cloud Service のどの　Scale Unit がデプロイされているかを表している。 ・ App Service は、 HTTP:80, HTTPS 443 のみ。 ・インバウンド IP のみが確保される。　Front End は、SSL のターミネーションも実施している。 Public VIP inbound Http トラフィックを受け付ける。 Nslookup とかで見ると中身が Cloud Service とわかる。 outbound VIP は、App Service Plan の Function App の Property に Out bond IP が５つのVIPが がある。1つの Public VIP と、4つの Outbound IP がわりあてられている。 Consumption Plan の Outbound IP はない App Service Environment だと、IP を確定できるが、 Functions にはない。 ネットワークポートの注意（ポイント） ・　outbound のネットワーク呼び出し（REST や DB 等)の呼び出しには注意が必要 ・　Function App からの外部ネットワーク呼び出しは、Azure Netwrok の NAT マッピングに依存する。 新しい NAT マッピングのエントリを作ることは、時間がかかる 1つのスケールユニットについて、NATマッピングの数が限られる。 App Service は、outbound コネクションに たいして、次の制限がある。 ・ 1,920 コネクション (B1/S1/P1) インスタンス ・ 3,968 コネクション (B2/S2/P2) インスタンス ・ 8,064 コネクション (B3/S3/P3) インスタンス ・ 64k max 上限 per App Service Environment (Function App には関係なし） 　　　この上限を超えると、function App は失敗しだす。こんなエラーをみることになる。 “An attempt was made to access a socket in a way forbidden by its access permissions aa.bb.cc.ddd.” これを避けるためには次のベストプラクティスが有効 ・ADO.NET/EF などのデータベースコネクションプーリング ・ php/mySQL には、 persistent database connections ・ Node には、outbound HTTP/HTPS コールを keep-alive を設定する。Outbound が再利用されるように ・ .NET アプリケーションには、HttpClient をプールし再利用する。Keep-Aliveを設定する。System.Net.ServicePointManager.DefaultConnectionLimit を増やす。 　　そうでなければ、２つのアウトバウンドコンカレントリクエストに制限されてしまう。 　　 他の制限が App Service Sandbox に存在する。（必見） https://github.com/projectkudu/kudu/wiki/Azure-Web-App-sandbox PDFも使えるのが決まっている。
• #45: ScriptHost の実行は何から行われるか？ V1 : IIS (w3wp.exe) V2: dotnet.exe or node.exe with local IIS as a reverse proxy Funciton App の中で、何個の ScriptHost が実行されるか？ -> 1 つ。 CPU とメモリが、ScriptHost そしてそこの上で動いている Functions でシェアされる。 コンサンプションプランの場合の、スリープの振る舞いは？： ファンクションアップは、 20分でアイドルになる。そして、VMからアンロードされる。 もし、新しいリクエストがやってきたら、 Front End がData Role に問い合わせてどのVM が適切かを見極めてアサインし、ファンクションのランタイム (Script Host) をスタートする。実際のコールドスタートは、様々なケースがある。例えば、ホスティングプラン (App Service Plan, コンサンプション) , Function Runtime (V1, V2) 言語、読み込む必要のある言語にもよる。　(現在質問中） Front end は、どこにホストされているか？どの程度の Worker を担当するか？ フロントエンドは、Azure App Service のインターナルVMに存在している。普通は A2, A3 のVMでできている。実際の数とかサイズは場合による。 通常は、8 – 20 Worker : 1 FrontEnd 割合はどれぐらいビジー化によって決まる。　１つの Front end につき大抵は数百の Worker を担当する。ただ、数千もの Workerを担当する場合もある。　 コンサンプションプランの最初のVM の割り当て 基本的に１台のVMに割り当てられる。ただし、バーストモード以外。 コンサンプションプランでの、App Service Plan の共有はできない。 Scale Controller が使っているモニタリングツールは？ スケールコントローラーがカスタムトリガーをモニタリングしている。あるケースでは、ポーリングデータのデータキャッシュをみている。タイマーでは、クーロンのスケジュールをパースして、低k実行の１分前に Function App がプロビジョニングされるようにしています。 タイトルはあまり意味がない。 説明したいことが複数あるばあいは、スライドをわけるか視点誘導する 図はそのままでルーペを使って視点誘導をする
• #46: サーバーの上限は200
• #47: ScriptHost の実行は何から行われるか？ V1 : IIS (w3wp.exe) V2: dotnet.exe or node.exe with local IIS as a reverse proxy Funciton App の中で、何個の ScriptHost が実行されるか？ -> 1 つ。 CPU とメモリが、ScriptHost そしてそこの上で動いている Functions でシェアされる。 コンサンプションプランの場合の、スリープの振る舞いは？： ファンクションアップは、 20分でアイドルになる。そして、VMからアンロードされる。 もし、新しいリクエストがやってきたら、 Front End がData Role に問い合わせてどのVM が適切かを見極めてアサインし、ファンクションのランタイム (Script Host) をスタートする。実際のコールドスタートは、様々なケースがある。例えば、ホスティングプラン (App Service Plan, コンサンプション) , Function Runtime (V1, V2) 言語、読み込む必要のある言語にもよる。　(現在質問中） Front end は、どこにホストされているか？どの程度の Worker を担当するか？ フロントエンドは、Azure App Service のインターナルVMに存在している。普通は A2, A3 のVMでできている。実際の数とかサイズは場合による。 通常は、8 – 20 Worker : 1 FrontEnd 割合はどれぐらいビジー化によって決まる。　１つの Front end につき大抵は数百の Worker を担当する。ただ、数千もの Workerを担当する場合もある。　 コンサンプションプランの最初のVM の割り当て 基本的に１台のVMに割り当てられる。ただし、バーストモード以外。 コンサンプションプランでの、App Service Plan の共有はできない。 Scale Controller が使っているモニタリングツールは？ スケールコントローラーがカスタムトリガーをモニタリングしている。あるケースでは、ポーリングデータのデータキャッシュをみている。タイマーでは、クーロンのスケジュールをパースして、低k実行の１分前に Function App がプロビジョニングされるようにしています。 タイトルはあまり意味がない。 説明したいことが複数あるばあいは、スライドをわけるか視点誘導する 図はそのままでルーペを使って視点誘導をする
• #48: Http Trigger 系　のアルゴリズム 　・直近の５件をスケールの可否のサンプルにする 　・デルタは、0.1 ・20 RPS / worker だとスケールアウト 　・実行中のリクエストが上向きの場合スケールする Queue系のアルゴリズム 　・ Queue length > Worker数 * 1000 　・ Queue の数や、Queue時間が上昇傾向だとスケールアウト タイマー系、KeepAlive系 Worker 0 なら Worker 起動。１ならキープ。そうでなければ Remove する。 スケールアルゴリズムの種類 Queue, EventHub, Service Bus Queue, CosmosDB -> Make DesicisionFor Queue Http -> HttpActivationTask Pending Timers, -> Timers ActivationTasks -> Keep Alive 基本的にQueue 系と、Http系が存在する。 バーストモードについて質問している。
• #49: Http Trigger 系 “バーストモード” 20 RPS/worker もしくは、リクエスト/レイテンシが増加傾向 (10%+) だとスケールアウト リクエストがなくなったり、実行中のリクエストがワーカーの数より少なくなったらスケールイン Queue 系 Worker当たり、1000 以上 だとスケールアウト Queue の数や、Queue 時間が増加傾向だとスケールアウト Queue がなくなったり、Queue が減少傾向だとスケールイン 濃い色の白抜きにする
• #54: これはライブで、ブログを見せる https://www.azurefromthetrenches.com/azure-functions-vs-aws-lambda-scaling-face-off/#comment-178988 https://www.azurefromthetrenches.com/azure-functions-significant-improvements-in-http-trigger-scaling/
• #55: ３つの理由でパフォーマンスを改善した 1. Worker VM は、たくさんのHTTP トラフィックが一度にくると簡単にアップアップになっていた。我々はこれを、同時リクエストが来たら、複数のVMにバースト（炸裂）させるようにした。 2.昔は、新しい Worker を追加するのが遅かった 　 a. Scale Controller と Front End のフィードバックループが遅かった（10秒に１回のチェックで、３０秒に１回しかVMを足さなかった） b. コールドスタートは、スケールアウトを遅くしていた。なぜなら我々はトラフィックをルーティングするまでに、コールドスタートが終わるのをまっていた。 我々は、a を解決し、bを、Front End でスケールの決定をオンデマンドで実施するようにした。Scale Controller が定期的に決定するよりも。 3.Front End は、ラウンドロビンを使っていた。これは、ダイナミックにVMが足された場合よくなかった。今は、Weight / Concurrency ベースのアルゴリズム（chris作）に移行した。
• #56: C#, F# は同じプロセスで実行させる。 Node 等は、別プロセスで実行 (grpc) grpc: https://qiita.com/oohira/items/63b5ccb2bf1a913659d6 このような仕組みなので、 Output bindings は functions の実行後に実行される ただし、自分でカスタムの bindings を作ると、Functions 実行中に実行されるものも作ることが可能
• #63: Bindings https://github.com/TsuyoshiUshio/VSTSBindingsSample Trigger https://qiita.com/TsuyoshiUshio@github/items/4d74ea1a4e48139f7426