20190514 Smart Store - Azure servlerless architecture

Azure
Smart Store
サーバーレスアーキテクチャ
Issei Hiraoka / @hoisjp
Cloud Solution Architect – Microsoft Japan
2019/05/14

レベル 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概要解説
提供
予定
本コース

レベル、目標、対象者、前提知識、および注意事項
レベル
⚫ 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) を確認してください。

本コースの内容
第 1 章サーバーレスと Microsoft Azure
第 2 章 Azure Functions
第 3 章参照アーキテクチャ

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

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

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

インフラの効率化から、アプリケーションのイノベーションへビジネス価値
時間
効率
イノベーション
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

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

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 開発者ツール

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

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

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

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

アーキテクチャ
Azure App Service と WebJobs が基盤
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

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

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

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

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

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 では、各関数で言語を選択することができます。

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

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

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

サポートされるトリガーとバインド (参考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 ✔ ✔ ✔

C# スクリプト C# (クラスライブラリ)
プロジェクトのフォルダー構造 (C#)
関数アプリ
関数
MyFunctionProject
bin
run.csx
function.json
MyFunction1
host.json
extensions.csproj
C# スクリプトコード
バインディング
拡張機能定義
トリガーとバインドの定義
関数
run.csx
function.json
MyFunction2
拡張機能
ライブラリ
関数アプリ全体の構成
関数アプリ
関数
netcoreapp2.x
bin
function.json
MyFunction1
host.json
extensions.csproj
拡張機能定義
アセンブリ、
バインディング拡張機能
ライブラリ
関数アプリ全体の構成
関数
function.json
MyFunction2

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

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 への
接続文字列
トリガーやバインドの種類により、設定するプロパティは異なります。

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

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

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

バインディング拡張機能の登録
トリガーとバインディングは、「バインディング拡張機能」を必要とする
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 パッケージの管理

タイマートリガー
スケジュールに基づいて関数をよびだすことができるトリガー。スケジュールは 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 * * * *
秒分時日月曜日
タイマートリガーは、関数の途中で失敗しても再試行されず、
次のスケジュールを待ちます。

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」すると、戻り値として指定し
た値が応答として送信される。

承認レベル
関数を呼び出す際に、キーを必要とするかどうかを設定できる。
HTTP エンドポイントを難読化するために利用する。
キーの種類
承認レベルと必要なキー
承認レベルの設定 URL
anonymous https://<関数アプリ名>.azurewebsites.net/api/<関数名>
function https://<関数アプリ名>.azurewebsites.net/api/<関数名>?code=<関数キー>
または
https://<関数アプリ名>.azurewebsites.net/api/<関数名>?code=<ホストキー>
admin https://<関数アプリ名>.azurewebsites.net/api/<関数名>?code=<_master キー>
キーの種類説明
関数キー各関数でのみ有効なキー。
ホストキー関数アプリ内のすべての関数で有効なキー。「_master」という名
前のホストキーは、管理アクセスのために利用する。

URL
https://mstep-functions2.azurewebsites.net/api/customer/Tanaka
HTTP エンドポイントのカスタマイズ
HTTP エンドポイントの route プロパティを設定することで、関数のアドレスを変更することができる。
{ } を使ったパラメーターもサポートされる。
function.json
{
"authLevel": "function",
"name": "req",
"type": "httpTrigger",
"direction": "in",
“methods”: [ "get", "post" ],
"route": "customer/{name}"
}
run.csx
public static string Run( HttpRequest req,
string name ,
ILogger log)
{
return $"hello, {name} ";
}
パラメーター
引数

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
デバイスからのデータ収集データを加工
デバイス
データを保存

Cosmos DB バインド - C# スクリプト
Cosmos DB への入力・出力バインドがサポートされる
function.json
{
"type": "cosmosDB",
"name": "$return",
"databaseName": "mstepDB",
"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 に
追加

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 属性を使用
接続先などの
パラメータ値の実体は変数
代入されている
値の取り出し

Cosmos DB バインド – 入力 C# クラスライブラリ
{
public static class DocByIdFromJSON
{
[FunctionName("DocByIdFromJSON")]
public static void Run(
[QueueTrigger("todoqueueforlookup")] ToDoItemLookup toDoItemLookup,
[CosmosDB(
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 属性を使用
接続先などの
パラメータ
値の実体は変数
代入されている

Cosmos DB バインド – 出力 C# クラスライブラリ
キュートリガー、1 つのドキュメントの書き込み
{
public static class WriteOneDoc
{
[FunctionName("WriteOneDoc")]
public static void Run(
[QueueTrigger("todoqueueforwrite")] string queueMessage,
[CosmosDB(
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に書き込み

参考：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 での
開発も可能

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

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 から入手することもできます。

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

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

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 上の既存の関数アプリへの発行

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

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

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# クラスライブラリの区別に注意

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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 の利用を検討する
→①②③ の問題を解決できる。

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

マイクロサービス環境でのアプリケーション変更
運用環境ではイベントは停止しない。破壊的な変更に留意する。
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”}

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
トピック
イベント
サブスクリプション

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

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

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

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

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

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

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

オーケストレーター関数 (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 のエラー処理を
含めることができます。
アクティビティ関数を呼び出すのに使用

クライアント関数 (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
オーケストレーター関数を
呼び出すために利用
結果と実行状態を取得する
エンドポイントを返すメソッド
オーケストレーター
関数名

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

参照アーキテクチャ
第 3 章

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

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

Azure Functions のエラー処理
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 などのエラーハンドリングを行う。

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

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

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

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

20190514 Smart Store - Azure servlerless architecture

Recommended

Recommended

More Related Content

What's hot

What's hot (20)

Similar to 20190514 Smart Store - Azure servlerless architecture

Similar to 20190514 Smart Store - Azure servlerless architecture (20)

More from Issei Hiraoka

More from Issei Hiraoka (20)

Recently uploaded

Recently uploaded (9)

20190514 Smart Store - Azure servlerless architecture