SlideShare a Scribd company logo
1 of 61
ワタシハ Azure Functions
チョットデキル
AD28
“チョットデキル”
画像は Cloud Watch (impress様より )
https://cloud.watch.impress.co.jp/img/clw/docs/649/658/html/linuxcon02-01.jpg.html
創った
https://twitter.com/chomado/status/867378770482577408
創った
https://twitter.com/uramanira/status/764997855186677760
金メダリスト
このセッションの案内文
チョットデキル
Serverless の重要性
しかし・・・
に完全お任せだよね・・・
サーバレスでも
制御したい!
クラウドの障害を
前提とした設計
内部構造を理解する
Azure Functions の
開発者になる
メッセージングサービスの
選択
クラウドが障害を
起こしたら?
再実行可能にする!
同期実行と障害とスケール
非同期実行と障害とスケール
お金にもやさしい設計!
障害に強いサーバーレスの設計
https://docs.microsoft.com/en-us/azure/azure-functions/functions-best-practices
Single Responsibility
Principal
冪等性
サーバレスで下記のことが必要になったら
Azure のメッセージング
SignalR
Storage Queue
Queue と Publish-Subscribe
Service Bus
https://docs.microsoft.com/en-us/azure/service-bus-messaging/service-bus-azure-and-service-bus-queues-compared-contrasted
Event Grid
https://docs.microsoft.com/en-us/azure/event-grid/compare-messaging-services
Event Hub / IoT Hub
https://blogs.msdn.microsoft.com/appserviceteam/2017/09/19/processing-100000-events-per-second-on-azure-functions/
SignalR Service
Functions 間通信の基本
何故か動いた!
突然動かなくなった
Azure Functions
内部アーキテクチャを理解する
Function App
作成の要求
要求を ARM
が転送
適切な Scale Unit を選んで
要求を転送
Function App
の割り当て
Scale Unit
App Service Plan の Functions 割り当て
Scale Unit は
Pre-Provision され
たプールを持つ
プールから Worker
が割り当てられる
Functions を
デプロイ
App Service Plan のアーキテクチャ
Azure Functions が
負荷に耐えられない!
Azure Functions Load Testing
Consumption Plan のアーキテクチャ
outboundに注意
Scale Contorller あるとき、ないとき
Consumption Plan のアーキテクチャ
outboundに注意
Scale に関する考慮事項 (Consumption)
Scale Controller が Worker の増減を決定
バーストモード (Worker 4 台まで)
Queue の数 (1000 queue/worker)
滞在時間の増加/減少傾向 (10%+)
Http 20 rps/worker もしくは
リクエスト/レイテンシの増加傾向 (10%+)ならスケールアウト
“host.json” で worker 毎のリクエスト制限
ログを Dashboard Storage Account と分ける
ハイスケールシナリオ時 1回の実行で複数アイテム処理
EventHub, Queue,
ServiceBus
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 を使う
ベストプラクティス
Application Insights を使う
非同期処理 (async/await)
HttpClient 等は static としてキャッシュする
host.json を設定する
VSTS リリースマネジメントを使う
Azure Functions Load Testing
Http Trigger の性能改善
https://www.azurefromthetrenches.com/azure-functions-significant-improvements-in-http-trigger-scaling/
どうやって改善したの?
解決策
解決策
解決策
解決策
Functions の実行イメージ (V2)
Trigger
C#, F#
Bindings(in)
Bindings(out)
Node 他
Bindings(in)
Bindings(out)
C#, F#
grpc
Azure Functions を自作する
あの機能ないし、
このバグどうしよう?
Azure Functions
の共同開発者になる
代表的なリポジトリ
総合窓口 実行基盤
HttpTrigger / Bindings
Queue / Service Bus 等
Trigger / Bindings
その他の
Trigger / Bindings
Portal UI CLI
リポジトリ
https://github.com/Azure/Azure-Functions
https://github.com/Azure/azure-functions-host
https://github.com/Azure/azure-webjobs-sdk/
https://github.com/Azure/azure-webjobs-sdk-extensions
https://github.com/Azure/azure-functions-host/wiki/Language-Extensibility
https://github.com/Azure/azure-functions-ux
https://github.com/Azure/azure-functions-core-tools
https://github.com/Azure/azure-functions-durable-extension
https://github.com/Azure/azure-functions-eventgrid-extension
https://github.com/Azure/azure-functions-iothub-extension
Custom Bindings
https://qiita.com/TsuyoshiUshio@github/items/345887a5fa5d59e7444a
Azure Functions
分析完了!
モブプログラミングで貢献
シグマコンサルティングさんが語ってくれ
たこと
マイクロソフトが実装してくれるのを
待って 気軽に本家のリポジトリに
貢献できる
Live Contribution
Serverless を制御して
チョットデキル人に!!
リソース
https://github.com/Azure/azure-
webjobs-sdk/wiki/Creating-custom-input-and-output-bindings
https://github.com/Azure/azure-webjobs-sdk-
extensions/wiki/Binding-Extensions-Overview
https://qiita.com/TsuyoshiUshio@github/items/345887a5fa5d59e7444a
https://qiita.com/TsuyoshiUshio@github/items/4d74ea1a4e48139f7426
© 2018 Microsoft Corporation. All rights reserved.
本情報の内容(添付文書、リンク先などを含む)は、作成日時点でのものであり、予告なく変更される場合があります。

More Related Content

What's hot

世界一わかりやすいClean Architecture
世界一わかりやすいClean Architecture世界一わかりやすいClean Architecture
世界一わかりやすいClean ArchitectureAtsushi Nakamura
 
Dockerからcontainerdへの移行
Dockerからcontainerdへの移行Dockerからcontainerdへの移行
Dockerからcontainerdへの移行Kohei Tokunaga
 
MongoDBが遅いときの切り分け方法
MongoDBが遅いときの切り分け方法MongoDBが遅いときの切り分け方法
MongoDBが遅いときの切り分け方法Tetsutaro Watanabe
 
AKS と ACI を組み合わせて使ってみた
AKS と ACI を組み合わせて使ってみたAKS と ACI を組み合わせて使ってみた
AKS と ACI を組み合わせて使ってみたHideaki Aoyagi
 
3分でわかるAzureでのService Principal
3分でわかるAzureでのService Principal3分でわかるAzureでのService Principal
3分でわかるAzureでのService PrincipalToru Makabe
 
Dockerからcontainerdへの移行
Dockerからcontainerdへの移行Dockerからcontainerdへの移行
Dockerからcontainerdへの移行Akihiro Suda
 
君はyarn.lockをコミットしているか?
君はyarn.lockをコミットしているか?君はyarn.lockをコミットしているか?
君はyarn.lockをコミットしているか?Teppei Sato
 
Kubernetes にこれから入るかもしれない注目機能!(2022年11月版) / TechFeed Experts Night #7 〜 コンテナ技術を語る
Kubernetes にこれから入るかもしれない注目機能!(2022年11月版) / TechFeed Experts Night #7 〜 コンテナ技術を語るKubernetes にこれから入るかもしれない注目機能!(2022年11月版) / TechFeed Experts Night #7 〜 コンテナ技術を語る
Kubernetes にこれから入るかもしれない注目機能!(2022年11月版) / TechFeed Experts Night #7 〜 コンテナ技術を語るPreferred Networks
 
Grafana LokiではじめるKubernetesロギングハンズオン(NTT Tech Conference #4 ハンズオン資料)
Grafana LokiではじめるKubernetesロギングハンズオン(NTT Tech Conference #4 ハンズオン資料)Grafana LokiではじめるKubernetesロギングハンズオン(NTT Tech Conference #4 ハンズオン資料)
Grafana LokiではじめるKubernetesロギングハンズオン(NTT Tech Conference #4 ハンズオン資料)NTT DATA Technology & Innovation
 
5分でわかるGoのポインタ
5分でわかるGoのポインタ5分でわかるGoのポインタ
5分でわかるGoのポインタY N
 
ドメイン駆動設計 ( DDD ) をやってみよう
ドメイン駆動設計 ( DDD ) をやってみようドメイン駆動設計 ( DDD ) をやってみよう
ドメイン駆動設計 ( DDD ) をやってみよう増田 亨
 
今こそ知りたいSpring Batch(Spring Fest 2020講演資料)
今こそ知りたいSpring Batch(Spring Fest 2020講演資料)今こそ知りたいSpring Batch(Spring Fest 2020講演資料)
今こそ知りたいSpring Batch(Spring Fest 2020講演資料)NTT DATA Technology & Innovation
 
【BS13】チーム開発がこんなにも快適に!コーディングもデバッグも GitHub 上で。 GitHub Codespaces で叶えられるシームレスな開発
【BS13】チーム開発がこんなにも快適に!コーディングもデバッグも GitHub 上で。 GitHub Codespaces で叶えられるシームレスな開発【BS13】チーム開発がこんなにも快適に!コーディングもデバッグも GitHub 上で。 GitHub Codespaces で叶えられるシームレスな開発
【BS13】チーム開発がこんなにも快適に!コーディングもデバッグも GitHub 上で。 GitHub Codespaces で叶えられるシームレスな開発日本マイクロソフト株式会社
 
ツール比較しながら語る O/RマッパーとDBマイグレーションの実際のところ
ツール比較しながら語る O/RマッパーとDBマイグレーションの実際のところツール比較しながら語る O/RマッパーとDBマイグレーションの実際のところ
ツール比較しながら語る O/RマッパーとDBマイグレーションの実際のところY Watanabe
 
今だからこそ知りたい Docker Compose/Swarm 入門
今だからこそ知りたい Docker Compose/Swarm 入門今だからこそ知りたい Docker Compose/Swarm 入門
今だからこそ知りたい Docker Compose/Swarm 入門Masahito Zembutsu
 
シリコンバレーの「何が」凄いのか
シリコンバレーの「何が」凄いのかシリコンバレーの「何が」凄いのか
シリコンバレーの「何が」凄いのかAtsushi Nakada
 
ユーザーストーリー駆動開発で行こう。
ユーザーストーリー駆動開発で行こう。ユーザーストーリー駆動開発で行こう。
ユーザーストーリー駆動開発で行こう。toshihiro ichitani
 
入門 Kubeflow ~Kubernetesで機械学習をはじめるために~ (NTT Tech Conference #4 講演資料)
入門 Kubeflow ~Kubernetesで機械学習をはじめるために~ (NTT Tech Conference #4 講演資料)入門 Kubeflow ~Kubernetesで機械学習をはじめるために~ (NTT Tech Conference #4 講演資料)
入門 Kubeflow ~Kubernetesで機械学習をはじめるために~ (NTT Tech Conference #4 講演資料)NTT DATA Technology & Innovation
 

What's hot (20)

世界一わかりやすいClean Architecture
世界一わかりやすいClean Architecture世界一わかりやすいClean Architecture
世界一わかりやすいClean Architecture
 
分散トレーシング技術について(Open tracingやjaeger)
分散トレーシング技術について(Open tracingやjaeger)分散トレーシング技術について(Open tracingやjaeger)
分散トレーシング技術について(Open tracingやjaeger)
 
Dockerからcontainerdへの移行
Dockerからcontainerdへの移行Dockerからcontainerdへの移行
Dockerからcontainerdへの移行
 
MongoDBが遅いときの切り分け方法
MongoDBが遅いときの切り分け方法MongoDBが遅いときの切り分け方法
MongoDBが遅いときの切り分け方法
 
AKS と ACI を組み合わせて使ってみた
AKS と ACI を組み合わせて使ってみたAKS と ACI を組み合わせて使ってみた
AKS と ACI を組み合わせて使ってみた
 
3分でわかるAzureでのService Principal
3分でわかるAzureでのService Principal3分でわかるAzureでのService Principal
3分でわかるAzureでのService Principal
 
Dockerからcontainerdへの移行
Dockerからcontainerdへの移行Dockerからcontainerdへの移行
Dockerからcontainerdへの移行
 
君はyarn.lockをコミットしているか?
君はyarn.lockをコミットしているか?君はyarn.lockをコミットしているか?
君はyarn.lockをコミットしているか?
 
Kubernetes にこれから入るかもしれない注目機能!(2022年11月版) / TechFeed Experts Night #7 〜 コンテナ技術を語る
Kubernetes にこれから入るかもしれない注目機能!(2022年11月版) / TechFeed Experts Night #7 〜 コンテナ技術を語るKubernetes にこれから入るかもしれない注目機能!(2022年11月版) / TechFeed Experts Night #7 〜 コンテナ技術を語る
Kubernetes にこれから入るかもしれない注目機能!(2022年11月版) / TechFeed Experts Night #7 〜 コンテナ技術を語る
 
Grafana LokiではじめるKubernetesロギングハンズオン(NTT Tech Conference #4 ハンズオン資料)
Grafana LokiではじめるKubernetesロギングハンズオン(NTT Tech Conference #4 ハンズオン資料)Grafana LokiではじめるKubernetesロギングハンズオン(NTT Tech Conference #4 ハンズオン資料)
Grafana LokiではじめるKubernetesロギングハンズオン(NTT Tech Conference #4 ハンズオン資料)
 
5分でわかるGoのポインタ
5分でわかるGoのポインタ5分でわかるGoのポインタ
5分でわかるGoのポインタ
 
【BS4】時は来たれり。今こそ .NET 6 へ移行する時。
【BS4】時は来たれり。今こそ .NET 6 へ移行する時。 【BS4】時は来たれり。今こそ .NET 6 へ移行する時。
【BS4】時は来たれり。今こそ .NET 6 へ移行する時。
 
ドメイン駆動設計 ( DDD ) をやってみよう
ドメイン駆動設計 ( DDD ) をやってみようドメイン駆動設計 ( DDD ) をやってみよう
ドメイン駆動設計 ( DDD ) をやってみよう
 
今こそ知りたいSpring Batch(Spring Fest 2020講演資料)
今こそ知りたいSpring Batch(Spring Fest 2020講演資料)今こそ知りたいSpring Batch(Spring Fest 2020講演資料)
今こそ知りたいSpring Batch(Spring Fest 2020講演資料)
 
【BS13】チーム開発がこんなにも快適に!コーディングもデバッグも GitHub 上で。 GitHub Codespaces で叶えられるシームレスな開発
【BS13】チーム開発がこんなにも快適に!コーディングもデバッグも GitHub 上で。 GitHub Codespaces で叶えられるシームレスな開発【BS13】チーム開発がこんなにも快適に!コーディングもデバッグも GitHub 上で。 GitHub Codespaces で叶えられるシームレスな開発
【BS13】チーム開発がこんなにも快適に!コーディングもデバッグも GitHub 上で。 GitHub Codespaces で叶えられるシームレスな開発
 
ツール比較しながら語る O/RマッパーとDBマイグレーションの実際のところ
ツール比較しながら語る O/RマッパーとDBマイグレーションの実際のところツール比較しながら語る O/RマッパーとDBマイグレーションの実際のところ
ツール比較しながら語る O/RマッパーとDBマイグレーションの実際のところ
 
今だからこそ知りたい Docker Compose/Swarm 入門
今だからこそ知りたい Docker Compose/Swarm 入門今だからこそ知りたい Docker Compose/Swarm 入門
今だからこそ知りたい Docker Compose/Swarm 入門
 
シリコンバレーの「何が」凄いのか
シリコンバレーの「何が」凄いのかシリコンバレーの「何が」凄いのか
シリコンバレーの「何が」凄いのか
 
ユーザーストーリー駆動開発で行こう。
ユーザーストーリー駆動開発で行こう。ユーザーストーリー駆動開発で行こう。
ユーザーストーリー駆動開発で行こう。
 
入門 Kubeflow ~Kubernetesで機械学習をはじめるために~ (NTT Tech Conference #4 講演資料)
入門 Kubeflow ~Kubernetesで機械学習をはじめるために~ (NTT Tech Conference #4 講演資料)入門 Kubeflow ~Kubernetesで機械学習をはじめるために~ (NTT Tech Conference #4 講演資料)
入門 Kubeflow ~Kubernetesで機械学習をはじめるために~ (NTT Tech Conference #4 講演資料)
 

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

帰ってきた インフラ野郎 Azureチーム ~Azure データセンターテクノロジー解体新書2018春~ - de:code2018
帰ってきた インフラ野郎 Azureチーム ~Azure データセンターテクノロジー解体新書2018春~ - de:code2018帰ってきた インフラ野郎 Azureチーム ~Azure データセンターテクノロジー解体新書2018春~ - de:code2018
帰ってきた インフラ野郎 Azureチーム ~Azure データセンターテクノロジー解体新書2018春~ - de:code2018Toru Makabe
 
Microsoft Antimalware for Azure による Azure 仮想マシンの簡易的なマルウェア対策
Microsoft Antimalware for Azure による Azure 仮想マシンの簡易的なマルウェア対策Microsoft Antimalware for Azure による Azure 仮想マシンの簡易的なマルウェア対策
Microsoft Antimalware for Azure による Azure 仮想マシンの簡易的なマルウェア対策wintechq
 
AWSへのWindows Server 2003の移行 そして今後インフラとどう向き合うべきか
AWSへのWindows Server 2003の移行 そして今後インフラとどう向き合うべきかAWSへのWindows Server 2003の移行 そして今後インフラとどう向き合うべきか
AWSへのWindows Server 2003の移行 そして今後インフラとどう向き合うべきか真吾 吉田
 
Tech Night Recap Sapporo - Ignite & .NET Conf -.pptx
Tech Night Recap Sapporo - Ignite & .NET Conf -.pptxTech Night Recap Sapporo - Ignite & .NET Conf -.pptx
Tech Night Recap Sapporo - Ignite & .NET Conf -.pptxYasuaki Matsuda
 
Azure vm の可用性を見直そう
Azure vm の可用性を見直そうAzure vm の可用性を見直そう
Azure vm の可用性を見直そうShuheiUda
 
Azure Functions&Logic Appではじめるサーバレスアプリケーション開発 - 入門編 -
Azure Functions&Logic Appではじめるサーバレスアプリケーション開発 - 入門編 -Azure Functions&Logic Appではじめるサーバレスアプリケーション開発 - 入門編 -
Azure Functions&Logic Appではじめるサーバレスアプリケーション開発 - 入門編 -Yoichi Kawasaki
 
20160217 hbstudy73 linux on Azure
20160217 hbstudy73 linux on Azure20160217 hbstudy73 linux on Azure
20160217 hbstudy73 linux on Azure雄哉 吉田
 
できる!サーバレスアーキテクチャ
できる!サーバレスアーキテクチャできる!サーバレスアーキテクチャ
できる!サーバレスアーキテクチャazuma satoshi
 
Azure と MT のフシギな関係
Azure と MT のフシギな関係Azure と MT のフシギな関係
Azure と MT のフシギな関係Six Apart KK
 
講演資料「Azure AI Update Ignite Fall 2021を振り返ろう!」
講演資料「Azure AI Update Ignite Fall 2021を振り返ろう!」講演資料「Azure AI Update Ignite Fall 2021を振り返ろう!」
講演資料「Azure AI Update Ignite Fall 2021を振り返ろう!」Kohei Ogawa
 
Azure IaaS update (2018年6月~7月 発表版)
Azure IaaS update (2018年6月~7月 発表版) Azure IaaS update (2018年6月~7月 発表版)
Azure IaaS update (2018年6月~7月 発表版) Takamasa Maejima
 
Windows Azure and PowerShell DSC
Windows Azure and PowerShell DSCWindows Azure and PowerShell DSC
Windows Azure and PowerShell DSCKazuki Takai
 
JAZUG #26 AKS backup with Velero
JAZUG #26 AKS backup with VeleroJAZUG #26 AKS backup with Velero
JAZUG #26 AKS backup with VeleroTetsuya Sodo
 
NoOpsへ舵を切れ
NoOpsへ舵を切れNoOpsへ舵を切れ
NoOpsへ舵を切れHiromasa Oka
 
半日でわかる コンテナー技術 (応用編)
半日でわかる コンテナー技術 (応用編)半日でわかる コンテナー技術 (応用編)
半日でわかる コンテナー技術 (応用編)Toru Makabe
 
Infra as Code in Azure
Infra as Code in AzureInfra as Code in Azure
Infra as Code in AzureIssei Hiraoka
 
kubernetes on Azure 最新情報
kubernetes on Azure 最新情報kubernetes on Azure 最新情報
kubernetes on Azure 最新情報Takayoshi Tanaka
 

Similar to ワタシハ Azure Functions チョットデキル (20)

帰ってきた インフラ野郎 Azureチーム ~Azure データセンターテクノロジー解体新書2018春~ - de:code2018
帰ってきた インフラ野郎 Azureチーム ~Azure データセンターテクノロジー解体新書2018春~ - de:code2018帰ってきた インフラ野郎 Azureチーム ~Azure データセンターテクノロジー解体新書2018春~ - de:code2018
帰ってきた インフラ野郎 Azureチーム ~Azure データセンターテクノロジー解体新書2018春~ - de:code2018
 
Non-coding! Azure
Non-coding! AzureNon-coding! Azure
Non-coding! Azure
 
Microsoft Antimalware for Azure による Azure 仮想マシンの簡易的なマルウェア対策
Microsoft Antimalware for Azure による Azure 仮想マシンの簡易的なマルウェア対策Microsoft Antimalware for Azure による Azure 仮想マシンの簡易的なマルウェア対策
Microsoft Antimalware for Azure による Azure 仮想マシンの簡易的なマルウェア対策
 
AWSへのWindows Server 2003の移行 そして今後インフラとどう向き合うべきか
AWSへのWindows Server 2003の移行 そして今後インフラとどう向き合うべきかAWSへのWindows Server 2003の移行 そして今後インフラとどう向き合うべきか
AWSへのWindows Server 2003の移行 そして今後インフラとどう向き合うべきか
 
Tech Night Recap Sapporo - Ignite & .NET Conf -.pptx
Tech Night Recap Sapporo - Ignite & .NET Conf -.pptxTech Night Recap Sapporo - Ignite & .NET Conf -.pptx
Tech Night Recap Sapporo - Ignite & .NET Conf -.pptx
 
Azure vm の可用性を見直そう
Azure vm の可用性を見直そうAzure vm の可用性を見直そう
Azure vm の可用性を見直そう
 
Azure Functions&Logic Appではじめるサーバレスアプリケーション開発 - 入門編 -
Azure Functions&Logic Appではじめるサーバレスアプリケーション開発 - 入門編 -Azure Functions&Logic Appではじめるサーバレスアプリケーション開発 - 入門編 -
Azure Functions&Logic Appではじめるサーバレスアプリケーション開発 - 入門編 -
 
Azureといえば
AzureといえばAzureといえば
Azureといえば
 
20160217 hbstudy73 linux on Azure
20160217 hbstudy73 linux on Azure20160217 hbstudy73 linux on Azure
20160217 hbstudy73 linux on Azure
 
できる!サーバレスアーキテクチャ
できる!サーバレスアーキテクチャできる!サーバレスアーキテクチャ
できる!サーバレスアーキテクチャ
 
Azure と MT のフシギな関係
Azure と MT のフシギな関係Azure と MT のフシギな関係
Azure と MT のフシギな関係
 
講演資料「Azure AI Update Ignite Fall 2021を振り返ろう!」
講演資料「Azure AI Update Ignite Fall 2021を振り返ろう!」講演資料「Azure AI Update Ignite Fall 2021を振り返ろう!」
講演資料「Azure AI Update Ignite Fall 2021を振り返ろう!」
 
TFSUG 20151126
TFSUG 20151126TFSUG 20151126
TFSUG 20151126
 
Azure IaaS update (2018年6月~7月 発表版)
Azure IaaS update (2018年6月~7月 発表版) Azure IaaS update (2018年6月~7月 発表版)
Azure IaaS update (2018年6月~7月 発表版)
 
Windows Azure and PowerShell DSC
Windows Azure and PowerShell DSCWindows Azure and PowerShell DSC
Windows Azure and PowerShell DSC
 
JAZUG #26 AKS backup with Velero
JAZUG #26 AKS backup with VeleroJAZUG #26 AKS backup with Velero
JAZUG #26 AKS backup with Velero
 
NoOpsへ舵を切れ
NoOpsへ舵を切れNoOpsへ舵を切れ
NoOpsへ舵を切れ
 
半日でわかる コンテナー技術 (応用編)
半日でわかる コンテナー技術 (応用編)半日でわかる コンテナー技術 (応用編)
半日でわかる コンテナー技術 (応用編)
 
Infra as Code in Azure
Infra as Code in AzureInfra as Code in Azure
Infra as Code in Azure
 
kubernetes on Azure 最新情報
kubernetes on Azure 最新情報kubernetes on Azure 最新情報
kubernetes on Azure 最新情報
 

More from Tsuyoshi Ushio

ログの書き方がチームの生産性を爆上げする話
ログの書き方がチームの生産性を爆上げする話ログの書き方がチームの生産性を爆上げする話
ログの書き方がチームの生産性を爆上げする話Tsuyoshi Ushio
 
アメリカの超巨大クラウドの 「中の人」に転生した ガチ三流プログラマが 米国システム開発の現実を リークする話
アメリカの超巨大クラウドの「中の人」に転生したガチ三流プログラマが米国システム開発の現実をリークする話アメリカの超巨大クラウドの「中の人」に転生したガチ三流プログラマが米国システム開発の現実をリークする話
アメリカの超巨大クラウドの 「中の人」に転生した ガチ三流プログラマが 米国システム開発の現実を リークする話Tsuyoshi Ushio
 
Serverless の自動回復と自動化のためのアーキテクチャ
Serverless の自動回復と自動化のためのアーキテクチャServerless の自動回復と自動化のためのアーキテクチャ
Serverless の自動回復と自動化のためのアーキテクチャTsuyoshi Ushio
 
"サーバーレス"を超越する。なぜ?から理解する Durable Functions
"サーバーレス"を超越する。なぜ?から理解する Durable Functions"サーバーレス"を超越する。なぜ?から理解する Durable Functions
"サーバーレス"を超越する。なぜ?から理解する Durable FunctionsTsuyoshi Ushio
 
三年後のエンジニアがもっているとお得な資質
三年後のエンジニアがもっているとお得な資質三年後のエンジニアがもっているとお得な資質
三年後のエンジニアがもっているとお得な資質Tsuyoshi Ushio
 
Visual Studio Team Services を使った Serverless のための継続的デリバリ
Visual Studio Team Services を使った Serverless のための継続的デリバリVisual Studio Team Services を使った Serverless のための継続的デリバリ
Visual Studio Team Services を使った Serverless のための継続的デリバリTsuyoshi Ushio
 
Container microservices
Container microservicesContainer microservices
Container microservicesTsuyoshi Ushio
 
Rakuten and Microsoft talk DevOps in Real World
Rakuten and Microsoft talk DevOps in Real WorldRakuten and Microsoft talk DevOps in Real World
Rakuten and Microsoft talk DevOps in Real WorldTsuyoshi Ushio
 
技術と度胸のミニワークショップ InfoQで英語学習
技術と度胸のミニワークショップ InfoQで英語学習技術と度胸のミニワークショップ InfoQで英語学習
技術と度胸のミニワークショップ InfoQで英語学習Tsuyoshi Ushio
 
A New Business Model of Custom Software Development For Agile Software Develo...
A New Business Model of Custom Software Development For Agile Software Develo...A New Business Model of Custom Software Development For Agile Software Develo...
A New Business Model of Custom Software Development For Agile Software Develo...Tsuyoshi Ushio
 
Build Less Patterns AgileRoots 2014
Build Less Patterns AgileRoots 2014Build Less Patterns AgileRoots 2014
Build Less Patterns AgileRoots 2014Tsuyoshi Ushio
 
ITエンジニアのためのゼロから始める英語勉強法
ITエンジニアのためのゼロから始める英語勉強法ITエンジニアのためのゼロから始める英語勉強法
ITエンジニアのためのゼロから始める英語勉強法Tsuyoshi Ushio
 
Agile Fundamental Skill Set
Agile Fundamental Skill SetAgile Fundamental Skill Set
Agile Fundamental Skill SetTsuyoshi Ushio
 
プレゼンビフォアアフタ
プレゼンビフォアアフタプレゼンビフォアアフタ
プレゼンビフォアアフタTsuyoshi Ushio
 
Ultimate agilisttokyo(japanese)
Ultimate agilisttokyo(japanese)Ultimate agilisttokyo(japanese)
Ultimate agilisttokyo(japanese)Tsuyoshi Ushio
 
How to be an agile programmer.
How to be an agile programmer.How to be an agile programmer.
How to be an agile programmer.Tsuyoshi Ushio
 
アジャイルツアー大阪
アジャイルツアー大阪アジャイルツアー大阪
アジャイルツアー大阪Tsuyoshi Ushio
 

More from Tsuyoshi Ushio (20)

ログの書き方がチームの生産性を爆上げする話
ログの書き方がチームの生産性を爆上げする話ログの書き方がチームの生産性を爆上げする話
ログの書き方がチームの生産性を爆上げする話
 
アメリカの超巨大クラウドの 「中の人」に転生した ガチ三流プログラマが 米国システム開発の現実を リークする話
アメリカの超巨大クラウドの「中の人」に転生したガチ三流プログラマが米国システム開発の現実をリークする話アメリカの超巨大クラウドの「中の人」に転生したガチ三流プログラマが米国システム開発の現実をリークする話
アメリカの超巨大クラウドの 「中の人」に転生した ガチ三流プログラマが 米国システム開発の現実を リークする話
 
Serverless の自動回復と自動化のためのアーキテクチャ
Serverless の自動回復と自動化のためのアーキテクチャServerless の自動回復と自動化のためのアーキテクチャ
Serverless の自動回復と自動化のためのアーキテクチャ
 
"サーバーレス"を超越する。なぜ?から理解する Durable Functions
"サーバーレス"を超越する。なぜ?から理解する Durable Functions"サーバーレス"を超越する。なぜ?から理解する Durable Functions
"サーバーレス"を超越する。なぜ?から理解する Durable Functions
 
三年後のエンジニアがもっているとお得な資質
三年後のエンジニアがもっているとお得な資質三年後のエンジニアがもっているとお得な資質
三年後のエンジニアがもっているとお得な資質
 
Visual Studio Team Services を使った Serverless のための継続的デリバリ
Visual Studio Team Services を使った Serverless のための継続的デリバリVisual Studio Team Services を使った Serverless のための継続的デリバリ
Visual Studio Team Services を使った Serverless のための継続的デリバリ
 
Agile overview
Agile overviewAgile overview
Agile overview
 
Container microservices
Container microservicesContainer microservices
Container microservices
 
Rakuten and Microsoft talk DevOps in Real World
Rakuten and Microsoft talk DevOps in Real WorldRakuten and Microsoft talk DevOps in Real World
Rakuten and Microsoft talk DevOps in Real World
 
技術と度胸のミニワークショップ InfoQで英語学習
技術と度胸のミニワークショップ InfoQで英語学習技術と度胸のミニワークショップ InfoQで英語学習
技術と度胸のミニワークショップ InfoQで英語学習
 
英語のリズム
英語のリズム英語のリズム
英語のリズム
 
A New Business Model of Custom Software Development For Agile Software Develo...
A New Business Model of Custom Software Development For Agile Software Develo...A New Business Model of Custom Software Development For Agile Software Develo...
A New Business Model of Custom Software Development For Agile Software Develo...
 
Build Less Patterns AgileRoots 2014
Build Less Patterns AgileRoots 2014Build Less Patterns AgileRoots 2014
Build Less Patterns AgileRoots 2014
 
ITエンジニアのためのゼロから始める英語勉強法
ITエンジニアのためのゼロから始める英語勉強法ITエンジニアのためのゼロから始める英語勉強法
ITエンジニアのためのゼロから始める英語勉強法
 
Agile Fundamental Skill Set
Agile Fundamental Skill SetAgile Fundamental Skill Set
Agile Fundamental Skill Set
 
プレゼンビフォアアフタ
プレゼンビフォアアフタプレゼンビフォアアフタ
プレゼンビフォアアフタ
 
Ultimate agilisttokyo(japanese)
Ultimate agilisttokyo(japanese)Ultimate agilisttokyo(japanese)
Ultimate agilisttokyo(japanese)
 
How to be an agile programmer.
How to be an agile programmer.How to be an agile programmer.
How to be an agile programmer.
 
Ultimate agilisttokyo
Ultimate agilisttokyoUltimate agilisttokyo
Ultimate agilisttokyo
 
アジャイルツアー大阪
アジャイルツアー大阪アジャイルツアー大阪
アジャイルツアー大阪
 

Recently uploaded

論文紹介:Selective Structured State-Spaces for Long-Form Video Understanding
論文紹介:Selective Structured State-Spaces for Long-Form Video Understanding論文紹介:Selective Structured State-Spaces for Long-Form Video Understanding
論文紹介:Selective Structured State-Spaces for Long-Form Video UnderstandingToru Tamaki
 
Amazon SES を勉強してみる その32024/04/26の勉強会で発表されたものです。
Amazon SES を勉強してみる その32024/04/26の勉強会で発表されたものです。Amazon SES を勉強してみる その32024/04/26の勉強会で発表されたものです。
Amazon SES を勉強してみる その32024/04/26の勉強会で発表されたものです。iPride Co., Ltd.
 
Amazon SES を勉強してみる その22024/04/26の勉強会で発表されたものです。
Amazon SES を勉強してみる その22024/04/26の勉強会で発表されたものです。Amazon SES を勉強してみる その22024/04/26の勉強会で発表されたものです。
Amazon SES を勉強してみる その22024/04/26の勉強会で発表されたものです。iPride Co., Ltd.
 
LoRaWANスマート距離検出センサー DS20L カタログ LiDARデバイス
LoRaWANスマート距離検出センサー  DS20L  カタログ  LiDARデバイスLoRaWANスマート距離検出センサー  DS20L  カタログ  LiDARデバイス
LoRaWANスマート距離検出センサー DS20L カタログ LiDARデバイスCRI Japan, Inc.
 
LoRaWAN スマート距離検出デバイスDS20L日本語マニュアル
LoRaWAN スマート距離検出デバイスDS20L日本語マニュアルLoRaWAN スマート距離検出デバイスDS20L日本語マニュアル
LoRaWAN スマート距離検出デバイスDS20L日本語マニュアルCRI Japan, Inc.
 
Utilizing Ballerina for Cloud Native Integrations
Utilizing Ballerina for Cloud Native IntegrationsUtilizing Ballerina for Cloud Native Integrations
Utilizing Ballerina for Cloud Native IntegrationsWSO2
 
論文紹介:Video-GroundingDINO: Towards Open-Vocabulary Spatio-Temporal Video Groun...
論文紹介:Video-GroundingDINO: Towards Open-Vocabulary Spatio-Temporal Video Groun...論文紹介:Video-GroundingDINO: Towards Open-Vocabulary Spatio-Temporal Video Groun...
論文紹介:Video-GroundingDINO: Towards Open-Vocabulary Spatio-Temporal Video Groun...Toru Tamaki
 
新人研修 後半 2024/04/26の勉強会で発表されたものです。
新人研修 後半        2024/04/26の勉強会で発表されたものです。新人研修 後半        2024/04/26の勉強会で発表されたものです。
新人研修 後半 2024/04/26の勉強会で発表されたものです。iPride Co., Ltd.
 
論文紹介: The Surprising Effectiveness of PPO in Cooperative Multi-Agent Games
論文紹介: The Surprising Effectiveness of PPO in Cooperative Multi-Agent Games論文紹介: The Surprising Effectiveness of PPO in Cooperative Multi-Agent Games
論文紹介: The Surprising Effectiveness of PPO in Cooperative Multi-Agent Gamesatsushi061452
 
知識ゼロの営業マンでもできた!超速で初心者を脱する、悪魔的学習ステップ3選.pptx
知識ゼロの営業マンでもできた!超速で初心者を脱する、悪魔的学習ステップ3選.pptx知識ゼロの営業マンでもできた!超速で初心者を脱する、悪魔的学習ステップ3選.pptx
知識ゼロの営業マンでもできた!超速で初心者を脱する、悪魔的学習ステップ3選.pptxsn679259
 

Recently uploaded (10)

論文紹介:Selective Structured State-Spaces for Long-Form Video Understanding
論文紹介:Selective Structured State-Spaces for Long-Form Video Understanding論文紹介:Selective Structured State-Spaces for Long-Form Video Understanding
論文紹介:Selective Structured State-Spaces for Long-Form Video Understanding
 
Amazon SES を勉強してみる その32024/04/26の勉強会で発表されたものです。
Amazon SES を勉強してみる その32024/04/26の勉強会で発表されたものです。Amazon SES を勉強してみる その32024/04/26の勉強会で発表されたものです。
Amazon SES を勉強してみる その32024/04/26の勉強会で発表されたものです。
 
Amazon SES を勉強してみる その22024/04/26の勉強会で発表されたものです。
Amazon SES を勉強してみる その22024/04/26の勉強会で発表されたものです。Amazon SES を勉強してみる その22024/04/26の勉強会で発表されたものです。
Amazon SES を勉強してみる その22024/04/26の勉強会で発表されたものです。
 
LoRaWANスマート距離検出センサー DS20L カタログ LiDARデバイス
LoRaWANスマート距離検出センサー  DS20L  カタログ  LiDARデバイスLoRaWANスマート距離検出センサー  DS20L  カタログ  LiDARデバイス
LoRaWANスマート距離検出センサー DS20L カタログ LiDARデバイス
 
LoRaWAN スマート距離検出デバイスDS20L日本語マニュアル
LoRaWAN スマート距離検出デバイスDS20L日本語マニュアルLoRaWAN スマート距離検出デバイスDS20L日本語マニュアル
LoRaWAN スマート距離検出デバイスDS20L日本語マニュアル
 
Utilizing Ballerina for Cloud Native Integrations
Utilizing Ballerina for Cloud Native IntegrationsUtilizing Ballerina for Cloud Native Integrations
Utilizing Ballerina for Cloud Native Integrations
 
論文紹介:Video-GroundingDINO: Towards Open-Vocabulary Spatio-Temporal Video Groun...
論文紹介:Video-GroundingDINO: Towards Open-Vocabulary Spatio-Temporal Video Groun...論文紹介:Video-GroundingDINO: Towards Open-Vocabulary Spatio-Temporal Video Groun...
論文紹介:Video-GroundingDINO: Towards Open-Vocabulary Spatio-Temporal Video Groun...
 
新人研修 後半 2024/04/26の勉強会で発表されたものです。
新人研修 後半        2024/04/26の勉強会で発表されたものです。新人研修 後半        2024/04/26の勉強会で発表されたものです。
新人研修 後半 2024/04/26の勉強会で発表されたものです。
 
論文紹介: The Surprising Effectiveness of PPO in Cooperative Multi-Agent Games
論文紹介: The Surprising Effectiveness of PPO in Cooperative Multi-Agent Games論文紹介: The Surprising Effectiveness of PPO in Cooperative Multi-Agent Games
論文紹介: The Surprising Effectiveness of PPO in Cooperative Multi-Agent Games
 
知識ゼロの営業マンでもできた!超速で初心者を脱する、悪魔的学習ステップ3選.pptx
知識ゼロの営業マンでもできた!超速で初心者を脱する、悪魔的学習ステップ3選.pptx知識ゼロの営業マンでもできた!超速で初心者を脱する、悪魔的学習ステップ3選.pptx
知識ゼロの営業マンでもできた!超速で初心者を脱する、悪魔的学習ステップ3選.pptx
 

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

Editor's Notes

  1. Azure Functions をコントロールするために必要なこと ・ メッセージングサービスの使い分け ・ 内部の仕組みを理解すること  ・ 無ければ作ってしまう
  2. 障害児の戻りの矢印はなくす
  3. サーバーレスの冪等性の考え方 https://medium.com/@tsuyoshiushio/serverless-idempotency-with-azure-functions-23ed5da9d428 何故、上記のことが必要になってくるのか? ・大きなコードはタイムアウトしてしまう(Consumption plan の functions は 10 分が最大) ・ステートレスで冪等性 (クラウドは、いつ落ちるかわからない。それを前提にした設計が良い。つまりリトライを可能にする、ステートレスは並列実行、スケールしやすくなる) ・失敗を前提(問題が発生することを前提としたコードを書くことで、) ・非同期によって、スケール、突発的な需要変動に対応できる(リソースレベリングのパターン) -> サーバーレスの魅力:サーバーのインフラのおもりをすることなく、コードだけに集中して、スケールし、
  4. Queue: 非同期の信頼あるメッセージングのため。速度は速くない(アプリを障害に強くスケールするようにする) Publish-Subscribe: 同報通信もしくは、プッシュ型の早いメッセージング(ローレイテンシー)
  5. エンタープライズ向け非同期メッセージ送信 Queue及びPublish – Subscribe メッセージサイズ 256K まで 順番保証あり ユースケース: 金融機関システムのメッセージング
  6. https://medium.com/@jeffhollan/in-order-event-processing-with-azure-functions-bb661eb55428
  7. 視線誘導上、 SignalR のロゴは最後に出す
  8. ディシジョンフローにする。(写真参照)
  9. 言葉を読んでみる。 意味の塊で文章を作る。息継ぎのところで改行をする
  10. Function App 作成の要求 ARM がリクエストを Geo-Master に送信 Geo-Master が適切な Scale Unit を選んでリクエストを転送 Scale Unit が Function App を割り当てる
  11. Function App 作成の要求 ARM がリクエストを Geo-Master に送信 Geo-Master が適切な Scale Unit を選んでリクエストを転送 Scale Unit が Function App を割り当てる
  12. サポートサーバの用途は、冗長性やスケールのためのインスタンスになっている。
  13. Fig 1. 先にプロビジョンされたプールが存在する Fig 2. App Service Plan で、2つのサーバーを割り当てる Fig 3. 2 つのワーカーを追加する。ワーカーは既にプレプロビジョンされて、ウオームアップされている。    あとはアプリをWorker にデプロイするのみ。デプロイできたら、ワーカーはローテーションに入り、Front End が    トラフィックをアロケートする。このプロセスは数秒かかる。 Fig 4. 複数のApp Service Plan を示している。これは複数の顧客が含まれている
  14. ポイント: 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 よりこちらのほうがずっと高速である。
  15. 複数の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 アプリケーション は1つの App Service Plan にわりあてて、1つのコンピュートリソースを確保する ・ 5 の mid-to-low volume のアプリケーション を 2個目の App Service Plan それは、1つのコンピュートリソースを確保する ・負荷の高い 5つのアプリケーションは、それぞれ別の App Service Plan にわりあてる。App Service Plan をスケール In/Out すると  CPU / Memory の利用状況の改善になる。  こうすると、効率的にリソースを割り当てて、別々にスケールアウトできるようになる。 他の方法としては、Per-App スケールという方法がある。先ほどと同じの50の Function App の例で考える。 一つの App Service Plan を作る。 ・ 40 の low-volume の Function App は、 最大 1 つのサーバーで動くように制限する ・5つの mid-to-low は、最大2つのサーバーに ・ 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 が5つの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 を増やす。   そうでなければ、2つのアウトバウンドコンカレントリクエストに制限されてしまう。    他の制限が App Service Sandbox に存在する。(必見) https://github.com/projectkudu/kudu/wiki/Azure-Web-App-sandbox PDFも使えるのが決まっている。
  16. 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 割合はどれぐらいビジー化によって決まる。 1つの Front end につき大抵は数百の Worker を担当する。ただ、数千もの Workerを担当する場合もある。  コンサンプションプランの最初のVM の割り当て 基本的に1台のVMに割り当てられる。ただし、バーストモード以外。 コンサンプションプランでの、App Service Plan の共有はできない。 Scale Controller が使っているモニタリングツールは? スケールコントローラーがカスタムトリガーをモニタリングしている。あるケースでは、ポーリングデータのデータキャッシュをみている。タイマーでは、クーロンのスケジュールをパースして、低k実行の1分前に Function App がプロビジョニングされるようにしています。 タイトルはあまり意味がない。 説明したいことが複数あるばあいは、スライドをわけるか視点誘導する 図はそのままでルーペを使って視点誘導をする
  17. サーバーの上限は200
  18. 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 割合はどれぐらいビジー化によって決まる。 1つの Front end につき大抵は数百の Worker を担当する。ただ、数千もの Workerを担当する場合もある。  コンサンプションプランの最初のVM の割り当て 基本的に1台のVMに割り当てられる。ただし、バーストモード以外。 コンサンプションプランでの、App Service Plan の共有はできない。 Scale Controller が使っているモニタリングツールは? スケールコントローラーがカスタムトリガーをモニタリングしている。あるケースでは、ポーリングデータのデータキャッシュをみている。タイマーでは、クーロンのスケジュールをパースして、低k実行の1分前に Function App がプロビジョニングされるようにしています。 タイトルはあまり意味がない。 説明したいことが複数あるばあいは、スライドをわけるか視点誘導する 図はそのままでルーペを使って視点誘導をする
  19. Http Trigger 系 のアルゴリズム  ・直近の5件をスケールの可否のサンプルにする  ・デルタは、0.1 ・20 RPS / worker だとスケールアウト  ・実行中のリクエストが上向きの場合スケールする Queue系のアルゴリズム  ・ Queue length > Worker数 * 1000  ・ Queue の数や、Queue時間が上昇傾向だとスケールアウト タイマー系、KeepAlive系 Worker 0 なら Worker 起動。1ならキープ。そうでなければ Remove する。 スケールアルゴリズムの種類 Queue, EventHub, Service Bus Queue, CosmosDB -> Make DesicisionFor Queue Http -> HttpActivationTask Pending Timers, -> Timers ActivationTasks -> Keep Alive 基本的にQueue 系と、Http系が存在する。 バーストモードについて質問している。
  20. Http Trigger 系 “バーストモード” 20 RPS/worker もしくは、リクエスト/レイテンシが増加傾向 (10%+) だとスケールアウト リクエストがなくなったり、実行中のリクエストがワーカーの数より少なくなったらスケールイン Queue 系 Worker当たり、1000 以上 だとスケールアウト Queue の数や、Queue 時間が増加傾向だとスケールアウト Queue がなくなったり、Queue が減少傾向だとスケールイン 濃い色の白抜きにする
  21. これはライブで、ブログを見せる 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/
  22. 3つの理由でパフォーマンスを改善した 1. Worker VM は、たくさんのHTTP トラフィックが一度にくると簡単にアップアップになっていた。我々はこれを、同時リクエストが来たら、複数のVMにバースト(炸裂)させるようにした。 2.昔は、新しい Worker を追加するのが遅かった   a. Scale Controller と Front End のフィードバックループが遅かった(10秒に1回のチェックで、30秒に1回しかVMを足さなかった) b. コールドスタートは、スケールアウトを遅くしていた。なぜなら我々はトラフィックをルーティングするまでに、コールドスタートが終わるのをまっていた。 我々は、a を解決し、bを、Front End でスケールの決定をオンデマンドで実施するようにした。Scale Controller が定期的に決定するよりも。 3.Front End は、ラウンドロビンを使っていた。これは、ダイナミックにVMが足された場合よくなかった。今は、Weight / Concurrency ベースのアルゴリズム(chris作)に移行した。
  23. C#, F# は同じプロセスで実行させる。 Node 等は、別プロセスで実行 (grpc) grpc: https://qiita.com/oohira/items/63b5ccb2bf1a913659d6 このような仕組みなので、 Output bindings は functions の実行後に実行される ただし、自分でカスタムの bindings を作ると、Functions 実行中に実行されるものも作ることが可能
  24. Bindings https://github.com/TsuyoshiUshio/VSTSBindingsSample Trigger https://qiita.com/TsuyoshiUshio@github/items/4d74ea1a4e48139f7426