LoginSignup
80
64
@nidcode(Akifumi Niida)

ServerlessDays Tokyo 2023が最高すぎた！

Last updated at Posted at 2023-09-25

はじめに

4年ぶりの開催となるServerlessDays Tokyoに参加してきました
https://tokyo.serverlessdays.io/

「もっとうまくやりたい、誰よりも上手にやりたい」

というメッセージとともに開催されたServerlessDays Tokyo 2023ですが、超豪華なスピーカー陣を国内外から集め、ここ数年のServerlessの成熟と未来をしっかりと味わえる濃いイベントです。

1日目がセッション、2日目がワークショップということで、熱力の高いうちに激熱なサービスを素早く学べる構成になっていて、とても充実した内容でした。

所感

4年前のServerless

LambdaをはじめとするFaaSをいかに簡単にデプロイ、運用していくかというツール系の話と
S3やSQS,SNSなどのFaaS以外のServerlessなサービスの組み合わせでLowOpsな仕組みを作っていこうという話が多かったと記憶しています。
ある意味当たり前になってきている部分もあり、正直キャッチアップしても面白くなくなっていた自分がいました。

今のServerless

今回のイベントで サーバーレスキャッシュのmomentoやサーバーレスRDBのTiDB Serverless、CDNだけでなくエッジコンピューティングの世界を切り開くCloudflareなど、Pay As You Goを実現したサービスが続々と紹介され、デプロイすれば使えたり、利用するだけという世界観になってきたと感じています。
そこにはとてつもなく快適な開発者体験があります。
自分自身インフラエンジニアですが、IaCってなんだっけ？なんで僕たちはCI/CDのパイプラインを頑張って作ってたんだっけ？という気持ちにさせられます。こういった武器をしっかり学んで提案、活用できるようになっていないと、この10年ぐらいで学んできたものがオールドスタイルに変わっていく事を実感しています。

去年の頭ぐらいからこの流れを感じて、少しずつキャッチアップしてきました。

「もっとうまくやりたい、誰よりも上手にやりたい」というメッセージは、世の中には新しい技術が出続けているので、自分がのっかっている黄金パターンに乗り続けるんじゃなくて、常に課題感をもって新しいことにチャレンジしていこうと解釈しています。

以下、セッションのメモ

雑多なメモなので読み飛ばしていただいて大丈夫ですｗ

[同時通訳]KEYNOTE: TBA Alex Debrie (AWS Data Hero, DynamoDBBook著者)

Serverless Now and Then

オンプレミス->EC2->Lambda
少しずつコンピュータのことを考えなくてよくなってきた。
Herokuから生まれたTwelve Factors Appの考え方に繋がる

サーバレスのカギ

なぜDynamoDBがポピュラーになったのか？

  • もともと書き込みスケールに対応したDBのはずだが、そこまで必要なユースケースはないはず

答えは「フルマネージド」がLambdaにマッチした。

  • VPCが必要じゃなかった
  • 接続の制限がない
  • IaCと素早いプロビジョニング
  • オペレーションが不要（ディスクやメモリー、ＣＰＵ、ファームのバージョンアップなど）
    RDSはこれらがない。。

サーバーレスのカギはマルチテナント
MomentoのKhawajaさん、PingCapのEd Huangさん、S3の開発者がブログでマルチテナンシーの重要性をブログに書いている。
メモできなかったけどこの当たり？
https://www.gomomento.com/blog/the-dark-art-of-multi-tenancy
https://www.pingcap.com/blog/some-notes-on-dynamodb-2022-paper/

今のサーバーレス

初期のサーバーレススタックはAWSヘビーだった

  • IaCに大きく依存していた（CloudFormationやServerless Frameworkなど）
  • AWSサービスの信頼性の高さがあって実現されていた

ここに適用しないものが出てきた

  • Auth0, Snowfalkeなど

ここから変わった

  • PlanetScale, TiDB, Momento, ...

いつAWS以外のサーバーレスサービスを使うのか

  • ユーザー体験
    • Auth0
    • Vercel/Netlify
    • PlanetScale: ブランチ、インサイト、自動アップデート
  • マルチテナントの機能が優れている
    • Snowflake
    • Algolia
    • TiDB, Momento

サーバーレスで成功できるチームのパターン

  • Platformを学ぶ
    • AWSのサービスが過剰になってきている。
    • うまく使いこなせるように時間をかけてレベルアップしていく。
  • チームに権限を与える
    • チームごとに自律性、自主性を与える。（責任も）
    • その方がより多く学べるし、より早く学べる
  • ツールを共有しよう
    • ローカル開発・クラウド開発
    • デプロイツール　安全に使えるか。場合によっては元に戻せるか
    • モニタリング　うまく機能しない時にどのようにFixしていくのか？ baselinerとかのサービスも有効　何がアプリケーションに起きているかを把握する
    • 全てを自動化する　インフラもアプリの一部になっているので自動化する。
    • パートナー選定を慎重にする　
      ゴールは「早く試行錯誤（実験）をしながら、Rapid開発」をしていくこと

KEYNOTE: The future is serverless / 未来はサーバーレスにあり Eric Johnson (Amazon Web Services)

サーバーレスを定義する

Lambdaがサーバーレスを定義した

  1. サーバー管理がない
  2. 自動でスケールする
  3. セキュリティがビルトインされている
  4. 使った分だけの支払い

サーバーレスのトレンド

認証、認可、ルーティング、ビジネスロジック。全てがLambdaに載った。
ExpressやFlaskを動かすパターンも出てきた。

全てをマイクロサービスにするのは狂気じみている → THE HYPER MICRO SERVICE
モノリスとの間はないか？ → THE BLENDED ARCHITECTURE

  • 論理的に分割されたコード（ドメイン）
  • ルーティング
  • ビジネスロジック
  • Webバックエンド
  • EDAアプリケーション
    • 何かが起きたら反応する

コンフィグのほうがコードより優れている

Lambdaなしでもシステムが作れる
API Gateway、DynamoDB、SQS・・・

同期から非同期へ

  • 同期型の場合、どこかがクラッシュした場合はサービスが停止する
  • APIがまずはDynamoDBやSQS等に保存したらリクエストを返す
  • 保持されたリクエストをコンピュートが処理する
  • 失敗したらリトライする

サーバーレスの未来

1.全てはサーバーレスになる

  • Event Driven アーキテクチャ（EDA）　すべてのサーバーレスはEDAである。
  • EDAは非同期がプライマリ

2.サーバーレスコンテナ

  • StepFunctionsでサイズを見て大きければ fargate , 小さければLambdaみたいなことができる

3.生成AI

4.開発者体験が良くなる

  • SAM
  • CDK
  • SST クラウドでデバッグができる
  • Infrastructure From Code(IFC)
    • Winglang.io
    • GetAmpt.com

KEYNOTE: サーバーを超えて： 開発者のために作られたTiDB ServerlessとChat2Query Max Liu (PingCAP創業者)

TiDB Serverless

サーバーレスのRDB（MySQL）

なぜTiDBサーバーレスを作ろうと思ったか

普通にやろうとすると5000億円以上年間でかかる。
1.トラディショナルアーキテクチャーをあきらめた
→スポットインスタンスを多用した　8割ぐらいコストカット→350億円ぐらいになる。

2.ストレージをマルチテナンシーモデルにした。

3.コンピューティングをもう少し分解

  • 軽い処理と重い処理を分ける
  • 重い処理はインデックスの再作成やテーブル定義の変更など。
  • 処理をマイクロサービスにして外出しする。
    結果として軽い処理は早くなったし、重い処理は規模の経済の恩恵を受けた。

TiDB ServerlessはAWSで動いている
MySQL互換だが、GoとRustで全部書いてる。
HTAP（列志向）があるので、スキャン系のGroupByとかがめちゃくちゃ早い。

Azure OpenAI Service リファレンスアーキテクチャからみる、本番システムレベルのLLMアプリに必要な検討項目の解説 坂部広大 (Microsoft)

本日のGOAL リファレンスアーキテクチャの歩み方と最初の一歩

10yrs lessons for Serverless practices and how to build LLM app using SST for startups Peter Sbarski (AWS Serverless Hero, 元ACloudGuru VP / Serverlessconf Chief)

Prime Videoをモノリスにしてコスト削減した話

  • ECSにうつしたことでSaving Planを使えたことでコスト削減でき、かつスケーラブルになった。
  • 最初は市場に早く投入するためにサーバーレスのアーキテクチャを採用した
  • LambdaとS3のアクセスが頻繁にあった（異常なほど）
  • マイクロサービスをリファクタリングしてモノリスになった。
  • これは過去のモノリスとは違うアプローチだ

ブログ

  • やっていることはVideoのエンコード、変換
  • LambdaでMap＆Reduceしていた
  • ビデオを区切ってLambdaで並列処理していた？

現在は開発者3人の小さな会社をやっている

  • serverless first
  • UX
  • Developer eXperience

SST Serverless Stack

  • CDKをWrapしたもの
  • ローカルで開発ができる。
  • AWSからローカルにプロキシするので、AWSのサービスをMockする必要がない。
  • ユーザー体験をコンテキスト化する。

Serverless GPU , Container

サーバーレスな開発ライフサイクルのモメンタムの変遷＋秋のサーバレス運動会　亀田さん

Cloudflareのビジョン

To help build a better internet
インターネットは私たちが思ってたよりも良いものじゃなくなってきたよね。

Cloudflare WokerがAWS Lambdaと違うところ

  • Region,VPCが存在しない
  • Node.jsサポートが限定的
  • Service Workers + Web WoekersベースでJavaScriptを実行
    • Service Workers: ページに対するプロキシとして通信に割込みが可能
    • Web Workers: マルチスレッドによる並列処理

Workersのアップデート

  • Workers Connect
    • OutboundのTCPソケット通信が可能になった。
      • ターゲットはRDB接続
  • Workers Smart Placement
    • 通信の特性を考慮して、最適な位置でWorkerを動かす。
      • 例えば、DBとの通信のやり取りが多い場合はDBに近い場所に移動してレイテンシーを下げてくれる等

秋のServerless運動会

1から1億まで足す処理で比較
以下、早い順

  • Cloudflare Workers Rust(WASM) → 196ms
  • Lambda@Edge w/o Cold Start → 215ms
  • Cloudflare Workers JavaScript → 601ms
  • Lambda Node.js w/o Cold Start → 997ms
  • Lambda@edge w/ Cold Start → 2.12s
  • Lambda Node.js w/ Cold Start → 2.43s
  • CloudFront Functions → Limit Exceeded

Storage

RDB,Cacheの接続オプション

  • Neon
  • PlanetScale
  • Supabase
  • Upstash Kafka
  • Upstash QStash
  • Upstash Redis
  • Momento!!!

Cloudflare Pages

  • CI/CDの自動化
  • すべてのブランチにステージング環境を提供
  • Cloudflare Accessによる保護されたプレビューリンク
  • フルスタックフレーム枠との連携
    • Next.js
    • Remix
    • SvelteKit
    • Nuxt
    • Astro
    • Qwik

You Build You Run it

CLOSING KEYNOTE Khawaja S Shams (Momento, 元Amazon DynamoDB VP)

なぜコミュニティが必要か？

コミュニティの人のつながりがあって技術が広がっていく
オーガナイザーへの感謝

Momento

Serverelessである理由

  • Security
  • availability
  • scale

MR2 Request Router

  • ホットキーがある場合に自動的にコピーすることでファンアウトできるようになっている

Vector Index

  • Vectorの特徴は似たようなＩＮＰＵＴを同一として扱うことが可能になる。

最後に

ServerlessDays Tokyo 2023のスタッフの皆様、スピーカーの皆様、素晴らしいイベントをありがとうございました！
とても心地よく参加でき、大きな熱量をいただけました。
また、Serverlessを盛り上げる一員として仲間のように参加できたこと、大変嬉しく思います。

80
64
1

Register as a new user and use Qiita more conveniently

  1. You get articles that match your needs
  2. You can efficiently read back useful information
  3. You can use dark theme
What you can do with signing up
Sign upLogin
80
64