インタビュー: Microsoft Azure CTO マーク・ルッシノビッチ氏によるサーバーレスとエッジコンピューティングの交差点

Microsoft Azure にとって、2017 年はサーバーレスとエッジ コンピューティングの年として記憶されるでしょう。この 2 つのコンセプトは、同社の幹部が登壇するほぼすべての場面で取り上げられ、製品戦略でも大きな部分を占めてきました。

通常、これらは別々に議論されるのですが、先週サンフランシスコで開催された Structure カンファレンスで、Azure の最高技術責任者である Mark Russinovich 氏と話す機会があり、サーバーレス コンピューティング技術 (イベントと関数を中心に設計されたアプリケーション) とエッジ コンピューティングの交差点について話し合いました。エッジ コンピューティングとは、接続されたデバイスと産業用インターネットが進化し続けるにつれて、コンピューティングが中央データセンターから離れていくという概念です。

以下は私たちの会話を軽く編集したものです。

GeekWire: 少し理解に苦しむのは、サーバーレスは他のクラウドプロバイダーへのある程度の移植性を提供するはずだということです（一部の支持者によると）。しかし、実際にはほぼ逆のようです。特定のプロバイダーの機能を中心に構築した場合、その機能を別の機能プロバイダーに移行するのはそれほど簡単ではないようです。

Mark Russinovich: サーバーレスサービス（当社のもの、Azure Functions、（Amazon Web Servicesの）Lambda、Google Cloud Functions、OpenWhiskなど）を見てみると、それぞれが異なっていることがわかります。基本的に、これらはアプリケーション環境なので、それぞれのサービスに合わせてコードや操作を記述する必要があります。

ポータビリティに関して言えば、サーバーレスについて語る際には、その重要な要素として「as a service」という側面について語っていると思います。これは、サーバーレスを活用するアプリケーションの運用要件や設計にも影響します。プラットフォームが提供する機能、SLA、そしてどのようなパフォーマンスを実現するかといった点です。

ポータビリティ、つまり「このAzure関数をAzureの外部で実行できるか？」という点に関しては、これは私たちの明確な目標でした。オープンソースなので、このランタイムをあらゆる環境に導入できます。例えば、他のクラウドでも実行できます。ただし、その時点では「as-a-service」としての側面はありません。

サーバーレス（業界で採用されている純粋で標準的な定義）について見てみると、イベントドリブン、つまり自動スケールとマイクロビリングが特徴的です。しかし、自社インフラで運用する場合、マイクロビリングは適用されず、サーバーレスも必ずしも適用されません。なぜなら、基盤となるインフラを管理し、スケーリングロジックを記述する必要があるからです。

私たちは実際にはより広い定義を信じており、サーバーレスは一般的にマイクロ課金で自動スケール（アプリ）されると考えています。しかし、自動スケールとイベントドリブンは、一般的に短命なコードにのみ適用されます。関数は通常、1秒未満で実行されます。

私たちは、サーバーレスの拡張と、それに伴う長期実行コードの組み込みを信条としています。長期実行コードでは、プラットフォームがアプリケーションの要件を学習・理解しながら、自動スケーリングやオンオフの切り替えを行います。

Azure Container Instances を見れば、サーバーレスの定義を広げた一例がお分かりいただけるでしょう。コンテナ、例えば Docker コンテナを Azure にデプロイするだけで、仮想マシンを指定する必要はありません。コンテナの実行時間に対してのみ料金が発生します。また、イベント発生時に起動するコンテナではなく、長時間実行されるコンテナであっても構いません。

GeekWire: 長期実行とは何でしょうか?

ルシノビッチ：数分、数時間。

GeekWire: 何時間も実行されるイベントや関数を中心に構築されたものを作りたいのは、どのような場合ですか?

Russinovich: アプリケーションのバックグラウンド部分を扱う場合、専用の仮想マシンを用意する必要はありません。これらの機能を迅速に起動し、必要なリソースに対してのみ料金を支払う形で実行したいのです。また、基盤となるインフラストラクチャについて心配する必要もありません。

Azure は、ハードウェアを管理するという前提で、さまざまなクラウドで実行できるオープンなサーバーレス モデルをサポートしていますか?

Russinovich: Azure Functions の場合、ランタイムは Github にあります。誰でもそれを取得してどこからでも実行し、独自のものを実行することができます。

GeekWire: サーバーレスはエッジのモデルになると思いますか？エッジの展開方法もサーバーレスになるのでしょうか？

Russinovich氏: いいえ、必ずしもそうではありません。サーバーレスの定義は少し[間]明確に定義されていません。

開発が進むエッジプラットフォームを見てみると、デバイスと機能は実に多岐にわたります。ほんの少しのコードしか実行できない小さなデバイスから、PCクラスのデバイス、そしてAzure Stackのようなエッジデプロイメントまで、PaaS（Platform as a Service）サービスを備えた非常にリッチで高可用性な機能システムまで、多岐にわたります。人々が展開するコンピューティング処理を見てみると、サーバーレスだけではありません。長時間実行される機械学習モジュール、アプリケーションの一部である長時間実行されるコードを実行するDockerコンテナ、そしてアプリケーションの関数部分など、様々なものが存在します。

今日のクラウドアプリケーションアーキテクチャにおいて関数がどのように位置づけられているかを見てみると、多くの場合、関数はアプリケーションと外部世界、あるいはアプリケーション内の異なるコンポーネント間の接着剤として機能しています。しかし、関数はアプリケーションの長期的な側面もサポートしています。

GeekWire: (長くてまとまりがなく、後から考えるとかなり複雑な質問です。)

Russinovich: つまり、エッジでサーバーレス化を行う理由は何でしょうか?

GeekWire: そうですね。

Russinovich: エッジを見てみると、対応したいイベントが存在します。これらのイベントに応答するためのカスタムコードを用意することで、実質的には非常に特化したマイクロサービス、イベントドリブン型のマイクロサービスを構築できます。つまり、アーキテクチャを「これは継続的に処理を実行する長期実行部分」と「これは時折実行される部分で、これはそのイベントのみを処理する小さなコード」というように分解するのに適した方法です。

しかし、サーバーレスは開発者向けアーキテクチャ、あるいはアプリケーションアーキテクチャのメリットの方が大きいと考えています。特にエッジコンピューティングでは、ハードウェアリソースが固定されているため、クラウドのようなマイクロビリングや弾力性を活用できないという状況が顕著です。エッジコンピューティングでは、イベントドリブンアーキテクチャの利便性だけがメリットになります。

GW: リソースのセットが固定されている場合、サーバーレスでは従来のアプリケーション アーキテクチャを実行する場合よりもコストパフォーマンスが高くなりますか?

Russinovich:もちろん可能です。例えば、デバイスには一定量のRAMが搭載されているなど、アーキテクチャを設計する際には考慮すべき点があります。複数のDockerコンテナをデプロイし、それぞれにRAMを指定すると、基本的にそのRAMが、そのコンテナが実際に使用するかどうかに関わらず割り当てられることになります。

関数を使えば、関数を起動・停止させ、リソースを共有することができます。つまり、ある関数がアクティブでない時は、別の関数がその関数を使えるということです。ただし、アプリケーションを設計する際には、エッジデバイス上のアプリケーションのスループットとレイテンシの要件を満たすように注意する必要があります。多くの関数が同時に実行したい、あるいは実行する必要があるというボトルネックが発生し、それらを実行するためのリソースが不足してしまうような事態に陥らないように注意する必要があります。

私たちはまだその第一歩を踏み出した段階だと思います。今、エッジコンピューティングを見てみると、「これは固定された機能だ。このコードを書き、基本的にはデバイスに焼き付けられていて、自分では触ることはない」という世界から、「アプリケーションを分解してプッシュすれば、動的に更新可能なハードウェアになる」という世界へと移行しつつあります。

(そして将来的には)「最新のマイクロサービス アプリケーション アーキテクチャを実際に採用して実行したいのですが、それを確実に実行したいですし、さまざまなリソース、さまざまなレベルのリソースを持つデバイス群にわたって実行したいのですが、このアプリケーションを採用して公開したときに実際に正常に動作するという高い信頼性を確保したいのです。」

私たちはまさにその道を歩み始めています。そのレベルの洗練度が実現するまでにはしばらく時間がかかるでしょうが、エッジでリッチなアプリケーションを実行できるようになることで、エッジがますます戦略的になるにつれて、間違いなく有望な未来が待っていると考えています。

GeekWire: 質問したいのですが、実際にこれをやっている人はいるのでしょうか?

ルシノビッチ氏：デバイスのインテリジェント化が進むにつれ、この分野への関心が非常に高まっています。その大きな原動力となっているのは、エッジでの機械学習、つまりエッジAIです。私たちはこれに大きな関心を寄せています。だからこそ、クラウドでモデルをトレーニングし、そのモデルをエッジにプッシュしたり、モバイルデバイスにプッシュしてローカルで実行したりできるようになっているのです。

モデルは通常、より大きなアプリケーションの一部です。そして、そのモデルを自己完結的なユニットとして構成しつつ、他のものと相互作用させたいと考えています。例えば、イベント駆動型アーキテクチャでは、モデルは「オブジェクトを検出しています。そして、特定のオブジェクトを見つけたら、特定のアクションを実行したいのです」といった動作をします。

これがイベントになります。「このオブジェクトを見て、生成されたイベントをシグナルすると、それに対応する関数が呼び出されます。ねえ、このオブジェクトが見えますか？このコードを実行してください。」

GeekWire: こうしたシナリオの実際の応用例は何でしょうか?

ルシノビッチ氏：小売業では、この機能が求められるシナリオが数多くあります。倉庫環境や店舗環境、レジなどで起きていることに基づいてアクションをトリガーするといったものです。こうした場所では、お客様がこの機能を活用したり、活用したいと望んでいることが確かに見られます。

GeekWire: あなたの意見では、エッジ コンピューティングは主にイベント駆動型になるのでしょうか、それともより従来型のアプローチを実行する理由があるのでしょうか?

ルシノビッチ氏：両方になると思います。例えば、エッジに搭載したいのは画像検出のような物体検出です。継続的に実行されるものがあり、それを監視し、画像を生成・キャプチャし、処理します。そして、環境の動作に応じてイベントが生成されます。つまり、アーキテクチャには長期実行とイベント駆動の両方の要素が含まれることになります。

GeekWire: (サーバーレスへの業界標準のアプローチ) は存在すると思いますか?

ルシノビッチ氏：分かりません。いつか標準化されるかもしれないという話は出ていますが、まだ初期段階だと思います。

誰もが進化と革新を終える前に標準化するのは避けるべきです。それは単に進化と革新を阻害するだけだからです。標準化すべき核となるものが何なのか、まだ誰も分かっていません。

それがどのように進化していくかは、まだ予測が難しいです。なぜなら、私たちがサーバーレスのAzure Functionsをどのように進化させてきたかを見れば、（Amazon Web Servicesの）Lambdaと大きな違いがあるからです。私たちが持っているバインディングは、他のFunctionsのランタイムには見られないものです。

さて、皆がそれに同意し、皆がそれを望んでいると決めて、そのようなものを標準化するのでしょうか？それはまだ分かりません。それに、（マイクロソフトは）まだそういったイノベーションを終わらせていないと思います。