Upload
-
View
226
Download
0
Embed Size (px)
Citation preview
サーバレスの進化は止まらない
Azure Durable Functions
2017年11月25日 .NET ラボ登壇資料
自己紹介
・名前 : 木下 裕之
・HN:kingkino
・Twitter:@kingkinoko
・FaceBook:kino.king.37
・Azure暦:7年
・MCSE : Cloud Platform and Infrastructure 2017
・Microsoft MVP for Microsoft Azure
・Azureもくもく会主催
注意事項
※この資料は2017年11月25日時点での情報を元に作成しています
※更新が早いのですぐに古い情報になる可能性がありますが予めご了承ください
本日のゴール
1. Serverlessを知ってもらう
2. Azure Functionで出来ることを理解してもらう
3. Azure Durable Functionsを利用することでサーバレスの活用の幅が広がるのを感じてもらう
サーバレスを知り、Azure Functionsを知ってもらい、DurableFunctionsを学んでもらうのが目的です。
アジェンダ
1:サーバレスアーキテクチャについて
ServerlessとFaasの説明、メリットについて
2:Azure Functionsについて
Azure Fucntionsの概要、トリガーや料金プランについて
3:Azure Durable Functionsについて
Azure Durable Functionsの各パターンの概要説明
4:デモ
Azure Durable Functionsの環境構築と実行(Azure編)
5:まとめ
サーバレスアーキテクチャについて
サーバレスアーキテクチャについて
先に行っておくとServerlessとは
「サーバを管理する必要がない仕組み」ということでサーバがないという意味ではありません
Serverlessには2つの意味あいがあります
・Backend as a Service(BaaS)
SPAやモバイルアプリケーションから利用するクラウド上で稼働しているバックエンドサービス
・Function as a Service(FaaS)
イベント駆動で実行されるサービス、昨今流行ってるサーバレスはこちらです
※サーバレスアーキテクチャーを詳しく知りたい方はマーティン・ファウラー氏のブログを参照してください。
https://martinfowler.com/articles/serverless.html
サーバレスアーキテクチャについて
FaaSはPaaSに似ていますが違いがあります
PaaS:リクエストごとにアプリケーション全体を起動・終了させる「リクエストリプライ方式」
FaaS:必要なサービス(関数)毎に起動・終了させる「イベントドリンブン方式」
大きな差としてはスケーリングです。PaaSの場合はスケーリングについて意識して設定しないとい
けませんがFaaSの場合は自動でスケーリングするのでコスト面で効率的です。
FaaSを利用するメリット
・イベントドリブン方式でコードを書いて連携させるだけで一連の業務処理を実行できる
・実行に必要なサーバはサービスが自動で割当てを行い必要に応じてスケールしてくれる
・使った分のサーバ使用料が課金されるためコスト削減が期待できる
Azure Functionについて
Azure Functionとは
言わずと知れたMicrosoftがAzureで提供するFaaSサービスです。
Code Events + data Azure Fucntions
特徴としては下記が挙げられます• インフラの管理コストを削減できる• アプリケーションサーバーとしては自由度が低いが、BaaSよりかは自由度が高いコンピューティングが可能• 常駐型と比較するとアプリケーションのプロセス起動によるオーバーヘッドが大きくなり、速度が遅くなる可
能性がある• Azure WebJobsのサーバレスな進化系
Azure Functionのアーキテクチャ
App Service
Azure Storage
Web Apps / Web Job
Azure
Porta
l/Azure
Functio
ns P
orta
l
Input Bindings
Output Bindings
Trig
ger
Functions ランタイムWebJobs Core SDK Functions
Azure Functionのロードマップ
日付 リリース内容 日付 リリース内容
2016年4月 PP:Azure Functions 2017年7月 PP:Visual Studio 2017 tools for Azure Functions
2016年11月 GA:Azure Functions
2017年9月
PP:Azure Functions support for Graph bindings and custom bindings
2017年1月 PP:Azure Functions deprecating Native integration between Azure Cosmos DB and Azure Functions
2017年2月 PP:Azure Functions Proxies Azure Functions support for .NET Core
2017年3月 PP:Azure Functions Open API (Swagger) support 2017年10月 Java support for Azure Functions
2017年4月
Azure Functions integration with Application Insights 2017年11月 GA:Azure Functions Proxies
New integrated portal for Azure Functions
2016年11月15日にGAしてから1年が経ちました。進化が早く,この1年間のうちにも17を超えるPublic Preview(PP)とGeneral Avalavility(GA)をしています。2017年5月
PP:Azure Functions with Common Data Service
PP:Direct export of Azure Functions for PowerApps
PP:Azure Functions and App Insights integration
PP:Azure Functions Runtime for Windows
Triggerと対応言語の種類
利用可能な言語は今のところC#、F#、Node.js、PHP、PowerShell、Python、Bash等々です。
型 サービス トリガー 入力 出力
スケジュール Azure Functions 〇
HTTP (REST または Webhook) Azure Functions 〇 〇
Blob Storage Azure Storage (Azure Storage) 〇 〇 〇
イベント Azure Event Hubs 〇 〇
キュー Azure Storage (Azure Storage) 〇 〇
キューとトピック Azure Service Bus 〇 〇
Storage テーブル Azure Storage (Azure Storage) 〇 〇
SQL テーブル Azure Mobile Apps 〇 〇
NoSQL DB Azure Cosmos DB 〇 〇 〇
プッシュ通知 Azure 通知ハブ 〇
Twilio SMS テキスト Twilio 〇
SendGrid 電子メール SendGrid 〇
Excel テーブル Microsoft Graph 〇 〇
OneDrive ファイル Microsoft Graph 〇 〇
Outlook メール Microsoft Graph 〇
Microsoft Graph イベント Microsoft Graph 〇 〇 〇
認証トークン Microsoft Graph 〇
Azure Functions プランの比較
App Service Planを利用する場合のケース• App Serviceにインスタンスを実行している使用率の低いインスタンスがある場合• 従量課金プランで提供されるよりも多くの CPU またはメモリを利用する場合• 従量課金プランで許可されている最大実行時間 (10 分) よりも長く実行する場合• VNET/VPN接続などのApp Service プランでのみ使用できる機能が必要である場合
Consumption(従量課金プラン)を使用するケース• 費用をなるべく安く済ませたい場合• 処理自体が軽く実行コストが低い場合(必ず10分以内に終わるような処理)• サーバメンテナンスや設定をする必要がない場合
課金の考え方観測されたリソース使用量と実行時間で計算されます使用されたリソース(メモリ)は最小128Mに丸められ、最大1536Mに切り上げられます
例:観測されたメモリ消費量が512MBで500万回実行され実行時間は3秒とします①リソース使用量(秒) 500万回実行数 × 3秒 = 1500万秒②リソース使用量(GB秒) 512MB / 1024MB × 1500万秒 = 750万GB-s③課金対象のリソース使用量 750万GB-s – 400000GB秒(無料分) = 710万GB-s④月あたりのリソース使用量の料金 710万GB-s × \0.001632/GB秒 = 11,582円
Azure Functions プランの比較
項目 従量課金プラン App Serviceプラン
課金体系実行した時間分と利用したリソース分で課金が発生します、夢の0円運用もやりようによっては可能
選択したインスタンスのプランに応じて課金が発生します (例:A2 \16.31/時間
スケーリング必要に応じて自動的にスケーリングを行うため意識する必要ない
手動・自動を選択可能、またスケーリングする量や閾値を柔軟に選択できるため自由度が高い但し手動で設定する必要あり
実行環境(スペック)
128M~1,536Mの間で変動し課金に影響するCPUについては不明
選択したインスタンスのプランに応じてスペックが変動する(例:A2 CPU2コア RAM 3.50GB TempHDD 490GB
実行時間~5分(初期値)~10分(最大)設定時間を越えると強制的にプロセスが終了します
10分以上の実行が可能
常時接族自動でアクティブ化されるため意識する必要なし※トリガーに応じて問題あり
手動で常時接続の設定を施す必要あり※Standardプラン以上にする必要あり
その他本当の意味でのFaaSは従量課金プラン 自由度が高いがサーバを意識しなくてはいけない為
サーバレスの定義から若干外れていると思う
Azure Durable Functionについて
Azure Durable Fucntionsとは
Azure Durable FunctionsはAzure WebJobを拡張したもので、サーバレス環境で長時間実行可能でステートフルなコードを記述することができます。
Azure FunctionsはAzure Webjobsのサーバレスな進化系ですがAzure DurableFunctionsはDurable Task FrameWorkのサーバレスな進化系ともいえます。
既にMicrosoft内ではミッションクリティカルなプロセスを自動化するために利用されているようです。
※まだプレビューです
注意(MSDN抜粋)Durable FunctionsはAzure Functionsの高度な拡張機能ですが、すべてのアプリケーションに適しているわけではありません。この記事は開発者がAzure Functionsのコンセプトを十分に理解しており、サーバーレスアプリケーションの開発に取り組んでいることを前提としています。
OchestratorFunction
Azure Functionのアーキテクチャ
App Service
Azure Storage
Web Apps / Web Job
Azure
Porta
l/Azure
Functio
ns P
orta
l
Input Bindings
Output Bindings
Orc
hestra
tion
Trig
ger
Functions
Functions ランタイム※Durable Task
WebJobs ExtensionWebJobs Core SDK
オーケストレータについて
・オーケストレータとは(従来)
システムやソフトウェアサービスなどの構築や運用管理を自動化することを指します仮想化環境においては仮想サーバーやアプリケーションの設定を統合的に行ったり、あるいは運用を自動化するといった意味で利用されることが多い
・Durable Functionsのオーケストレータ
オーケストレーターはステートフルなワークフローをコードで表現することができます。他の関数を同期と非同期のどちらでも呼び出すことができ、呼び出された関数からの出力をローカル変数に保存することが可能です。関数が待機状態になるたびに、自動で進行状況にチェックポイントを設定するためプロセスがリサイクルされるかVMが再起動された場合でもローカルの状態が失われることはないそうです。
Function Chain
F1 F2 F3
Function Chainingとは特定の順序で分散している関数を順次実行していくパターンです。上記の図を見るとイメージしやすいかと思いますが1回のトリガーでF1 → F2 → F3と関数を順次実行していくイメージです。
今までは分散している関数をトリガー別に順次呼び出す必要がありましたが、 orchestrator Triggerを利用することで関数をまとめて実行することができるようになりました。
FanOut/FanIn
F1
F2
F3
Fan-In/Fan-Outは複数の関数を同時に呼び出すOrcehstratorを記述し、その結果に対して何らかの集計を実行する方法を示す高度なユースケースです。
左図で説明するとF2のFunctionが並列で複数同時に実行されるのをイメージしてください。並列で実行されたFunction毎の処理完了タイミングは別々ですので全てのFunctionが完了するのを待ってから次の処理に移行します。
例えばAzure Blob Storageに大量のファイルアップロードを並列で行う等の処理にむいていたりします。
Async Http APIs
DoWorkStart
GetStatus
Async Http APIsは長時間実行される関数に対して現在の状態の確認を行うことのできるパターンです。
長時間実行しているファンクションの状態がどういう状態にあるのかを確認するために利用します。
Stateful Singleton(Lightweight Actor)
Lightweight Actorは状態を格納し他の関数から長期的に参照することのできるオーケストレータ関数です。Service fabricのActorに似ているといわれています。
ステートレスな場合は状態をサーバ側で保持できないので値の増減はできませんがステートフルな場合はサーバ側で値を保持し続けるので増減することが可能です。
カウンタのように増減するような操作はatomic(保護されている状態)である必要があります。操作によって互いに上書きする競合状態が発生してしまうため並行性を管理する必要性があるためです。
オーケストレーションインスタンスは常にシングルスレッドなので、この種の動きは簡単に実装できます。
Human Interaction
RequestApproval
RequestApproval
Escalate
Human interaction and timeoutsは人間の所作を介在させるオーケストレーションを利用するパターンです。実際の人物がプロセスに介在し、その人物に通知を送信し、その人物のアクションを非同期的に応答を受け取り実施します。SMS認証でモバイルデバイスに送られた認証コードの入力を一定時間待ち、入力されたら認証する、一定時間過ぎたら認証失敗にする等のユースケースが考えられます。
DEMO
おまけ:各クラウドのサーバレスサービス比較表
特徴 AWS lambda Google Cloud Functions Azure Functions
スケーラビリティと可用性 自動スケーリング 自動スケーリング手動スケーリングまたは計量スケーリング(App Service Plan)自動スケーリング(Consumption Plan)
関数の最大数 無制限 プロジェクトごとに1000 無制限
同時実行 アカウント・地域ごとに1000回の並列実行 制限なし 制限なし
最大実行 300秒(5分) 540秒(9分)無制限(App Servie Plan)300秒~600秒(5分~10分)(Consumpiton Plan)
サポート言語 JavaScript、Java、C#、Python JavaScriptのみC#、JavaScript、F#、Python、バッチ、PHP、PowerShell、Bash
デプロイ方法ZIPアップロードのみ(LambdaまたはS3へのアップロード)
ZIPアップロード、クラウドストレージ、クラウドソースリポジトリ
Visual Studio Team Services、OneDrive、ローカルGitリポジトリ、GitHub、Bitbucket、Dropbox、外部リポジトリ
イベント駆動型
S3、SNS、SES、DynamoDB、Kinesis、CloudWatch、Cognito、API Gateway、CodeCommitなど
クラウドパブリケーション/サブまたはクラウドストレージオブジェクトの変更通知
Blob、EventHub、汎用WebHook、GitHub WebHook、キュー、Http、ServiceBusキュー、サービスバストピック、タイマートリガー
ロギング CloudWatchログ スタックドライバロギング App Servicesの監視
モニタリング CloudWatch&X-Ray スタックドライバーの監視 アプリケーションの分析
価格設定無料から$ 0.20/1Mの呼び出し、$ 0.00001667/GB-secの1M要求
1M要求を無料、次に$ 0.40 / 1M呼び出しに加えて$ 0.00000231 / GB-sec
100万回の無料リクエスト、0.20ドル/ 1Mコール、0.000016 / GB-s
出典:https://cloudacademy.com/blog/microsoft-azure-functions-vs-google-cloud-functions-fight-for-serverless-cloud-domination-continues/
おまけ:参考資料等々
• Azure Functions公式ドキュメントhttps://docs.microsoft.com/ja-jp/azure/azure-functions/
• 環境構築公式ドキュメントhttps://docs.microsoft.com/ja-jp/azure/azure-functions/durable-functions-install
• Functions Chain公式ドキュメントhttps://docs.microsoft.com/ja-jp/azure/azure-functions/durable-functions-sequence
• FanOut/FanIn公式ドキュメントhttps://docs.microsoft.com/ja-jp/azure/azure-functions/durable-functions-cloud-backup
• Stateful Singleton公式ドキュメントhttps://docs.microsoft.com/ja-jp/azure/azure-functions/durable-functions-counter
• Human Interaction公式ドキュメントhttps://docs.microsoft.com/ja-jp/azure/azure-functions/durable-functions-phone-verification
おまけ:参考資料等々
• Azure Functions の 超イケてる Durable Functions を使ってみるhttps://qiita.com/TsuyoshiUshio@github/items/3e8acb1b0388b6045fdb
• Azure Durable Functionsを弄ってみた(環境構築編&Function Chaining実行編)https://goo.gl/5qpVXu
• Azure Durable Functionsの「Function Chaining」を試してみたhttps://goo.gl/QK576h
• Azure Durable Functionsの「Fan-In/Fan-Out」を試してみたhttps://goo.gl/mDoDRe
• Azure Durable Functionsの「Lightweight Actor」を試してみたhttps://goo.gl/hyxZVh
• Azure Durable Functionsの「 Human interaction and timeouts」を試してみたhttps://goo.gl/ekw52W
おまけ:参考資料等々
• Azure Functions Get Started Sitehttps://functions.azure.com/signin
• Azure Functions quickly with a premade(Functionを1時間だけ利用できるサイト)https://functions.azure.com/ng-min/try?trial=true
• GitHub:azure-functions-durable-extension durabletaskhttps://github.com/Azure/azure-functions-durable-extensionhttps://github.com/Azure/durabletask
• Visual Studio 2017https://www.visualstudio.com/ja/
• POSTMANhttps://www.getpostman.com/
• Azure Storage Explorehttps://azure.microsoft.com/ja-jp/features/storage-explorer/
まとめ
Functionsは設計とアセスメント(事前評価)が非常に大切です!!
ServerlessとAzure Functionsは
※クラウド全体に言えることでもありますが
「用法・容量を検討して正しくご利用下さい」
長時間ご清聴頂きありがとうございました
告知
12月2日(土)にAzureもくもく会を開催します。よろしければご参加ください。CONNPASSで募集してます。