以前まで利用していたbitbucket+rijiなブログがいつの間にかbitbucket側のサービス変更の影響で閲覧できない状態閲覧できない状態となっていました。

ですので、ひとまずAzure Web AppsのFreeプランで閲覧できるようにしておきましたので、お暇な方はどうぞご覧ください。

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

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

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

まとめ

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

AtomにGit Lensを移植できないだろうかというような議論がAtom Discussに上がるくらいには便利ですし、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を使うと、開発環境の構築が意外と簡単でした。

※このエントリは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 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の話かなにかをしてくれるようですよ。楽しみですね。

※このエントリは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の本気はどうやらこっち側だ。」ということでまとめとさせていただきたいと思います。

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

原因を確認する

南関テイオーの予想配信関数は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（特に従量課金プラン）においては、リソース枯渇による関数実行の失敗がありえます。これはクラウドサービスを活用する以上、付いて回る類の問題と言えるのではないでしょうか。

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

山の日(8/11)、私がひっそりと進めている南関競馬予想「南関テイオー」が朝の予想バッチをサボタージュしてしまいました。南関テイオーの開発秘話についてはこちらに書いてありますので、興味のある方は是非読んでみてください。なお、南関テイオーは事業化できるように鋭意調整中です。

南関テイオーの大まかな構成

南関テイオーは、Azure(従量課金プラン)上に予想エンジンを構築してあり、予想結果と当選情報をBloggerに垂れ流すようにしてあります。最近まで一部、機械学習を用いた学習モデルを適用している箇所がありましたが、試行錯誤の末、一般的な数式に置き換えました（その方が回収率が高い）。

forkに失敗する？

山の日に起こった現象は、「forkに失敗するせいで関数が起動できない」というものでした。以下、実際にAzure Portalで確認した内容です。

念のためAzureSupportに聞いてみる

あまりにもよくわからない現象でしたので、@AzureSupportに質問することにしました。

@AzureSupport Function App(US Central) has failed it’s own task today. What’s happened? pic.twitter.com/C6MMDm2m6o

— わいとん (@ytnobody) August 11, 2017

その後Direct Messageで詳細を聞かれましたが、Support Requestを送るように指示されました。

We recommend filing a support case via “Resource health” from the Azure Portal. After selecting the resource you are having issues with, navigate to “Resource health” by clicking the link under the “Support + Troubleshooting” section of the left blade. Select the option for “Contact Support” and follow the “New support request” workflow to submit your case. If you do not have a Support Plan enabled, be sure to select “Resource health” as the Support Plan.

オペレーション方法も教えてくれて、めっちゃ親切です。

で、この指示に従ってSupport Requestを送りました（念のため英語で・・・本当に拙い英語で・・・）。

すると10分後・・・

電話がかかってきた！

電話の相手は日本マイクロソフトのサポート担当の女性の方でした。英語ではなく日本語で対応してくれたことをありがたく思っていたところ、サポート曰く、

「事業影響度をAに設定したのはなぜですか？」

とのこと。事業影響度というのは、Support Requestのパラメータの一つであり、A,B,Cの3段階で1つ選択して設定することができるものなのですが、それぞれ以下のような定義となっています。

A. Critical impact - Significant loss or degradation of services (重大な影響 - サービスの大幅な損失または劣化)

B. Moderate impact - Moderate loss or degradation of services (中程度の影響 - 中程度の損失またはサービスの低下)

C. Minimal impact - Minimal loss or degradation of services (最小限の影響 - サービスの最小限の損失または劣化)

南関テイオーは当時も現在もサービスとして有償提供しているものではありません。しかし冒頭にも書いた通り、事業化を視野に入れていることも事実です。そこで私は先ほどの質問に対し、

「現時点では個人で稼働させているものであり、サービスインしているわけではないのですが、将来的にサービスインさせた時に、現在のこの状況はお客さんからクレームが来ることになりますので、Aとしました。」

と答えたところ、

「わかりました、それでは事業影響度をAとして対応を進めさせていただきます。後ほどエンジニアから連絡します。」

とのお返事をいただきました。すごい。ちゃんと話すことは重要ですね。

サポート部門のエンジニアさんからの連絡

数分後、サポートエンジニアのXさん（こちらは男性）からお電話がありました（祝日にもかかわらず対応ありがとうございました）。どこかで聞いたようなお名前の方でしたが、それはさておき、まずは調査してくださるということでした。

さらに数分後、Xさんから改めてお電話があり、関連しているかもしれない異変があることを説明してくれました。

1
2
3
4
5
6
7

Xさん「当該時間帯に、デプロイ先のインスタンスでメモリリソースの枯渇があったようです。現時点では解決しているので、関数を再実行できるようでしたらお試しいただけますでしょうか？」

私「ありがとうございます。試してみます。（インスタンスのメモリリソース枯渇って、PaaS利用者としては気にしたくないことだよなぁ・・・）」

Xさん「それから、現在Consumption Planで稼働しているようですが、関数のメモリ使用量が多いようですので、App Service Planでの稼働もご検討してみてください。」

私「わかりました、ありがとうございます。」

若干の違和感を感じながらも、ひとまず関数の再実行を試みたところ、正常に稼働しました。Azure Functionsでforkできない時には、メモリ不足を疑うと良いようですね。

まとめ

どうしてもわからない障害にぶち当たった時でも、24/365で対応してくれるAzureのサポート体制に大変感動しましたし、そして本当に助かりました。

今日色々とAzure Web Appsで設定をしていて、デプロイオプション周りでハマりました。とはいえ、わかってしまえばどうと言うことのないことなので、簡単に説明していきます。

Azure Web Appsでデプロイオプションを変更すると、~/.sshが初期化される

見た通りのことなのですが、例えばn0bisuke氏が書いたこのエントリを参考にデプロイ設定をしたとします（なお、リンク先は本当に参考になるエントリです）。

で、一通り設定が終わった後に、Azure Portalから「デプロイオプション」> 「切断」を実行すると、 ~/.ssh の中身が空っぽになります。

この挙動に気がつかないと、改めて「デプロイオプション」を再設定しても「なぜかgit cloneに失敗する」という状態に陥ることになります。

まとめ

デプロイオプションを変更したら、 ~/.ssh の中身を確認しましょう。

Azure Functionsを使った以下のようなサイト巡回の仕組みについて、是非とも気をつけたい箇所がありましたので、共有です。

このような特定のサイトを巡回する仕組みを作るとき、巡回先のサイトに対して秒間10リクエストくらいの比較的高密度なリクエストを送ることは、普通に考えると相手先のシステムにとって迷惑であろうと想像がつくことでしょう。

このような場合、リクエスト密度を軽減するために、並列リクエスト数の制限を行ったり、リクエストとリクエストの間にクールダウンを設けたりすることがあります。

クールダウンについては適宜sleepを入れるなどの対応をすることで、一応相手先に対するリクエスト密度の軽減が見込めることでしょう。しかし、並列リクエスト数の制限を行わないことには、ひっきりなしにリクエストを投げることになりかねません。

Queue Triggerにおけるジョブの並列処理数調整

今回例に挙げた構成の場合、巡回対象URLが多くなってくるとQueue Storageに一気にジョブが登録され、それらが片っ端から一気にQueue Triggerによって処理されてしまうことが問題となります。

上記の図にもある通り、Azure FunctionsにおけるQueue Triggerの並列処理数は、デフォルトでは16となっています。

この並列処理数を下げるためには、プロジェクト直下に以下のような内容でhost.jsonを作成し、デプロイする必要があります。

1
2
3
4
5

{
    "queues": {
        "batchSize": 3
    }
}

このqueues.batchSizeこそが、Queue Triggerの並列処理数設定となっています。

このように、相手先のシステムに過剰な負担を与えないようにすることができます。

まとめ

web巡回をAzure Functionsでシステム化しようとしている方は、是非ともQueue Triggerの並列処理数にも気をつけてください。

なお、host.jsonに関わる情報はgithubのazure-webjobs-sdk-scriptプロジェクトしか情報源を見つけることができませんでしたが、host.jsonをしっかり確認することで、Azure Functionsのチューニングが可能とも言えますので、要チェックです。