ワタシハ Azure Functions チョットデキル
•Als PPTX, PDF herunterladen•
12 gefällt mir•12,739 views
de:code 2018 の 上記講演のスライドです。Azure Functions の下記の内容に関してお話ししました。資料が欲しいという要望をいただき先に公開しています。詳細の説明などは動画の後悔をお待ちください。 ・非同期メッセージング ・メッセージングサービスの選択 ・Function App / Azure Functions の内部構造 ・カスタムバインディング ・コントリビューション
Empfohlen
Weitere ähnliche Inhalte
Was ist angesagt?
Was ist angesagt? (20)
Ähnlich wie ワタシハ Azure Functions チョットデキル
Ähnlich wie ワタシハ Azure Functions チョットデキル (20)
Mehr von Tsuyoshi Ushio
Mehr von Tsuyoshi Ushio (20)
Kürzlich hochgeladen
Kürzlich hochgeladen (8)
ワタシハ Azure Functions チョットデキル
- 2. “チョットデキル”
- 3. 画像は Cloud Watch (impress様より ) https://cloud.watch.impress.co.jp/img/clw/docs/649/658/html/linuxcon02-01.jpg.html 創った
- 6. このセッションの案内文
- 7. チョットデキル
- 10. サーバレスでも 制御したい！
- 11. クラウドの障害を 前提とした設計
- 12. 内部構造を理解する
- 14. メッセージングサービスの 選択
- 15. クラウドが障害を 起こしたら？
- 16. 再実行可能にする！
- 17. 同期実行と障害とスケール
- 18. 非同期実行と障害とスケール
- 19. お金にもやさしい設計！
- 23. Storage Queue
- 27. Event Hub / IoT Hub https://blogs.msdn.microsoft.com/appserviceteam/2017/09/19/processing-100000-events-per-second-on-azure-functions/
- 28. SignalR Service
- 29. Functions 間通信の基本
- 32. Function App 作成の要求 要求を ARM が転送 適切な Scale Unit を選んで 要求を転送 Function App の割り当て
- 33. Scale Unit
- 34. App Service Plan の Functions 割り当て Scale Unit は Pre-Provision され たプールを持つ プールから Worker が割り当てられる Functions を デプロイ
- 35. App Service Plan のアーキテクチャ
- 37. Azure Functions Load Testing
- 41. Scale に関する考慮事項 (Consumption) Scale Controller が Worker の増減を決定 バーストモード (Worker 4 台まで) Queue の数 (1000 queue/worker) 滞在時間の増加/減少傾向 (10%+) Http 20 rps/worker もしくは リクエスト/レイテンシの増加傾向 (10%+)ならスケールアウト “host.json” で worker 毎のリクエスト制限 ログを Dashboard Storage Account と分ける ハイスケールシナリオ時 １回の実行で複数アイテム処理 EventHub, Queue, ServiceBus
- 43. Cold Start Run-From-Zip https://github.com/Azure/app-service-announcements/issues/84 Run-From-Zip デプロイメントを使う Node の場合、 funcpack を使う C# はスクリプトよりクラスライブラリ 起こすために定期的に ping する App Service Plan を使う 現状では、 V1 を使う
- 44. ベストプラクティス Application Insights を使う 非同期処理 (async/await) HttpClient 等は static としてキャッシュする host.json を設定する VSTS リリースマネジメントを使う
- 45. Azure Functions Load Testing
- 47. 解決策 解決策 解決策 解決策
- 48. Functions の実行イメージ (V2) Trigger C#, F# Bindings(in) Bindings(out) Node 他 Bindings(in) Bindings(out) C#, F# grpc
- 52. 代表的なリポジトリ 総合窓口 実行基盤 HttpTrigger / Bindings Queue / Service Bus 等 Trigger / Bindings その他の Trigger / Bindings Portal UI CLI
- 56. モブプログラミングで貢献
- 61. © 2018 Microsoft Corporation. All rights reserved. 本情報の内容（添付文書、リンク先などを含む）は、作成日時点でのものであり、予告なく変更される場合があります。
Hinweis der Redaktion
- Azure Functions をコントロールするために必要なこと ・ メッセージングサービスの使い分け ・ 内部の仕組みを理解すること ・ 無ければ作ってしまう
- 障害児の戻りの矢印はなくす
- サーバーレスの冪等性の考え方 https://medium.com/@tsuyoshiushio/serverless-idempotency-with-azure-functions-23ed5da9d428 何故、上記のことが必要になってくるのか？ ・大きなコードはタイムアウトしてしまう（Consumption plan の functions は 10 分が最大） ・ステートレスで冪等性 （クラウドは、いつ落ちるかわからない。それを前提にした設計が良い。つまりリトライを可能にする、ステートレスは並列実行、スケールしやすくなる） ・失敗を前提（問題が発生することを前提としたコードを書くことで、） ・非同期によって、スケール、突発的な需要変動に対応できる（リソースレベリングのパターン） -> サーバーレスの魅力：サーバーのインフラのおもりをすることなく、コードだけに集中して、スケールし、
- Queue: 非同期の信頼あるメッセージングのため。速度は速くない（アプリを障害に強くスケールするようにする） Publish-Subscribe: 同報通信もしくは、プッシュ型の早いメッセージング（ローレイテンシー）
- エンタープライズ向け非同期メッセージ送信 Queue及びPublish – Subscribe メッセージサイズ 256K まで 順番保証あり ユースケース： 金融機関システムのメッセージング
- https://medium.com/@jeffhollan/in-order-event-processing-with-azure-functions-bb661eb55428
- 視線誘導上、 SignalR のロゴは最後に出す
- ディシジョンフローにする。（写真参照）
- 言葉を読んでみる。 意味の塊で文章を作る。息継ぎのところで改行をする
- Function App 作成の要求 ARM がリクエストを Geo-Master に送信 Geo-Master が適切な Scale Unit を選んでリクエストを転送 Scale Unit が Function App を割り当てる
- Function App 作成の要求 ARM がリクエストを Geo-Master に送信 Geo-Master が適切な Scale Unit を選んでリクエストを転送 Scale Unit が Function App を割り当てる
- サポートサーバの用途は、冗長性やスケールのためのインスタンスになっている。
- Fig 1. 先にプロビジョンされたプールが存在する Fig 2. App Service Plan で、２つのサーバーを割り当てる Fig 3. 2 つのワーカーを追加する。ワーカーは既にプレプロビジョンされて、ウオームアップされている。 あとはアプリをWorker にデプロイするのみ。デプロイできたら、ワーカーはローテーションに入り、Front End が トラフィックをアロケートする。このプロセスは数秒かかる。 Fig 4. 複数のApp Service Plan を示している。これは複数の顧客が含まれている
- ポイント: 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 よりこちらのほうがずっと高速である。
- 複数の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も使えるのが決まっている。
- 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 がプロビジョニングされるようにしています。 タイトルはあまり意味がない。 説明したいことが複数あるばあいは、スライドをわけるか視点誘導する 図はそのままでルーペを使って視点誘導をする
- サーバーの上限は200
- 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 がプロビジョニングされるようにしています。 タイトルはあまり意味がない。 説明したいことが複数あるばあいは、スライドをわけるか視点誘導する 図はそのままでルーペを使って視点誘導をする
- 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系が存在する。 バーストモードについて質問している。
- Http Trigger 系 “バーストモード” 20 RPS/worker もしくは、リクエスト/レイテンシが増加傾向 (10%+) だとスケールアウト リクエストがなくなったり、実行中のリクエストがワーカーの数より少なくなったらスケールイン Queue 系 Worker当たり、1000 以上 だとスケールアウト Queue の数や、Queue 時間が増加傾向だとスケールアウト Queue がなくなったり、Queue が減少傾向だとスケールイン 濃い色の白抜きにする
- これはライブで、ブログを見せる 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/
- ３つの理由でパフォーマンスを改善した 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作）に移行した。
- C#, F# は同じプロセスで実行させる。 Node 等は、別プロセスで実行 (grpc) grpc: https://qiita.com/oohira/items/63b5ccb2bf1a913659d6 このような仕組みなので、 Output bindings は functions の実行後に実行される ただし、自分でカスタムの bindings を作ると、Functions 実行中に実行されるものも作ることが可能
- Bindings https://github.com/TsuyoshiUshio/VSTSBindingsSample Trigger https://qiita.com/TsuyoshiUshio@github/items/4d74ea1a4e48139f7426