#builderscon でサーバーレスについて発表してきた＋質疑応答の補足とか

8月5日(土)にbuilderscon tokyo 2017で「ここが辛いよサーバーレス。だが私は乗り越えた」というタイトルで発表してきました。運営の方々、本当にありがとうございました！
簡単に、発表と質疑応答の補足をしたいと思います。

発表で伝えたかったこと

buildersconは特定の言語や技術に特化したイベントではありません。「Lambdaの話」とか「AWSの話」とかはいっぱい話されているので、なるべくそこに限定されない「サーバーレスの話」をしたいなと思って発表内容を詰めていきました。

僕が発表で一番伝えたかったのは２つです。
・サーバーレスは「クラウドの技術」ではなく、サーバーレスのライフサイクルは自分で作れる
・マネージドサービスは「落ちる」かもしれないので、備えるべき
このうち２つめは、質疑応答でも出た話につながるので、あとで説明します。

サーバーレスに関して僕が感じているのは
・処理が必要なときだけリソースを確保し、必要がなくなれば捨てる
・処理は「関数」という形で抽象化されている
・処理が抽象化されているので、マネージドを使って楽ができる
です。Lambdaがあるからサーバーレスがあるのではなく、抽象化されているからマネージド(＝Lambda)で動かせる、という関係性です。したがって、サーバーレスのために作ったアプリケーションは、自分のローカル環境でも、Docker Swarmの上でも、EC2の上でも、オンプレでも、同様に動くように作れるはず、、、といった想いが伝われば幸いです！

質疑応答の補足

マネージドサービス(S3など)に障害が起きたときどうすればいいのか？

２つのケースがあると思います。

１つは、DAXのようなキャッシュ用途や、データレイクとしてのS3などの場合のように、信頼性が低くてもいい場合や書き込みだけできればいい場合です。この場合は、障害の起きてないリージョンに差し替えたり、一時的な避難先(例えばキャッシュであれば redis など)に差し替えれば良いです。理想を言えば、リージョンや実装を差し替えられるように、コードレベルで最初から考えておくとベターでしょう(発表で紹介した「WSGIで作る」もこれに含みます)。

一方で、データベースとしてのDynamoDBや、Kinesisなど、読み込みが必要なものに障害が起きた場合・・・は、まあ、どうしようもないと思います(笑)。どうしようもないのですが、「リスクマネジメント」の観点で考えておくと良いのではないかというのが僕の意見です。

リスクマネジメントの観点では、「障害の起きたときの損失×障害が起きる確率」が、「非マネージドのコスト(人件費など)」よりも安いかどうかを考えて、「マネージドのリスクを受け入れる」または「マネージドを選択しない」ということを考えます。このことに思いを馳せてマネージドを選択をすると、何か障害が起きても「まあ、しゃあないか」と受け入れられるようになります(笑)

Lambdaの実行制限数(1000)に引っかかったときどうすればいいのか？

まず大前提として、監視は入れておくのが良いと思います。

そして、AWSにお願いすると、同時実行数制限を引き上げできるとのことです(僕は引っかかって困ったことがなかったので自信のない回答でした)。

では引き上げのリクエストが間に合わないときにどうすればいいか、、、ということなんですが、もしAPIであれば、Route 53 にラウンドロビンさせるという手がありそうだなと思いました。Lambdaの同時実行数はリージョンごとにカウントされるので、14リージョン×1000同時実行数ぐらいいけるんじゃないでしょうか(笑)　もしくは、APIサーバーをEC2やオンプレに立てて、同様に負荷分散させるという手もあると思います。

お二方、ご質問いただきありがとうございました！

発表で心がけたこと

大きいカンファレンスで30分の発表というのは人生初だったので、いくつか心がけてみました。

・アイスブレイク：自己紹介スライドにSwitchのフレンドコードを貼ってみたのですが、ウケてよかったです。笑　ちなみにフレンドは増えました！

・発表練習：５回ぐらい発表練習したので、きっちり25分で発表できました。しかし、カンペ読んでる感が出てしまったのが失敗だったなと思います(カンペはなかったんですよ!!
・iPhoneでキーノートの操作：マイクが発表場所に固定された状態での発表だったので、あんまり意味なかったな、と反省しています。
・聴いてくれる方を向いて喋る：こちらの目を見て発表を聞いてくださる方が何人か居たのですが、反応がわかりやすくてすごく心強かったです、ありがとうございました！