Serverless Meetup Tokyo #13 に参加してみました
Serverless Meetup Tokyo 第13回 に参加してみました。
会場は Speee Lounge
ServerlessDays Tokyo 2019
というイベントの啓発（参加者、登壇者）ありました。私も参加しようと思っています。登壇は、、検討します（笑）
Azure Serverless 2019 Summer Edition
三宅 和之（ 株式会社ゼンアーキテクツ）
自分は普段AWSの世界に浸かられてるのでAzureは新鮮でした。Azure Functions ではが C# と Node.js が主流だが最近 Java が最近サポートし始めてる。 Runtime は全てOSSらしい。
Azure Functions v2 はオススメ！v1と違って、v2はgRPCを利用して基盤となる.NET Coreとワーカーを分離することによって軽量化できたらしい。なるほど。
Premium Planを使えば “Pre-warmed instances” という機能は使える – これはお金払ってもAWS Lambdaも提供してない。（ 起動時間はいつも改善しようとしてるらしいけど・・・）
TypeScript正式利用！これはすごいね。デフォルトで？どこでコンパイルされるんだろう？
Durable Functions: ステートフルファンクション。 AWSならStep Functions？概要読んだところ、コード（C#, F#, JavaScript）で定義できるのは面白いですね。
KEDA “Kubernetes-based Event Driven Autoscaling”.
Azure Cosmos DB – DynamoDBみたいなやつ。もっと機能があるように見える。Change Feed ≈ DynamoDB Streams。Change Feed から Azure Function を起動することができる。SignalR というものと組み合わせれば、WebSocketsにパブリッシュできそう。SignalRはDynamoDB Streams + Lambda + API Gateway WebSocket よりかなり簡易的に実装できそう！
SQL DB Serverless。AWS Aurora Serverlessと同じような挙動してるっぽい。いつか完全にリクエスト課金のSQLデータベースできるといいね。。
Azure 世界は OSS プロダクトが多いのでコントリビュートできる。
でも正直なところ、あまりAWSから移行する！という感じはしなかった。個人的にはTypeScript興味ありますが、C#など全然興味ありません（C#を勉強する前に、Rustをちょっと深掘りしたい・・）。ただ、冒頭の通りあまりAzureのこと触れないので、今回はとてもいい機会でした。
営業職から見たサーバーレス
「既存の開発メニューにはまらない」
「どうやってサーバレスをクライアントに売る？」
私は個人的には、「サーバレス」を直接うるんじゃなくて、サーバレスで運用が楽になった分、たとえ運用費を同じ額をもらってると特になると思う。（エンドユーザーからみたら、全く同じ方式）ただ、サーバレスで以前できなかったことを実現できれば付加価値として請求できると思う。例えば、サーバレスは急なバーストなどに耐えられる設計しやすいので、「安易に急なバーストを耐えられるアプリを作る」という提案はできます。それ以外は、あくまで最適化の手段の一つだと思う。
LambdaとDynamoDBでつくるIoTバックエンド
岡本 忠浩（ 株式会社MMM）
AWS SAM を使ってる。SAMで管理しきれないのは別レポジトリーのCloudFormationが。
100個以上のLambda関数。多い！６ヶ月をかけてエンジニア2人で作ってるみたい。なんて複雑なプロジェクト。。
DynamoDBのテーブル設計
始まりがだいたい良さそう。RDBのER図を書いて、アクセスパターンを列挙して、DynamoDB を設計する。「 Serverlessを極めるためにDynamoDBデータモデリングを極めよう」という資料を参考になります。
まあ、ベストプラクティスを従ってると問題ない、という感じだね。
変わってるところがあれば、 Go で定義を落とし込んでる。
DynamoDBトランザクションが10個に制限されてる。「簡易に超過する」いいえ、これはDynamoDBをRBDMSっぽく使うとそうなるけど、本当にNoSQLファーストな設計じゃないとだめ。（先ほどのServerlessを極めるために・・）
やっぱり、DynamoDBと限らないNoSQLは、「大量なデータに適した技術」なので、まだRBDMSを使った方が適切な場合は多いと思います。特に私がいるスタートアップ界隈は条件などが急に変わったりすると、アクセスパターンがかなり変わる。。アクセスパターンを更新するたびにデータベース設計も変えないといけなかったら、かなり厳しい感じします。DynamoDBを意識しない仕組みを作るのがベストというが、これは絶対にしちゃいけないこと。そうすると慣れてるRBDMSっぽいことをしようとする。
AWS Step Functions を使ってるみたい。私も使いたいと思って、以前自分で Lambda -> SQS -> Lambda -> SQS で簡易的に対応したけど、もっと複雑な課題があったら Step Functions の方が適切っぽい。
FaaS上のコードをもっとシンプルに書くためのトランスパイラ
木村 功作（ 富士通研究所）
https://github.com/fujitsulaboratories/escapin
正直、これって async await とどう違うのか？という疑問。技術自体はかなり凄いと思う！いつかトランスパイラー作ると面白いかもしれない。
まとめ
楽しかった！普段触れない技術や話に色々触れたので、非常に勉強になりました。