Azure Functions たのしいです。今回は、現時点で グラニにおいて Azure Functions を展開するにあたり気をつけていることをメモしておきたいと思います。
現時点で、リリースされて2週間程度に加えて、プレビュー版なので今後変わる可能性が高いです。
が、いったんのまとめということで。
目次
- 目次
- サンプルコード
- API Gateway + Lambda ほど API的な利用はできない
- 実装において気をつけていること
- 安定性の向上
- デプロイ
- 開発環境
- わからないことは気軽に質問する
- 今後の期待
- まとめ
サンプルコード
Azure Functions に関する記事で扱った内容は、Github にあげています。参考になれば幸いです。
API Gateway + Lambda ほど API的な利用はできない
これはコンセプトの違いなので、よくも悪くもないです。
API Gateway + Lambda
API Gateway を AWS Lambda の前面におくことで、RESTful API のように展開ができます。
これの何が嬉しいかというと、GET や POST などの 各種HTTP Method を自由に組み合わせたり、API共通の Token を設けたり Request Header や Response Header をいじったり、エンコーディング触ったりと、いい感じにフロントエンド(API Gateway)で加工してからロジック(Lambda) に渡せます。カスタムドメインを割り当てたりアクセスURLも統一的に扱えて、バージョニング、デプロイタイミングまで自在です。つまり、本当に Managed RESTful API なんですね。
URL もこのようにAPI Gateway で管理して、Lambda は API ごとに割り当てます。複数の処理も常に統一したアクセスURL で提供できるのがいいです。
https://<gatewayname>.apiname.ap-northeast-1.amazonaws.com/<stage>/<apiname> https://<customdomain>/<stage>/<apiname>
とはいえ、手元の環境からいい感じでデプロイ、C# サポートがない、など今後にまだまだ期待を持っています。
Azure Functions
ではAzure Functions はどうかというと、あくまでも入力に対して何かをしてくれる関数 であり、関数ごとに個別にURL + tokenを付与したものです。
そのため、次のような URL が発行されます。
https://<FunctionAppName>.azurewebsites.net/api/<FunctionName>?code=<Functionごとに一意な文字列>
外から叩くときも、POST メソッドで application/json しか受け付けられません。雑に叩くとこんな感じです。
ちなみに PowerShell でInvoke-RestMehotdを使って叩くと、エンコーディングが utf8 じゃないので日本語が化けます。HttpClientを使いましょう。
Function ごとに一意の文字列が付与されることも含めて、API Gateway + Lambda ほどは RESTful として統一的なアクセスは難しいということです。しかし、似た処理を1つのFunction App にまとめることでアクセスをある程度統一的にできないことはないです。
性質からすると、比較的 Webhook 処理を任せたり、Azure のリソースをイベント発火点としてFunction起動するのが初めの一歩としても役割としても活用しやすいでしょう。
実装において気をつけていること
単純なことです。
#load を活用する
Azure Functions が実行を保証していない以上、処理をつなげるのに Azure Functions を内部で次々と呼び出すネスト構造は不向きです。
そこで、多段 Azure Functions の呼び出しをやめて #load に寄せる のが効果的です。
機微情報は App Settings を使う
コード生埋めは避けましょう。System.Configuration.ConfigurationManager.AppSettings[<string>] で取得できるので、違和感なく扱えるはずです。
拡張メソッドを利用する
拡張メソッドが利用できるかは使い勝手に直結します。積極的に使っていくといいでしょう。
私は、拡張メソッドを Function App の上位階層に配置して、必要に応じて#load で読み込んでいます。こうすることで、再利用性があがっていい感じえす。
安定性の向上
パフィーマンスチューニングのしようがほぼないので、少しだけ設定で気をつけることです。
メモリを増やすと実行が安定する
Azure Functions は、SLA 100% のような必ず実行される というものではありません。実際、グラニでは128MB では50回の実行で 5回程度は失敗を計測しています。
Azure Function を安定的に動かすには、処理によってですが メモリを 128MB から 256MB 程度に増やすのも有効です。
メモリを256MB に増やした後は実行がこけることなく安定するようになったように見えるので、今後も計測監視です。
32-bit Platform のままにする
Azure Functions は、Azure Web Appsなので32bit と 64bit でプラットフォームが選択可能です。デフォルトが 32bit ですが、現在のところ 64bit にしないことが推奨です。
Azure Functions の父であるDavid Ebbo が質問に解答してくれました。
デプロイ
CI 大事です。
本番系は CI を組む
Azure Functions が、AWS Lambda + API Gateway より圧倒的に楽なのが CI です。特に Github CI は、PRベースとかなり相性が良く最強感あります。
かならず、本番系はCI を組むことを推奨します。Azure Portal と開発環境を可能な限り分離するのは当然あるべき状態です。
テスト環境を用意する
もう1つ大事なのが、テスト環境です。残念ながら API Gateway と違ってステージの考えを持たないため、別に Function App を用意しましょう。
私はこの環境は CI しないことで、好きに触ったり本番を再現したりしています。
開発環境
本番を Github CI しているので、Visual Studio から直接 Publish というのはなしです。
Visual Studio を使った リモートデバッグ周りの情報が乏しいので、次はその辺ですね。
わからないことは気軽に質問する
公式の推奨は、MSDNフォーラム か StackOverflow(azure-functions タグ) に質問を投げることです。
実際、私も StackOverflow に質問を投げてますが、中の人から超速でアドバイスが来ます。すぎょい。
現在は、なぜか Azure Functions の記事を公開すると Azure Functions の中の人に補足されています。そのお陰か Twitter でつぶやくと質問に解答が来たりします。
@guitarrapc_tech We often test new, non-impacting features in production to get organic user feedback, but that does mean there is less docs
— Christopher Anderson (@crandycodes) April 15, 2016
とりあえずオススメは、ふと調べて疑問に思ったら Twitter で英語でつぶやく + StackOverflow で質問 です。
今後の期待
Azure Functions も AWS Lambda 同様にちょくちょく実行が失敗するします。
そのため、モニター機能が待ち望まれます。GA することで、SLA も少し来るかもしれませんね。
まとめ
現時点で気をつけていることを簡単にまとめました。日々良くなっていっているので、使える機能や面白い活用が思いついたら記事にしたいと思います。
