サーバレスか、コンテナか　歴史とともに振り返る、仮想化の次に来るもの

ゲーム開発にサーバレスを導入する

丹羽一智氏：みなさん、お忙しいなか来ていただいて、ありがとうございます。Game Server Servicesの丹羽と申します。よろしくお願いします。

さっそく始めさせていただきたいと思います。最初に自己紹介いたしますと、丹羽一智と申しまして、Game Server Services株式会社の代表取締役社長をしております。

2006年に新卒でセガに入社して、最初は携帯電話向けのゲームやサーバ開発をやっておりました。2009年に任天堂株式会社に転職をして、ニンテンドー3DSのOSやSDKの開発をして、その後ゲームサーバの開発・運用業務をやっておりました。2016年にGame Server Services株式会社という会社を創って、社長をしているという状態です。

最初に会社の説明をさせていただくと、フルサーバレスアーキテクチャ、FaaSと言われる技術を中心にモバイルゲーム向けの汎用ゲームサーバを開発して、BaaSとして提供するといった事業をしています。

なんでこれをやろうと思ったのかというと、各社がゲームサーバを開発していて、似たようなものをいろんな会社が作っているという現状に疑問を感じて。

任天堂で働いて汎用ゲームサーバを作って開発者に提供していた時は、任天堂プラットフォーム向けにゲームを作っている会社であれば、任天堂だけでなくサードパーティの開発者の人たちも同じ汎用ゲームサーバを使ってネットワークゲームを作れるという環境があって、ゲーム開発者たちはそんなにネットワークの知識がなくてもネットワーク対応のゲームが作れるという状態にあったんですが、モバイルのほうはそうなっていないというところが課題だと感じていました。ひと言で言うなら、ゲームサーバにおけるUnityみたいな存在を目指してサービスを開発しております。

来月で設立から2年というひよこスタートアップなんですけれども、今年3月にDeNA、KLabらから資金調達を実施しました。

主な採用事例として、お盆ぐらいに『私、茄子で飛びます。』というゲームがちょっとバズりました。バズった時は、けっこうアクセスがあったんですけれども、サーバレスアーキテクチャのおかげで、無障害でサービス提供をしております。

サーバレスアーキテクチャの歴史

さて、今回のお題はゼロの状態からサーバレスアーキテクチャの最先端に追いつこうということで、これを成し遂げるにはざっと歴史を追いかけるのが一番手軽というか間違いがないだろうということで、この歴史をまとめてきました。なので、順を追っていこうと思います。

まず、サーバレスアーキテクチャと言われるものの始まりと言えるのが、2014年11月、AWS Lambdaが発表された時です。

これまでもPaaSのあたるGoogle App Engineなどもあったんですけれども、「サーバレス」というキーワードを背負って拡大し始めたのはこのLambdaが発表されたタイミングからだと考えています。

じゃあ「AWS Lambdaってそもそもなに？」というと、これはAWS内のイベントをトリガーにしてクラウドに登録しておいた関数が実行されるという仕組みですね。

Amazon S3があって、ファイルをアップロードすると「S3にファイルがアップロードされたよ」というPUT通知がトリガーイベントとして通知されます。それがトリガーしてAWS Lambdaが起動すると、そこで事前に登録しておいた関数が実行されて、処理を終えたらサーバは破棄される、というのが一番ベーシックなAWS Lambdaの実行イメージです。

これが発表されたre:Inventのスライドです。

AWS Lambdaは、Easy to Use and Low Maintenance（簡単に使えて、メンテナンスコストが低く利用できる）というところが1つ目の利点です。

さらに、Very Rapid Responses to Event、イベントに対して素早く反応するところが重要だと。イベントに対してミリ秒単位で素早く反応してその関数が実行されるというところがLambdaの利点だと言われています。

AWS Lambda、先ほどS3にファイルが送れたらという話をしたんですが、イベントソースはS3だけでなくいろんなものがあります。

ここで例に挙げられていたのは、S3のアップロードやダウンロード。それから削除や更新といったイベントをソースにしたり。DynamoDB Streamsといって、DynamoDBというデータベースがあって、そいつへの書き込みで、アップデート、削除がイベントとして使えます。

ほかにもKinesisのイベント。Kinesisというのはストリームをするための仕組みで、ストリームにデータが流れてくると、Lambdaが起動されてそのイベントを処理できます。Custom Eventsとは、いわゆるAWS SDKを使ってLambdaをキックするというものですね。こういったものがいろんなデータソースとして、イベントソースとして使えるということになっています。

Lambdaの使用例

これがAWS Lambdaの使用例で、re:Inventではこんな例で紹介されていました。

S3に写真をアップロードします。そうするとLambdaが動き始めて画像のメタデータを解析します。画像のメタデータをDynamoDBに書き込む。そのあと、イベントがフックされて、そのメタデータに含まれる写真の位置情報などを解析する処理が走って、その位置情報をまたDynamoDBに入れるという処理をして。

さらにその近く、自分が「この近辺の画像がアップロードされたら教えてね」というようなことを登録していたとしたら、そのnotifyのファンクションが次に呼ばれて、アップロードされた画像の近くで画像がアップロードされたら教えてねと言った人に対してプッシュ通知を返す、というようなところを例として出していました。

先ほど言ったように、これは3つ関数を用意するだけで、複雑な仕組みを作れてしまうというところが新しい。しかも、それのインフラはとくに気にせず、書いたファンクションが動いていればサービスが動くというようなところが新しい発想だという話になっています。

「お高いんでしょう？」と思うでしょうが、これが100万リクエストあたり0.2ドル。あるいは、実行時間100ミリ秒×そのファンクションに割り当てたメモリの割り当て容量128MB。これをかけた値×利用料金として0.00000021ドルというような利用料金になっています。

「これはどれぐらいなの？」というと、常に回したらEC2よりは高いですが、EC2に関しては性能を100パーセント使いきれるわけないですし、そもそもアイドル時間があることを考慮すると、どっちがいいのかは変わってきます。

Lambdaの軌跡

この頃、アーキテクチャの名称はまだ定まっていませんでした。今はAWS LambdaはFunction as a Serviceと言われるカテゴリに属していますが、当時はDynamic Computingだったり、このLambdaがServerless Architectureそのものだというような言い方だったり、Serverless ComputingがLambdaだと呼ばれたりしていました。

現在は、Dynamic ComputingやServerless Computingといった呼ばれ方はあまりしなくなりましたが、Serverless Architectureという呼ばれ方は今でも残っています。

これはLambdaだけを指すものではなく、サーバの存在を感じさせないアーキテクチャの総称として、Function as a Serviceだけでなく、Backend as a Service、Platform as a Serviceも含むニュアンスで、今では利用されています。

2015年6月、発表から半年ほど経って、AWS Lambdaが東京リージョンで利用できるようになりました。

同じく6月、最初はNodeでしか利用できなかったAWS Lambdaでしたが、追加でJavaが利用できるようになりました。

2015年7月にはDynamoDBをイベントソースに指定できるようになりました。「これ、さっきre:InventのスライドでDynamoDB Streamsで更新されたらうんぬんって言っていたのでは？」と思うんですが、あの発表をしていながら、Lambdaの発表から8ヶ月ぐらいでリリースされました。

その後、2015年7月にAPI Gatewayというサービスが発表になりました。これは、RESTful APIを定義して、その定義したRESTful APIのエンドポイントに対してHTTPでアクセスをすると、そのアクセスしてきたエンドポイントにバインドされたLambdaが起動されるというサービスです。

2015年9月に、GS2という私の会社がやっているゲームサーバもAPI Gatewayを見て「これ、ゲームサーバに使えるんじゃない？」とふと思って、「できるか試してみよう」という感じで基礎研究を始めたのがこの時期です。

その後、2015年10月にJAWS Frameworkというアプリケーションフレームワークが公開になりました。現在はServerless Frameworkという名前になっていて、今ではおそらく一番勢いのあるFaaSのアプリケーションフレームワークだと思います。その前身であるJAWS Frameworkが公開されました。

新サービスが続々と追加

その後、2015年10月、Kinesis Firehoseがリリースされました。

このKinesis FirehoseはAWSのKinesisシリーズで、このKinesis Firehoseが登場した時にKinesis Analyticsというのと一緒に2つ登場しています。その前にはもともとKinesisと言われたサービスがあったんですが、それがKinesis Streamsという名前に同時に変わって、3つがKinesisのラインナップに上がりました。

その中でなぜでKinesis Firehoseだけをピックアップしたのかというと、このKinesis Firehoseだけが流量に対する課金になっているんですね。

Kinesis Streamsはシャードというのを事前に購入して、流量に合わせてそのシャードを自分で増やしたりしないといけないんですが、このFirehoseはシャードの大きさなども気にせずに、Firehoseに対してどんどんログを投げていくと、最終的にこのFirehoseに流れてきたログがS3に吐き出されるというサービスになっていて。

これが、Serverless Architectureでログ集約をする目的ですごく使いやすいサービスとして存在しているので、これだけピックアップしてみた次第です。

次にAWS IoTというサービスがpreviewリリースされました。

「なんでAWS IoT？」という思うかも知れません。IoTでしか使えないような名前に見えるんですが、これはフルマネージドなMQTTサーバなんですね。

MQTTはPubSubのメッセージングサーバで、メッセージプロトコルなんですが、そのサーバがキャパシティプランニングを一切せずに使えるというのがAWS IoTなので、これを使うことによってリアルタイムPubSubがサーバレスを実現できるということで、これをピックアップしています。

さっき9月に基礎研究を始めたという話をしましたが、これでいけそうな気がするという感触が得られたので、実際にゲームサーバとして作っていこうと思ったのがこの2015年11月です。

次に、2015年の12月、LambdaがPython 2.7をサポートしました。それまでNodeとJavaだったところにPythonが入ってきたという感じですね。

先ほどの2015年12月に、AWS IoTがGA（General Available）して正式採用するようになりましたと。

2016年1月、Lambdaのイベントソースに新しいものが追加されて、このEventsというものが追加されました。これは、要はcronなんですね。Lambdaを定期実行できるようになりました。出た当初は最短で5分間隔だったんですが、現在は1分間隔でイベントが設定できるようになっています。

なので、LambdaはさっきのAPI Gatewayだけで作ってしまうとすごく受け身なサービスになってしまうんですが、こういうEventsを使って非同期処理を組み込んでいくとちょっと設計の幅が広がってくる感じですね。

Google Cloud Functionsが登場

ずっとAWSの話をしていましたが、2016年2月にGoogle Cloud Functionsがαリリースされました。

これがGoogleが提供を始めたFaaSで、当時は招待制でαリリースされました。この時点での対応言語はNode.jsのみでした。

同じく2016年2月にはLambdaがVPCに対応。VPCはいわゆるEC2の仮想ネットワーク、プライベートネットワークですね。なので、このVPCにLambdaが対応したことによって、プライベートネットワーク内にあるEC2のリソースにアクセスできるようになりました。

なので、例えばS3に画像がアップロードされたときにDynamoDBにメタデータを書き込むという例が先ほどあったと思いますが、そのDynamoDBはグローバル（インターネット）に公開されたインターフェースを持ったデータベースなので、それで実現できるんですね。

このVPCにLambdaが対応する前だと、それがプライベートネットワーク内にあるデータベースに対して書き込もうと思っても、当然インターネットからプライベートネットワークにアクセスするのは穴を開ける以外になかったので、そういうRDBMSにメタデータを持ちたいなと思っても難しいということがありました。

このLambdaがVPCに対応したことによって、プライベートネットワーク内にあるMySQLにメタデータを書き込むというようなことができるようになりました。

これはすごくうれしい話だと思いますが、一方でちょっと使いどころが難しいところもあって。ここに書いてあるように、処理的には、Lambdaが起動した仮想サーバに対してENIと呼ばれる仮想NICを割り当てて、その仮想NICがVPCにコネクションを持っているということでLambdaがVPC内のリソースに触られるようになるという仕組みです。

このENIを割り当てるのに数秒から10秒ぐらいかかります。Lambdaにイベントが発生してそのファンクションが実行されるまでに、7秒ぐらいはレイテンシが発生することになります。

なので、例えばAPI GatewayでキックするLambdaをVPC内で動かしたいと思ったら、レイテンシが7秒ぐらいかかってしまうので、非常に難しい場合があると。管理用途や非同期処理などであれば使えるかなというところです。

あと、気をつけないといけないことがもう1つあって、Lambdaはスケールするとコンテナが増えるので、コネクション数がネックになるという点です。コンテナの最大数が想定出来ない用途にはRDBMSは向かないです。

IBM・Microsoftも参入

次に2016年2月にBluemix OpenWhiskがpreviewリリースです。

IBMが提供しているクラウドサービスがBluemixで、それがpreviewリリースされました。これもFaaSですね。

この時は、珍しいことにNode.jsとSwiftに対応した状態でリリースされました。現在でもSwiftが使えるのはこのOpenWhiskだけですね。最近発表されたGCPのServerless Containersというサービスは、コンテナのイメージを登録すればいいのでSwiftもいけるかな。でも、FaaSというかたちではOpenWhiskのみですね。

続々と各ベンダーが参入してきて、2016年4月にMicrosoftのAzureがFunctionsをリリースしました。これもNode.jsとC#のみの対応という状態です。

2016年5月に、ServerlessConfというコミュニティ主催のカンファレンスとしては初めての勉強会が、世界で初めてニューヨークで開催されました。

私が今着ているTシャツもServerlessConfのTシャツです。

来月末にTokyo第3回があって、今はまだチケットを売っている上に、今日Twitterで30パーセントOFFぐらいのクーポンがあるというのが流れていたので、興味があれば。

2016年6月にFirebaseがリリースされました。

Firebaseとは、Googleが2014年に買収したFirebaseという会社をGCPと統合してリリースされたものです。このFirebaseだけがちょっと特徴的で、さっきまで続々とリリースといっていたのはFunction as a Serviceが基本だったんですが、Firebaseはデータベースを軸にしたBaaSで。

データベースの構造をURLとして考えようというような感じで、パスがキーで、そのパスにアクセスするとそのキー以下のモデルがJSONで返ってくるような思想のデータベースですね。それをGoogleがGCPと統合して、GCPのアカウントで使えるようにしたFirebaseというのをリリースしました。

2016年9月にはGS2が創業しました。

同じく9月にはAzure FunctionsがF#に対応しました。

BluemixのOpenWhiskがβリリースになりました。この時にJavaとPythonにも追加対応しました。存在としてはあまり知られていないですが、精力的に開発をしていると思います。

次にAzure FunctionsがAPI Routingに対応。これがAPI Gatewayに対応したことで、RESTfulなAPIを定義して、そこからAzure Functionsが使えるようになりました。

なので、Function as a Serviceを各社出すというところから、そのFunction as a Serviceを使うためのエコシステムを作っていこうというふうに、だんだん舵が変わっていくタイミングですね。

2016年10月にServerlessConf Tokyoが初めて開催されました。これが世界で2都市目。先ほどのニューヨークに続いて2都市目で開催されました。私が創業したのが9月で、10月1日のイベントにGS2として登壇もしました。

サーバレスはどんな課題を解決するのか？

ここからその時の登壇のスライドを振り返ってみたいと思います。

内容的にはちょっと古いんですが、2016年10月1日に「サーバレスとマイクロサービスで変わるゲームサーバ開発」という題目で発表しました。そこから重要そうなエッセンスだけ抽出してお話ししたいと思います。全文はSpeaker Deckに上がっているので興味があれば見ていただければと思います。

この中で、なんでそもそもGS2という事業をやろうと思ったのかというところで「サーバレスという仕組みが出てきたからです」という話をしたあとで、じゃあなんでサーバレスは自分の課題を解決すると思ったのかという話をしました。

1つ目がスケーラビリティを確保すること。2つ目が可用性を担保すること。3つ目が保守性を確保すること。4つ目が価格優位性を確保すること。この4つの課題をサーバレスは解決するという発表をしています。

最初のスケーラビリティと2つ目の可用性はほぼ同じことだと思っていて、そこを1つにまとめて。

サーバレスの実行環境というのは、コンテナが定期的に破棄されるという仕組みを制約上、システムというのは状態を持ってはいけないですし、アップロードしたファンクションはそのアップロードしたときから不変であることから、Function as a Serviceを使うと絶対にImmutableでStatelessなシステムになると。

ImmutableでStatelessなシステムになるとなにがうれしいのかというと、分散処理ができるようになるんですね。状態を持っているサーバがないし、状態が変わって、同じ状態の変化がないコードがデプロイされたコンテナというのがたくさんあれば分散処理できると。

その結果、状態を持っていないということは、極端な話、サーバをボーンと捨てても次に起動したのが同じ状態なので、サーバ障害に対する耐性が強くなる。

しかも、ゲームサーバは事前にアクセス数を予測するのが非常に難しい分野で、ヒットしたときにはもう想定以上のアクセスが容易に発生すると。なので、こういうスケーラビリティや可用性のような要素は非常に重要ですね。

先ほど言ったようにImmutableでStatelessなので、サーバが1個ボーンと消えたところでなにも影響がないということで、可用性が高いということですね。

サーバレスによって生まれる優位性

次の保守性ですね。Lambdaは、例えばデータセンター、いわゆるAvailability Zoneに障害が発生しても、そのAvailability Zoneで処理をするコンテナを起動しなくなる。あるいは廃棄されたコンテナに仕事を割り当てなくなるだけなので、そのデータセンターが復旧したときにはそういった状態から復旧するというオペレーションまで含めて、すべてAmazonがやってくれます。

なので、サーバレス化することで、データセンターの障害によって、例えば「リタイアメントの連絡が来たんですが」というようなものや、そもそもインスタンスが突然死をするといったインフラのマネジメントから一切解放される。

なので、リソースリッチではないGS2にとって、このインフラの保守管理をすべてAmazonに任せることができるというのは、事業をやる上で非常に大きなメリットだというところです。

次に価格優位性についてです。これは2年前の時点での話なんですが、現在もそんなに変わっていないと思います。今はEC2や仮想サーバのインスタンスを調整してアクセス数に応じて価格を最適化するということをいろんな会社がやっていると。

サーバレスの場合、実際に関数が実行された時間に対して課金されるので、キャパシティコントロールということを一切しなくてよいと。さらに言うなら、アクセス数がないときには費用が発生しないので、価格的に非常に最適化できると。

Lambdaは関数を実行するときに、先ほど128MBあたりいくらというような話をしたと思うんですが、その割り当てるコンテナのメモリ容量はファンクション単位で設定ができるんですね。なので、「このファンクションはメモリをいっぱい必要とするからメモリを大きく割り当てよう」というように設定したり。

それをメモリ割り当てといっていて、実際はメモリだけじゃなくてCPUの速度やネットワークの速度なども全部比例して上がっていくようになっているので、「この処理は早く終わらせたいからメモリの割り当てを増やそう」という感じで、その関数の特性に合わせたリソースの割り当てができると。なので、柔軟にリソースの割り当てをすることで価格の最適化ができる。

こういう技術を使うことによって、普通は私が仮想サーバでゲームサーバを作ってBaaSとして提供しますというと、当然その利用価格は仮想サーバの価格よりも高くなるわけですね。私が運用したり開発したりすると利用料金に相当するマージンを取らないといけないので。

でも、こういうサーバレスをうまく使うことによって、仮想サーバを使ってゲームサーバを作るときとそんなに変わらない価格帯でGS2というサービスが提供できるようになったと思っています。それによって、競合が出てきたとしても、それなりの価格優位を持った状態で事業ができると考えています。

サーバレスの課題

次にサーバレスの課題の話をしました。いいところばかりではないという話ですね。1つ目が、要件によって言語を使い分けなければならないこと。2つ目が、ステートフルなシステムがどうしても必要な場合があって、そういうシステムを作るのはサーバレスでは難しい。さっきも言ったように状態が持てないというところですね。3つ目に、まだフレームワークが未成熟だよねという話をしました。

先ほど言語の話があったように、Lambdaはこの段階でPythonとJavaScript/Node.jsとJavaの3言語が利用できましたが、最初Javaで全部作ろうと思ったところ、これが大失敗でした。

Javaはコンテナの起動時に仮想マシンを起動することになるわけですよね。コンテナを起動してJVMを起動して、その上でアプリケーションが動き始めるというふうになっていて。このJVMの起動に4秒、8秒といった時間がかかって、しかも、動き始めたらものすごくメモリも食うんですね。

基礎研究や、なにかサービスを最初に作るというところはJavaでやっていたんですが、正直Javaは向いていなかったので、「ダメだ。これじゃサービスの品質にならない」と思って1回全部捨てて、Pythonで書き直すということをしました。

でも、Javaにもいいところがあって、起動してしまったらものすごく処理が速いです。PythonやNodeはFaaSの性質上JITが期待できないですよね。実行してそのコンテナが再利用されることもあるんですが、基本的に、実行時にコンパイルして、次回以降はコンパイルした結果を使って実行するというようなものはあまり期待できない。

ということもあって、APIのインターフェースにはPythonやNode.jsを使うのがいいのではないかと。バッチ処理はJava。今だとC#もありますが、そのあたりはバッチ処理には向いているかなと。

この時点では言及していないですが、Golangも最近はLambdaに一応対応して。Golangは言語としてまだ進化途中なので、プロダクトでどんどん中心に据えて作っていくと、もしかしたら負債になるかもしれない。今ツール周りではけっこう人気があるんですが、サービスの開発でガンガン使われているという印象がないのは、そういうところがあるのかもしれません。

少なくともサーバレスにおいてはGolangは最強で、バイナリをいきなり実行するだけなので起動もすごく早いし、実行速度もネイティブコードで速いというところで最強ではあります。

そういうところで、今まではとりあえず自分の好きな言語で開発してくればよかったんですが、この言語の特性に合わせて使い方を考える。あるいは使い方によって言語を変えるということをしないといけなくなりました。

ステートフルなシステムを開発するのが難しい

次に「ステートフルなシステムを開発するのが難しい」というところについて。サーバレスでアプリケーションを作ると、そのコンテナがいつ破棄されるかわからないということで、状態をサーバサイドに持つことができません。サーバに持てないので、データベースにデータを書き込んだり、キーバリューストアなどにデータを書き出すということをしないといけないんですね。

これが外部資源で、高速にアクセスできて、しかもお値段がお手頃というデータベースがないんです。2年前はないと言っていたんですが、現在もありません。

DynamoDBは読み書きがけっこう速くて、レイテンシも10ミリ秒以下で書き込んだり読み込んだりできます。その一方でこの変数の読み書きみたいなレベルでIOを要求すると高い。DynamoDBは「1秒間に何回書き込みしますか、何回読み込みしますか？」というようなキャパシティを予約して使うという感じなので、書き込み・読み込みをいっぱいするとその分高くなり、コスト面でちょっと厳しい。

一方で、「じゃあMemcacheやRedisを使ったらどう？」というと、今度はスケールしづらいという制約がくっついてきてしまうので、大量にアクセスが来たときにさばけるというFaaSの特徴を殺してしまうと。

じゃあファイルシステムにファイルを書き出していい感じにできないかというと、コンテナが破棄されると当然ファイルシステムは一緒に消えてしまうので状態を持つのは難しいという話ですね。ここは、札束で殴ってDynamoDBでいくという話になってきます。

次に、フレームワークがまだ未成熟。今はサーバレスフレームワーク、SAMと言われるようなアプリケーションフレームワークは複数出てきていて。もうわりと実績も出てきているのではないかと思うので、現在、この課題はそれほど障害にはなっていないとは思います。

ですがGS2が開発を始めた段階ではJAWSとかもまだまだ製品レベルに達していなかったというのもあって、今も自分でフレームワークを作って、サービスを作っています。

とにかく、ここではFunction as a Serviceはすごくとっつきにくて。そのとっつきにくさを取っ払うには、アプリケーションフレームワークの整備が今後重要になるよねという話をしていました。

仮想化の次はコンテナではなくサーバレス

次にサーバレスの未来として、青臭い話なんですが、仮想化の流れの次はコンテナではなくて、サーバレスなのではないかというのを2年前に言ってました。

なんでかというと、IaaSが世の中に出てきた時に、みんなハードウェアの管理……電源管理、ラックにどう納めるかというようなことを考えることから解放されたわけですよ。IaaSによってオンデマンドで必要な時に必要なだけのサーバが手に入るという世界を見たわけですね。

一方で「じゃあコンテナはどうだ？」と考えたときに、みんなEC2を並べてクラスタを作って、そのクラスタの上で動くコンテナを必要に応じて立てるわけですよ。

「せっかくハードウェアが持つキャパシティにどう仮想サーバを割り当てるかという話から解放されたのに、なんでコンテナになると、クラスタのサイズを気にして、そのクラスタの上でいかにコンテナを起動するかという話になってるんだ？」となるわけですね。

なので、このサーバレスというのはFunction as a Serviceのことを指しています。この頃はまだサーバレスという単語の定義が揺れていたこともあって、「サーバレスはアイドルリソースは完全になくなる」と言っているのは、Function as a Serviceはアイドルリソースがなくなるという話です。

この発表をするというCfPを出したときに、「サーバレスにコミットしたサービスをこの時期、この段階でやるというのに不安はなかったか？」というのを主催の吉田真吾さんに聞かれたんですよね。

当然、最初はFunction as a Serviceは枯れていないから、枯れていないがゆえに問題が発生することも当然あるでしょうと。でも、2010年頃に私が初めてS3を使うかどうかという話をしていた時に、当然社内から「いつかこのS3とやらは終わるんじゃないか？」「終わったらアップロードしておいた画像とかどうすんだ？」という話をしたわけですよ。

今、「S3が終わったら……」という話をする人は、よっぽどAWSを触っていない人でないとありえない話だと思っていて、サーバレスもいずれそうなるのではないかと。実際、今いきなり「Lambdaサービスが終了します」と言ったら、あちこちがたぶん燃え上がる状態にすでになってきていると思います。

これでServerlessConf Tokyoの振り返りは終わりです。