[追加再掲載] AWSのサーバレスアーキティクチャがすごそうなので、Azureでできるか考えてみた!

Azure Functions が発表されたため、追加再掲載

capture20160402212854159

過去に以下のような記事を書いていたのですが、予想していた App Service できるんじゃね?実装が発表されました。

虚構新聞ではありませんので謝ることはありません。

Build 2016 で発表されて以後、様々な人がAzure Functionsをいじり倒してくれていますので、詳しくは以下のリンクに譲ります。

Azure Functions – C#で Github Webhoook や VSTS Build 通知 を Slack に通知してみた

Azure Function で Slash Commands 作ってみた

Azure Functions で使える Dynamic Service Plan について調べてみた

Azure Functions は Storage Blob のトリガーをリアルタイムサポートして欲しい

簡単に Azure Functions とは、このブログでも過去に触れていたように、イベントトリガーによってコールされる Serverless アーキティクチャです。どうも見ていると、 App Service  WebJobs を拡張して作ったように思えますね。

対応言語

サービス 言語対応
Azure Functions C#, Node.js(JavaScript), Python, F#, PHP, batch, bash, Java, PowerShell
AWS Lambda Node.js (JavaScript), Python, Java (Java 8 互換)

CI統合

Visual Studio Team Services や GitHub / Bitbucket / OneDrive / Dropboxなどからデプロイ統合が可能です。

リモートデバッグ対応

リモートデバッグに対応しています、とても便利ですからVisual Studio Communityからでも初めて見るとよいでしょう。

Authentication/Authorization

おそらくは Oauth2 によるものですが、Azure Directory B2C の機能を生かして、各 IdP との連携認証を持っているようです。

AAD / Facebook / Google / Twitter / MSアカウントなどが連携できそうです。

実はVNETの中にも展開可能に

勘の良い人は、すぐに気が付くと思いますが、 VNET の中に App Service を展開する方法があります。

つまり、 Azure Functions も VNET の中で、 Dedicated な自前インスタンスとしても実行可能となります。

Runtime は 実は既に公開済み

Github をお散歩していると以下のようなリポジトリを見つけました♪  MIT ライセンスですね。書いたソースがどこでも動く事は、ソフトウェアの資産の維持や移植などの手間を下げますので、とても有意義な事と思います。

注意点

現在はまだプレビュー扱いですので、処理できる量にはLimitがあるかもしれません、よく確認してから使ってくださいませ。

— ここからは古い記事です。

AmazonLambda-200x200.png

AWSのサーバレスアーキティクチャ

LambdaとAWSでサーバレスアーキティクチャという言葉が盛り上がっていたので、調べてみることにしました。日本語の資料だとこれだろうか 、プロセス管理モデルに踏み込んで解説をしてくれておりとても良いと思いました。

まだまだ、未熟で私も十分に理解してるとは思えませんので、皆さんの忌憚なき意見をお待ちしています。

サーバーレスアーキテクチャという技術分野についての簡単な調査によると

  • メンテナンスすべきアプリケーションサーバーがなければメンテナンスコストはかからない
  • サーバーレスアーキテクチャは「非常駐型プロセス」をイベントによってトリガーするインフラストラクチャ
  • 開発者はインフラストラクチャに関する仕事の多くから解放される

なるほど、とても素晴らしいじゃないの!!もう少し読み込んでいくと、このアーキティクチャは

  • Unixでいうデーモン(サーバプロセス)を常駐しない事で、無駄なリソースを使うことをやめよう
  • 必要な時、イベントトリガーに合わせて、プロセスを起動して応答すればいい

消費リソースも少ないし、サーバプロセスがないから、サーバーレスアーキティクチャなのね!

API Gateway経由のLambdaファンクションの応答時間は「早いと250 msec、遅いと8000 msecぐらい

との事だけど、リソース食うよりはいいよね、プロセスの起動時間を引くときあるけどね!

Azureが提供するサーバレスアーキティクチャ

capture20160314125318234.pngAzureにはApp Serviceという、PaaSサービスがあります。

  • Web Apps
  • Mobile Apps
  • Logic Apps
  • API Apps

さて、これらのサービスの中でAPI Appsの話をしましょう。
API Appsは名前の通りAPIを作成するPaaSサービスです。NETとJavaとNode.JSで開発ができ、自前のAPIをホストしたり、カスタマイズしたりする事ができます。

それらのAPI管理や配布したAPIキーとユーザーの管理などは、別にAPI Managementというサービスで管理ができます。AWSでいうAPI Gatewayみたいなもので、よく似たサービスです。

さて、本題です。

API Appsにデプロイすると、AppServiceアプリケーションプールという監視プロセスの管轄下で、デプロイされたプロセスは管理されます。

アプリケーションプールは、
これらのプロセスを常駐させません。

理由は簡単で、そもそもAppServiceがサーバーレスアーキティクチャだからです。

AppServiceではAWS Lambdaと同様で、プロセスが必要になった際(APIへのアクセスなど)によって、はじめてプロセスが起動します。

そして、実行時間範囲を超えるプロセスや使われなくなったプロセスは強制的に閉じられます。また、プロセスとディスク領域はchrootとよく似た仕組みで、アプリケーション同士が分離(アイソレーションといいます)されて常に管理されます。コンテナ化に似たような仕組みですね。

Azure AppServiceの共有サーバープランや無料プランは容赦なく時間で切られます、これによって一台のサーバに大量のサイトをホスティングする事を可能にしているのです。
占有プランにすると、この仕組みを持ったサーバを自前のものとして扱うことができます。常駐に設定を変更する事も可能ですし、デフォルトは非常駐となり、一定時間でプロセスは切られます。
AWS Lambdaの場合、どのように動作するかはわかりませんが、プロセスは5分間で強制的に切られてしまうのでしょうか、この辺りは調べてみたいところです。

ちなみに、このアプリケーションプールは、別段Azure固有のものではなく、Windows Sever 2003のIIS 6.0から導入された概念ですので、Windows Server 2003が提供された頃から存在しているものです。よって、別にAzureの世界ではサーバレスアーキティクチャは目新しい事ではなく、当たり前の世界として理解されています。

PaaSとサーバーレスアーキティクチャ

さて、サーバレスアーキティクチャはPaaSじゃない!!って話なのですが、Azureで提供しているApp serviceと呼ばれるPaaSサービスは2011年に提供を開始されてから、最初っからサーバレスアーキティクチャです。

って説明するのもなんか違うので、PaaSですって言っています。

開発者の視点からすればプログラムをプラットフォームにデプロイメントしている向こう側の話なんざ、どんなアーキティクチャだろうがベンダ責任範囲なのだからってのが、Azureのスタンスだったのでしょう。

なので、AzureではサーバレスアーキティクチャをPaaSで提供しています、他のプラットフォームにも移植可能な状態で手軽にAPIを作ることができます、JSONを入れたら自動的にDBスキーマも作ってくれるEasy APIなど便利な機能があります。

Azureが提供するサーバレスアーキティクチャを是非お試しあれ!