WEBVTT

00:00:00.000 --> 00:00:03.640
今日のトピックは誰もが一度は耳にしたことがあってもほとんど誰も説明できないものです

00:00:03.640 --> 00:00:07.660
サーバーレス一体何なのでしょうか単に何もないところでコードが動いているだけなのでしょうか

00:00:07.660 --> 00:00:10.400
それとももっと大きな何かがあるのでしょうかはっきりさせておきましょう

00:00:10.400 --> 00:00:12.580
サーバーレスとはサーバーがないという意味ではありません

00:00:12.580 --> 00:00:16.480
サーバーのことを考えなくて良いという意味でありその違いがソフトウェア構築のあり方を一変させるのです

00:00:16.480 --> 00:00:21.740
このエピソードを最後まで見ればAzure Functionsの正体実際の料金体系そしていつ使うべきかが理解できるはずです

00:00:21.740 --> 00:00:25.060
最大の誤解から始めて構成要素ごとに分解していきましょう

00:00:25.060 --> 00:00:29.000
サーバーレスの本当の意味とはいくつかの誤解をすぐに解いておきましょう

00:00:29.000 --> 00:00:32.300
サーバーレスという名称はマイクロソフトが考えた中で最悪のマーケティング用語です

00:00:32.300 --> 00:00:34.560
サーバーが文字通り存在しないかのような印象を与えてしまいます

00:00:34.560 --> 00:00:37.720
それは間違いですサーバーは存在しますそれも大量に

00:00:37.720 --> 00:00:39.620
ただ私たちが触れる必要が一切ないだけです

00:00:39.620 --> 00:00:43.020
20年前インターネット上でコードを動かそうと思ったら膨大な作業が必要でした

00:00:43.020 --> 00:00:47.740
仮想マシンを借りOSをインストールしウェブサーバーを設定してアプリケーションをデプロイするのです

00:00:47.740 --> 00:00:52.100
そして毎週末セキュリティパッチを当てたり深夜3時にシステムが落ちないよう見守ったりしていました

00:00:52.100 --> 00:00:56.380
それにこれを聞いてくださいコードが動いていようがいまいがサーバー代は支払わなければなりませんでした

00:00:56.380 --> 00:00:59.380
サーバーは眠っている間もずっと稼働しお金を浪費し続けていたのです

00:00:59.380 --> 00:01:01.660
サーバーレスはこのモデルを根元から覆します

00:01:01.660 --> 00:01:05.220
コードを書いてアップロードすればあとはプラットフォームがすべて処理してくれます

00:01:05.220 --> 00:01:11.340
OSの管理セキュリティパッチスケーリング可用性まであなたの仕事は重要なロジックを書くことだけです

00:01:11.340 --> 00:01:15.480
レストランの厨房を運営することと自動販売機を使うことの違いだと考えてみてください

00:01:15.480 --> 00:01:19.620
レストランの厨房にはスタッフ絶え間ない食材の補充メンテナンスが必要です

00:01:19.620 --> 00:01:22.540
客が一人も来なくても毎日コストがかかります

00:01:22.540 --> 00:01:26.800
一方自動販売機は誰かがボタンを押すまで隅でじっとしています

00:01:26.800 --> 00:01:29.780
ボタンが押されると動き出し仕事を終えるとまた眠りにつきます

00:01:29.780 --> 00:01:32.320
実際に動いている時だけ電気代を払えば良いのです

00:01:32.320 --> 00:01:36.360
それがサーバーレスの真髄ですAzure Functionsはこの仕組みに対するマイクロソフトの回答です

00:01:36.360 --> 00:01:38.720
イベントに応じて小さなコード断片を実行します

00:01:38.720 --> 00:01:42.740
コードは何かに呼び起こされるまでは休止しており実行が終わればまた眠りにつきます

00:01:42.740 --> 00:01:45.220
では実際のコードはどのようなものなのでしょうか

00:01:45.220 --> 00:01:49.860
Azure Functionsの正体関数とは特定の仕事を一つだけこなすコードの断片のことです

00:01:49.860 --> 00:01:54.180
それだけですログイン画面やデータベース20もの画面を持つようなアプリケーション全体ではありません

00:01:54.180 --> 00:01:56.140
一つの目的に特化したタスクなのです

00:01:56.140 --> 00:01:58.300
家の照明のスイッチを想像してみてください

00:01:58.300 --> 00:02:01.460
オンになると動き出し仕事が終わればまたオフになります

00:02:01.460 --> 00:02:08.120
従来のウェブサーバーはその逆で誰もいない家で24時間365日全ての電気をつけっぱなしにしているようなものです

00:02:08.120 --> 00:02:11.360
Azure Functionsは様々なプログラミング言語をサポートしています

00:02:11.360 --> 00:02:15.500
JavaScript、Python、C Sharp、Java、PowerShellなど使い慣れた言語を選べます

00:02:15.500 --> 00:02:16.960
正解は一つではありません

00:02:16.960 --> 00:02:18.700
すでに知っている言語を選びましょう

00:02:18.700 --> 00:02:20.700
ここでよくある混乱を解消しておきましょう

00:02:20.700 --> 00:02:23.240
関数アプリと関数、ファンクションは同じものではありません

00:02:23.240 --> 00:02:25.200
関数アプリとはコンテナのようなものです

00:02:25.200 --> 00:02:26.620
道具箱を想像してください

00:02:26.620 --> 00:02:30.120
まず関数アプリという一つの道具箱を作りその中に複数の関数を追加していきます

00:02:30.120 --> 00:02:32.940
各関数はそれぞれの仕事をするための個別の道具です

00:02:32.940 --> 00:02:38.520
例えばユーザー登録を処理する関数、アップロードされた画像を処理する関数、夜間にレポートを送信する関数などがあります

00:02:38.520 --> 00:02:41.560
それらはすべて同じ道具箱に入っていますが個別に動作します

00:02:41.560 --> 00:02:44.400
関数についてもう一つこれらは設計紙ステートレスです

00:02:44.400 --> 00:02:46.880
つまり実行の合間に情報を保持することはありません

00:02:46.880 --> 00:02:49.600
関数がファイルを処理して終了すればそこで終わりです

00:02:49.600 --> 00:02:52.740
次に実行されるときは前回の記憶がない状態でゼロから開始されます

00:02:52.740 --> 00:02:56.400
制限のように聞こえますが実はこれこそが関数を強力にしている機能なのです

00:02:56.400 --> 00:03:03.420
関数はメモリや状態を保持しないためトラフィックが急増すればアジュールが瞬時に100個のコピーを立ち上げ減少すれば素早くシャットダウンできます

00:03:03.420 --> 00:03:07.020
これこそがアイドル状態のサーバーにコストをかけずにスケーラビリティを実現する方法です

00:03:07.020 --> 00:03:08.060
ここで疑問です

00:03:08.060 --> 00:03:11.800
何かが起動させるまで何もしない関数は一体何が起動させているのでしょうか

00:03:11.800 --> 00:03:13.600
そこで登場するのがトリガーです

00:03:13.600 --> 00:03:15.640
トリガーとはいつ実行するかを決めるものです

00:03:15.640 --> 00:03:18.460
全ての関数には必ず一つのトリガーが必要でこれは必須の設定です

00:03:18.460 --> 00:03:20.740
トリガーは関数を呼び起こすイベントのことです

00:03:20.740 --> 00:03:23.400
トリガーがなければコードは何もせずに待機しているだけです

00:03:23.400 --> 00:03:25.320
トリガーを玄関の予備輪に例えてみましょう

00:03:25.320 --> 00:03:27.080
関数は家の中で待機しています

00:03:27.080 --> 00:03:28.720
いつまでも待ち続けることができます

00:03:28.720 --> 00:03:31.020
誰かが予備輪を鳴らすまでは何も起こりません

00:03:31.020 --> 00:03:34.980
予備輪が鳴ると関数が動き出しドアを開けて仕事をこなしまた待機状態に戻ります

00:03:34.980 --> 00:03:37.580
初心者が最もよく遭遇するトリガーは4つあります

00:03:37.580 --> 00:03:40.660
httpトリガーが最も一般的な出発点です

00:03:40.660 --> 00:03:44.260
誰かがurlにアクセスしたりapiを呼び出したりすると関数が起動します

00:03:44.260 --> 00:03:48.040
これを利用すればフルスペックのwebサーバーを構築せずに軽量なapiを作成できます

00:03:48.040 --> 00:03:51.140
次にスケジュールに従って実行されるタイマートリガーがあります

00:03:51.140 --> 00:03:55.880
クローン式を設定して1時間ごとや毎晩深夜0時といった時間を指定すれば

00:03:55.880 --> 00:03:57.820
そのタイミングで関数が実行されます

00:03:57.820 --> 00:04:01.820
メンテナンス作業やクリーンアップジョブ夜間レポートの生成などに最適です

00:04:01.820 --> 00:04:05.180
ブロブトリガーはファイルがazureストレージにアップロードされたときに起動します

00:04:05.180 --> 00:04:08.060
例えば誰かが特定のフォルダにpdfをアップロードしたとします

00:04:08.060 --> 00:04:11.380
ブロブトリガーがそのアップロードを検知し自動的に関数を実行します

00:04:11.380 --> 00:04:14.980
これは画像処理やドキュメント変換ファイルの検証などに非常に役立ちます

00:04:14.980 --> 00:04:17.980
そしてqトリガーはqにメッセージが届いたときに起動します

00:04:17.980 --> 00:04:20.920
qはシステムの各パーツを素結合にするための手段です

00:04:20.920 --> 00:04:25.240
あるサービスがqにメッセージを入れれば関数がそれを受け取り準備ができたときに処理します

00:04:25.240 --> 00:04:28.480
これにより一つの遅いサービスが他のすべてをブロックするのを防げます

00:04:28.480 --> 00:04:30.100
ここが重要なポイントです

00:04:30.100 --> 00:04:33.400
トリガーが起動するとデータが自動的に関数へ渡されます

00:04:33.400 --> 00:04:36.280
ポーリングしたり何かが起きたかを確認したりする必要はありません

00:04:36.280 --> 00:04:39.500
トリガーが必要なものすべてを提供してくれるので関数はそれを処理するだけです

00:04:39.500 --> 00:04:42.380
トリガーのない関数は何もせずにただそこに存在するコードにすぎません

00:04:42.380 --> 00:04:44.500
トリガーこそが関数に目的を与えるのです

00:04:44.500 --> 00:04:46.740
つまりトリガーは関数に実行タイミングを伝えます

00:04:46.740 --> 00:04:49.080
ではデータはどこから来てどこへ行くのでしょうか

00:04:49.080 --> 00:04:50.860
そこで登場するのがバインディングです

00:04:50.860 --> 00:04:53.280
バインディングはデータの入出力を担います

00:04:53.280 --> 00:04:56.660
バインディングを使えば余計なコードを書かずにどのデータを読み込み

00:04:56.660 --> 00:04:58.360
どこに結果を送るかを関数に指定できます

00:04:58.360 --> 00:05:00.660
少しややこしいので簡単に説明しましょう

00:05:00.660 --> 00:05:01.840
2種類存在します

00:05:01.840 --> 00:05:04.160
入力バインディングはデータを関数に取り込みます

00:05:04.160 --> 00:05:06.540
出力バインディングはデータを外へ送り出します

00:05:06.540 --> 00:05:09.160
バインディングがなければストレージアカウントやデータベース

00:05:09.160 --> 00:05:11.840
Qと通信するたびにSDKコードを書く必要があります

00:05:11.840 --> 00:05:13.580
接続文字列の管理やリトライ処理

00:05:13.580 --> 00:05:14.640
データのシリアライズ

00:05:14.640 --> 00:05:16.340
レスポンスのデシリアライズが必要です

00:05:16.340 --> 00:05:17.600
たった一つのファイルを読み込むために

00:05:17.600 --> 00:05:19.240
大量の提携コードが必要になってしまいます

00:05:19.240 --> 00:05:21.420
バインディングを使えば必要なものを宣言するだけで済みます

00:05:21.420 --> 00:05:23.500
このブログコンテナから読み込みたいと指定するだけです

00:05:23.500 --> 00:05:25.640
あるいはこのQに書き込みたいといった具合です

00:05:25.640 --> 00:05:27.460
残りの処理はランタイムが言ってくれます

00:05:27.460 --> 00:05:31.140
接続を開きデータを読み込みパラメータとして関数に渡してくれます

00:05:31.140 --> 00:05:33.660
関数が終了すると戻り値を受け取り

00:05:33.660 --> 00:05:35.180
指定した場所に書き込んでくれます

00:05:35.180 --> 00:05:37.480
バインディングはパイプのようなものだと考えてください

00:05:37.480 --> 00:05:40.540
関数をストレージアカウントやデータベースQに接続します

00:05:40.540 --> 00:05:43.060
データはそれらのパイプを通って自動的に流れます

00:05:43.060 --> 00:05:45.400
関数はパイプの仕組みを知る必要はありません

00:05:45.400 --> 00:05:48.120
流れてきたものを受け取り送るべきものを送り出すだけです

00:05:48.120 --> 00:05:49.660
具体的な例を見てみましょう

00:05:49.660 --> 00:05:51.820
ブロブ入力バインディングがある場合で説明します

00:05:51.820 --> 00:05:54.620
関数が開始されるとブロブストレージからファイルが自動的に読み込まれ

00:05:54.620 --> 00:05:55.660
パラメータとして渡されます

00:05:55.660 --> 00:05:57.860
ストレージのSDKコードを書く必要はありません

00:05:57.860 --> 00:05:59.620
データを受け取って処理するだけです

00:05:59.620 --> 00:06:01.820
別の例としてQの出力バインディングがあります

00:06:01.820 --> 00:06:04.900
関数で何らかの処理を行い最後に値を返すだけです

00:06:04.900 --> 00:06:07.800
ランタイムがその値を受け取りシリアル化してQに格納します

00:06:07.800 --> 00:06:09.680
Qを操作するコードを書く必要はありません

00:06:09.680 --> 00:06:11.120
値を返すだけでいいのです

00:06:11.120 --> 00:06:12.480
バインディングはオプションです

00:06:12.480 --> 00:06:14.580
0個でも1個でも複数でも構いません

00:06:14.580 --> 00:06:17.340
トリガーだけでバインディングを一切必要としない関数もあります

00:06:17.340 --> 00:06:20.640
逆に異なるサービスに接続するバインディングを3つや4つ持つものもあります

00:06:20.640 --> 00:06:24.020
トリガーとバインディングの組み合わせこそがAzure Functionsを強力にしているのです

00:06:24.020 --> 00:06:27.260
あなたはビジネスロジックつまり実際の意思決定を行うコードを書くだけです

00:06:27.260 --> 00:06:29.560
統合に関連する処理はすべてプラットフォームが担います

00:06:29.560 --> 00:06:33.300
そのため関数は小さく焦点を絞った理解しやすい状態にもたれます

00:06:33.300 --> 00:06:34.820
次は料金についてです

00:06:34.820 --> 00:06:37.420
この料金体系はほとんどの初心者を驚かせます

00:06:37.420 --> 00:06:40.400
多くの場合消費プランコンサンプションプランがデフォルトの選択肢であり

00:06:40.400 --> 00:06:41.940
9割のケースでこれから始めるべきです

00:06:41.940 --> 00:06:42.920
仕組みはこうです

00:06:42.920 --> 00:06:45.380
関数が実際に実行された時だけ料金が発生します

00:06:45.380 --> 00:06:47.380
アイドル状態であれば料金はかかりません

00:06:47.380 --> 00:06:48.840
0、1000もかかりません

00:06:48.840 --> 00:06:50.920
料金は2つの要素で構成されます

00:06:50.920 --> 00:06:54.120
1つ目は実行数つまり関数が何回起動したかです

00:06:54.120 --> 00:06:57.700
2つ目は実行時間でギガバイト秒という単位で計測されます

00:06:57.700 --> 00:07:01.360
これは基本的に関数の実行時間に使用メモリ量を掛け合わせたものです

00:07:01.360 --> 00:07:03.140
無料枠は非常に寛大です

00:07:03.140 --> 00:07:07.220
毎月100万回の実行と40万ギガバイト秒までが完全に無料です

00:07:07.220 --> 00:07:10.060
ほとんどの小規模プロジェクトやホビーアプリ、プロトタイプであれば

00:07:10.060 --> 00:07:11.160
費用は一切かかりません

00:07:11.160 --> 00:07:12.480
一生無料です

00:07:12.480 --> 00:07:15.060
もし無料枠を超えても料金は驚くほど安価です

00:07:15.060 --> 00:07:16.780
100万回実行あたり20セントです

00:07:16.780 --> 00:07:17.880
タイプミスではありません

00:07:17.880 --> 00:07:19.800
100万回の実行でわずか20セントです

00:07:19.800 --> 00:07:22.460
スイッチを入れた時だけ電気代を払うようなものだと考えてください

00:07:22.460 --> 00:07:25.400
壁の中の配線に対して月額の基本料金を払う必要はありません

00:07:25.400 --> 00:07:27.540
実際に使用した電力分だけを支払うのです

00:07:27.540 --> 00:07:29.260
さて他のプランも存在します

00:07:29.260 --> 00:07:32.020
フレックスコンサンプションは比較的新しく仮想ネットワークをサポートしています

00:07:32.020 --> 00:07:35.260
プレミアムは関数を常にオウム状態に保つためコールドスタートによる遅延がありません

00:07:35.260 --> 00:07:38.400
デリケーテッドは従来のアップサービスプランで固定容量を提供します

00:07:38.400 --> 00:07:41.540
しかしまずはコンサンプションプランを選択するのがほとんどの場合において最適です

00:07:41.540 --> 00:07:43.140
ただし一つ注意点があります

00:07:43.140 --> 00:07:46.300
無料枠は同じサブスクリプション内の全ての関数アプリで共有されます

00:07:46.300 --> 00:07:49.920
もし10個の関数アプリがあればそれら全てが同じ100万回の無料枠を分け合うことになります

00:07:49.920 --> 00:07:52.880
そのためアプリを複数作り始める場合はその点に注意してください

00:07:52.880 --> 00:07:54.280
料金は素晴らしいですよ

00:07:54.280 --> 00:07:56.580
では具体的な例を挙げてみていきましょう

00:07:56.580 --> 00:07:58.100
現実世界のシナリオです

00:07:58.100 --> 00:08:01.060
ユーザーがプロフィール写真をアップロードするウェブサイトを運営していると想像してください

00:08:01.060 --> 00:08:03.860
それらの画像が1枚10MBもあるような巨大なものだとします

00:08:03.860 --> 00:08:06.160
するといくつか深刻な問題が発生します

00:08:06.160 --> 00:08:07.840
大きなファイルはストレージ費用がかさみ

00:08:07.840 --> 00:08:10.140
ページを読み込むたびにサイトの表示速度が低下し

00:08:10.140 --> 00:08:12.660
写真の読み込みを待たされるユーザーをイライラさせてしまいます

00:08:12.660 --> 00:08:15.920
そこで画像を自動的に縮小する方法が必要になります

00:08:15.920 --> 00:08:19.960
Azure Functionsを使わなければバックグラウンドで動作するワーカーをゼロから構築しなければなりません

00:08:19.960 --> 00:08:23.560
つまり別のサーバーを用意しワークロードを管理するキューを設定し

00:08:23.560 --> 00:08:25.920
複雑な処理を行うコードを書く必要があるのです

00:08:25.920 --> 00:08:29.500
画像の縮小という単純な作業にしてはあまりにも複雑すぎます

00:08:29.500 --> 00:08:33.380
Azure Functionsなら必要なのは一つのブロブトリガーと一つの関数だけです

00:08:33.380 --> 00:08:35.320
サーバーを管理する心配もありません

00:08:35.320 --> 00:08:36.840
仕組みを説明しましょう

00:08:36.840 --> 00:08:38.880
ユーザーがウェブサイトから写真をアップロードすると

00:08:38.880 --> 00:08:40.920
そのファイルがAzureブロブストレージに保存されます

00:08:40.920 --> 00:08:43.880
ファイルが保存された瞬間ブロブトリガーが自動的に起動します

00:08:43.880 --> 00:08:45.980
関数が動作して圧縮コードを実行し

00:08:45.980 --> 00:08:48.080
縮小されたバージョンをストレージに保存します

00:08:48.080 --> 00:08:50.300
これらすべてが数秒のうちに完了します

00:08:50.300 --> 00:08:53.060
この処理はすべてバックグラウンドで目に見えない形で行われるため

00:08:53.060 --> 00:08:54.660
ユーザーが待たされることはありません

00:08:54.660 --> 00:08:56.680
もう一つ日常的な例を挙げます

00:08:56.680 --> 00:08:59.120
サービス登録時のウェルカムメール送信です

00:08:59.120 --> 00:09:02.260
httpトリガーがウェブサイトからの登録リクエストをキャッチします

00:09:02.260 --> 00:09:04.480
関数が起動してユーザーのメールアドレスを取得し

00:09:04.480 --> 00:09:06.940
センドグリッド経由でウェルカムメールを送信して完了です

00:09:06.940 --> 00:09:09.000
ユーザーはほぼ瞬時にメールを受け取ります

00:09:09.000 --> 00:09:11.640
メールサーバーの設定も送信級の管理も不要

00:09:11.640 --> 00:09:14.220
一つの関数で一つの仕事を完了するだけです

00:09:20.300 --> 00:09:22.660
ワークフローではなく何かのきっかけで起動し

00:09:22.660 --> 00:09:24.440
特定の処理を的確に行うためのものです

00:09:24.440 --> 00:09:26.640
アジュールファンクションズはいつ使うべきでしょうか

00:09:26.640 --> 00:09:30.000
ではいつ関数を選択しいつ別の手段を使うべきなのでしょうか

00:09:30.000 --> 00:09:31.820
判断するための簡単な基準があります

00:09:31.820 --> 00:09:34.240
そのタスクが短時間で終わりイベント駆動型であり

00:09:34.240 --> 00:09:36.080
ステートレスであるかどうかを自問してみてください

00:09:36.080 --> 00:09:39.680
すべてイエスならアジュールファンクションズが最適なツールです

00:09:39.680 --> 00:09:41.940
まずは適したユースケースから見ていきましょう

00:09:41.940 --> 00:09:44.440
APIやWebhookは完璧な組み合わせです

00:09:44.440 --> 00:09:47.100
httpリクエストに応答して一つの処理を行い

00:09:47.100 --> 00:09:49.600
結果を返す軽量なエンドポイントが必要な場合

00:09:49.600 --> 00:09:51.780
まさにhttpトリガーがうってつけです

00:09:51.780 --> 00:09:54.240
ファイルや画像の処理も重要なユースケースです

00:09:54.240 --> 00:09:56.440
ファイルがストレージに保存されると関数が起動し

00:09:56.440 --> 00:09:57.760
処理して結果を保存する

00:09:57.760 --> 00:09:59.920
これらすべてがサーバーレスで実現できます

00:09:59.920 --> 00:10:03.140
夜間のクリーンアップやレポート生成のような定期的なタスクには

00:10:03.140 --> 00:10:04.700
タイマートリガーが最適です

00:10:04.700 --> 00:10:07.880
ETLパイプラインのためのデータ変換もよくある用途です

00:10:07.880 --> 00:10:09.780
またファンクションズは本来連携しない

00:10:09.780 --> 00:10:12.900
2つのサービスを接続する統合の接着剤としても完璧です

00:10:12.900 --> 00:10:15.840
では次にファンクションズが適さない場合についてお話しします

00:10:15.840 --> 00:10:18.320
長時間実行される処理は問題になります

00:10:18.320 --> 00:10:21.760
重量課金プランでは関数のタイムアウト制限はデフォルトで5分

00:10:21.760 --> 00:10:23.620
設定しても最大10分だからです

00:10:23.620 --> 00:10:26.720
それ以上の時間がかかるジョブであれば別の手段が必要です

00:10:26.720 --> 00:10:28.820
ステートフルなアプリケーションも不向きです

00:10:28.820 --> 00:10:31.200
ファンクションズは実行間で何も記憶しません

00:10:31.200 --> 00:10:34.040
セッション状態の保持やステップ間の進捗管理が必要な場合

00:10:34.040 --> 00:10:35.860
その設計思想に反することになります

00:10:35.860 --> 00:10:37.820
高負荷な計算処理も適していません

00:10:37.820 --> 00:10:40.760
数分から数時間にわたってCPUを占有する必要があるなら

00:10:40.760 --> 00:10:42.740
仮想マシンやコンテナの方が良い選択です

00:10:42.740 --> 00:10:45.540
またあるタスクが別のタスクに依存するような複雑なワークフローは

00:10:45.540 --> 00:10:48.000
デュラブルファンクションズやロジックアップスで処理する方が適しています

00:10:48.000 --> 00:10:50.360
ここで代替手段の概要を簡単に説明します

00:10:50.360 --> 00:10:53.660
Azure Logic Appsはサービスを接続するためのノーコードの選択肢です

00:10:53.660 --> 00:10:55.200
カスタムコードを書く必要がないのであれば

00:10:55.200 --> 00:10:57.420
ロジックアップスならビジュアルデザイナーだけで作業を完結できます

00:10:57.420 --> 00:11:01.340
Azure Appsサービスは24時間365日稼働するフル機能のウェブアプリケーション向けです

00:11:01.340 --> 00:11:04.820
常時稼働する完全なウェブサイトやAPIが必要ならこれが最適なツールです

00:11:04.820 --> 00:11:08.840
Azure Container Appsはランタイムをより詳細に制御できるコンテナ化されたマイクロサービスを提供します

00:11:08.840 --> 00:11:12.700
そしてAzure Virtual Machinesは必要に応じてオペレーティングシステム全体を完全に制御できます

00:11:12.700 --> 00:11:14.760
ここで単純な目安を紹介しましょう

00:11:14.760 --> 00:11:19.020
ジョブを一文で説明できるならそれはファンクションズに適した候補と言えます

00:11:19.020 --> 00:11:21.160
画像がアップロードされたら圧縮する

00:11:21.160 --> 00:11:23.700
誰かがサインアップしたらウェルカムメールを送る

00:11:23.700 --> 00:11:25.980
毎晩深夜にクリーンアップジョブを実行する

00:11:25.980 --> 00:11:28.520
一つの文一つの仕事一つの関数

00:11:28.520 --> 00:11:30.560
避けるべき初心者のよくある失敗

00:11:30.560 --> 00:11:33.100
では注意すべき点についていくつかお話しします

00:11:33.100 --> 00:11:36.040
これらは初心者の誰もが最初に陥りやすいミスです

00:11:36.040 --> 00:11:39.480
よくある初心者のミスはファンクションズは常に無料だと思い込むことです

00:11:39.480 --> 00:11:42.920
無料枠は寛大で100万回実行は多く聞こえるかもしれませんが

00:11:42.920 --> 00:11:45.800
関数が急激に拡散したりボットの攻撃を受けたりすると

00:11:45.800 --> 00:11:47.560
実行回数はすぐに積み上がります

00:11:47.560 --> 00:11:49.160
ですので使用状況を監視し

00:11:49.160 --> 00:11:50.600
Azureで予算アラートを設定して

00:11:50.600 --> 00:11:52.400
月末に予期せぬ請求が来ないようにしましょう

00:11:52.400 --> 00:11:54.880
もう一つのミスはコールドスタートを無視することです

00:11:54.880 --> 00:11:57.980
アイドル状態から関数が初めて実行される際は時間がかかります

00:11:57.980 --> 00:12:00.440
重量課金プランでは数秒かかることがあります

00:12:00.440 --> 00:12:02.240
ほとんどの用途では問題ありません

00:12:02.240 --> 00:12:05.680
しかしミリ秒単位が重要な0.4に敏感なAPIを構築している場合は

00:12:05.680 --> 00:12:06.960
プレミアムプランを検討するか

00:12:06.960 --> 00:12:08.720
Always Ready Instanceを有効にしてください

00:12:08.720 --> 00:12:11.740
それから実行時間が長すぎる関数を書くことも避けるべきです

00:12:11.740 --> 00:12:13.540
重量課金プランにはタイムアウトがあり

00:12:13.540 --> 00:12:15.680
デフォルトは5分最大でも10分です

00:12:15.680 --> 00:12:17.900
もし関数の処理に15分かかる場合

00:12:17.900 --> 00:12:19.980
途中で強制終了されてしまいます

00:12:19.980 --> 00:12:21.480
ジョブを細かく分割するか

00:12:21.480 --> 00:12:23.360
別のホスティングプランを使用してください

00:12:23.360 --> 00:12:24.960
見落としがちなも一つのポイントは

00:12:24.960 --> 00:12:27.180
パッケージからの実行デプロイを使っていないことです

00:12:27.180 --> 00:12:28.680
これは簡単な設定変更で

00:12:28.680 --> 00:12:30.020
コールドスタートを改善し

00:12:30.020 --> 00:12:31.420
デプロイをより確実にします

00:12:31.420 --> 00:12:33.180
個別のファイルをコピーする代わりに

00:12:33.180 --> 00:12:34.720
ジップパッケージをデプロイするのです

00:12:34.720 --> 00:12:36.760
ポータルでチェックボックスを一つ入れるだけです

00:12:36.760 --> 00:12:37.740
実行しましょう

00:12:37.740 --> 00:12:41.080
認証なしでhttpエンドポイントを公開するのもありがちな罠です

00:12:41.080 --> 00:12:43.040
テスト中に匿名設定のままにしておき

00:12:43.040 --> 00:12:44.540
ロックするのを忘れがちです

00:12:44.540 --> 00:12:46.880
最初から権限レベルを正しく設定しておきましょう

00:12:46.880 --> 00:12:48.700
関数キーまたは管理者キーを使用してください

00:12:48.700 --> 00:12:50.240
扉を開けっぱなしにしないでください

00:12:50.240 --> 00:12:52.900
複数の関数アプリでストレージアカウントを使い回すのも問題です

00:12:52.900 --> 00:12:54.940
開発環境であれば共有しても問題ありません

00:12:54.940 --> 00:12:58.080
本番環境では各関数アプリに専用のストレージアカウントが必要です

00:12:58.080 --> 00:13:00.480
そうしないとある関数のトラフィックが別の関数を遅くする

00:13:00.480 --> 00:13:01.740
隣接干渉の問題が起きます

00:13:01.740 --> 00:13:04.200
最後はアプリケーションインサイトを有効にしていないことです

00:13:04.200 --> 00:13:06.240
これがないと手探り状態で運用することになります

00:13:06.240 --> 00:13:08.500
失敗やエラーパフォーマンスの問題を把握できません

00:13:08.500 --> 00:13:09.940
関数が長時間実行されているのか

00:13:09.940 --> 00:13:11.360
サイレントに失敗しているのかもわかりません

00:13:11.360 --> 00:13:12.980
初日から必ず有効にしてください

00:13:12.980 --> 00:13:15.600
設定は30秒で済みデバッグの時間を何時間も節約できます

00:13:15.600 --> 00:13:17.120
これらすべてに共通する黄金率は

00:13:17.120 --> 00:13:19.620
関数を小さく焦点を絞りステートレスに保つことです

00:13:19.620 --> 00:13:21.920
関数一つにつき一つの仕事それ以上は不要です

00:13:21.920 --> 00:13:23.380
システムについては以上です

00:13:23.380 --> 00:13:27.140
Azure Functionsはイベントに応答して小さなコードを実行するサーバーレスコンピューティングです

00:13:27.140 --> 00:13:29.420
コードが実行される時だけ料金が発生します

00:13:29.420 --> 00:13:31.060
トリガーが起動のタイミングを伝え

00:13:31.060 --> 00:13:32.920
バインディングが必要なデータに接続し

00:13:32.920 --> 00:13:35.840
重量課金プランなら小規模プロジェクトはほぼ無料で運用できます

00:13:35.840 --> 00:13:37.380
今すぐできる最善の一手は

00:13:37.380 --> 00:13:40.820
Azureポータルでシンプルなhttpトリガー関数を作成することです

00:13:40.820 --> 00:13:42.960
5分で完了し費用はかかりません

00:13:42.960 --> 00:13:45.000
マイクロソフトナレッジナゲッツを登録して

00:13:45.000 --> 00:13:46.380
わかりやすい解説をチェックし

00:13:46.380 --> 00:13:49.340
サーバーレスとは何かと聞いてくる友人にこの動画をシェアしてください

00:13:49.340 --> 00:13:49.860
フラウ