タグ: AWS Lambda

サーバーレスツールスタートアップのThundra（サンドラ）は、米国時間1月22日に、Battery Venturesが主導する400万ドル（約4億4000万円）のシリーズAを発表した。同社は、2018年に2億9500万ドルでAtlassian（アトラシアン）に売却されたOpsGenie（オプスジニー）から、スピンアウトした企業だ。

画像クレジット: Adrienne Bresnahan / Getty Images

ラウンドにはさらに、York IE、Scale X Ventures、そしてOpsGenieの創業者であるベルケイ・モラムスタファオール（Berkay Mollamustafaoglu）氏も参加した。Batteryのバッテリーのニーラジ・アガルワル（Neeraj Agarwal）氏は、契約条項に基づき、同社の取締役会に参加する。

このスタートアップはまた、最近Ken Cheney（ケン・チェイニー）氏をCEOとして雇い、技術創業者のSerkan Ozal（セルカン・オザール）氏がCTOになったことも発表した。

もともとThundraは、OpsGenieの中でサーバーレスプラットフォームの実行を支援していたツールだ。商用ツールとしてThundraは、AWS Lambdaでのサーバーレスワークロードの監視、デバッグ、セキュリティ保護を支援する。チェイニー氏は、これらの3つのタスクを別のツールとして提供するのは簡単だが、それぞれが互いに何らかの形で関連し合っているために、すべてを一体として提供することには意味があると語る。

「すべてを統合して、アプリケーション内で何が起こっているかをエンドツーエンドで表示します。これがThundraの本当にユニークな点なのです。実際に、絶えず変化するアプリケーションの高レベルの分散ビューを提供し、そうしたアプリケーションのすべてのコンポーネント、それらの相互関係、およびそれらのパフォーマンスを示します。また、ローカルサービスのトラブルシューティングを行うだけでなく、ランタイムコードを調べて問題の発生箇所を確認し、迅速に通知することもできます」とチェイニー氏は説明した。

同氏によれば、これにより、開発者は通常は難しいサーバーレスアプリケーションの非常に詳細なビューの取得が可能になり、インフラストラクチャ自身の基本部分に対する心配を減らすことができるという。そもそも開発者がサーバーレスを選ぶ理由が、アプリケーションにより多く集中するためなのだ。

Thundraの提供するサーバーレストレースマップ。スクリーンショット提供：Thundra

Thundraはこれらすべてを、（サーバーが固定されておらずリソースが一時的なために）問題の特定と修正が難しいサーバーレスの世界で行うことができる。これはAWSのLambda（AWSのサーバーレス機構）レベルに、またはライブラリレベルのコンテナに、実行時にエージェントをインストールすることによって行われるとチェイニー氏は語る。

Batteryのニーラジ・アガルワル氏は、OpsGenieに投資したことで、エンジニアリングチームを知ることができ、彼らがその内部ツールをより広く適用可能な製品に移行させることができることに自信を持つことができたと語る。

「これまでOpsGenieを育ててきた、エンジニアリングチームの品質に関係していると考えています。彼らは非常にマイクロサービス指向であり、かつ製品指向なので、製品の反復開発をきわめて迅速に行います。これは社内のツールでしたが、製品化の価値が高いもので、それをより広範な市場に販売できることに対してとても興奮しています」と彼は語っている。

同社は無料版を提供し、その後、使用量、ストレージ、データ保持に基づいて段階的な価格設定を提供する。現在の製品はクラウドサービスだが、近い将来にはオンプレミスバージョンを追加する予定だ。

サーバーレスは最近の大きな流行語だが、そうなったのには正当な理由がある。開発者がコ​​ードを書く方法を、完全に変えてしまう可能性があるのだ。その世界では、開発者たちは単に連続するイベントトリガーを書き、後はクラウドベンダーたちに、その仕事を終わらせるために必要な計算リソースの確保の心配を、任せてしまうことができるのだ。このことによって、プログラムが開発される方法は大きく変化するが、このやり方はまだ極めて新しいものであるために、完全にこの方法を採用する会社を見出すのは難しい。

顧客たちがそれぞれの企業内で使う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