ServerlessDays Tokyo 2022に参加しました

こんにちは、中山（ @k1nakayama ) です。

今回は2022年12月17日（土）にオンラインイベントとして行われたServerlessDays Tokyo 2022に参加したので、その感想や気付きなどをレポートしたいと思います。

ServerlessDays Tokyoとは

イベントページはこちらから御覧ください。

日本のServerless Communityとしては、2016年に初開催されたServerlessconf Tokyo 2016から始まり、東京で2019年まで4回、福岡で2019年に開催された1回の計5回のカンファレンスイベントとして開催されてきました。そして、コロナ禍に入り開催が出来ておらず、今回のServerlessDays Tokyo 2022は3年ぶりとなる開催でした。

私もコミュニティの運営メンバーとしては、2018年から参加させていただき、今回も運営メンバーとして登壇者の方と一緒にガヤとして参加させていただきました。

サーバーレスという考え方

昨今「サーバーレス」という言葉は、色々なベンダーが様々なサービスに対して謳っているため、実際のところサーバーレスとはなにか？が人によって捉え方が変わっています。

その中で、今回の吉田真吾さんが示した考え方として、共通認識となるはずの「サーバーレスで何を目指しているか」という考え方として下記の3点をとりあげていました。

上記についてまさにその通りであり、サーバーレスによって恩恵を受けられている部分だと感じています。また、これに付け加え私がこの話の中で伝えたこととして、「1人のアプリケーションエンジニアだけで、インフラレイヤーまでを含めフルスタックにデリバリーまでを行っていくことが出来るようになった。」つまり、1人のエンジニアのケーパビリティを広げることができる、というのもサーバーレスだから実現できるものだと考えています。（このあたりは「サーバーレスをオススメする理由」の記事でも触れているので、是非合わせてお読みください）

EventBridge

今回のセッションの中で、私が開催前に社内のメンバーなどに特にオススメのセッションとして伝えていた楽しみなセッションだったのがこの「見せてやるよ、EventBridge の本気ってやつをな」というタイトルのAWSさん+トリさんのセッションです。

このセッションの中ではEventBridge について、下記の様々な機能を分かりやすく説明していただいてました。

上記の中でAPI Destinationは、Slack等のAPIへイベントを送る場合、通常は送信先のレートリミットなどの制限や、認証、またリトライなど様々なことに気を配らなければならない上、送信先のAPIのレイテンシーが高い場合、これらをLambda上で実行していると、無駄なコストも発生してしまいますが、API Destinationを使用するだけで、イベントをAPI Destinationに渡した後はよしなにこれらの管理を引き受けてくれる機能になっていて、外部サービスなどと連携していく上ではとても心強いサービスだと感じました。

またSchedulerについては、イベントドリブンに将来のイベント実行を時間指定で予約したり、Cron式などで定期実行のイベントを追加することが簡単に行えるサービスということを知り、これも今までに何度となくやりたいけど実装がしづらかったものを、簡単に使うことが出来る機能でとても魅力を感じました。

そして、先日のre:Inventで発表された時点でとても魅力を感じていた機能なのが、EventBridge Pipesです。この機能は、SQSやStreamなどのデータを受け取って、StepFunctionsやEventBridgeのEventBusなどにデータを受け渡す際に、毎回それらをつなぎ合わせるための、いわゆるグルーコードを書いていたわけですが、これらが不要となる機能です。この機能については、後日詳しく記事を書きたいと思います。

上記の他にも様々な機能が紹介されていますが、EventBridgeはサーバーレスアーキテクチャではなくてはならない存在と言えるかと思いますので、とてもオススメしたいサービスです。

momento

momentoはサーバーレスなキャッシュサービスです。
これまでサーバーレスにおいて、キャッシュを行うためのサービスは存在しませんでした。この足りなかったピースを埋めたのが、momentoです。このセッションではmomentoを使用した事例や、デモなどを見せていただきましたが、このmomentoはめちゃくちゃ爆速なのにも関わらず、利用料もめちゃくちゃ安く、ほとんどの場合無料枠で収まっているそうです。どれぐらい速いのかというと、DynamoDBとのベンチマークをデモでお見せいただきましたが、基本的にDynamoDBの倍ぐらいの速さでした。

DynamoDBを使っている中でもGetItemのように、Keyを直接指定で値を取得するようなケースがある場合、DynamoDBやElastiCacheの代わりにmomentoという選択肢を持っておくと良さそうです。

Amazon CodeCatalyst

こちらも先日のre:Inventで発表された新サービス（現在Preview)で、アプリケーション開発における統合ソフトウェア開発サービスという位置づけのサービスです。基本的には、用意されたBluePrintを選択するだけで、CI/CDやコード、テスト、プロジェクトマネジメントに関連した機能などを丸っと用意してくれるサービスです。

私がこのサービスの発表を聞いた際には、CodeStarに似たもう少し拡張されてBluePrintが用意されている開発支援サービスかな？という印象でしたが、今日のセッションを聞いて、これまでのCodeシリーズなどとは完全に別のものであり、私がCodePipelineなどになくて使いにくさを感じたPipelineのコード定義や、モノリポなどで必須となる変更されたファイルやディレクトリによってトリガーを分ける挙動や、GitLabで初めて感動を覚えたReviewAppなどのためのデプロイなど、これまでのCodeシリーズでは難しかったことが、一挙に出来るようになっていて、とても興味がわきました。

現状では自分たちのアプリケーションをBluePrintに登録することは出来ないようですが、このあたりも付いてGAしてきてくれたらとても良さそうだと感じました。

3factor app

今日のセッションのトリとなった北海道テレビの三浦さんの「サーバレスでVODとECをリニューアルして、さらにくっつけてみました！」のセッションの中では、これまで3年間に目まぐるしい進化を行ってきた話をお聞きし、短期間でここまで進めてこれていることに驚きました。

その進化の結果、なんと100以上のStepFunctionsのステートマシーンが作られており、それらがイベントドリブンに数珠つなぎとなって実行されている様子がありました。しかし三浦さんは、現在このStepFunctionsの数珠つなぎの中で、どこかのStateMachineで失敗してしまった際の処理や、リトライなどを考え、この複雑なStepFunctionsで行っている処理をどうしていくべきかに悩まれていました。

この点について、私からお伝えしたものとして、「3factor app」の考え方で、各StateMachineのステータスを、それぞれAppSyncに対してMutationしていくことで、イベントを管理しやすく、疎結合にし、耐障害性に強い構造に出来るのでは？という提案をさせてもらいました。

3factor appは私が最近知って、ユースケースによってはとても簡単にスケールしやすいアプリケーション設計にしていける考え方なので、マッチしそうなものには積極的に取り入れていきたいと考えているものです。この3factor appについても、後日詳細を記事に出来たらと思います。

DynamoDBテーブル設計

先程の三浦さんやコロニーの菅さんのセッションなどで、DynamoDBの設計について悩まれていました。このDynamoDBテーブルの設計については、普段から社内でも話題になりがちな点であり、中々難しいものかと考えています。

このあたりについては、DynamoDBのベストプラクティスに則って、アクセスパターンから設計をしていくのがよく、多くの場合画面の表示単位などでスキーマ構造を考えていくと、分かりやすいかと思っています。

DynamoDBテーブルの設計について、AWSの下川さんが詳しく説明している投稿があるので、このあたりなどを参考に設計をし直してみるとよいのかと思いました。

最後に

やっぱりServerlessDaysは最高に楽しいし、1日で得られたことが多くありました。
来年はオンサイト開催に戻してやっていこうということだったので、運営メンバーとしても、１人のエンジニアとしても楽しみです。