サーバーレスという言葉が広く受け入れられるようになったのは7年ほど前だが、その使命は20年近く前からありました。実際、Simple Queuing Service（SQS）とS3（2004年と2006年に開始）は、常にサーバーレスでした。これらは、プロビジョニングされた容量に関連するコストと複雑さを軽減することで、迅速な実験を可能にしました。クラウド・コンピューティングの初期には、データセンター・プロバイダーが「クラウド」を乗っ取ろうとし、明らかにクラウドではないサービスに「クラウド」のステッカーを貼り始めました。サーバーレスにも同様の傾向が見られる。サーバーレスの採用は非常に効果的であり、サーバーレスのステッカーをサービスに貼ることで、サービスをチェックしようとしています。サーバーレスの誤った表現は広く混乱を引き起こし、サーバーレスのミッションを希薄化させる危険性があります。

そして幸運なことに、本物のクラウドは、サーバーレスのスラップオン体制がもたらす脅威を克服しました。クラウド・ウォッシャーたちを罵倒し、何がクラウドの本当の姿なのかを明らかにすることは、クラウドがプライベート・データセンターよりも優位に立つ上で極めて重要なことでした。このブログでは、サーバレスの真のミッションを主張し、サーバレスではないものを概説し、サーバレスの盗賊を素早く見分けるための簡単なリトマス試験紙を提示します。

サーバーレスとは何か？そうでないものは何か？

サーバーレスの使命は、参入障壁（コスト、複雑さ、市場投入までの時間）を減らすことで、実験とイノベーションを加速させることです。製品が真にサーバーレスであれば、開発者の生産性が向上します。コンフィギュレーション、ベンチマーク、障害、プロビジョニング……これらすべての気晴らしが根絶され、開発者は単純により速くイノベーションを起こすことができ、維持するインフラはほとんど、あるいはまったくありません。このミッションは、サーバーレスの中核となる考え方で実現されています。

サーバーレスの核となる考え方

Simplicity 

サーバーレスには、より高いシンプルさのハードルがあります。設定も遅延もなく、ただ動くだけです。従来のサーバーベースの顧客は通常、より多くのコントロールを望んでいます。このコントロールは、インスタンス・サイズからインスタンス・ファミリー、インスタンス数、プロビジョニングされたキャパシティ・ユニットなど、コンフィギュレーションという形で提供されます。これらの抽象化を正しく行う負担は、サービス・プロバイダーではなく、完全にユーザーにのしかかります。これは、従来のクラウドインフラが悪いという意味ではなく、異なるトレードオフを選んでいるだけなのです。

インスタント・スタート‍

サーバーレスでは、開発者はAPIを1回呼び出すだけで、シームレスなプロビジョニングを体験できます。特定のインスタンスの起動やブートストラップなどを待つ必要はありません。S3でバケットをプロビジョニングするとき、バケットにリクエストを送り始める前にクラスタが立ち上がるのを待つことはありません。すぐに準備が整います。

瞬時の弾力性

弾力性は相対的なものです。クラウド以前は、物理的なサーバーの形でキャパシティを注文するのに数カ月や数週間で測られていました。最近では、数秒単位で計測されるべきです。サーバーレスは、インスタンス（仮想サーバー）が立ち上がるのを待つことなく、すぐにデプロイできるキャパシティを提供します。

デフォルトのベストプラクティス

サーバーレスには、構成、スケール、セキュリティなどのベストプラクティスが組み込まれています。一見すると、それは制限のように思われがちです。しかし、制限というものは、もどかしいものではあるが、実はあなたにとって良いものなのです。Redisに512MBのオブジェクトを最大20億アイテムのマップに格納することができるが、ある日誰かが単純なHGETALLの形でマップクエリからselect * mapを発行するまでです。このクエリは、大きなアイテム（または多くのアイテム）が誤ってマップに挿入されるまでは、問題なく動作します。ここでの爆発半径は、大きなアイテムだけではありません。クリティカル・パスにこのクエリーを持つすべての顧客である可能性があります。バグは起きます。制限のようなガードレールは、このようなバグが大惨事になる可能性を減らします。制限を設けることで、重大な障害、根本的な原因、トリアージとして現れるであろう注意散漫をなくすことができます。

偽サーバーレス盗賊のトリック‍

Provisioned capacity

サーバーレスは、プロビジョニングされた容量を前もって課すことはありません。キャパシティの確保についてヒントを得るのは構わないが、サービスを利用するために前もってキャパシティのコミットメントを要求することは、開発者に不必要な認知的・金銭的負担を強いることになります。プロビジョニング・キャパシティの危険性は、標準的なものにとどまらない（過剰にプロビジョニングした場合は高くつき、過小にプロビジョニングした場合は障害が発生し、あるいはその両方が発生します）。キャパシティのプロビジョニングには、キャパシティの管理、計測、ベンチマーキングが伴います。

これは私たちの信条のすべてに違反しています。単純ではありません。キャパシティのプロビジョニングを前もって行わなければならない場合、インスタンスが現れるのを待つことになり、高速ではありません。この専用キャパシティは、DynamoDBのような共有プールのように高速にスケールすることはできないので、即座に弾力的とは言えません。容量について決定しているのであれば、十分な容量という重荷を背負っていることは間違いありません。1つでも判断を誤れば、キャパシティに関連した障害が発生します。それはデフォルトではベストプラクティスではありません。

インスタントについて言及されていないオートスケーリング

率直に言いましょう。オートスケーリングは多くの場合、それほど自動的なものではありません。動作に時間がかかり、調整が複雑で、鋭いエッジを持っています。キャパシティの拡張は、キャパシティの管理を意味します。

オートスケーリングは、2009年に発表された当初は大きな恩恵でした。しかし、あらゆるものがサーバーレスになった現代では、オートスケーリングは遅すぎるし、複雑です。Time-to-Scaleは、負荷による停止か、スパイクを乗り越えて利用可能なままかを分ける重要な指標です。同様に、Time-to-Scaleが長すぎると、顧客はこの遅さを補うために必然的に過剰なプロビジョニングを行うことになります。

例えば、ElastiCacheの自動スケーリングには数十分かかることがあり、ベストプラクティスには、未使用の容量とコストを削減するためにスケーリングダウンを行わないことが含まれます。これでも十分辛くないのであれば、2つの次元（CPUとメモリ）のうち1つでしかスケーリングできません。これは簡単に言えば、”手動でオーバープロビジョニングした容量 “ということになるのです。

オートスケーリングがスパイクの持続時間よりも長くかかるということは、即座の弾力性がないことを意味します。サービス・プロバイダーは、オートスケールのルールを設定させ、スケールダウンしないなどのベスト・プラクティスを掲示するだけで、この問題から逃れています。

最低収容のキャパシティ

真のサーバーレスには最小限のキャパシティは存在しません。サーバーレス・サービスは参入障壁が低く、費用対効果が高いのが特徴です。最小限のフットプリントで、低スケールでの運用にはほとんどコストがかかりません。このスケール・ツー・ゼロ・モデルにより、開発者はキャパシティの過剰プロビジョニングによる関連コストを心配することなく製品を出荷することができます。偽サーバーレス・サービスには、年間コストが数千ドル単位で設定されていることが多くあります。これは通常、数学的な体操と開発者の大きな精神的負担につながり、重要なシンプルさの信条に真っ向から反します。

インスタンス

あなたのDynamoDBテーブルやS3バケットをサポートしているインスタンスはいくつあるでしょうか？おそらく多数だろうが、これらのサービスがサーバーレスであるのは、あなたがそれを知る必要がなく、成功するために心配する必要がないからです。サーバーレスインスタンスというものは存在しません。サーバーレスを装っているサービスのドキュメントにこのようなことが書かれていたら、あなたは容量管理に騙されているのです。

偽サーバーレス・サービスは、今やドキュメントで “サーバーレス・インスタンス “について語るほど図々しくなっています。スペードはスペードと呼びましょう。インスタンスは即座に立ち上がるものではありません。サーバレスインスタンス “盗賊団と仕事をしているのなら、インスタンスの数やサイズを伝えることは、シンプルさの信条に違反していることになります。インスタンスの数やサイズを伝えることは、シンプルさの原則に違反しています。インスタンスは、コンフィギュレーションという形で、ケアとフィードを必要とします。インスタンスを扱うなら、デフォルトでは存在しない厄介な設定を扱うことになります。

メンテナンス・ウィンドウ

今日の高可用性サービスには、計画的なダウンタイムは存在しません。サーバーレスにはメンテナンス・ウィンドウがありません。デプロイ、アップグレード、スケーリングのイベントは、あなたが知ることなく起こります。それこそがサーバーレスなのです。コア・テネットの警告：毎週のダウンタイムはベスト・プラクティスではありません。

サーバーレスのリトマス試験紙：すべてをまとめよう

そのすべてをもっとシンプルにしましょう。サーバーレスとはまさにこのことです！サーバーレスのためのリトマス試験（LTS）です。

このテストは、#fauxserverless bandit サービスを素早く特定するために設計されています。もしあなたが評価しているサービスが前述の基準のいずれかに違反しているなら、あなたはサーバーレスの世界にいない可能性は高いといえます。

Amazon DynamoDB On-Demandに対するAmazon Neptune Serverlessの例を考えてみよう。

Neptune Serverless

・NCU (Neptune Capacity Unit)を前もってプロビジョニングし、オートスケーリングルールでサイズを管理する。LTSの基準#1に違反します。
・最低2.5台のNCUを用意し、最終的に$3500/年以上のコストがかかる(リードレプリカが必要な場合は$7000/年)。LTS基準#2に違反する。
・技術的には1回のAPIコールで利用可能です（複雑なパラメータはあるが）。LTSの基準3についてはパスとしよう。
・Neptune Serverlessには週に30分のメンテナンスウィンドウがあり、その間にアップデートを開始することができます。これらのアップデートはウィンドウ内で終了することが保証されていないため、影響は毎週30分よりもずっと長くなる可能性があります。LTS 基準 #4 に違反します。
・Neptune Serverlessには “サーバーレス・インスタンス “があり、それを管理・監視しなければならりません。これはLTSの基準#5と#1に違反している。これらのインスタンスは漏れた抽象化であり、キャパシティを管理し、計画的なダウンタイムに対処し、アイドル状態のインスタンス（別名サーバー）に対してお金を支払わなければならないという事実の根本的な原因です。
・前節で述べたレッドフラッグはすべて、Neptuneのドキュメントに記載されている。

DynamoDB On-Demand

・プロビジョニング・キャパシティもオートスケーリング・ルールもありません。LTSの基準1、チェック。
・アイドル時にはコストがかかりません。LTS基準2、チェック。
・1回のAPIコールで準備が完了します。LTS基準3、チェック。
・計画的なダウンタイムやメンテナンスの必要はありません。 LTS基準4、チェック。
・インスタンスなし！LTS基準5、チェック。

結論

サーバーレスは世界に大きなインパクトを与え続けている。私たちは、あらゆるサーバーレスに向けてポジティブなトレンドに乗ってきました。しかし、最近開始されたサーバーレスを装ったサービスのせいで、「すべてのサーバーレス」の未来は危機に瀕しています。サービス・プロバイダーには、サービスを適切に表示・宣伝する責任を持たせましょう。

これはつまり、私たちもこの基準で私たちを評価してほしいということです。

サーバーレスのリトマス試験紙をテストしてみましょう！お気に入りのサーバーレス・サービスを選び、基準と照らし合わせてみてください。どうだろう？サーバーレスの定義を満たしていますか？もしそうでなければ、どこに不足があるのだろうか？あるいは別の方向から、少し楽しんでみるのもいいかもしれません。サーバーレスでないことは百も承知でも、サーバーレスであることを誇らしげに自慢しているサービスを選び、それがどのように評価されるかを見てみましょう。

私たち (@ksshams と @NoSQLKnowHow) と @momentohq に #fauxserverless の発見を知らせてください。説明責任はオープンな議論から始まります。楽しみにしています！