サーバレス革命はなぜ行き詰ったのか

原文(投稿日：2020/10/12)へのリンク

サーバは死なない、永遠に不滅だ！

あるいは、サーバレス革命の勝利の雄叫びが上がるのか。過去数年間の業界紙にざっと目を通してみれば、これまでのサーバモデルの命脈は尽きて、数年後には誰もがサーバレスアーキテクチャを運用するようになるだろう、という結論に行き着くのは簡単です。

しかしながら、この業界に従事する者ならば誰でも知っているように、そしてサーバレスコンピューティングの現状に関する私たちの記事でも指摘しているように、これは事実ではありません。数多くの記事がサーバレス革命の真価をうたっているにも関わらず、いまだ実現していないのです。事実、最近行われた調査では、サーバレス革命がすでに行き詰っている可能性が示唆されています。

サーバレスモデルが実現するといった約束は、いくつかは間違いなく現実になっていますが、すべてではありません。実現していないことが、まだまだたくさんあるのです。

今回の記事では、サーバレスモデルが明確に定義された環境においては極めて有用であることが分かったにも関わらず、システムとしてのアジリティやフレキシビリティの欠如が広範な採用への障害となっている、その理由について考えてみたいと思います。 

サーバレスコンピューティングが実現するもの

サーバレスコンピューティングの問題を取り上げる前に、それが提供するはずであったものは何か見てみましょう。サーバレス革命の約束するものは複数あり、- 時には — 非常に野心的です。 

この用語を見慣れない方のために、簡単に定義しておきましょう。サーバレスコンピューティングとは、一般的にはリモートホストされた実行環境内で、アプリケーションがオンデマンドに実行されるアーキテクチャを指しています。つまり、サーバレスシステムを自社内でホストすることも可能なのです。レジリエントなサーバレスモデルの構築は、この数年間、システム管理者やSaaS企業にとって大きな課題となっています。それはこのアーキテクチャが、"従来の"サーバ・アンド・クライアントモデルに対して、いくつかの重要なアドバンテージを提供するものだ(と言われている)ためです。

1. サーバレスモデルではオペレーティングシステムをメンテナンスする必要や、特定のOS用にアプリケーションを構築する必要はありません。開発者は汎用的なコードを書き上げて、サーバレスフレームワークにアップロードして、それが動作するのを見ていればよいのです。
2. サーバレスフレームワークに使用されるリソースは、一般的には分単位(あるいは秒単位)で課金されます。従ってクライアントは、実際にコードを実行した時間についてのみ支払えばよいのです。このことは、ほとんどがアイドル時間であるマシンに対しても料金を支払わなければならない、従来のクラウドベースの仮想マシンとは対照的なメリットです。
3. スケーラビリティも大きな魅力です。サーバレスフレームワーク内のリソースは動的に割り当てられます。従って、要求の突然のスパイクにも対応することが可能です。

これらを簡単にまとめて、サーバレスモデルはフレキシブルで安価、かつスケーラブルなソリューションである、と言われているのです。このように考えれば、これまでこのアイデアを思い付かなかったことが不思議な位です。

新しいアイデアなのか？

実を言うと、そうではありません。コードが実際に実行された時間に対してのみ料金を払うというコンセプトは、2006年にZimki PaaSの一部として導入されたものであり、Google App Engineも当時、これに極めて近いソリューションを提供していました。 

実際に今、私たちが"サーバレス"モデルと呼んでいるものは、"クラウドネイティブ"とされているテクノロジの多くより古く、実現していることもほぼ同じです。一部から指摘されているように、サーバレスモデルは、基本的には10年ほど前からあるSaaSビジネスモデルを拡張したものなのです。

また、両者に関係性はあるものの、サーバレスモデルとFaaSアーキテクチャは別のものである、という点も理解しておく価値があります。FaaSは基本的にサーバレスアーキテクチャのコンピューティングを重視した部分です。従って、システム全体を表すことなく、この部分のみを形成することができます。

今なぜ"サーバレス"なのか？発展途上国へのインターネットの進出速度が急速に高まっていることにより、コンピューティングリソースの需要も同じように増加しています。例えば、Eコマース部門が急速に成長している多くの国には、これらのプラットフォームを運用するためのアプリに対処できるようなコンピューティングインフラストラクチャが存在していません。従って、有償のサーバレスプラットフォームが必要になるのです。

サーバレスの問題

問題なのは、サーバレスモデルには"問題があること"です。誤解しないでください — サーバレスモデルが悪いとか、会社や状況によっては十分な価値を提供していない、と言っているのではありません。ですが、"革命"の中核的主張 — サーバレスが従来アーキテクチャを間もなく置き換えることになるだろう — が実現することは決してないのです。

その理由を説明しましょう。

プログラミング言語が限定されている

大部分のサーバレスプラットフォームでは、特定の言語で記述されたアプリケーション以外は実行できません。このために、この種のシステムのアジリティや適用性は著しく制限されたものになります。

確かに、ほとんどのサーバレスプラットフォームは、最も主流の言語をサポートしています。AWS LambdaとAzure Functionsでは、パフォーマンス上のコストを伴う場合が多いものの、サポート対象外の言語で記述されたアプリケーションや関数を実行可能にするラッパ機能も提供しています。従って多くの企業組織にとって、ほとんどの場合、この制限は大きな差異にはならないでしょう。それでも問題はあります。サーバレスモデルのメリットのひとつは、目立たない、使用頻度の低いプログラムを安価に運用できる点にあります。実行した時間分の料金のみを払えばよいからです。そして、目立たない、使用頻度の低いプログラムは得てして ... 目立たない、使用頻度の低いプログラム言語で書かれているものなのです。 

この事実は、サーバレスモデルの重要なメリットを損ねることになります。

ベンダロック

サーバレスプラットフォーム、あるいは少なくとも現時点でのその実装方法における第2の問題は、運用レベルでの共通点がほとんどないことです。関数の記述、デプロイ、管理方法に関するプラットホーム間の標準はないに等しく、そのために関数を特定ベンダのプラットフォームから別のプラットフォームに移行する作業には多くの時間を必要とします。

サーバレスのマイグレーションにおける最も困難な部分は計算機能 — 一般的にはコードのスニペットに過ぎない — ではなく、オブジェクトストレージや認証管理、キュー機能といった、アプリケーションが接続するシステムとの関わり合いの方法にあります。関数の移動は可能ですが、アプリケーションの他の部分がポータブルではないのです。これは、安価でアジャイルなプラットフォームという、サーバレスシステムの約束に反しています。

一部の人たちからは、サーバレスモデルはまだ新しいので、開発方法を標準化するのに十分な時間がないのだ、という主張があるかも知れません。ですが、すでに指摘したように、サーバレスモデルは新しくはありませんし、コンテナのような他のクラウドネイティブテクノロジの多くは、コミュニティを基盤とした強固な標準の開発と普及を通じて、ずっと使いやすいものになっているのです。

パフォーマンス

サーバレスプラットフォームのコンピューティングパフォーマンスの測定が困難な理由のひとつは、これらのサービスを提供する企業に、この情報を秘匿することの既得権益があるからです。大部分の企業は、関数をリモートで実行するサーバレスプラットフォームは、不可避に発生する遅延の問題を別とすれば、社内サーバと同じ速度で実行される、と主張しています。

しかし事例による証拠は、まったく逆を示しています。そのプラットフォームでこれまで実行したことのない、あるいはしばらく実行していなかった関数は、初期化のために時間が必要です。これはおそらく、そのようなコードがアクセス性の低いストレージメディアに移動されているためだと思われるのですが、サーバレスコンピューティングベンダのほとんどは、これに相当するケースについて — パフォーマンス統計と同じく — 公開していません。

回避策はもちろん、たくさんあります。そのひとつは、サーバレスプラットフォームが実行するクラウドネイティブ言語に合わせて関数を最適化することですが、この方法では、サーバレスプラットフォームが"アジャイル"であるという主張を多少損なうことになります。

 もうひとつのアプローチとして、パフォーマンスの重要なプログラムを短いインターバルで実行して"フレッシュ"さを保つ、という方法があります。この第2のアプローチは、当然ながら、プログラムの実行時間にのみ課金されるため最もコスト効率がよいという、サーバレスプラットフォームの主張とは矛盾しています。クラウドプロバイダはコールドスタートを抑制する新たな方法を導入していますが、その多くには"scale to one"モデルが必要なため、FaaSの元々の価値を損なうことになります。

このような"コールドスタート"の問題は、サーバレスシステムを社内で運用することで軽減できますが、今度はそれ自体のコストが必要になるため、リソースの潤沢なチームのニッチな選択肢という域を出ることはありません。

アプリケーション全体の運用ができない

サーバレスアーキテクチャが、当面は従来のモデルをリプレースすることはないという、最後の、おそらくは最も大きな理由は、アプリケーション全体をサーバレスシステム上で実行することが(一般的には)できない、という点です。 

正確には、もし可能であったとしてもコスト面で効率的ではない、ということです。完成済のモノリシックなアプリケーションを4ダースの関数に分割して、8つのゲートウェイ、4つのキュー、1ダースのデータベースインスタンスと接続する、というのは、おそらく不可能でしょう。このような理由から、サーバレスは新規開発向けなのです。既存のアプリケーション(アーキテクチャ)が移植されることは、事実上ありません。マイグレーションは可能でも、ゼロからのスタートが必要なのです。

これはつまり、ほとんどのケースにおいて、サーバレスプラットフォームは社内サーバの付属物として、大量のコンピュータリソースを必要とするタスクを実行するために使用されている、ということを意味しています。このことは、サーバレスプラットフォームを、コンテナと仮想マシンという、いずれもリモートコンピューティングを行う総括的手段を提供するクラウドネイティブテクノロジの2形式とは、まったく異なるものにしているのです。この事実が、マイクロサービスからサーバレスへの移行における困難さのひとつを表しています。

もちろんこれは、必ず問題になる訳ではありません。偶発的に必要となる膨大なコンピューティングリソースを、社内設備で実現する場合のようなハードウェア投資を必要とすることなく提供する能力は、多くの企業組織にとって現実的かつ永続的なメリットのあるものです。しかしながら、一部を社内で、残りをサーバレスクラウドアーキテクチャで運用するようなアプリケーションの実行管理には、アプリケーションのデプロイにおける新たなレベルの複雑性が伴う可能性があります。

革命万歳?

不満はたくさんありますが、私はサーバレスソリューション自体に反対はしていません。本当です。開発者は — 特に初めてサーバレスモデルを検討している場合には — このテクノロジがサーバの直接的なリプレースではないことを認識するべきだ、と言いたいのです。その上で、サーバレスアプリケーション構築に関するヒントやリソースを参考にして、このモデルをデプロイする上で最も良い方法を判断してください。

著者について

Bernard Brode 氏はMicroscopic Machinesのプロダクト研修者で、AIやサイバーセキュリティ、ナノテクノロジの交差が最終的に私たちに何を見せてくれるのかということに、永遠の関心を寄せています。