10/30に実施されたSmart Storeリファレンスアーキテクチャーのセミナーで使用したサーバーレスアーキテクチャの資料です。 日本マイクロソフト株式会社 平岡一成

1. Azure
Smart Store
サーバーレスアーキテクチャ
Issei Hiraoka / @hoisjp
Cloud Solution Architect – Microsoft Japan
2019/10/30 40 min

2. 平岡 一成 ひらおかいっせい
日本マイクロソフト株式会社
パートナー事業本部、パートナー技術統括本部
クラウドソリューションアーキテクト
担当領域
Azure Apps (Application Development)
Web, API Server, PaaS, OSS, Container, Cognitive Services, NoSQL
経歴
• 2004年より、エンジニアとしてWebアプリケーション開発・運用プロジェクトに従事。
• 2012年に国内最大手EC事業会社に入社。サービスを支えるバックエンドAPIの開発・運用を行うグループマネー
ジャを担当。大規模＆高負荷システムの構築を得意とする。
• 2017年３月より現職。Azureパートナー向けの技術支援やPoC支援などを担当し、現在に至る。
自己紹介
@hoisjp
hoisjp

3. de:code 2019 CD07
AWS 技術者向け Azure サーバーレス
日本マイクロソフト株式会社
クラウドプラクティス技術本部 クラウドソリューションアーキテクト
平岡 一成
LinkedIn: hoisjp
Twitter: @hoisjp
https://www.microsoft.com/ja-jp/events/decode/2019session/detail.aspx?sid=CD07

4. レベル 100 (初級・入門） レベル 200（中級） レベル 300 （Smart Store用）
Smart Store Azure 関連トレーニング コース
はじめてシリーズ
Azure Data and AI
IoTで加速する
デジタルトランスフォーメーション
営業
Azure Data and AI
商品認識の仕組み（その１）
IoT
提供
予定
Azure Data and AI
商品認識の仕組み（その２）
AI
提供
予定
Azure Data and AI
オンプレミス SQL Server から Azure 上の
SQL サービス利用へのポイントと使い分け!
技術
Azure Data and AI
技術者向けいまさら聞けない
機械学習/AI の基礎
技術
SmartStoreリファレンスアーキテクチャハンズオン（ハッカソン）（2日間）
AI,IoT,App,DB
Azure Data and AI
Azure Cosmos DB の概要を
あらためて理解する
技術
Azure Data and AI
商品マスタとトランザクション管理
DB
提供
予定
対面Azure Data and AI
進化を続けるAzure IoT
技術
今日から始める Azure Functions 2.0
技術
Azure App and Infra Azure App and Infra
サーバレスアーキテクチャ
App
SmartStoreリファレンスアーキテクチャトレーニング（2日間）
AI,IoT,App,DB
対面
はじめてシリーズ
SmartStore概要解説
提供
予定
本コース
https://ms-smartstore.connpass.com/

5. レベル、目標、対象者、前提知識、および注意事項
レベル
⚫ Level 300 アドバンスド
目標
⚫ Azure Functions の特徴を理解し、サーバーレス アプリを開発できるようになること
前提知識
⚫ Microsoft Azure に関する基礎知識をお持ちの方
対象者
⚫ Microsoft Azure が提供する サーバーレス サービス (Azure Functions) を利用して
Smart Store ソリューションを構築される方
注意
⚫ 本コースの内容は、「mstep Microsoft Azure サーバーレス アプリ開発」の内容を元にしています。
⚫ Azure サービスは、日々進化しています。本テキストは 2019 年 5 月時点で確認した内容を記載しています。
⚫ 最新情報は、サービスの更新情報 (https://azure.microsoft.com/ja-jp/updates) を確認してください。

6. 本コースの内容
第 1 章 サーバーレスと Microsoft Azure
第 2 章 Azure Functions
第 3 章 リファレンス アーキテクチャ

7. サーバーレスと Microsoft Azure
第 1 章

8. ■サーバーレス概要■
• クラウドの利用形態
• サーバーレス コンピューティングとは
• Microsoft Azure におけるサーバーレス コンポーネント
• サーバーレス アプリケーションの例
• 本日ご紹介するサーバーレス コンポーネント

9. クラウドの利用形態
ストレージ
サーバー
ネットワーク
OS
ミドルウエア
仮想化
データ
アプリケーション
ランタイム
OS
ミドルウエア
データ
アプリケーション
ランタイム
ユ
ー
ザ
ー
管
理
アプリケーション
データ
ベ
ン
ダ
ー
管
理
Microsoft Azure 仮想マシン
Windows Server Hyper-V
Windows Server Microsoft Azure
App Service
Office 365
Dynamics 365
ベ
ン
ダ
ー
管
理
ユ
ー
ザ
ー
管
理
ユ
ー
ザ
ー
管
理
ベ
ン
ダ
ー
管
理

10. インフラの効率化から、アプリケーションのイノベーションへビジネス価値
時間
効率
イノベーション
PaaS
IaaS
サーバーレス
466% return on investment
$5.91M net present value
80% IT time saved
50% faster service deployment
Statistics based on five-year, risk-adjusted figures for a composite organization constructed from aggregated interviews with eight Microsoft Azure IaaS customers.
Source: “The Total Economic Impact Of Microsoft Azure PaaS,” a commissioned study conducted by Forrester Consulting, June 2016

11. 増大する IT システムの運用コスト（企業）
IT 関連コストを、以下の３つに分類
• 新規開発
• 保守開発
• 運用管理
http://itpro.nikkeibp.co.jp/article/COLUMN/20130702/488891/
44.9
30.8
24.3 運用管理
保守開発
新規開発
運用と保守で75％以上

12. 増大する IT システムの運用コスト（政府）
参考：政府オープンデータ
IT Dashboard: http://www.itdashboard.go.jp/
平成28年度政府情報システム投資計画
• 整備経費（イニシャルコスト） ：1,293 億円
• 運用等経費（ランニングコスト）：4,097 億円
⇒75%以上が運用コスト
世界最先端IT国家創造宣言（平成25年6月14日閣議決定）の目標
2021年度目途に 3割減（-30%）

13. サーバーレス コンピューティングとは
サーバー、インフラストラクチャ、オペレーティング システムを抽象化されているため、
インフラストラクチャを心配せずに、より早くアプリケーションを作成できる。
フル マネージド サービスを利用可能 柔軟なスケーリング 使用したリソース分のみ課金
⚫ サーバーのプロビジョニングや管理をする必
要がないため、サーバー管理の負荷を低
減でき、ビジネス ロジックに注力できる
⚫ コードをデプロイするだけで、高可用性のア
プリを実行できる
⚫ 同時実行される関数がゼロから数万に増
えても、数秒でスケールされる
⚫ スケールの構成は自動でおこなわれる
⚫ ほぼリアルタイムでイベントとトリガーに反
応できる
⚫ イベント発生時に瞬時にリソースが割り当
てられ、コードの実行時間とリソースの使
用分のみ課金される
・・・
</> € ¥
＄

14. スケーリング：例えば、EC サイトのトラフィックの性質
朝 昼 夜
システム
負荷
朝 昼 夜
システム
負荷
自動スケールなし
OFF OFF
OFFOFF
自動スケールあり
24 時間課金継続
￥
￥
￥
￥
￥
￥
￥ ￥
起動時間のみ課金
Web アプリ Web アプリ

15. イベントドリブンアーキテクチャ
https://docs.microsoft.com/ja-jp/azure/architecture/guide/architecture-styles/event-driven
イベントプロデューサー（生成元）とイベントコンシューマーで構成される
E ent Consumers
E ent Consumers
E ent Consumers
E ent Producers E ent Ingestion

16. Microsoft Azure におけるサーバーレス コンポーネント
Azure Functions Logic Apps Azure Storage Cosmos DB Azure Active Directory
コンピューティング
ワークフロー
オーケストレーション
ストレージ データベース
セキュリティと
アクセス制御
Event Grid API Management Azure Stream Analytics Azure Bot Service Visual Studio
クラウド
メッセージング
API の管理 分析 Intelligence 開発者ツール

17. サーバーレス アプリケーションの例
Web アプリケーション アーキテクチャ IoT バック エンド
SaaS 統合 モバイル バック エンド
シングル ページ アプリから
Functions を呼び出し
Functions でユーザー 情報
に基づき、広告を決定
数百万のデバイスが Stream
Analytics にデータを送信
Azure Cosmos DB に
データを書き込み
Functions で
データを変換・構造化
OneDrive に
Excel ファイルを
保存
Functions で Microsoft Graph API
を使いコンテンツを分析
グラフを新規シート
に作成
写真を撮ったときに
Functions を呼び出し 画像を BLOB に保存
画像をモバイルに合わ
せたサイズに変換
ページが完成

18. 事例：富士フィルムソフトウェア様 IMAGE WORKS
https://customers.microsoft.com/ja-jp/story/fujifilm-manufacturing-azure-ai-functions-jp-japan

19. © 2017 Ebiya Ltd. All rights reserved.
Challenge
• 在庫適正化困難ゆえの
高廃棄コスト
• 利益を圧迫する人件費
• 提供までの時間が長い
ことによる低い回転率
Solution
• 来客データ数値化、
AI で一週間 /
一日 / 一時間単位で
それぞれ需要を予測
• 需要予測的中率 90%
超、Power BI で視覚化
Benefits
• 定量的判断に基づく対処
• 4 年間で売上 4 倍・利益率
10 倍・平均給与 20% Up
• 人員配置適正化実現、配膳
スピード改善、回転率向上
来店予測 AI で調理準備最適化、回転率 3 倍以上
ピークタイム予測で効率よい人員配置を実現
「EbiLab (For 食堂)」

20. https://www.youtube.com/watch?v=LOJbM0aXZp0

21. 道具が自動化される
確認作業が自動化される
作業が並行に行われる
作業が複雑化する（できることが増えている）
無駄がなくなり、スピードが速くなっている
⇒競技自体のスタイルを変えてしまう
何が変わったのか

22. Microservices マイクロサービス

23. Microservices マイクロサービスとコンウェイの法則
コンウェイの法則
「システムを設計する組織は、その構造をそっく
りまねた構造の設計を生み出してしまう」
"Organizations which design systems
are constrained to produce designs
which are copies of the communication
structures of these organizations."
連邦法と州法

24. Azure Functions
第 2 章

25. ■Azure Functions 概要■
• Azure Functions とは
• Azure Functions の利用シナリオ
• アーキテクチャ

26. Azure Functions とは
サーバーを準備せずにコードを記述・実行できるた
め、プログラミングに集中できる
コードを実行した分だけ課金されるため、コストを
抑えることができる
Azure 上の様々なストレージに、少ないコードで読
み書きできる
業務要件に応じたスケーリングが可能
C# / F# / JavaScript / Java / Python などの言
語をサポートするため、開発者のこれまでのスキル
を活かすことができる
Azure Functions
イベント ドリブン型のサーバーレス コンピューティング

27. Azure Functions の利用シナリオ
IoT デバイスから送られてくるデータをリアルタイムに構造化して データベースに保存
フライトの遅延情報の登録をトリガーに、搭乗者のモバイル アプリに通知を送信
画像ファイルが Blob にアップされたことをトリガーに Computer Vison API で文字を読み取りデータベースに保存
IoT Hub
Stream
Analytics
デバイスからのデータ収集 データを構造化
デバイス
画像を OCR にかけ
結果を データベースへ
画像をアップロード
遅延情報の登録
モバイル・通知サービスの
呼び出し

28. アーキテクチャ
Azure App Service と WebJobs が基盤
参考：Ignite 2018 セッション Azure Functions Internals
App Service Dynamic Runtime
Hosting, CI, Deployment Slots, Remote Debugging, etc.
WebJobs Core
Programing model, common abstractions
WebJobs Extensions
Trigger, input and output bindings
Azure Functions Runtime (WebJobs Script)
Dynamic Compilation, Language abstractions, etc.
Language Runtime
V1 (C#, Node.js, F#, PHP, Python, etc.) / V2 (C#, Node.js, Java)
Code Config

29. ■Function App – 関数アプリケーション■
• Function App
• 2 つのホスティング プラン
• Azure Functions ランタイムのバージョン
• V1 / V2 でサポートされるプログラミング言語

30. Function App - 関数アプリケーション
Function App - 関数アプリケーション とは
関数をホストする実行コンテキスト。1 つの関数アプリケーションに複数の関数を作成可能。
実行環境の設定は Azure ポータルの [アプリケーション設定] でおこなう。
Windows のランタイム スタックは
.NET / JavaScript / Java
Linux は .NET / JavaScript
/ Python
関数コード ファイルやログ
などの保存に使用
関数
アプリ
関数

31. 2 つのホスティング プラン
◼ サーバーレス
•コードの実行時にコンピューティング リソースが自
動で割り当てられる
•内部的には App Service が使われているが
意識することはない
•自動でスケーリングされる
◼ リソースの使用量と実行回数に基づ
き課金
•リソース使用量：ギガバイト秒単位
(実行時間 × 平均メモリサイズ)
•実行回数：関数の実行総数
•Azure App Service プランよりも安価になるこ
とが多い
◼ 時間のかかる処理は不向き
•最大 10 分でタイムアウトする
従量課金プラン
◼ App Service 専用インスタンス上で
実行
•サーバーレスではない
•スケーリングの管理をおこなう必要がある
◼ 料金は固定 (Basic 以上のプランが
必要)
• 継続的に実行する関数なら、従量課金プラン
より安価になることがある
App Service プラン
関数アプリ作成時に選択。
後から変更はできない。

32. Azure Functions ランタイムのバージョン
V1 と V2 がある。新規に作成する関数アプリは V2 を推奨。
Azure Functions の ランタイムには V1 と V2 があり、関数アプリ単位でバージョンを選択する。Azure ポータルで関数アプリを作
成すると、V2 となるが、後から管理ポータルや Azure CLI から変更できる。
関数アプリ内に関数があると、変更できません

33. V1 / V2 でサポートされるプログラミング言語
言語 V1 V2
C# GA (.NET Framework 4.7) GA (.NET Core 2)
JavaScript GA (Node 6) GA (Node 8 / Node 10)
F# GA (.NET Framework 4.7) GA (.NET Core 2)
Java - GA (Java 8)
Python 試験段階 プレビュー (Python 3.6)
TypeScript 試験段階 GA (JavaScript へのトランスパイリングによる)
PHP 試験段階 -
バッチ (.cmd / .bat) 試験段階 -
Bash 試験段階 -
PowerShell 試験段階 プレビュー (PowerShell Core 6)
V2 では、1 つの関数アプリ内のすべての関数は同じ言語で作成する必要があります。
V1 では、各関数で言語を選択することができます。

34. 参考：Node のバージョン設定
関数アプリの [アプリケーション設定] で確認・変更可能

35. ■トリガーとバインド■
• トリガーとバインド
• サポートされるトリガーとバインド
• プロジェクトのフォルダー構造 (C#)
• プロジェクトのフォルダー構造 (JavaScript)
• function.json ファイル
• function.json と [統合]

36. トリガーとバインド
トリガーとは
Azure Functions はイベント駆動型。イベントの発生に応じてコードを呼び出すのがトリガー。1 つの関数には 1 つのトリガーが必
須。また、1 つの関数に複数のトリガーを設定することはできない。
バインドとは
関数と関数で処理するデータを結びつけるもの。バインドを利用することで、データソースに接続して読み書きするコードが不要となる。
バインドには入力・出力の方向があり、入力バインドからデータを読み取り、出力バインドにデータを書き込むことができる。入力、出
力バインドはそれぞれ 1 つの関数に複数定義できる。
App Service
Functions Runtime
出力バインド
入力バインド
Functions
Programing
Interface
トリガー

37. サポートされるトリガーとバインド (参考URL)
Type V1 V2 トリガー 入力バインド 出力バインド
Blob Storage ✔ ✔ ✔ ✔ ✔
Cosmos DB ✔ ✔ ✔ ✔ ✔
Event Grid ✔ ✔ ✔
Event Hubs ✔ ✔ ✔ ✔
外部ファイル ✔ ✔ ✔
外部テーブル ✔ ✔ ✔
HTTP ✔ ✔ ✔ ✔
Microsoft Graph Excel テーブル ✔ ✔ ✔
Microsoft Graph OneDrive ファイル ✔ ✔ ✔
Microsoft Graph Outlook メール ✔ ✔
Microsoft Graph Events ✔ ✔ ✔ ✔
Microsoft Graph Auth トークン ✔ ✔
Mobile Apps ✔ ✔ ✔
Notification Hubs ✔ ✔
Queue Storage ✔ ✔ ✔ ✔
SendGrid ✔ ✔ ✔
Service Bus ✔ ✔ ✔ ✔
Table Storage ✔ ✔ ✔ ✔
Timer ✔ ✔ ✔
Twilio ✔ ✔ ✔
Webhook ✔ ✔ ✔

38. プロジェクトのフォルダー構造 (JavaScript)
関数アプリ
関数
MyFunctionProject
bin
index.js
function.json
MyFunction1
host.json
extensions.csproj
JavaScriptコード
バインディング
拡張機能定義
トリガーとバインドの定義
関数
index.js
function.json
MyFunction2
バインディング
拡張機能
ライブラリ
関数アプリの構成

39. function.json と [統合]
Azure ポータルでは、GUI で function.json ファイルを定義可能
トリガーは 1 つのみ
入力、出力バインドは
複数作成可能

40. function.json ファイル
関数のトリガーとバインドを JSON 形式で定義するファイル
「bindings」 コレクションに、トリガーとバインドを定義する。
{
"bindings": [
{
"type": "eventHubTrigger",
"name": "myIoTHubMessage",
"direction": "in",
"eventHubName": "samples-workitems",
"connection": "mstephub_events_IOTHUB",
"consumerGroup": "$Default"
},
{
"type": "cosmosDB",
"name": "$return",
"direction": "out“,
"databaseName": "mstepDB",
"collectionName": "mstepCollection",
"createIfNotExists": false,
"connectionStringSetting":
"mstep-cosmos_DOCUMENTDB"
}
]
}
トリガーの種類
パラメーター名
方向(入力)
バインドの種類
パラメーター名
方向(出力)
Cosmos DB へ
の接続文字列
IoT Hub への
接続文字列
トリガーやバインドの種類により、設定するプロパティは異なります。

41. ■バインドとコード■
• バインディング拡張機能の登録
• タイマー トリガー
• HTTP トリガー
• 承認レベル
• HTTP エンドポイントのカスタマイズ
• IoT Hub / Event Hub トリガー
• Cosmos DB バインド
参考：
https://docs.microsoft.com/ja-jp/azure/azure-functions/functions-triggers-bindings

42. ■バインドとコード■ ※本コースでは抜粋して紹介
✓ バインディング拡張機能の登録
• タイマー トリガー
✓ HTTP トリガー
• 承認レベル
• HTTP エンドポイントのカスタマイズ
• IoT Hub / Event Hub トリガー
✓ Cosmos DB バインド
参考：
https://docs.microsoft.com/ja-jp/azure/azure-functions/functions-triggers-bindings

43. バインディング拡張機能の登録
トリガーとバインディングは、「バインディング拡張機能」を必要とする
V1 では拡張機能は自動で登録される。V2 では、HTTP と Timer 以外は手動での登録が必要。
開発環境 V1 V2
Azure ポータル 自動 手動 ([統合] から GUI でインストール)
Azure Functions Core Tools (ローカル) 自動 手動 (func extensions install コマンドでインストール)
Visual Studio 2017 (C#) 手動 (NuGet からインストール) 手動 (NuGet からインストール)
Visual Studio Code (C#) - 手動 (dotnet add package コマンドでインストール)
自動ではインストール
されないので注意！
Azure ポータルでの
拡張機能インストール
Visual Studio での
NuGet パッケージの管理

44. タイマー トリガー
スケジュールに基づいて関数をよびだすことができるトリガー。スケジュールは CRON 式を使って指定
する。
Azure Functions で使用できるCRON 式
function.json
{
"name": "myTimer",
"type": "timerTrigger",
"direction": "in",
"schedule": "0 */5 * * * *"
}
run.csx
using System;
public static void Run(TimerInfo myTimer, ILogger log)
{
log.LogInformation(
$"C# Timer trigger function executed at: {DateTime.Now}");
}
0 */5 * * * *
秒 分 時 日 月 曜日
タイマー トリガーは、関数の途中で失敗しても再試行されず、
次のスケジュールを待ちます。

45. HTTP トリガー
HTTP リクエストで関数を呼び出し、レスポンスを返すことができるため、REST API として利用
可能。
function.json
{
"authLevel": "function",
"name": "req",
"type": "httpTrigger",
"direction": "in",
“methods”: [ "get", "post" ]
},
{
"name": "$return",
"type": "http",
"direction": "out"
}
承認レベル。anonymous /
function / admin のいずれか
を設定。
関数が応答する
HTTP のメソッド。
出力バインド
HTTP 応答のためのパラメーター名。
「$return」すると、戻り値として指定し
た値が応答として送信される。

46. IoT Hub / Event Hub トリガー
Event Hub / IoT Hub により取得されたデータを Azure Functions で操作できる。
function.json
{
"type": "eventHubTrigger",
"name": "myIoTHubMessage",
"direction": "in",
“eventHubName”: "samples-workitems",
“connection”:
"mstephub_events_IOTHUB",
"consumerGroup": "$Default"
}
IoT Hub
デバイスからのデータ収集 データを加工
デバイス
データを保存

47. Cosmos DB バインド - C# スクリプト
Cosmos DB への入力・出力バインドがサポートされる
function.json
{
"type": "cosmosDB",
"name": "$return",
"databaseName": "mstepDB",
"collectionName": "mstepCollection",
"createIfNotExists": false,
"connectionStringSetting":
"mstep-cosmos_DOCUMENTDB",
"direction": "out"
}
接続先のアカウント /
データベース / コレク
ションを指定
run.csx
public static string Run(string myIoTHubMessage, ILogger log)
{
DeviceInfo device =
JsonConvert.DeserializeObject<DeviceInfo>(myIoTHubMessage);
if(temperature <= 20)
{
device.status = "低";
}
return JsonConvert.SerializeObject(device);
}
public class DeviceInfo
{
public string messageId { get; set; }
public string deviceId { get; set; }
public string temperature { get; set; }
public string humidity { get; set; }
public string status { get; set;}
}
IoT デバイスからの情報
を JSON で取得
JSON から
オブジェクトを生成
取得したデータ
を加工
戻り値として JSON を指定
するだけで、Cosmos DB に
追加

48. Cosmos DB バインド – トリガー C# クラスライブラリ
https://docs.microsoft.com/ja-jp/azure/azure-functions/functions-bindings-cosmosdb-v2
namespace CosmosDBSamplesV2
{
public static class CosmosTrigger
{
[FunctionName("CosmosTrigger")]
public static void Run([CosmosDBTrigger(
databaseName: "ToDoItems",
collectionName: "Items",
ConnectionStringSetting = "CosmosDBConnection",
LeaseCollectionName = "leases",
CreateLeaseCollectionIfNotExists = true)]IReadOnlyList<Document> documents,
ILogger log)
{
if (documents != null && documents.Count > 0)
{
log.LogInformation($"Documents modified: {documents.Count}");
log.LogInformation($"First document Id: {documents[0].Id}");
}
}
}
}
CosmosDBTrigger 属性を使用
接続先などの
パラメータ 値の実体は変数
代入されている
値の取り出し

49. Cosmos DB バインド – 入力 C# クラスライブラリ
namespace CosmosDBSamplesV2
{
public static class DocByIdFromJSON
{
[FunctionName("DocByIdFromJSON")]
public static void Run(
[QueueTrigger("todoqueueforlookup")] ToDoItemLookup toDoItemLookup,
[CosmosDB(
databaseName: "ToDoItems",
collectionName: "Items",
ConnectionStringSetting = "CosmosDBConnection",
Id = "{ToDoItemId}")]ToDoItem toDoItem,
ILogger log)
{
log.LogInformation($"C# Queue trigger function processed Id={toDoItemLookup?.ToDoItemId}");
if (toDoItem == null)
{
log.LogInformation($"ToDo item not found");
}
else
{
log.LogInformation($"Found ToDo item, Description={toDoItem.Description}");
}
}
}
CosmosDB 属性を使用
接続先などの
パラメータ
値の実体は変数
代入されている

50. Cosmos DB バインド – 出力 C# クラスライブラリ
キュー トリガー、1 つのドキュメントの書き込み
namespace CosmosDBSamplesV2
{
public static class WriteOneDoc
{
[FunctionName("WriteOneDoc")]
public static void Run(
[QueueTrigger("todoqueueforwrite")] string queueMessage,
[CosmosDB(
databaseName: "ToDoItems",
collectionName: "Items",
ConnectionStringSetting = "CosmosDBConnection")]out dynamic document,
ILogger log)
{
document = new { Description = queueMessage, id = Guid.NewGuid() };
log.LogInformation($"C# Queue trigger function inserted one row");
log.LogInformation($"Description={queueMessage}");
}
}
}
CosmosDB 属性を使用
変数を上書きすると、
CosmosDBに書き込み

51. 参考：Azure Functions と Python
V2 では現状は Linux ベースの Azure Functions が必要 (プレビュー)
V1 では、Windows ベースでも Python を利用可能。V2 ではプレビューのため、パフォーマンスが低い。
Azure Functions Core Tools を使い、ローカルでの開発も可能
Windows だけではなく、Linux、MacOS での開発も可能。開発には Python 3.6 の仮想環境を必
要とするため、「python -m venv XXX」 コマンドを実行する。
Visual Studio Code を使い、開発および Azure へのデプロイも可能
Python での
開発も可能

52. API Management の必要性
多くの Azure Function を使用するアプリケーションの場合、API の管理が煩雑になる。
a.azurewebsites.net/api/customers
b.azurewebsites.net/api/products
c.azurewebsites.net/api/orders
HTTP エンドポイント
が様々…

53. API Management
API Management
API ゲートウェイ機能を持つサービス。API のルーティングが可能。
a.azure-api.net/api/customers a.azurewebsites.net/api/customers
a.azure-api.net/api/products b.azurewebsites.net/api/products
a.azure-api.net/api/orders c.azurewebsites.net/api/orders
.../api/customers
.../api/products
.../api/orders
ルーティング
API Management と Azure Functions を利用した構成例は、「Azure 上のサーバーレス Web アプリケーション」をご覧ください。
https://docs.microsoft.com/ja-jp/azure/architecture/reference-architectures/serverless/web-app
サンプルの実装コードを GitHub から入手することもできます。

54. Azure API Management 従量課金モデル
https://azure.microsoft.com/ja-jp/blog/announcing-azure-api-management-for-serverless-architectures/
• https://azure.microsoft.com/ja-jp/updates/azure-api-management-
consumption-tier-is-now-generally-available/
• 現時点では、リージョンが限定

55. ■開発ツール■
• Azure ポータル
• Azure Functions Core Tools
• Visual Studio
• Visual Studio Code

56. Azure ポータル
Azure 環境で直接コーディングとテストができる

57. Azure Functions Core Tools
ローカル環境での Functions 開発コマンドツール
ローカル環境で実行やデバッグも可能になる。コマンド プロンプトからコマンド ベースで関数を開発できる。V1 (.NET Framework)
は、Windows のみ。V2 (.NET Core) は Windows、Linux、および MacOS にインストール可能。func コマンドで関数の作成か
ら実行、発行まで可能。
Windows へのインストール
1. .NET Core をインストール
2. Node.js と npm をインストール
3. Azure Functions Core Tools V2 インストール
func コマンドを使った開発と Azure への発行
npm install -g azure-functions-core-tools
コマンド 説明
func init 関数プロジェクトの作成
func extensions install バインディング拡張機能のインストール
func new 関数の作成
func start ローカルでの実行
func azure functionapp publish Azure 上の既存の関数アプリへの発行

58. Visual Studio (1)
Visual Studio で Azure Functions の開発が可能
C# の Azure Functions プロジェクトテンプレートと関数テンプレートを使って開発ができる。 Azure Functions Core Tools をイン
ストールすれば、ローカルでのデバッグ実行も可能。Azure 上のリソースをトリガーにした関数を、ローカルで実行することもできる。
利用するストレージの場所を指定する。
• 参照：Azure 上のストレージを利用。
• ストレージ エミュレーター：ローカルのストレージ
エミュレーターを利用。
「ストレージ エミュレーター」は複数人で
開発する際におすすめです。Azure
上のストレージを使うと、1 つのデータを
複数人で共有することになり、想定
外の結果になることがあります。
トリガーを選択
V1 or V2 の選択
プロジェクト
テンプレート

59. プロジェクトに作成されるファイル
Visual Studio (2)
関数 Azure / ローカルいずれ
にも適用される設定
ローカル実行時でのみ
使用される設定
host.json
{
"version": "2.0"
}
local.settings.json
{
"IsEncrypted": false,
"Values": {
"AzureWebJobsStorage": "UseDevelopmentStorage=true",
"FUNCTIONS_WORKER_RUNTIME": "dotnet"
}
}

60. Visual Studio (3)
バインディングは属性で設定するが、ビルド時に「function.json」ファイルが生成される。
Function1.cs
public static class Function1
{
[FunctionName("Function1")]
public static async Task<IActionResult> Run(
[HttpTrigger(AuthorizationLevel.Function, "get", "post", Route = null)] HttpRequest req,
ILogger log)
{
....
}
}
ビルド
注意：ドキュメント上では、C# スクリプト と C# クラスライブラリの区別に注意

61. Visual Studio Code (1)
Azure Functions 拡張機能をインストールすることで開発できる
インテリセンス、デバッグツールも利用した開発が可能。Azure Functions へのデプロイもできる。MacOS や Linux での開発も可能
に。
②Azure Functions 拡張機能を使い、
プロジェクトと関数を作成
①Azure Functions 拡張機能をインストール
[ターミナル] ウィンドウを使えば、 func コマンドでプロジェクトや
関数を作成することもできます。
プロジェクト作成
関数作成

62. Visual Studio Code (2)
③ローカルでデバッグ実行

63. ■デプロイ■
• Visual Studio
• Visual Studio Code
• 継続的なデプロイ
https://docs.microsoft.com/ja-jp/azure/azure-functions/functions-continuous-deployment

64. Visual Studio
[ビルド] メニューの [プロジェクト名の発行] で、Azure に発行可能。
[新規作成]
Azure 上に新規に関数アプリを作成し、発行する。
[既存のものを選択]
Azure 上の既存の関数アプリに発行する。Azure 関数アプリ内
のすべてのファイルが上書きされる。
☑パッケージファイルから実行する
有効にすると Run-From-Zip 構成になる。デプロイ用ファイルを
パッケージ (zip ファイル) にして発行する。関数はデプロイ パッケー
ジ (zip) から直接実行され、関数アプリは読み取り専用になる。
発行

65. 参考：展開スロットとスワップ (プレビュー)
従量課金プランでも展開スロットを作成可能に
①展開スロットの作成 ②展開スロットに関数作成 ③スワップ
ポータルで
関数作成
発行
従量課金プランの関数アプリで作成できる
展開スロットは 1 つのみです。

66. 参考：アプリ設定
[アプリケーション設定] には、起動時にアプリがロードする名前と値のペアを含むことができる。
コードや function.json から使用できる。各スロットでのみ有効にしたいアプリ設定は、[スロットの設定] を有効にする
function.json からの利用
{
"type": "cosmosDB",
"name": "$return",
"databaseName": "%MyDB%",
"collectionName": "mstepCollection",
"createIfNotExists": false,
"connectionStringSetting": "mstep-cosmos_DOCUMENTDB",
"direction": "out"
}
「%名前%」アプリ設定
から取得
Connection は特別で、
「名前」だけで取得
このスロットでのみ有効

67. Visual Studio Code
Azure の [FUNCTIONS] 領域で [Deploy to Function App] を選択することで、発行可能。
発行
関数アプリの
作成も可能
発行

68. [デプロイ センター] から継続的なデプロイ設定ができる
継続的なデプロイ
ソース管理を選択
ビルドサーバーを
選択
リポジトリを指定
App Service を
ビルド サーバーに
することができる
デプロイは関数アプリごとに構成されます。 継続的なデプロイが有効になると、
ポータル内の関数コードへのアクセスは、 読み取り専用に設定されます。
https://docs.microsoft.com/ja-jp/azure/azure-functions/functions-continuous-deployment

69. ■監視■
• ビルトイン モニター
• Application Insights

70. ビルトイン モニター
組込みの監視機能
リクエストログや成功・エラーカウントなど、簡単なログを確認することができる。関数の [監視] ページで、[クラシックビューに切り替え
ます] を選択して表示する。
ログの保存先
ログはストレージに保存される。[アプリケーション設定] の
[AzureWebJobsDashboard] で保存先の接続文字列を指定する。
リクエストログ
成功カウント エラーカウント

71. Application Insights (1)
組込みログ機能よりも詳細なテレメトリ データの収集と分析が可能
設定方法
① 関数アプリ作成時に有効にする
② 関数アプリ作成後に有効にする
[監視] タブで [構成] ボタンを選択する。Application Insights が作成され、アプリケーショ
ン設定の [APPINSIGHTS_INSTRUMENTATIONKEY] に、インストルメンテーション キーが
設定される。
運用フェーズでは Application Insights を強く推奨。
Functions 作成時
に有効化

72. Application Insights (2)
[監視] タブをクリックし、テレメトリ データを表示
呼出し日時を
クリック
ログ出力が
表示
[監視] タブで表示される実行履歴は、表示されるまでに最大 5 分の遅延が発生する
可能性があります。
開発時などで、即座に確認したい場合は、Live Metrics Stream を使用します。

73. Application Insights (3)
Live Metrics Stream
リアルタイムでログをモニタリングし、必要に応じてフィルタリングする。
サーバーごとに表示
ログをフィルタリング
特定の関数のログのみ表示したい
ときは、Trace テーブルの Custom
Dimension 列の Category プロ
パティに関数名を指定する
関数アプリ内のすべ
てのログが表示

74. Application Insights (4)
アプリケーション マップ
Functions アプリの依存関係をマップで表示する。直感的にボトルネックを発見できる。
操作、依存関係、ロール
ごとのパフォーマンスを
表示できる

75. ■Azure Functions の考慮事項■
• コールド スタート
• Blob トリガー
• タイムアウト
• エラー処理とリトライ
• マイクロサービス環境でのアプリケーション変更

76. コールド スタート
コールド スタートとは
従量課金プランでは、一定時間関数の呼び出しがないとインスタンスが解放される。次回呼び出し時はインスタンスの準備から行
うためコードの実行開始までに時間がかかる。
コールド スタートの回避方法
Run-From-Zip デプロイメントを使う
従量課金プランでは、アプリのファイルは Azure Files に保存されファイル単位でロードされる。これにより、ファイルの IO が多くなり低速にな
る。Run-From-Zip を使うと、ファイルが zip にまとめられているため IO が 1 度ですむ。
休眠した Functions を起こす
定期的に ping する。フォームを開いたときなどに、事前にリクエストを送る。
C# はスクリプトよりクラスライブラリ
スクリプトでは再スタート時にビルドされるため遅くなる。
App Service プランにする
App Service プランでは関数の呼び出しがなくてもインスタンスは解放されない。

77. Blob トリガー
Blob トリガーを使用する際の注意点
① Blob ストレージ アカウントには Blob トリガーを利用できない
② 高スケールな Blob (10,000 以上の Blob を含むコンテナーや 1 秒あたり 100 を超える更新が行われる Blob )で
は、イベントがキャプチャされないことがある
③ Blob トリガーを使用する関数アプリがアイドル状態になっている場合、Blob の処理が最大 10 分遅延することがある。
blob トリガーを利用したい場合の方法
Queue トリガーを使用する
Blob とともに Queue に書き込み、Functions からは Queue トリガーを利用する。
→②③ の問題を解決できる。
App Service プランを利用する
→③ の問題を解決できる。
Event Grid や Service Bus の利用を検討する
→①②③ の問題を解決できる。

78. 実行時間の長い関数を使用しない
より小さな関数セットに分割する。
host.json ファイルで functionTimeout 値を変更する
10 分まで増やすことができる。
App Service プランを利用する
専用の VM が割り当てられるため、無制限にできる。
V1 では既定で無制限。
V2 では既定が 30 分に変更されたので注意！host.json で変更する。
タイムアウト
従量課金プランでは、既定では 5 分でタイムアウトする
従量課金プランでは、実行時間が 5 分を経過すると関数の実行はタイムアウトする。
タイムアウトさせない方法

79. エラー処理とリトライ
https://docs.microsoft.com/ja-jp/azure/azure-functions/functions-bindings-error-pages
次のトリガーには、組み込みで再試行（リトライ）の仕組みをサポート
• Azure BLOB Storage
• Azure Queue Storage
• Azure Service Bus (キュー/トピック)
既定の回数分、再試行した場合（全てエラーだった場合）、
これらのトリガーは特別な、有害キュー (Poison Messages) にメッセージを書き込む。
他の Functions トリガーでは、組み込みで仕組みがないため、
Functions アプリケーション内で、必要に応じて try-catch などのエラーハンドリングを行う。

80. マイクロサービス環境でのアプリケーション変更
運用環境ではイベントは停止しない。破壊的な変更に留意する。
Function A
v1
Function B
v1
Queue
format v1
Function A
v2
Function B
v1
Queue
format v2
{“name”: “SmartStore”, “pref”:”Tokyo”}
{“name”: “SmartStore”, “city”:”Tokyo”}
Function B ver 1 は
このフィールドを処理できない
Function A
v1
Function B
v2
Queue
format v1
{“name”: “SmartStore”, “city”:”Tokyo”}
事前に Function B を ver 2 へ
Function A
v2
Function B
v2
Queue
format v2
{“name”: “SmartStore”, “pref”:”Tokyo”}

81. イベント/メッセージングを扱うコンポーネントが多い
正しく使い分ける知識が必要
✔

82. イベント/メッセージングサービスの使い分け
ポイントを以下に抜粋
Azure Event Grid、Event Hubs、Service Bus
Storage キューと Service Bus キューの比較

83. イベント/メッセージングサービスの使い分け
バインディング視点で見ると、（ドキュメント）
Type V1 V2 トリガー 入力バインド 出力バインド
Event Grid ✔ ✔ ✔
Queue Storage ✔ ✔ ✔ ✔
Service Bus ✔ ✔ ✔ ✔
• Event Grid に出力バインドがサポートされていないので、エンキューはライブラリが必要
• Azure CLI、PowerShell、REST、.NET、Java、Python、Node.js

84. イベント/メッセージングサービスの使い分け（料金）
料金単価 5000万操作あたり
Queue Storage
General Purpose v1
（トランザクション最適）
キュー操作 (10,000 回あたり)
LRS、GRS、RA-GRS 共通で
¥0.0404
¥201.60
Queue Storage
General Purpose v2
（ストレージ最適）
キュー操作 (10,000 回あたり)
LRS、GRS、RA-GRS 共通で
¥0.448
¥2,240.00
Service Bus (Basic) 時間料金：0
100万回操作あたり：¥5.60
¥280.00
Service Bus (Standard) 時間料金 730時間：¥1,098.94
¥89.600/100 万操作
¥1,098.94 + 操作分
= ¥4,414.14
Event Grid 100万操作単位：¥67.20 ¥3,353.28

85. Event Grid
クラウドのイベント処理サービス
Blob Storage のイベント ソースを使い、Event Grid
経由でイベントを取得することで、Blob トリガーの問
題が解決できる。
Event Grid の概念
⚫ イベント ソース
イベントの発生場所
⚫ イベント ハンドラー
イベントの送信先
⚫ トピック
発行元がイベントを送信するエンドポイント
⚫ イベント サブスクリプション
イベントをルーティングするエンドポイント
Media Service
Blob Storage
Azure
Subscription
Resource
Group
Event Hubs
IoT Hub
Service Bus
カスタム トピック
Logic Apps
Azure
Functions
Azure
Automation
Webhook
Queue
Storage
ハイブリッド
接続
Event Hubs
イベント ソース
イベント ハンドラー
Event Grid
トピック
イベント
サブスクリプション

86. Event Grid と Azure Functions
Azure Functions の Event Grid Trigger から イベント サ
ブスクリプションの作成が可能

87. イベント サブスクリプションの確認と変更

88. ■Durable Functions ■ ※本コースでは割愛
https://docs.microsoft.com/ja-jp/azure/azure-functions/durable/durable-functions-overview
• 適用できるアプリケーションのパターン
• Durable Functions の 3 つの関数
• アクティビティ関数 (C# クラス ライブラリ)
• オーケストレーター関数 (C# クラス ライブラリ)
• クライアント関数 (C# クラス ライブラリ)
本コースでは割愛いたしますが、
非常に強力な機能ですので、ぜひ参考リンクや配布資料を参照ください。

89. 適用できるアプリケーションのパターン (1)
F1 F2 F3 F4
関数チェーン
特定の順序で関数のシーケンスを実行する
F1
F2
F3
F1
F2
F3
F1 F2 F3 F4
ファンアウト / ファインイン
複数の関数を並列に実行し、すべての関数の完了を待って
別の関数を呼び出す

90. 適用できるアプリケーションのパターン (2)
非同期 HTTP API
ロングランの関数の実行状態を他の関数から取得
Start DoWork
GetStatus
監視
実行時間の長い関数を監視し、関数の状態によって
後続の処理を変える
人による操作
イベントが呼び出されるまで関数の実行を止める

91. Durable Functions の 3 つの関数
クライアント関数
オーケストレーター関数
アクティビティ関数 アクティビティ関数 アクティビティ関数
クライアント関数
• Http や Queue など、トリガーは何でもよい
• OrchestrationClient バインディングを使っ
て、オーケストレーションを作成する
オーケストレーター関数
• アクションが実行される方法や順序を表現する
• OrchestrationTrigger によって始動される
アクティビティ関数
• 基本作業単位。実際の処理を行う。
• ActivityTrigger によって始動される

92. アクティビティ関数 (C# クラス ライブラリ)
[FunctionName("Function1_Hello")]
public static string SayHello([ActivityTrigger] string name, ILogger log)
{
log.LogInformation($"Saying hello to {name}.");
return $"Hello {name}!";
}
トリガーは
ActivityTrigger
アクティビティ関数
の名前

93. オーケストレーター関数 (C# クラス ライブラリ)
[FunctionName("Function1")]
public static async Task<List<string>> RunOrchestrator(
[OrchestrationTrigger] DurableOrchestrationContext context)
{
var outputs = new List<string>();
outputs.Add(await context.CallActivityAsync<string>("Function1_Hello", "Tokyo"));
outputs.Add(await context.CallActivityAsync<string>("Function1_Hello", "Seattle"));
outputs.Add(await context.CallActivityAsync<string>("Function1_Hello", "London"));
return outputs;
}
呼び出すアクティビティ
関数
呼び出す関数名 関数に渡す引数
トリガーは OrchestrationTrigger
オーケストレーター
関数の名前
アクティビティ関数の結果を
リストで返す
オーケストレーター関数に try...catch のエラー処理を
含めることができます。
アクティビティ関数を呼び出すのに使用

94. クライアント関数 (C# クラス ライブラリ)
[FunctionName("Function1_HttpStart")]
public static async Task<HttpResponseMessage> HttpStart(
[HttpTrigger(AuthorizationLevel.Anonymous, "get", "post")]HttpRequestMessage req,
[OrchestrationClient]DurableOrchestrationClient starter,
ILogger log)
{
string instanceId = await starter.StartNewAsync("Function1", null);
log.LogInformation($"Started orchestration with ID = '{instanceId}'.");
return starter.CreateCheckStatusResponse(req, instanceId);
}
バインドは
OrchestrationClient
オーケストレーター関数を
呼び出すために利用
結果と実行状態を取得する
エンドポイントを返すメソッド
オーケストレーター
関数名

95. starter.CreateCheckStatusResponse() の結果
実行結果や実行を管理する URL を取得する
ロングランの関数の実行状態を他の関数から取得
starter.WaitForCompletionOrCreateCheckStatusResponseAsync
オーケストレーターの実行結果を API のレスポンスとして返したいときに使用
項目 説明
id オーケストレーターのインスタンス ID
statusQueryGetUri 実行状態と結果を取得する URL
sendEventPostUri イベントを発生させる URL
terminatePostUri 実行を終了させる URL
rewindPostUri 失敗したオーケストレーターを再実行する URL
完了実行中 失敗

96. リファレンス アーキテクチャ
第 3 章

97. docs.azure.com: サーバーレス Web アプリケーション
URL: docs , GitHub

98. docs.azure.com: サーバーレスなイベント処理
URL: docs , GitHub

100. POS
顧客用アプリ
Android/iOS
Box状態管理
1.ボックスオープン
2.商品取り出し
3.ボックスクローズ
IoT Hub
統合商品マスタ
Azure Functions
Cosmos
DB
Blob
商品API
商品データ 商品イメージ
リアルタイム在庫管理
Azure Functions
Azure FunctionsSQL DB
Cosmos
DB
在庫トランAPI 在庫イベントソース
在庫データマート 在庫モニターAPI
顧客
バックオフィス
Azure Functions
バックオフィス用BFF
Android/iOS
Webモニター
Azure Functions
顧客アプリ用BFF
Box
Azure Functions
Push通知
ショッピングカートAPI
商品登録一覧
レシート
買物開始
Boxオープン状態
商品変動状態
Boxクローズ状態
Box状態
プッシュ情報送信
モバイルデバイスへの通知
在庫情報参照
在庫情報取得
商品情報取得
商品情報取得
在庫トラン
カートAPI呼び出し
BFF呼び出し
Azure Functions
Cosmos
DB
各種データ
カートAPI
サンプル実装：Smart Box（アーキテクチャ）

101. Smart Storeプラットフォームにクラウドを選ぶ理由(1)
✓ スピード
これまでは機器設備の調達や設置に多くの日数を要するため、事前に入念な計画が必要でした。クラウドの最大のメ
リットは、最小限の準備で「すぐに」実行できるスピードにあります。店舗数や来店客数、品数や在庫量・流通量などの
データ変動量の予測が困難になっている現在、フェイルファスト（行動学習）可能な環境は何よりも強い武器になりま
す。
✓ スケーラビリティ
将来のデータの変動量の予測が難しい現状では、例えば3年後に必要になるサーバーやストレージのサイズを予想する
ことに意味はありません。必要なのは「必要な時に必要なだけ拡張/縮小できるリソース」です。クラウドは、無駄な資
源とともに無駄な検討時間も減らしてくれます。
✓ 高い保守性
オンプレでは最小限の物理機器で動作するため、店舗新規開設時やメンテナンス時の「取り回し」の軽さとともに、デー
タセンター側の冗長化や多重化などの災害対策環境も容易に構成できる能力が得られます。

102. Smart Storeプラットフォームにクラウドを選ぶ理由(2)
✓ アクセス性の向上
クラウドではパブリックかつ無尽蔵のリソースを利用できるようになることで、場所と時間を問わずリソースにアクセスする
ことができます。また、これまでインターネット経由のチャネル利用には自社ネットワークの増強が不可欠でしたが、プラッ
トフォームにクラウドを選択することで、最初からストレスのない帯域が手に入ります。
✓ セキュリティ
業務プラットフォームにクラウドを利用する際の最大の障壁がセキュリティでした。自社データセンターと専用線接続の
みで構成された環境はセキュリティ面で最も強固です。しかし、現在のリテールシステムはインターネットと切り離して考
えることはできない状況になりつつあります。一方で、クラウドシステムは全てソフトウェアで構成されています、高価な
ファイアウォールもクラウドであれば全てのエンドポイントに配置することも可能です。これまでのデータセンターでは考えら
れなかった強固なセキュリティをクラウドでは実現することができるのです。

103. マイクロサービスの採用
✓ ビジネス機能を一定の単位でカプセル化し、サービス間を疎結合に保つ設計手法
✓ 個々のサービスを、それぞれのビジネス機能に求められる非機能要件を適用できる
✓ ビジネスの規模や成長ステージに合わせて、個々のサービス毎に拡張、更新、スケールが可能となる
✓ それぞれのサービスに適したテクノロジーを個別に適用することができる
商品マスタサービス
POSサービス BOX管理サービス
在庫管理サービス
利用者向け
アプリ用サービス
管理者向け
Web用サービス
ビジネス機能単位で
サービスを分割
サービス間は疎結合に保ち
独立して追加・更新可能に
サービスの処理特性に応じて
個々にテクノロジーを適用
サービス毎の非機能要件に
合わせて、デプロイ・スケール
が可能
マイクロサービスの特徴と利点

104. 全体構成図 概要
✓サーバーレスコンピューティングサービス として Azure Functions を採用し、リソースの柔軟なスケールを実現します。
✓マイクロサービスアーキテクチャ をベースとしたサービス設計によりサービス間の疎結合性を確保します。
BFFサービス群 バックエンドサービス群
商品マスタサービス
商品照会API
商品更新API
POSサービス
カートAPI
決済API
BOX管理サービス
Box開閉API
商品追跡API
在庫管理サービス
在庫トランAPI
在庫照会API
利用者向け
アプリ用BFF
管理者向け
Web用BFF
クライアントApp
（Xamarin）
管理用Web
（Web App）
Application
Insights
分散トレーシングによる
マイクロサービス監視
マイクロサービスによる
疎結合なサービス間連携
BFFによるフロントエンド
の柔軟性確保
Azure Functions による
サーバーレスコンピューティング

105. ✓ Smart Box の状態監視に、Azure Functions の Durable Function モニターパターンを採用します。
✓ Smart Box の状態変化に伴うカートの変更を即時にアプリに反映するため、 App Center Push を採用します。
✓ 取引操作を Web API として実装します。
Azure Cosmos
DB
Azure Functions
取引操作を
API で提供
IoT Edge IoT Hub
アプリ
App Center Push
Smart Box →クラウドへのメッセージ
・鍵の開錠
クラウド→ Smart Box へのメッセージ
・在庫情報、差分情報
Azure Functions
Durable Function で
ステートフルに Smart
Box の状態を監視
POSサービス
プッシュ通知により取引状
態変化を反映
Smart Box BOX管理サービス
BOX 管理サービス – 概要

106. ✓ Azure Functions の Durable Functions を利用してステートフルなワークフロー処理
✓ モニターパターンを利用し、特定の条件が満たされるまで待機します。
✓ IoT Hub を経由した Smart Box との連携
✓ Smart Box からのメッセージ受信は IoT Hub を経由し、Event Hub Trigger により BOX管理サービスの
Azure Functions で受け付けます。
✓ Smart Box へのメッセージ送信は、 Azure IoT Hub サービス SDKを使用し送信します。
✓ POSサービス連携
✓ POSサービスの Web API を使用して、Smart Box の状態からカート操作や決済処理を行います。
✓ アプリとの連携
✓ 取引作成、情報取得のために、Web API を提供します。
✓ App Center Push を用いて、即座に取引の状態を通知します。
BOX 管理サービス – 主な機能と特長

107. まとめ

108. まとめ
第 1 章サーバーレスと Microsoft Azure
⚫ サーバーレスのメリット
第 2 章 Azure Functions
⚫ 関数アプリの作成方法
⚫ トリガー、バインドの利用方法
⚫ Azure Functions の考慮事項
第 3 章 リファレンスアーキテクチャ
⚫ サーバーレス Web アプリケーション
⚫ サーバーレスなイベント処理
⚫ Azure Functions のエラー処理

109. Microsoft Learn
Azure Functions のコースが追加されました！
https://docs.microsoft.com/ja-jp/learn/
• アカウント不要で 無料のサンドボックスを利用
サーバーレス アプリケーションの作成
• Azure Functions を使用したサーバーレス ロジック
の作成
• トリガーを使用して Azure 関数を実行する
• 入力バインディングと出力バインディングを使用して
Azure 関数を連結する

110. ◼ 本書に記載した情報は、本書各項目に関する発行日現在の Microsoft の見解を表明するものです。Microsoftは絶えず変化する市場に対応しなければならないため、
ここに記載した情報に対していかなる責務を負うものではなく、提示された情報の信憑性については保証できません。
◼ 本書は情報提供のみを目的としています。 Microsoft は、明示的または暗示的を問わず、本書にいかなる保証も与えるものではありません。
◼ すべての当該著作権法を遵守することはお客様の責務です。Microsoftの書面による明確な許可なく、本書の如何なる部分についても、転載や検索システムへの格納または挿入を行うことは、どのような形式または手段（電子的、機械的、複
写、レコーディング、その他）、および目的であっても禁じられています。
これらは著作権保護された権利を制限するものではありません。
◼ Microsoftは、本書の内容を保護する特許、特許出願書、商標、著作権、またはその他の知的財産権を保有する場合があります。Microsoftから書面によるライセンス契約が明確に供給される場合を除いて、本書の提供はこれらの特許、商
標、著作権、またはその他の知的財産へのライセンスを与えるものではありません。
© 2019 Microsoft Corporation. All rights reserved.
Microsoft, Windows, その他本文中に登場した各製品名は、Microsoft Corporation の米国およびその他の国における登録商標または商標です。
その他、記載されている会社名および製品名は、一般に各社の商標です。