"サーバーレス"を超越する。なぜ？から理解する Durable Functions
•Download as PPTX, PDF•
3 likes•3,284 views
Tech Summit 2018 Durable Functions よさを理解するための、資料です。L200 はじめての人向けになっています。
Recommended
More Related Content
Similar to "サーバーレス"を超越する。なぜ？から理解する Durable Functions
Similar to "サーバーレス"を超越する。なぜ？から理解する Durable Functions (20)
More from Tsuyoshi Ushio
More from Tsuyoshi Ushio (20)
Recently uploaded
Recently uploaded (8)
"サーバーレス"を超越する。なぜ？から理解する Durable Functions
- 1. ”サーバーレス” を超越する。 なぜ? から理解する Durable Functions 牛尾 剛 Microsoft Corporation CSE - EEST Senior Software Engineer AD10
- 2. Information 「Ask The Speaker」 各ブレイクアウトセッション終了後の休憩時 間に、 登壇したスピーカーに直接ご質問いただける コーナーを B2F 「Ask The Speaker」 Room に用意 しています。セッション内容のより深い理解 のため、 ぜひお役立てください。 （※ハンズオンラーニング、シアターセッション、ビジネス トラック 及び 一部のセッションを除きます） EXPO AREA 1 EXPO AREA 2 Room D
- 3. セッションアンケートにご協力ください。 公式イベントアプリで、「Microsoft Tech Summit 2018 参加者アンケート（必 須）」と 「各セッションアンケート（ 5 つ以上）」、合わせて 6 つ以上のアンケートに ご回答ください。 もれなくオリジナルグッズを贈呈いたします。 Information Twitter のご案内 本セッションに関するご質問やご感想は、 #mstsjp18 と セッション ID の ハッシュタグで、ご投稿をお願いします。 #mstsjp18
- 5. 日本最後の講演です。
- 7. アジェンダ なぜ Durable Functions か？ 現実世界における Durable Functions サーバーレスと、その限界 事例とTips
- 11. Platform Application delivery Operating system ●●● ●●● ●●● + https://github.com/azure/azure-functions-host (+other repos) Azure Functions host runtime Azure Functions Core Tools Azure Functions base Docker image Azure Functions .NET Docker image Azure Functions Node Docker image ●●●
- 12. Platform Application delivery Operating system ●●● ●●● ●●● + https://github.com/azure/azure-functions-host (+other repos) Azure Functions host runtime Azure Functions Core Tools Azure Functions base Docker image Azure Functions .NET Docker image Azure Functions Node Docker image ●●● Azure Functionsはどこでも動作する
- 16. ブラウザ Proxy Blob (SPA) Upload Blob (画像) CosmosDB Create Car Review 01 Search
- 17. Change Feed Blob (画像) CosmosDB Car Review 02 Change Feed Check Text Text checked Rejected
- 18. Send event Car Review 03 Handle Reject Review
- 19. ややこしいね ん
- 20. 10分
- 21. 障害起こったら どうするん？
- 24. F1 F2 F3 F4 Function chaining パターン
- 25. // calls functions in sequence public static async Task<object> Run(DurableOrchestrationContext ctx) { try { var x = await ctx.CallActivityAsync<object>("F1"); var y = await ctx.CallActivityAsync<object>("F2", x); var z = await ctx.CallActivityAsync<object>("F3", y); return await ctx.CallActivityAsync<object>("F4", z); } catch (Exception) { // global error handling/compensation goes here } }
- 31. 翻訳超めんどくさい問 題
- 32. 普段の解法 この筋肉で 解決
- 35. Markdown translator deep dive
- 37. リトライ [FunctionName("TranslationSubOrchestrator")] public static async Task<string> TranslationSubOrchestrator( [OrchestrationTrigger] DurableOrchestrationContext context) { var translationContext = context.GetInput<TranslationOrchestrationContext>(); var retryOptions = new RetryOptions(TimeSpan.FromMinutes(1), 5); // Read Document translationContext = await context.CallActivityWithRetryAsync<TranslationOrchestrationContext>( "ReadDocument", retryOptions, translationContext); : 中略 return translationContext.Path; } •最大試行回数: 再試行が行われる最大回数。 •1 回目の再試行の間隔: 1 回目の再試行を行う前の待機時間。 •バックオフ係数: バックオフの増加率を決定するために使用される係数。 既定値は 1 です。 •最大再試行間隔: 次の再試行を実行する前に待機する最大時間。 •再試行タイムアウト: 再試行を実行するために費やす最大時間。 既定の動作は、無限の再試行 です。 •ハンドル: 関数呼び出しを再試行するかどうかを決定するユーザー定義のコールバックを指定 できます。 https://docs.microsoft.com/ja-jp/azure/azure-functions/durable-functions-error-handling
- 39. 分散トレーシング こうご期待
- 40. 富士フィルム様 Durable Functions による AI ワークフロー改善
- 41. 著名大学へのAzure AD B2C＋LINE, Facebook/ Durable Functionsの導入事例 配送要求受付I/F 処理キュー 永続DB 受付記録を 書き込み 配送処理状況を 書き込み CTC B2C ID基盤 （Azure AD B2Cベース） 保護者ID⇒SNS ID変換 メッセージ配送システム 管理者 APIクライアント （学校側システム） 管理者 メッセージ配信状況確認 配送先 SNS IDの取得 配送先振り分け・ 配送制限件数で分割 LINEへの配送要求 FaceBookへの 配送要求 ※エラー時 リトライ ※エラー時 リトライ ※エラー時 リトライ ※エラー時 リトライ 各SNSへの 配送処理
- 43. これからつくるあなたへ Orchestrator は I/O やランダム禁止 バージョニングに注意！ Storage Emulator を開発に使う 内部アーキテクチャを知ろう host.json で劇的チューニング可能
- 47. 関連セッション
- 52. © 2018 Microsoft Corporation. All rights reserved. 本情報の内容（添付文書、リンク先などを含む）は、作成日時点でのものであり、予告なく変更される場合があります。
Editor's Notes
- https://www.pakutaso.com/
- Full abstraction of servers developers can just focus on their code—there are no distractions around server management, capacity planning, or availability. Instant, event-driven scalability Application components react to events and triggers in near real-time with virtually unlimited scalability; compute resources are used as needed. Pay-per-use Only pay for what you use: billing is typically calculated on the number of function calls, code execution time, and memory used.*
- いままでなかった時はどうでした？サーバーの発注、見積もり、、値切り交渉
- ３まいをまとめて、Queue地獄のページを作る 要素をへらさないといけない －＞Queueをへらすのがおおい
- https://www.pakutaso.com/
- ステップ数をふやす原因になっていたQueueが劇的に削減
- さんかくは、線にする 処理は、右からひだりへながれる
- Imagine a scenario where I have to take the output of a Function and use it as the input to call another Function. I’ll have to coordinate the chaining manually. If I have to have a function that takes some sort of event and then parallelizes it into multiple Functions, I can still do that but how will I know when all Functions have finished executing so I can aggregate the results and move on. What if I had to listen on multiple events and aggregate their outcome to determine which specific job or function to run in my application. What if I wanted to do some kind of extended monitoring on an endpoint? For example, if I were to monitor the temperature of a remote machine and take action x if the temperature were lower than a certain threshold, else do y or run job y. What if I have an API or endpoint that was running for a long time? I know Functions are short-lived but sometimes you guys put some serious load on them. Could there be a mechanism to provide status of the execution back to the client so they’re not left hanging? And lastly, what if I wanted to get some sort of human interaction in there? For example, if I am to do some sort of 2FA in the middle of my function execution but also don’t want to wait forever because sometimes people take forever to reply especially when the texts are automated. Today, I’m going to be talking about some of these problems – how you can approach them in regular FaaS? And how they can be simplified with the technology of Durable Functions.
- 非表示にしておく
- 40 分 -> 2 分に！
- いちづけはあくまで２００
- 広告をうまくけす
- 要するに、、、ということとさくっとお話しする。