サーバレス運用を実現――「AWS Lambda」「Azure Functions」を比較する

クラウドを利用するにも、プロビジョニングといった手間やコストが発生する。だが、システムが自動でそれを実行できるとしたら、手間が大幅に下がる。ではどのように自動化すればいいのだろう。

公開 2016年09月08日 15時00分

著者

Kurt Marko

[TechTarget]

印刷する

Azure Functionsの公式Webページ《クリックで拡大》

　Amazon Web Servicesの「Amazon Web Services」（AWS）やMicrosoftの「Microsoft Azure」といったクラウドサービスには各種のメリットがあるが、こうしたサービスは依然としてオーバーヘッドを伴う。仮想サーバであれ、オブジェクトストレージバケットであれ、SQLデータベースであれ、使用する前にまずリソースを最適に提供する「プロビジョニング」をする必要がある。こうした必須とみられる要件が、クラウドを利用するためのコストや時間、手間を確実に増大させる。

　だがシステムが自動的にサービスをプロビジョニングし、別のアプリケーションからの通信といった各種のイベントに反応してジョブを実行できるとしたらどうだろう。これが「サーバレスアプリケーション」の背後にある考え方だ。サーバレスアプリケーションは「クラウドファンクション」とも呼ばれる。本稿では、2つのサーバレスコンピュ―ティングサービスであるAmazon Web Servicesの「AWS Lambda」とMicrosoftの「Azure Functions」について比較しながら確認する。

併せて読みたいお勧め記事

AWS Lambdaに関する記事

コンテナって何？

トリガーと対応言語

　クラウドファンクションは新しい概念だが、既に複数のベンダーがサービスを提供している。リーダー的存在はAWS Lambdaだが、他にもIBMの「IBM Bluemix OpenWhisk」、Googleの「Google Cloud Functions」、Azure Functionsなどのサービスがある。

　Azure Functionsは現在プレビュー段階だ。「Azure App Service」や「Azure WebJobs」といった既存のPaaS（Platform as a Service）を利用し、モバイルアプリケーションやブラウザベースなどに必要なアプリケーション向けバックエンドコンポーネントの開発を簡素化する。「JavaScript」や「C#」「Python」「PHP」などの言語で記述されたコードモジュールのセットを、下記の外部イベントをトリガーとして発生したときのみ実行する仕組みだ。トリガーとなるイベントはAzureに限定されず、サードパーティーやオンプレミスのシステムで発生するあらゆるイベントを利用できる。

ストレージコンテナ内の変化
メッセージキューに対する操作
公開されている「HTTP API」からのアクセス

　AWS Lambdaはトリガーを「イベントソース」と呼び、AWSの他のサービスや外部アプリケーションからも受け取れる。ユーザーはイベントソースとAWS Lambdaの関数をひも付けて利用する。例えば、AWSのクラウドストレージ「Amazon Simple Storage Service」（Amazon S3）のバケットにオブジェクトを作成する。そのとき、AWS Lambdaコードを実行する許可が与えられている場合、関数を実行するといった具合だ。AWS LambdaのイベントソースにはAmazon S3の他、AWSのデータベースサービス「Amazon DynamoDB」やSNSの通知、AWSのモニタリングツール「Amazon CloudWatch」のアクティビティーなどを設定できる。

　モバイルアプリケーションでAWSのソフトウェア開発キット「SDK」を利用し、公開されている「AWS Lambda API」を実行することで、オンデマンド機能を呼び出すことも可能だ。AWS Lambdaの関数は、「Node.js」やPython、「Java」などで記述できる。

コンテナの役割

　Azure FunctionsとAWS Lambdaはどちらもコンテナで動作する。ただし、実装方法や制限事項はそれぞれ異なる。

　Azure Functionsの関数はAzure App Serviceのコンテナアーキテクチャを使って構築する。料金プランには「App Serviceプラン」と「動的サービスプラン」の2種類がある。App Serviceプランでは、関数をその他のアプリケーションと同様に専用の仮想マシン（VM）で実行する。専用VMはコードが実行中かどうかにかかわらず、常に使用することが可能だ。App Serviceプランは関数を長期間継続的に実行する場合や既存のVMの使用率が低い場合などに適している。

　一方、動的サービスプランは関数専用のプランであり、関数を複数のVMに自動的にスケーリングできる。動的サービスプランは、実行時間が短い断続的なジョブに適している。

　AWS Lambdaの関数もコンテナで動作する。コンテナでメモリサイズや最大実行時間を設定する。関数がトリガーされると、AWS Lambdaはそうした設定に基づき、新しいコンテナを起動する。コンテナの設定と起動に時間がかかる。そのため同じ関数が繰り返し呼び出されたてから実行するまでのレイテンシを最小限に抑えられるよう、AWS Lambdaは起動したコンテナを一定時間保持する。さらに各コンテナは再利用に備えて、一定のディスク容量を一時的に確保する。ただしAWSによれば、AWS Lambdaは常にコンテナを再利用するわけではなく、場合によって新しいコンテナを作成することもあるという。

料金

　Azure Functionsにせよ、AWS Lambdaにせよ、サードパーティーが提供する同様のサービスにせよ、クラウドファンクションの魅力はその効率性とスケーラビリティにある。Azure FunctionsとAWS Lambdaの料金は、関数実行時間と実行回数に基づいて計算される。関数実行時間はGB／秒で計算され、GB／秒当たりの単価がある。

　関数は既に主要IaaS（Infrastructure as a Service）の標準機能となっているが、まだ新しく、急速に進化中のカテゴリーだ。今後、IaaS事業者が機能や言語のサポートを追加し、開発環境や継続的デリバリーツールとの連係を強化していく中での進展に注目したい。変化が期待される分野の1つに、設定ダッシュボードがある。イベントソースや関数のひも付けの件数を考えると、その役割は極めて重要だ。

　一般的には、既存のAWSユーザーはまずAWS Lambdaを試してみてから、他社の関数を試すと良い。Azureユーザーは、その逆だ。同様に、Azure Functionsが関数でJavaをサポートするまでJava開発者は、AWS Lambdaが必要であり、C#の利用者はAzure Functionsを使う必要があるだろう。

印刷する