AWS サミット ロンドンAmazon CTO の Werner Vogels 博士は、先週の AWS (Amazon Web Services) ロンドン サミットでサーバーレス コンピューティングの価値について語りました。
「私たちが目撃したのは、アプリケーション全体がサーバーから切り離され、コードだけが実行されるという革命です。多くの企業がアプリケーションの大部分を取り除き、サーバー、VM、コンテナをコードだけに置き換えています」と、2016年7月7日の基調講演で彼は参加者に語った。「もしかしたら、もうサーバーについて考える必要はないのかもしれません。」
業界は仮想マシン（VM）ではなくコンテナ（管理にはAmazonのECS（EC2 Container Service）など）を使用するという考え方に慣れつつある段階なので、コンテナが既に「廃止」されつつあるという考えは意外に思われるかもしれません。しかし、クラウドコンピューティングをIaaS（Infrastructure as a Service）ではなく、マネージドプラットフォームとして捉える考え方に賛同すれば、それも納得できます。
S3やDynamoDBといった初期のAWS製品では、VMやコンテナについて考える必要がなかったとヴォーゲルス氏は語る。「DynamoDBの設計を見れば、他のNoSQLデータベースもすべて管理が大変だということが分かります。シャーディング、バッファ管理、コネクションプールなど、すべてはデータベースから一貫したパフォーマンスを引き出すためだけに必要だったのです。」
「DynamoDB を検討した際に、どれくらいの速さのパフォーマンスが必要かを管理する機能だけを与えてはどうかと考えました。どのくらいの読み取りと書き込みを実行したいかを教えていただければ、一貫したパフォーマンスで確実に実行できるようにします」と氏は述べた。
これらの初期のサービスではコードを実行することはできませんでしたが、Amazon が 2014 年 11 月に Lambda を開始したことで状況は変わりました。これは当初、Amazon のストレージ サービスである S3 にファイルが到着するなどのイベントによってトリガーされる JavaScript でコードを記述する方法として提示されましたが、多くの種類のアプリケーションをサポートする可能性があり、開始以来大幅に進化しています。
現在、LambdaはJava、Node.js、Pythonをサポートし、スケジュールされた関数とイベントトリガー関数の両方をサポートしています。また、AWS VPC（仮想プライベートクラウド）に接続してプライベートネットワークにアクセスすることもできます。コードストレージの上限は5GBから75GBに増加しました。Lambdaは、API構築用のAPI GatewayやAWSリソースのグループを定義するためのCloudFormationなど、他のAWSサービスと連携することも可能です。
「コードを少し書いて、あとは私たちが実行します」とヴォーゲルス氏は述べた。「デプロイメントモデルはコードです。バージョン管理は引き続き行います。各関数の実行時間は数秒、長くても数分です。そして、各関数は単一のスレッドと単一のタスクを持ちます。必要に応じて、これらのLambda関数を数万、あるいは数十万個も並列実行することも可能です。料金モデルはもはやVMあたり時間単位ではなく、一定期間に保持したメモリ量と処理したリクエスト数の組み合わせに応じて支払うことになります」とヴォーゲルス氏は述べた。
彼の説明から、Lambda を使うのはコードをアップロードするだけという単純なものではないことがわかります。必要なメモリ量や、関数の実行時間がエラーでタイムアウトするまでの時間を指定する必要があります。とはいえ、Lambda は実行される VM やコンテナを抽象化します。ただし、Lambda のブレイクアウトセッションで参加者が学んだように、サービス自体はコンテナを介して実装されています。
AWS Lambda のメモリ設定の構成
この種のサービスを提供しているのはAmazonだけではありません。MicrosoftはAzure Functionsを、GoogleはCloud Functionsを、それぞれクラウドコンピューティングプラットフォームの一部として提供しています。
Microsoft、Google、Salesforceなどの他のクラウドプラットフォームでは、VMやコンテナを管理せずにアプリケーションを実行できるサービスが以前から提供されているのも事実です。GoogleのApp Engineは常にこの方法で動作してきました。MicrosoftのAzure App ServiceはVMを管理しますが、インスタンスは完全に抽象化されているわけではありません。
とはいえ、「サーバーレスコンピューティング」という用語は通常、モノリシックなアプリケーションをホストするプラットフォームではなく、小規模なマイクロサービス型の機能で構成されたアプリケーションを実現するプラットフォームを指す言葉です。典型的なアプローチの一つは、サーバーレスプラットフォームを使用して他のクラウドサービスを統合することです。これはクラウドプロバイダーにとって非常に有利であり、彼らが熱心に取り組んでいる理由かもしれません。例えば、Lambdaを他のAWSサービスと組み合わせて使用する可能性が高くなります。
「サーバーレスの世界では、もはやコンテナについて考える必要はなく、コードを書くだけで済みます。管理されている様々なパーツを繋ぎ合わせるだけで、すべて自動的に管理されます」とVogels氏は述べた。
アナリストの James Governor 氏が指摘するように、サーバーレスとは「オンデマンド コンピューティングを自然な形で実現したもの」であり、コードが実行されたときのみ料金が発生する、「顧客にとって価値のあるポイント」です。
サーバーレスは未来のテクノロジーでしょうか？その代償として、コードの実行方法に対する制御力の低下、クラウドプロバイダーにコード実行のために支払うマージンの増加、そして既存のアプリケーションを新しいモデルに移植するのが難しいという問題があります。
サーバーレスモデルが気に入ったとしても、そこに到達するには長い道のりがあることをVogels氏は率直に認めています。それでも、コンテナベースの新しい大規模プロジェクトに着手する前に、サーバーレスも選択肢の一つになり得るかどうか検討してみる価値はあります。®
