書評

書評 Azureテクノロジ入門2018

遅ればせながら、新年おめでとうございます。

さて、昨年末にAzureの風雲児であるところの@myfinder氏より献本いただきました。改めてお礼申し上げます。ありがとうございます。

本書について

2016年11月に出版されたAzureテクノロジ入門2016の改訂版となります。

もともとAzure関連の技術書は数少ないのですが、本書はその中でも入門者・初学者向けの位置付けとして発売されています。索引まで含めて233ページとなっており、定価は2500円と、技術書としてはかなり安価です。

著者陣はほぼ日本マイクロソフトの現任エバンジェリストやアーキテクトなどで占められており、マイクロソフトがいかにAzureというプロダクトを重要視しているかがわかります。

本書の目次

  1. Azureの基本と全体像
  2. AzureのインフラとIaaS ～ 仮想マシン、ストレージ、ネットワーク
  3. データベースと分析サービス
  4. 開発者のためのPaaS ～ Azure App ServicesとAzure Functions
  5. アイデンティティ管理と認証・認可
  6. 地上に広がるハイブリッドクラウド ~ Azure Stack

書評

表紙に「Azureを知るための最初の１冊！」「さらに進化したAzure全体像がよくわかる！」と書かれているのですが、まさにその通りの内容です。

そこそこAzureを使っている立場からすると、2章と5章は順序が逆でもいいかもしれないな、と感じました。AzureにおいてはそのくらいにID管理（Azure Active Directory 通称Azure AD, AAD)が肝となりますし、IaaSについてはAzureのPaaS/SaaSについて理解してからフォーカスするくらいでも遅くないと思います。

とはいえ、各章は初学者にもわかりやすいよう図解が多く用いられており、概念を理解する上で非常に心強い一助となることでしょう。すべて通読する必要はなく、手始めに利用する予定のあるサービスに応じて、必要な個所だけピックアップして読むのがおすすめです。ある程度ユースケースをカバーできたら、今度は通読してAzureの可能性をもっと広く学習することができます。

また、ある程度熟練した向きにとっても、次に利用する予定のAzureサービスについて手早く把握しておきたい場合に、辞書のように利用できることでしょう。というのも、本書では各章の要所要所にオンラインドキュメントのURLが記載されており、細かい部分についてはそちらで補完するような構成となっているためです。

あらゆることを正確に記憶しておける人間は稀です。本書は、Azureに関する知の高速道路を読者に提供してくれることでしょう。そして忘れかけたAzureの知見を改めて引き出す際にも十分に価値を発揮してくれると思います。

Perl

2017年のPaaS/SaaS周りを振り返って - フルマネージドDBサービス発展の年

2017年も終わりを迎えようとしておりますが、2017年はPaaS/SaaSにとって非常にインパクトの大きい一年でした。

このエントリでは、PaaS/SaaS利用者の観点から、2017年を振り返ってみようと思います。

なお、私は主にMicrosoft Azureを利用しているため、内容の濃さなどの面でどうしてもMicrosoft Azure寄りとなりますことをあらかじめご了承ください。

フルマネージドDBサービス発展の年

2017年は、フルマネージドDBサービスの利便性が大変向上した一年だったと思います。

特に「DBインスタンス」という考え方から脱却したサービスが登場し、本格的に利用された年だったと言えるのではないでしょうか。

アプリケーション開発者からすると、インスタンスのことを気にするのは本質的ではありません。そのような本質的ではないことについて一切触れる必要なく、DBをサービスとして利用することは、2017年で一気に身近になってきたことだと思います。

また、料金体系的にも「トランザクションごとに課金」というパターンが浸透してきたのも2017年の特徴ではないでしょうか。これによって、真に「利用した分だけ支払う」ことが現実のものとなったと思えます。

Azure Cosmos DB

スキーマレスなNoSQL DBとして利用でき、各リージョン間でデータレプリケーションが可能なDBaaSです。

もともとAzure Cosmos DBの源流として、Azure DocumentDBというサービスが2010年から提供されていたのですが、Build 2017にて名称をAzure Cosmos DBとし、以下のようなAPIへと対応しました。

料金体系についてはRU(Request Unit)と呼ばれる単位で計上されることになっており、インスタンスベースの課金体系ではないことが非常に重要です。

Azure Database for MySQL/PostgreSQL (プレビュー)

Azure SQL Databaseで培われてきたフルマネージドDBサービスの堅牢性とスケーラビリティが、MySQLおよびPostgreSQLのインターフェースで利用できるようになったものです。これもBuild 2017で発表されました。

従来であればMySQL/PostgreSQLともにVMを立ち上げ（あるいはオンプレミスのリソースを用意して）そこにインストールし、パフォーマンスモニタリングに気を使いながら、自力で運用するものでした。

このサービスは現時点ではまだプレビューですので、手放しで本番に投入して良いものかどうかは微妙だと思いますが、上記のような運用から解放される道筋が示されていることについて、将来十分に考慮に値することだと思います。

こちらの料金体系は、時間課金のコンピューティングユニットとデータ容量課金のストレージの合算値となり、やはりインスタンスベースの料金体系ではありません。

Amazon DynamoDB

Amazon DynamoDBは、フルマネージドDBサービスの中でも元祖と言えるでしょう。2012年にサービス提供が開始され、2013年に東京リージョンで利用可能となりました。

リージョン間でのレプリケーション（クロスリージョンレプリケーション）にも対応しており、課金体系もデータ量とスループットに基づいたものとなっています。

これらのことは、近代的なフルマネージドDBサービスの基礎となっており、Amazon DynamoDBがサービスを通して示したビジョンは大変重要なものと言えるでしょう。

フルマネージドDBサービスは開発者をより開発に集中させる

上記で紹介したサービスはいずれも、開発者からDBの管理という手間をなくそうという方向性のサービスです。自力でDBの管理を行う場合にかかるコストと、上記サービスを利用した場合のコストは、性質的に全く異なるものです。

また、自力でDBの管理を行う場合は、どうしても人間そのものがボトルネックになってしまいます（腰痛や風邪などの体調不良、冠婚葬祭に伴う休暇など）。速く移動するという本質で見た時に馬車から自動車へと変遷していった歴史があるように、DBの管理やスケーリングについてもより利便性の高い手段を検討していくことが肝要なのではないでしょうか。

そして、開発者がより開発に集中できるようにし、生産性の向上に繋げていくことが、最終的な競争力に寄与するのだろうと私は思います。

告知

TumblrからWordPressに移行しました。

TumblrとCloudflareの組み合わせは難しい

Tumblr + Cloudflareの食い合わせがあまり良くなかったらしく、どうにもDNS設定周りでしくじるので、思い切ってCloudflare + WordPress + Azure WebAppsにしてみました。

従来のエントリについては全く同じURLでアクセスできるようにしてあります。

App

VSCode-GitLensはいいぞ、という話

※このエントリはOSS紹介 Advent Calendarの17日目のエントリとなります。

Visual Studio Code使ってますか？

皆さん、Visual Studio Code（以下VSCode）使ってますか？

VSCodeはMicrosoftが開発しているOSSのエディタです。github上で活発にコミットされているプロダクトであり、その使い勝手は比較的Atomに似ていると言えるかもしれません。

今回は、そんなVSCodeのプラグインとして提供されているGit LensというOSSを紹介したいと思います。

Git Lensって何？

簡単に表現すると、git blameをVSCodeで超絶便利に使えるようにするプラグイン、という感じでしょうか。いちいちgithubとかbitbucketに見に行くのもだるいですし、かといってgit blameを毎回手打ちするのもだるい、という向きにこそうってつけのプラグインだと私は思います。

インストール手順ですが、VSCodeのプラグイン管理画面でgitlensを検索するとすぐに出てきます。あとは「インストール」ボタンを押すだけ。

プラグイン管理画面

非常に簡単ですね。

Git Lensの便利さ

とにかく見やすい、の一言に尽きます。以下の画像は、私が個人的に開発しているうまミるのプロジェクトにおけるGit Lens活用の様子です。

Git Lens活用のようす

Git Lensをインストールすると、左側にGITLENSと書かれたブレードが出てきます。これを開くとブランチ一覧が見えて、その中にはコミットの一覧がずらりとぶら下がっている状態となっています。

コミットを開くと、そのコミットで変更のあったファイルの一覧が表示されます。ファイルを選択すると、上の画像のように差分が見える、というわけです。

他にも、コミットに関する操作なんかも割と細かくサポートされています。

コミットに関する操作メニュー

まとめ

Git Lensは次世代のgit blameと言えるんじゃないかと私は思っております。

AtomにGit Lensを移植できないだろうかというような議論がAtom Discussに上がるくらいには便利ですし、VSCodeを使うなら是非とも利用したいプラグインでしょう。

Perl

Windows10でPerl+VSCodeな開発環境を整える

※このエントリはPerl入学式 Advent Calendarの13日目のエントリとして、滑り込むように執筆したものです。

私とPerl入学式の関わり

わいとんです。

実は私、第1回東京開催のころから散発的にPerl入学式のサポーターをやってきました。もう３年以上の関わりになるので、サポーターの中では最古参の部類に入るでしょう。

さて、今回はWindows10でPerlの開発環境を整える話をしたいと思います。

WindowsはPerlの開発に向いていないのではないかという話

Perl入学式の講義では、Windows向けの開発環境としてVirtualBoxにUbuntu Linuxをインストールする方法をレクチャーしています。

というのも、基本的にはWindowsでPerlのプログラミングを行うことはやや困難であるとか、あるいはWindowsでPerlを書いている人がサポーターを始め、さほど見受けられないので、サポートを受けにくい状況にある、などという理由が横たわっているためです。

当たり前を疑ってみる

では、本当にWindowsでPerlアプリケーションの開発を行うことは困難なのでしょうか？

あるコンテキストにおいてはこれはYesなのかもしれません。

例えば（Perl入学式の講義レベルから見ると相当高度な話となるのですが）MySQLを使った開発をすべてWindows上で行う場合は、もしかするとLinuxでは考えられない苦労が待っているのかもしれません（ただし、私は試したことがないので、これは間違いかもしれません）。

しかし、Perl入学式のカリキュラムの範囲であれば、私見ですがWindowsでも困ることはないだろうと思います。

WindowsでPerlの開発環境を構築したい向きには、もしかすると役に立つかもしれないので、私なりの環境構築法を紹介します。

Windowsにもパッケージマネージャがある！

個人的に、もっと有効活用されてもよいのにと思うプロダクトに、chocolateyというパッケージマネージャがあります。そう、yumやaptのように、ほしいプログラムパッケージ名を教えると、あとは全自動でインストールまでやってくれる便利なやつです。

chocolateyのインストール

まず、Windowsのスタートボタンを右クリックし、 Windows PowerShell（管理者）を選択します（この時、管理者権限を求められますので、「はい」を選びます）。

すると、PowerShellターミナルが開きますので、chocolateyのインストールガイダンスに従って、以下のコマンドをPowerShellターミナルに貼り付けて実行します(長いので折り返して見えるかもしれませんが、一行です）。

1
Set-ExecutionPolicy Bypass -Scope Process -Force; iex ((New-Object System.Net.WebClient).DownloadString('https://chocolatey.org/install.ps1'))

これでchocolateyのインストールが完了しました。

chocolateyは、Windows管理者にchocoコマンドを提供してくれます。うまくインストールできているか、試しにchocoコマンドを使って、以下のようにパッケージを検索してみましょう。

1
choco search perl

chocoateyのインストールに成功している場合、以下のようにパッケージがズラッと表示されます。

Perlを使えるようにする

さて、無事にchocolateyのインストールができたら、今度はPerlを使えるようにしたいところです。

Windows向けのPerlにはいくつか種類がありますが、比較的はまりどころが少ないと感じているStrawberry Perlを、chocolateyを使ってインストールしていきます。

先ほどの choco search の結果を見ると、パッケージ一覧の最初に

1
StrawberryPerl 5.26.1.1 [Approved]

と書いてあります。もう見たままなのですが、一番左側にはパッケージ名が、その次にはそのバージョンが表示されていまして、つまり以下のようにchocoを実行してやるだけで、Strawberry Perlの5.26.1.1がインストールされるというわけです。

1
choco install StrawberryPerl

非常に簡単ですね。途中でインストールの可否を問われますので、「Y」を選択してあげればOKです。

VSCodeをインストールする

VSCodeとはVisual Studio Codeの略称です。エディタですので、宗教上の理由によりほかのエディタでなければいけない、という方はここはスキップしてかまいません。

VSCodeは、MicrosoftがOSSとして開発しているエディタです。atomなどにも似ていると思います。

そんなVSCodeもchocolateyで検索・インストールすることができます。

1
choco install VisualStudioCode

たったこれだけです。

第２回の課題を一つ、Windowsで実際にやってみる

chocolateyを使って、いとも簡単にPerlの開発環境を整えることができました。

では、実際にこの開発環境をつかって課題をこなしてみます。

via GIPHY

まとめ

  • WindowsでもStrawberry Perlを使うと、Perl入学式のカリキュラムを乗り切ることができるかもしれません。
  • Windowsのパッケージマネージャchocolateyを使うと、開発環境の構築が意外と簡単でした。
PHP

最近使っているPHPライブラリ

※このエントリはOSS紹介 Advent Calendar 2017の11日目のエントリとなります。

10日目は@tsucchiさんの担当でstart-stop-daemon とちょっと変わったユースケースについてというエントリでした。

さて、今回は私が近ごろ使っているPHPのライブラリ（と言っても少ないのですが）を紹介していきます。

最終メンテ日時が結構前の物もあるのですが、おおらかな心でご笑覧いただけると幸甚です。

hashids/hashids

一意で連番ではなく短いID文字列を生成するライブラリ。bitlyやyoutubeのショートURLを想像してもらえるとわかりやすいでしょうか。

こんな感じで使うと、$hashに半角英数で表現されたハッシュ文字列が生成されます。

1
2
3
use HashidsHashids;
$hashids = new Hashids('Hello, world!');
$hash = $hashids->encode(333, 21, 101);

ちょっとメジャーすぎたかな。

uchiko/sql-maker

SQLクエリビルダですね。

詳しい使い方はドキュメントを見ていただくとして（雑）、私はこれを後述のライブラリと組み合わせて、Azure CosmosDB(DocumentDB API)への問い合わせ用クエリビルダとして利用しています。

cocteau666/AzureDocumentDB-PHP

CosmosDBのDocumentDB APIでPHPからクエリを投げ込むためのREST APIラッパーライブラリです。

前述のuchiko/sql-makerと組み合わせて、CosmosDBへPHPから自在に問い合わせを投げ込むことができるようになります。

junpei/geohex-php

GeoHex v3を取り扱うためのライブラリです。緯度経度からGeoHexコードに置き換えたり、その逆をやったり。

大まかな位置情報を扱いたいときに大変便利です。

ドキュメントがないので、だれかかいて（私が書くべきかｗ）

aporat/store-receipt-validator

Apple iTunesやGoogle Play、Amazon App Storeに対応したレシート検証ライブラリです。

PHPサーバサイドでモバイルアプリのレシート検証をすると言ったら、このライブラリを使えば簡単に実装できます。

Example書く元気がないので、各自ドキュメントを参照してください。（雑）

まとめ

私が使っているPHPのライブラリをいくつか紹介しました。本当に本当に雑な紹介ですけど、結構メジャーなところからマイナーなところまで取りそろえることができたと思います。

Perl

Perlコアモジュールに寄せてみる

※このエントリはPerl Advent Calendar 2017の9日目のエントリとなります。

8日目は@mackee_wさんの担当でマスタデータを宣言的かつ高速にテストするTest::MasterData::DeclareとTest2の構造についてというエントリでした。Test2を使ったモックデータを伴うテストの記述に、大変強力そうなモジュールでしたね。

さて、本エントリではPerl5におけるコアモジュールについてのさわりと、その中でも鉄板とも呼べる非常に有用なものをいくつか紹介していきます。

コアモジュールとは？

Perl5におけるコアモジュールとは、Perl5と抱き合わせでインストールされるモジュール群のことを指します。

コアモジュールとして収録されるモジュール群は、Perl5のバージョンごとに差がありますが、個人的な肌感としては、本当に鉄板とも呼べるような物は大抵5.14以降であればそろっていると考えても差し支えないと思います。

コアモジュールをちゃんと調べたい

私のようなテキトーな人間の肌感なんかは余り当てにならないでしょうから、確実性のあるソースを当たるのであればperldoc.perl.orgのコアモジュール一覧がありますので、そちらを参照するのが間違いないでしょう。

上記ページの左上には、Perlバージョンを指定するドロップダウンメニューがありますので、お使いのPerlバージョンを選ぶとよいでしょう。

もしくは、ターミナルで corelist モジュール名 と打ち込んでやると、そのモジュールがコアモジュールかどうかと、（もしコアモジュールの場合は）どのperlバージョンからコアモジュールに収録されたのかを返してくれます。

例えば私の使っているRazer Blade Stealth(Windows10 + Strawberry Perl 5.26.1)で Module::Load について corelist を使って調べてみると、以下のような結果が得られました。

1
2
3
4
C:Usersytnob>corelist Module::Load

Data for 2017-09-22
Module::Load was first released with perl v5.9.4

なお、 corelist コマンドは Module::CoreListというモジュールによって提供されておりますが、当然これもコアモジュールです。

1
2
3
4
C:Usersytnob>corelist Module::CoreList

Data for 2017-09-22
Module::CoreList was first released with perl v5.8.9

なぜコアモジュールを使うのか

Perlをはじめとしたモジュール管理のエコシステムが整ったプログラミング言語を各種開発に利用するにあたって、大抵はそのモジュラリティをフル活用した開発スタイルを取ることになると思います。つまり、インターネットなどを通じて外部からモジュールを取り入れて利用することがほとんどでしょう。

CPANなどで公開されている便利な外部モジュールを利用することで、本質的なロジックの開発に集中しようということがその狙いだったりするのですが、つぶさにコアモジュールを調べてみると、外部モジュールに頼るまでもなく、案外とコアモジュールで済ませられる事も多かったりします。

コアモジュールに寄せておくことで、以下のようなメリットに与ることができます。

  • スクリプトの利用環境制限を緩めることができる（Windowsでも動く、とか）
  • 外部モジュールのインストールの手間を省くことができる

私が選んだお気に入りコアモジュール5選

さて、ごちゃごちゃと説明してきましたが、私がよく使うコアモジュールを5つだけピックアップしてみました。本当はもっとお世話になっているコアモジュールはいっぱいあるのですが、執筆に必要な集中力の都合上、このくらいに留めさせておいてください。

HTTP::Tiny (from v5.13.9)

LWP::UserAgentやFurlよりもプリミティブな感じのあるHTTPクライアントモジュール。レスポンスがオブジェクトではなくハッシュリファレンスで帰ってくる点が前述のモジュール達よりもシンプルです。

HTTP::Tinyについては、shohexさんが6年前に書いたエントリが非常にわかりやすいですので、そちらもご覧ください。

Module::Load (from v5.9.4)

モジュールの動的ローディングを実現するモジュール。状況によって読み込むモジュールを差し替える（Strategyパターン）ようなケースに使ったりします。

似たようなものにはClass::Loadとかがあるんですが、Module::Loadだとちょっと足りない、というケースで使うかもしれません。私は使わないけど。

Encode (from 5.7.3)

日本人に生まれ日本語とPerlを操っている以上、マルチバイト文字と仲良くすることが求められるのですが、Encodeはそのためのツールを提供してくれるモジュールです。もはや説明の余地もないですね。

JSON::PP (from v5.13.9)

PerlでJSONを扱うためのモジュール。これとHTTP::Tinyをつかうことで、コアモジュールだけでちょっとしたAPIクライアントを作ったりすることができます。

とにかく速度を求められるケースであればJSON::XSを使ったりするのですが、速度よりも簡便性を求める場合にはJSON::PPを使うことが多いです。Windowsでもつるしで使えますし。

List::Util (from v5.7.3)

配列操作に関する追加の関数を提供してくれるモジュール。プログラムを書く仕事をして15年以上経過していますが、配列を処理するプログラムは頻出パターンの一つで、必然的にこのモジュールに助けられる事が多いです。

君もコアモジュールを探検してみよう

時折思い出したようにコアモジュールを探検してみると、「こんな便利なのがコアにあったんだ！」という発見があったり、「このモジュールはこういう使い方もできるな」という発想ができたりと、なかなか飽きないものです。

そもそもコアモジュール自体は結構種類があるので、全部を覚えるのはまぁ無理なんじゃないかとも思われますが、普段なかなか見かけないコアモジュールの使い道を考えたりするのも面白いものですよ。

さて、明日は@tsucchiさんの番で、なにやらMinionの話かなにかをしてくれるようですよ。楽しみですね。

Cloud

FunctionsのApp Serviceプランで快適な気になった話

※このエントリはMicrosoft Azure Advent Calendar 2017の3日目のエントリとなります。

個人的に運営しているサービスの運営にAzure Functions(従量課金プラン)を使っていたが・・・

@ytnobodyです。

私が個人で運営している「うまミる」（旧:南関テイオー）という競馬予想サービスでは、予想データを作成するロジックをAzure Functionsで実行しています。

そのうまミるですが、先月くらいに不可解な問題に直面しながらも、従量課金プランでだましだまし運用していたのですが、とうとう現象が毎日発生するようになってしまいました。

予想ロジックの複雑化に伴い、従量課金プランでは捌ききれなくなったのだろうと思い、思い切ってApp Serviceプラン(Basic S1)にデプロイしてたところ、予想以上に快適でした。

当たり前だけど速い

当然のことなのですが、従量課金プランと比較して段違いに速いです。料金的には、それまではだいたい月額1500円程度だったところが5400円ほどにアップしていますので、個人で支払うにはなかなかの額面になってしまったと感じています。

しかし、毎朝Functionsの状況を確認する必要性がなくなったことを考えると、コスパは予想以上に良いと感じました。

実際どのくらいのコンピューティングリソースを使っているのかを把握できる

PaaSを使うという観点では正直なところ、どれだけコンピューティングリソースを使っているのかという点について、個人的には全く気にしたくないところではあります。

しかし、安定稼働とコストの両立を考えると、どれくらいのコンピューティングリソースを使っているのかを把握しないと、ちょうどよさのあるプラン選定ができない、というのが現状です。

App Serviceプランにすると、Application Insightsを有効化するだけで簡単にリソース使用状況や関数の実行に関する統計（成功・失敗や関数の実行にかかった時間など）が可視化できます。これはちょうどよさのあるプランを選定するうえでありがたい話です。

そういえばこの原稿を書きながらApplication Insightsを見ていたら、妙に失敗率のたかい関数がなぜ失敗しているのかをようやく把握することができました（これについてはそのうち別途エントリを起こすと思います）。

まとめ

以前サポートを受けた際、「従量課金プランでは厳しいかもしれませんので、App Serviceプランもご検討ください」という助言をいただいていましたが、明らかに快適になりました。当然元々のペインポイントであった「毎日関数が起動できなくなってしまう」という問題も解決しています。

最後に、状況にもよるのでしょうが、Azure Functionsについては「従量課金プランで感覚をつかんだら、App Serviceプラン + Application Insightsも試してみてほしい。MSの本気はどうやらこっち側だ。」ということでまとめとさせていただきたいと思います。

Cloud

Azure Functionsの関数実行時にエラーとなった場合のとりあえずの処置方法

今朝、南関テイオーの予想配信関数が実行失敗しており、その復旧作業を行いました。本エントリではその一部始終をまとめてみました。

原因を確認する

南関テイオーの予想配信関数は7:10(JST)に起動するようにTimer Triggerが設定されています。

Azure Functionsでは、関数ごとに「モニター」という項目があり、そこで実行ログを閲覧することができます。

まず実行ログになんらかの異常が吐き出されているだろうということで確認してみたところ、案の定、予想配信関数の実行時に、以下のようなエラーが出ていました。

1
2
3
4
5
6
7
8
9
10
11
12
Exception while executing function: Functions.getRace
Microsoft.Azure.WebJobs.Host.FunctionInvocationException : Exception while executing function: Functions.getRace ---> System.ApplicationException :       0 [unknown (0xFB4)] bash 4924 D:Program Files (x86)Gitbin..usrbinbash.exe: *** fatal error - Couldn't set directory to \?PIPE temporarily.
Cannot continue.

   at async Microsoft.Azure.WebJobs.Script.Description.ScriptFunctionInvoker.ExecuteScriptAsync(String path,String arguments,Object[] invocationParameters,FunctionInvocationContext context) at C:projectsazure-webjobs-sdk-scriptsrcWebJobs.ScriptDescriptionScriptScriptFunctionInvoker.cs : 114
   at async Microsoft.Azure.WebJobs.Script.Description.ScriptFunctionInvoker.InvokeCore(Object[] parameters,FunctionInvocationContext context) at C:projectsazure-webjobs-sdk-scriptsrcWebJobs.ScriptDescriptionScriptScriptFunctionInvoker.cs : 64
   at async Microsoft.Azure.WebJobs.Script.Description.FunctionInvokerBase.Invoke(Object[] parameters) at C:projectsazure-webjobs-sdk-scriptsrcWebJobs.ScriptDescriptionFunctionInvokerBase.cs : 95
   at async Microsoft.Azure.WebJobs.Host.Executors.VoidTaskMethodInvoker`2.InvokeAsync[TReflected,TReturnType](TReflected instance,Object[] arguments)
   at async Microsoft.Azure.WebJobs.Host.Executors.FunctionInvoker`2.InvokeAsync[TReflected,TReturnValue](Object instance,Object[] arguments)
   at async Microsoft.Azure.WebJobs.Host.Executors.FunctionExecutor.InvokeAsync(IFunctionInvoker invoker,ParameterHelper parameterHelper,CancellationTokenSource timeoutTokenSource,CancellationTokenSource functionCancellationTokenSource,Boolean throwOnTimeout,TimeSpan timerInterval,IFunctionInstance instance)
   at async Microsoft.Azure.WebJobs.Host.Executors.FunctionExecutor.ExecuteWithWatchersAsync(IFunctionInstance instance,ParameterHelper parameterHelper,TraceWriter traceWriter,CancellationTokenSource functionCancellationTokenSource)
   at async Microsoft.Azure…

予測

ひとまずリトライを何度か試してみたところ、全て同じ現象が発生。これは以前サポートに相談した時と同様にリソース枯渇が原因なのではないか？と予想。

復旧手順

復旧までの手順は以下の通りとなり、今回は無事に復旧することができました。

  1. 新しいFunctions Appリソースを作成する（今回はリージョンの問題ではないので同一リージョンでOKだった）
  2. アプリケーション設定（環境変数）を新しいFunctions Appリソースにコピペする
  3. 従来のFunctions Appリソースを停止する（重複起動を防ぐ）
  4. 新しいFunctions App側でデプロイオプションを設定する（ここで関数のソースコードがデプロイされる）
  5. 関数を実行する

特に4の手順が実行できるよう、bitbucketなどを利用してgitレポジトリ連携をしておくことが、手早い復旧をする上で肝要と言えます。

まとめ

Functions App（特に従量課金プラン）においては、リソース枯渇による関数実行の失敗がありえます。これはクラウドサービスを活用する以上、付いて回る類の問題と言えるのではないでしょうか。

そのような問題を乗り越えるためには、最初から「壊れてもすぐ直せる」ようにシステムを作っておくことが大事だと考えます。