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しか受け付けられません。雑に叩くとこんな感じです。
https://gist.github.com/guitarrapc/fdcda5fe2471be453748577f23ddf7e4
ちなみにPowerShellでInvoke-RestMehotdを使って叩くと、エンコーディングがUTF-8じゃないので日本語が化けます。Invoke-RestMehotdを使いましょう。
https://gist.github.com/guitarrapc/6fdb8f069946a2020c3d39954bfe40ef
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設定だと5/50程度で失敗しています。
Azure Functionを安定的に動かすには、処理によってですが メモリを 128MB から 256MB 程度に増やすのも有効です。
メモリを256MBに増やした後は実行がこけることなく安定するようになったように見えるので、今後も計測監視です。
32-bit Platform のままにする
Azure Functionsは、Azure Web Appsなので32bitと32bitでプラットフォームが選択可能です。デフォルトが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タグ) に質問を投げることです。
https://social.msdn.microsoft.com/Forums/azure/en-US/home?forum=AzureFunctions
実際、私もStackOverflowに質問を投げてますが、中の人から超速でアドバイスが来ます。すぎょい。
現在は、なぜかAzure Functionsの記事を公開するとAzure Functionsの中の人に補足されています。そのお陰かTwitterでつぶやくと質問に解答が来たりします。
Christopher Anderson (@crandycodes) April 15, 2016
オススメはふと調べて疑問に思ったらTwitterで英語つぶやき、StackOverflowで質問です。
今後の期待
Azure FunctionsもAWS Lambda同様にちょくちょく実行が失敗するします。モニター機能が待ち望まれます。GAすることで、SLAも来たりするんでしょうか。
まとめ
現時点で気をつけていることを簡単にまとめました。日々良くなっていっているので、使える機能や面白い活用が思いついたら記事にしたいです。
