AzureFunctionsでCosmosDBのクエリ検索restサービスと監視

GYAOのtsです。
我々のチームは、オールパブリッククラウドで、Microservice Architectureを採用した次期バックエンドを設計中です。

経緯

チームが変わったりやなんやらで前回の投稿　から結構時間が空いてしまった。
引き続き我々のチームは戦陣切ってクラウド化を推進していこうと思う。
（なんでもクラウドにすればいいという意味ではなく、自由度を高め、視野を広げ、普通の力をつけようという意味で）

今回はfunctionを軸に構築する。
全ての主要クラウドベンダーから出ているサーバーレスアーキテクチャという代物だが、流行ってますね。
先日Azureの方とお話しましたが、pushされていらっしゃいました。Azureとしても力を入れていく領域なのかなと個人的には感じている。
というのも、使い始めた頃よりだいぶ進化していて、認証やらswaggerドキュメントの生成やら細かい便利そうな機能が追加されていてmicro serviceのIFを作ってくださいと言わんばかりな形になってきているので、我々もそれに乗っかろうかなと。「LogicAppsでもFunctionでも実装できない複雑なビジネスロジックがあった場合のみコンテナでrestを作ってそれをFunctionsやLogicAppsから呼ぶ」みたいなスタンスでいくとシンプルかなと。

作ってみる

実現したいこと

今回はCosmosDBに以下の形で入った複数のドキュメントをクエリ検索するrestサービスを作成する。

riceさんが複数のオブジェクト（コンテンツ）を持っている

{
  "contents": [
    {
      "id": "A00001",
      "time": 1497845466
    },
    {
      "id": "C00001",
      "time": 1497845586
    },
    {
      "id": "D00001",
      "time": 1497845686
    }
  ],
  "id": "rice",
  "pkey": "4"
}

okawariさんが別の複数のオブジェクト（コンテンツ）を持っている

{
  "contents": [
    {
      "id": "A00001",
      "time": 1497661986
    },
    {
      "id": "B00001",
      "time": 1497663986
    },
    {
      "id": "F00001",
      "time": 1497671986
    }
  ],
  "id": "okawari",
  "pkey": "4"
}

上記をidで検索して、「該当のコンテンツを保有しているのは誰か」を検索する。
クエリは下記の通り

 CosmosDBクエリ

SELECT d.id FROM docs d JOIN c IN d.contents WHERE c.id in({contentsId})

ちなみにクエリの構築はこちらを使うと便利です。

AzureFunctionsの構築

様々実装方法はあると思うが、今回はC#で構築。
まずはリソースの作成。

気をつけるのは、ApplicationInsightsをonにすること（後々監視でlogを拾えるようにするため）。

次は関数の作成だが、テンプレートでC#のHttp triggerがあると思うので、それを使用する。
関数名は下記のようにしてみた。まずは基本的な挙動の設定をしないといけないので、「統合」画面に行く。

AzureFunctionsはトリガ、入力、出力の基本項目をまず設定する。その基本項目の設定でコードとのバインドを作成し、それが関数の構築画面で使えるという流れ。
入力はトリガ以外の入力があれば設定（今回の場合はCosmosDBから検索結果の入力があるので設定）する。

今回のトリガ、入力、出力は下記の通り。

各項目を説明していく。

トリガ（HTTP）

オフィシャルドキュメントはこちら

• この関数はGETのみで使用するために、HTTPメソッドはGETに絞っておく。
• 認証をFunctionレベルでかけたいので、認証レベルはFunction。
• 要求inputパラメータ名が関数の作成画面で使用する同名のパラメータとバインドされる。
• **ルートテンプレートで、先程のcontentsIdのパラメータを指定できる。そうすると、関数の引数で受け取れる。 **

入力（Azure DocumentDB）

CosmosDBに名前が変わったはずだけど、ここはまだみたい。

オフィシャルドキュメントはこちら

• ドキュメントパラメータ名が、関数画面の同名変数にバインドされます。
• SQLクエリに下記のように記載

 CosmosDBクエリ

SELECT d.id FROM docs d JOIN c IN d.contents WHERE c.id in({contentsId})

出力（HTTP）

関数の戻り値をそのまま使用する。

以上で基本設定は終わり。次に関数の構築画面にいって、ここで定義したバインドを使用して関数を作っていく。

関数は下記の通り。超簡素。

lookupByContentsId

#r "Newtonsoft.Json"

using System;
using System.Net;
using Newtonsoft.Json;

public class Input
{
    public string contentsId { get; set; }
}

public static HttpResponseMessage Run(Input input, HttpRequestMessage req, IEnumerable<dynamic> inputDocument, TraceWriter log)
{
    log.Info("invoked.");
    if (inputDocument.Count() > 0)
    {
        var response = JsonConvert.SerializeObject(inputDocument);
        log.Info($"Document: {response}");
        return req.CreateResponse(HttpStatusCode.OK, $"{response}");
    }
    else
    {
        return req.CreateResponse(HttpStatusCode.NotFound);
    }
}

引数をみてみると、先程定義した名前と同名で定義してあると思う。各引数に関して説明をしていく。

• input
  • トリガのHttpをバインドしたバインド先。通常はHttpRequestMessageオブジェクトにバインドするが、今回は、リクエストの中にcontentsIdが入っていて、それを直にCosmosDBへのクエリのパラメータとして使用するため、こういう形となった。詳細はオフィシャルを参照。
  • 関数の外でInputクラス（POCO）をこさえると、そこにパラメータがバインドされる。CosmosDBを「入力」に使用する場合はこうする模様。Queueのpayloadのjsonをバインドするのがオフィシャルの例に乗っているが、今回はトリガのルートテンプレートで設定したcontentsIdをバインドした。（できた。）
• req
  • HttpRequestMessageオブジェクトは上述のように、通常Httpトリガのパラメータバインド先。今回はバインドしないので、コンパイルは通るが、実行時にエラーになる（AzureFunctionsはバインドのないパラメータを引数に取ると実行時エラーとなる）はずだが、ならない。そりゃHttpリクエストだからな。。。特別なんでしょう。ちなみに、レスポンス（HttpResponseMessage）の生成器にもなっているのでないと困る。
• inputDocument
  • CosmosDBの検索結果が格納される。つまり、この関数が呼ばれる前に前述のPOCOを使用したCosmosDBの検索が行われている形となる。
  • 今回はクエリを使用して複数ドキュメントを取得するので、typeはIEnumerable<dynamic>
  • ドキュメントが複数返ってくるのでJson.NETを使用して、jsonオブジェクト（リスト）を取得する。
• log
  • Logger。これを使って出力するものを、あとでApplicationInsightsで拾えるように設定します。

test

実行してみる。

おかわりさんが引っかかった。

Swaggerドキュメント書いてみる

API Definition（現在はpreview）からGenerate API Definition Templateを押すと、

contentsIdとかも含め情報を読み取って雛形を作成してくれる。なんて便利。
プロトタイプを作成して、同時にドキュメント作成、ある程度固まったらステークホルダにドキュメント渡す
みたいなスムーズなコミュニケーションがとれる。

Logの監視

ApplicationInsightsを使用して、logを一元管理していきたいと思う。
最初にApplicationInsightsをonにしたので、あとは下記を行って、紐付けていく。

1. ApplicationInsightsのプロパティ、のインストルメンテーションキーを取得する。

1. Functionsのアプリケーション設定でAPPINSIGHTS_INSTRUMENTATIONKEYというkeyで上記で取得した鍵を入力する。 1. ApplicationInsightsでログの状況を閲覧することができる。

所感

日に日にパワーアップするAzureFunctionsをいじってて普通に楽しい。エンジニアがクリエイティブな部分に集中できるように痒いところに手が届いてきた気がします。ドキュメントが若干読みにくいのと、リソース横断的なusageドキュメントが少ない印象のAzureですが、紐解いていくこと自体も楽しいのでよしとします。

今回の体験を経て、全体的にこんな感じにしようと思いました。チームメンバーの了承を得たらこれで行きます。

次回

Eventhubに関して書いていこうと思います。