Upgrade to Pro — share decks privately, control downloads, hide ads and more …

Bun がメジャーリリースされたけど、本当にBun はNode.js に取って代わるのか?をAWS Lambda で検証してみた

Makky12
November 18, 2023

Bun がメジャーリリースされたけど、本当にBun はNode.js に取って代わるのか?をAWS Lambda で検証してみた

2023/11/19(日) に開催された、JSConf JP における私のセッション「Bun がメジャーリリースされたけど、本当にBun はNode.js に取って代わるのか?をAWS Lambda で検証してみた」の発表資料になります。 #jsconfjp

https://jsconf.jp/2023/

Makky12

November 18, 2023
Tweet

More Decks by Makky12

Other Decks in Programming

Transcript

  1. 自己紹介 ◼ 名前: 鈴木 正樹 (Masaki Suzuki) ◼ 会社: 株式会社DeNA

    エンターテイメント開発事業本部 ◼ 職業: クラウドアーキテクト(というクラウド何でも屋) ◼ 技術・その他: • AWS(特にLambda), その他クラウドバックエンド全般, IaC (特にAWS CDK), CI/CD etc. • JavaScript(Node.js), TypeScript, Jestなど • JAWS-UG CDK支部, JAWS-UG 名古屋, AWS Community Builder (Serverless, 2023~) ◼ SNS: • @makky12 (SUZUKI Masaki@クラウドエンジニア) • @makky12.bsky.social • https://github.com/smt7174/ • http://makky12.hatenablog.com/ 3
  2. 前提 14 • プロダクトワークロードとして、AWS Lambdaを使用 • 「DynamoDBからランダムな1データ(※)を取得する」処理を実行する • 上記LambdaをAPI Gateway経由で実行する(=Web

    API) • 上記API Gatewayへのリクエストを20回行い、その結果を計測する ※ 使用するデータについては次スライドで説明
  3. 検証結果(単位は全てmsec) 17 ◼ やはりBunは速い!…と予想していたが、実際はNode.jsの方が速かった 平均差は116msなので、誤差と言えば誤差だけど、もっと複雑な処理をしたらどうなるか… ◼ Bun環境の場合、Cold Start時にLambdaレイヤーを読み込むので、前処理を含んだ 時間(≒Billed Duration)はもっと長い

    Bunで2,246ms、Bun(TypeScript)は10,811ms ◼ AWS環境の構成差も影響している?(BunはARM64 & カスタムランタイム必須) ここに 図 や テキスト を挿入します Node.js Bun Bun (Node.js ビルド) Bun (TypeScript) 項目名 Duration(Cold Start時) 773 1,056 689 1,459 Duration(最遅) 491 411 491 556 Duration(最速) 65 179 88 181 Duration(平均) ※Cold Startは含まず 171 287 172 318
  4. その2:嬉しい点 20 やっぱり速い! パッケージインストール・単体テストなどの実行が速い 特に単体テストはjestに比べて実感できるレベルで速い(※1) All-in-One Bun一つでパッケージ管理・テスト・ビルド・バンドルなどが完結する 特にTypeScriptトランスパイラも内包しているのは大きい LambdaをTSで動かせる ソースをTypeScriptのままアップロードして動かすことが可能(※2,

    ※3) マネジメントコンソールでのソースの確認・編集が容易になる ※1:テスト前の初期処理(ビルドなど?)含め、本当に一瞬で終わる ※2:正確にはLambda実行時にビルド処理が行われる ※3:上記ビルド処理の分、実行時間は少し多くなる(「実行結果」参照)
  5. ユースケース 22 ローカルでの作業 パッケージインストール・単体テスト・ビルドなど、Bunの実行速度を活かせる作業 特にテストの速さは本当に魅力的(モジュールモックの問題がクリアできれば) TSのままデプロイしたい マネジメントコンソールでのソースの可読性、及び編集目的 主に開発環境で実行する場合(本番環境では難しいと思うので) (※1) SSR(未検証)

    React SSRにおいてNode.jsの約4.8倍の性能、と公式サイトで名言 SSRの用途ならば、Bunの方が速い?(※3) ※1:「検証結果」の通り、速度的な問題で本番環境では難しいかも ※2:Bun公式ページの「Server-side rendering React」を参照 ※3:時間の関係&私がフロントエンドは専門外なので、今回は検証できませんでした
  6. LambdaでBunを実行する方法 26 1. BunのGitHubリポジトリをcloneし、packages/bun-lambdaに移動 2. “bun install” コマンド(パッケージインストール)を実行 3. “bun

    run publish-layer” コマンド(Lambdaレイヤー作成)を実行 4. Lambda関数で、3で作成したLambdaレイヤーを使用する(※1) ※1: ランタイムを「カスタムランタイム(provided.al2)」、アーキテクチャを 「ARM64」にしないと動かないので注意 ※参考: BunをLambdaのカスタムランタイムで動作させてみた (クラスメソッドさんのブログ) ※packages/bun-lambda/README.mdにもやり方が書いてある
  7. 「ビルドファイルが動かない」現象を回避する方法 27 ◼ node_modulesを使用すると、ビルド後のjsファイル実行時に 「(intermediate value).require is not a function」エラーが発生

    ◼ ビルド後のjsファイルの先頭に上記2行を追加すると、正常に実行可能 ◼ ビルドファイルのサンプルを下記で公開しています ◼ https://github.com/smt7174/jsconfjp2023_bun-aws-lambda // このコードをjsファイルの先頭に追加する import { createRequire as createImportMetaRequire } from "module"; import.meta.require ||= (id) => createImportMetaRequire(import.meta.url)(id);
  8. (おまけ)Bunにcontributeしました その2 29 ◼ 「Issue #5707 import.meta.require is not a

    function error after target: “node” build」において、ソース改善に関するコメントを投稿済み ※19ページの「その1:困った点」で紹介した現象に対応するissue ◼ 絵文字リアクションもそれなりにあるので、割と評価は良かった? ◼ 現在は #6168 に統合済み ここに 図 や テキスト を挿入します