サーバーレスは最近の大きな流行語だが、そうなったのには正当な理由がある。開発者がコードを書く方法を、完全に変えてしまう可能性があるのだ。その世界では、開発者たちは単に連続するイベントトリガーを書き、後はクラウドベンダーたちに、その仕事を終わらせるために必要な計算リソースの確保の心配を、任せてしまうことができるのだ。このことによって、プログラムが開発される方法は大きく変化するが、このやり方はまだ極めて新しいものであるために、完全にこの方法を採用する会社を見出すのは難しい。
顧客たちがそれぞれの企業内で使うSaaS利用の管理を助けるスタートアップであるBlissfullyは、そうした構築方法を採用すると決心した企業の1つだ。共同創業者でCTOでもあるAaron Whiteは、Blissfullyの初期バージョンを構築する際に、ある組織が利用しているすべてのSaaSプロダクトのリストを提供するためには、計算パワーを一時的に、迅速かつ大量に調達する必要があることに気が付いた。
必要に応じてその爆発的な計算機パワーを提供するためには、沢山のサーバーを予備として確保しておけば良いことはわかったが、そうするためには管理対象となる膨大なオーバヘッドが必要になってしまう。彼はサーバーレスと従来の仮想マシンの長所と短所を見比べて、サーバーレスが実現可能なアプローチとみなし始めた。しかしこの時点では、彼自身のSaaS管理アイデアが実現可能であることを証明しようとしているのは、彼1人しかいなかった。
彼がその過程で学んだことは、Blissfullyのような、必要に応じてスケールアップとダウンが繰り返される瞬発的なアプローチをとる企業に対しては、サーバーレスは多くの利点を提供できるということだった。しかし、それは完璧ではなく、管理や設定、そしてスケーリング能力に関する長所と短所の取扱に関わる課題があり、彼はそれを実践しながら学んで行かなければならなかった。特にこのアプローチを取り始めた初期のころには問題が山積していた。
サーバーレスは合理的だ
Blissfullyは、サーバレスを利用することが大変理に適ったサービスだ。利用していないサーバーに対して、管理をしたり支払いを行ったりする必要はない。また、基礎となるインフラストラクチャについても全く心配する必要がない。そうしたことはクラウドプロバイダーに任され、発生したバースト（瞬発的な利用増加分）に対して支払いを行うのだ。
サーバレスという名称は実は正確ではない。サーバーが実際にないということを意味してはいないからだ。実際に意味していることは、プログラムを実行するためにサーバーをセットアップする必要がないということである。そしてこれは驚くべき変化なのだ。従来のプログラミングでは、データセンターであろうがクラウドであろうが、事前にコードを書き、基礎となるすべてのハードウェアをセットアップしておく必要があった。サーバーレスでは、開発者はコードを書くだけで良く、残りの全てをクラウドプロバイダーが処理してくれるのだ。
実際には、プログラマたちが一連のイベントトリガを設定する。するとクラウドプロバイダーはそのイベントトリガーの発生に合わせて、必要なリソースをその場で提供するのだ。今ではクラウドベンダーのほとんどがこの種のサービスを提供している。例えばAWS Lambda、Azure Functions、そしてGoogle Functionsなどがその例だ。
ある時点から、Whiteはサーバーレスを、インフラストラクチャの管理と維持について考えることから彼を自由にしてくれるものと考え始めるようになったのだ：「この先、何処までいけるか見てやろうと考え始めたのです。全てをサーバーレスで本当に行うことが可能なのか？そしてそうしたときに、実際に行うべき、膨大な従来型DevOpsスタイルの作業を減らすことができるのか？（訳注：DevOpsとは開発と運用を意味する）。まだまだ多くのことがありますが、ともあれまずそれが最初に考えたことだったのです」と彼は語る。
問題を克服する
しかし、それにも問題があった。特に彼がサーバーレスに取り組み始めた当初の問題が大きかった。まずなにはともあれ、Whiteはこのようなやり方で作業できる開発者を見つける必要があった。しかし2016年に始めたときには、サーバーレススキルを持つ人の数はまだ多くなかった。Whiteは、Blissfullyをどのよう実装するかに関わらず、学習に意欲的で新しい技術に柔軟に取り組む人間を重用し、直接的な経験をあまり重視はしなかったと語る。
一度基礎を理解した後は、これがどのように構造的に機能するかを考える必要があった。「チャレンジの一部は、異なるサーバーレス機能間の境界を、どこに置けば良いかを決定することです。1つの機能の能力を他の機能に比べて、どれくらい重いものにするかをどのように決定すれば良いでしょう？そして、それをどのように分割すれば良いでしょう？非常に細かい機能に分割することもできれば、もちろん非常に大きな機能にすることも可能です。このようにして動作するコードベースを、どのように分割したいのかという点で、多くの判断が必要となります」と彼は語る。
サーバーレスのアプローチの中で、彼がまず直面したまた別の課題は、それを取り巻くツールの欠如だった。Whiteは、Serverless、Inc.と出会うことができ、同社は彼を開発の基礎的フレームワーク部分で手助けしてくれたが、優れたログツールには欠けていて、現在でも彼の会社は、その問題には苦労しているのだと語る。「DevOpsはなくなりません。それは、いまでもどこかのサーバ上で実行されていて（たとえ自分でそれをコントロールしていないとしても）、問題は発生するのです」。そのような問題の1つが、彼が言うところの「コールドスタート問題」である。
リソースを正しく確保する
BlissfullyはAWS Lambdaを利用している。そして彼らの顧客がリソースを要求したときに、Amazomはそのイベントを待つための専用のリソースを確保していてくれるわけではない。もしサーバーをコールドスタート（実行が全く行われていない状態から起動を始めること）する必要がある場合には、結果的にこれは遅延の発生に繋がる可能性がある。この問題を回避するために、BlissfullyはLambdaを刺激し続けるジョブを走らせている。このことによって実際のアプリケーションを実行する準備が常に整っていることになり、ゼロから開始することで起き得る遅延時間がなくなる。
もう一つの問題は、これとは逆の問題かもしれない。対処可能な規模を超えて容易にスケールアップしてしまうことができるため、小規模のチームにとっては問題になってしまう可能性があるのだ。彼は、そのような場合には、呼び出し速度にリミッターをかけることになるという。そうすれば支払い可能な上限を超えることはないし、チームが管理可能な上限を超えて規模が大きくなることもない。「ある意味、このことによって、通常はもっと大きな規模になってから真剣に考えることになる問題に、より簡単に遭遇してしまうことになると思います」とWhiteは言う。
また別の問題は、Lambdaですべての処理を行うようになると、外部APIが扱うことのできる能力以上の速度でデータを動かしてしまう可能性があるということである。このため実際の実行を遅くするためのリミッターが必要となることがあるのだ。「Googleの場合は、多くの計算材料を与えることで速すぎると文句をいってくる様なことに遭遇したことは、ありませんでした。Googleの場合は速すぎると言われるためには、多大な努力が必要ですが、Lambdaの場合はあまり努力せずともすぐに速すぎると言われるようになります。どんなリソースであっても使うことを決定したときには、他のAPIに対して重大な出力ダメージを与える可能性があるのです」。それが意味することは、彼と彼のチームは本当に初期段階で、洗練された速度制限スキームについて本当に考える必要があったということだ。
コストに関しては、Whiteはサービスを構築し配置した今、コストはずっと安くなったと考えている。「当社のコストは現在非常に低いものになっています。サーバーベースのインフラストラクチャを使用している場合よりもはるかに低いものです。私たちの計算パターンは非常に瞬発的なものなのです」。この理由は。SaaSデータベースの再解析を行うのは、1日に1度か、最初に顧客がサインアップしたときであるからだ。その間のデータのやり取りは非常に少ないものなのである。
「ということで、サーバーレスは私たちとっては完璧な選択でした。なぜなら純粋に無駄になってしまうかもしれないリソースを維持し続ける必要はないからです」。
[原文へ]
（翻訳：sako）
写真：Vladimir_Timofeev / Getty Images
