サーバーレス・コンピューティングの標準化は果たして進むのか？ | 東京エレクトロンデバイス

イベントドリブンとはなにか？

Amazon Web Services（AWS）が2014年に「AWS Lambda」を発表したことをきっかけに、「サーバーレス・アーキテクチャ」もしくは「サーバーレス・コンピューティング」が新たなアプリケーションの形式として注目され、先進的な開発者やユーザーを中心に普及が進んできました。

一般にアプリケーションを実行するには、コマンドラインなどにプログラムの実行開始コマンドを入力することが必要となります。しかしサーバーレス・コンピューティングが採用しているイベントドリブンな実行とは、利用者が明示的にプログラムを実行するというものではありません。あらかじめプログラムをイベントと紐づけて登録しておき、イベントが発生したら紐づいたプログラムが自動的に実行されるという仕組みです。

例えば「Amazon S3」ストレージの特定場所にファイルが保存されると、ファイルを保存するというイベントをきっかけにファイルを圧縮するプログラムが起動され、ファイルを圧縮して別の場所へ移動するといった動作が行われます。これがイベントドリブンな実行例です。

これにより、2つの大きなメリットが生まれます。

1つはサーバーレス・コンピューティングの利用者側のメリットとして、イベントが発生してプログラムが起動され、実行が終了するまでしか利用料金が発生しないという課金体系上のメリットです。これにより利用者は、アプリケーションを実行するための仮想マシンをプロビジョニングして確保し続け、仮想マシンを起動している間、ずっと料金を払い続けるといったことがなくなります。

アプリケーションが動いている時間だけ、つまり多くの場合、数秒から数分程度の時間が課金対象となるため、サーバーレス・コンピューティングでは従来のクラウド利用と比べて、利用料金が激減するのです。

もう1つのメリットはサービス提供者側にあります。利用者によって仮想マシンがずっと確保され続けることがなく、クラウド側でどのマシンでユーザーのプログラムを実行するかを柔軟にコントロールできるようになるため、クラウド基盤のメンテナンス、例えばOSへのパッチ適用や故障したハードウェアの交換などが容易になりますし、より効率的なコンピューティング資産の配分なども可能になります。

こうしたさまざまなメリットゆえに、イベントドリブンな仕組みを備えたサーバーレス・コンピューティングは、クラウドを活用するための優れたアーキテクチャとして有望視されているのです。

課題のひとつはベンダーロックイン

こうしたメリットの一方、もちろんサーバーレス・コンピューティングにも課題はあります。1つは、サーバーレス対応のアプリケーションは既存のアプリケーションのアーキテクチャとは大きく異なるという点です。そのため、既存のアプリケーションをサーバーレス・コンピューティング向けに移植するのは非常に困難で、アプリケーションを機能ごとにバラバラにしてイベントに紐づけるなど、ほぼ新規に作り直すようなものとなります。

もちろんプログラマーにとっても、イベントドリブンなアーキテクチャに対応するなど、新たなプログラミングのスキルが求められます。そのため多くの企業において、急速にサーバーレス・アプリケーションの普及が進むということにはならないと思われます。

もう1つの課題は、現時点のサーバーレス・コンピューティング向けアプリケーションは、AWS Lambda、Azure Functions、Google Cloud Functionsなどでそれぞれの互換性がなく、ベンダーロックインの傾向が強いということです。

前述のように、サーバーレス・コンピューティングはイベントドリブンであるため、AWSであればAWSが提供しているさまざまなイベントが対象となり、AzureであればAzureの、GoogleであればGoogleの、それぞれのクラウドのイベントがサーバーレス・コンピューティングと強く結びついているのです。そのため、AWS Lambda用のアプリケーションはAWSのイベントだけしか受け取りませんし、Azure Functions用のアプリケーションはAzureのイベントしか受け取らないといったことになります。

こうしたサーバーレス・コンピューティングが持つアーキテクチャの独自性やアプリケーションの非互換性といった点が、ベンダーロックインという課題の大きな要因になっているのです。

イベント情報を標準化するCloudEvents

このベンダーロックインを多少なりとも緩和するために、Kubernetes などの開発をホストする団体「Cloud Native Computing Foundation（CNCF）」が、イベント通知と記述の標準仕様である「CloudEvents」を策定、2019年10月に「バージョン1.0」に到達しました。

CloudEventsは、あるイベントが発生したことの通知と、そのイベントがどのようなものであるかを示すさまざまなメタデータの記述を、特定のクラウドに依存せずに可能にしたものです。具体的には、イベントID、ソース、バージョン、タイプ、イベントの内容、スキーマURL、発生時間などを含む、イベントにおける一般的なメタデータの記述方法が決められており、これをJSONなどでシリアライズし、HTTP、MQTTなどを用いて通信に載せてやりとりすることになります。

イベントゲートウェイ機能を持つソフトウェアなどを用いて、この標準仕様に沿ったデータ交換を行うことで、クラウドをまたいでイベントの通知ができるようになります。これにより、あるクラウドのイベントを別のクラウドで受け取り、それによってプログラムを実行するという、マルチクラウド構成のサーバーレス・コンピューティングが可能になるわけです。

すでに「Oracle Cloud」「Azure Event Grid」「Red Hat EventFlow」「SAP Kyma」「Event Gateway」「Knative Eventing」「OpenFaaS」など、CloudEventsに対応するクラウドサービスやゲートウェイなどが出てきています。

そのほかにもサーバーレス・コンピューティングをオープンにする試みとしては、オープンソースによるサーバーレス・コンピューティング基盤の実装があります。

“標準化”が2020年の重要トレンドに

このようにCNCFによる標準仕様の策定やオープンソースの開発などが行われているサーバーレス・コンピューティングですが、その標準化、すなわち各ベンダーが提供するサーバーレス・コンピューティングがCloudEventsに対応したり、あるいはKnativeやOpenFaaSなどを採用するなど、オープンソースによるサーバーレス・コンピューティング基盤の普及は今後進んでいくのでしょうか。

前述のように一部のベンダーはCloudEventsを一部採用しつつあり、またIBMはOpenWhiskをベースにしたサーバーレス・コンピューティングとして「IBM Cloud Functions」を提供するなど、標準化への動きはあります。しかし現時点でユーザーのマジョリティは、まだ「これからサーバーレス・コンピューティングに取り組もう」という段階です。

この段階を超えて、本格的にサーバーレス・コンピューティングの活用が多くのユーザーで始まらないと、マルチクラウドのための相互運用性やオープン性への本格的な要求は生じてこないのではないかと思います。しばらくはサーバーレスの標準化やオープン化も、ゆっくりとした歩みをとるのではないでしょうか。

ただし前述のように、サーバーレス・コンピューティングはクラウド活用一般においても、非常に重要なサービスもしくはアーキテクチャであると見られています。そうした位置づけの技術やサービスが標準化へ向かうこともまた確かであり、いざ本格的な活用が始まる段階では必ずや望まれることです。

そのためにも、サーバーレス・コンピューティングにおける標準化やオープン化の動きは、2020年の注目すべきトレンドといえるでしょう。

※本記事は東京エレクトロンデバイスが提供する不定期連載のタイアップコラムです。
※会社名および商標名は、それぞれの会社の商標あるいは登録商標です。