Serverless Operations, inc

>_cd /blog/id_xu024euy8kpy

title

Serverless Framework V4の変更点まとめ

summary

Serverless FrameworkとはAWS Lambdaを中心としたサーバレスアプリケーションのデプロイツールであり、世界中で広く使われているオープンソースのツールです。2024年6月14日にServerless FrameworkのV4がリリースされました。V3以下のバージョンと大きく何が変更されたのかを本記事でまとめています。

料金体系の変更

Serverless Framework V4からはライセンス形態が変更されて、年間200万ドル以上の売上のある組織では有料でサブスクリプションを購入する必要があります。それ以外の中小企業や個人の開発者は引き続き無料で使えます。これが既存ユーザからすると最も影響を受ける変更でしょう。料金はクレジットという単位で月ごとに購入し、Serverless Frameworkのサービスインスタンスやメトリクス、トレースに利用されます。また、最初の2クレジットは無料枠が設けられています。注意点としては月に購入したクレジットは現在の月から繰り越すことは出来ません。あなたがServerless Frameworkで運用するサービスに対して、サービスインスタンス、メトリクス、トレースの量を試算してクレジットを購入する必要があります。

支払いはServerless DashBoard上から以下のクレジット単位での購入が可能です。また、AWSのMarketplace経由でも購入が可能です。

クレジット数

料金

期間

2 Credits

無料

月額

15 Credits

$38

月額

50 Credits

$105

月額

300 Credits

$300

月額

Serverless Frameworkの料金ページ

サービスインスタンスとは

Serverless Frameworkにおける「サービスインスタンス」とは、serverless.ymlファイルで定義される「service」、「stage」、「region」の組み合わせによって決定されるもので、特定のステージおよびリージョンでのユニークなデプロイメントを表します。これは、Serverless Frameworkによって管理されるAWS CloudFormationスタックに相当します。

例えば東京とシンガポールリージョンのマルチリージョンで展開されているサービスがあるとします。それがテスト、ステージ、本番の3環境に存在する場合は、1サービス x 2リージョン x 3ステージ = 6クレジットが必要となります。

サービスインスタンスに対する料金は、Serverless Frameworkでデプロイを行ってから5日以上経過したスタックにのみ適用されます。例えばテストで一度デプロイをしてから5日以内に削除したスタックには課金されません。このポリシーは、短期間のテスト環境のデプロイに対して追加料金が発生しないように設計されています。

トレースとメトリクスとは

トレースとは、AWS Lambdaの呼び出しごとにリクエスト/レスポンスの詳細、スパン、エラー、パフォーマンス情報を含むペイロードです。Serverless DashboardのTrace Explorerでアクセスしてクエリを実行できます。50,000トレースのペイロードで1クレジットが支払われます。

メトリックは、AWS Lambda呼び出しの期間、最大メモリ、初期化時間、カスタムメトリックなどをキャプチャする単一の数値ペイロードです。Serverless DashboardのGlobal Metrics View、Trace Explorer、各サービスのMetricsビューで確認できます。生成された4,000,000メトリックにつき1クレジットが支払われます。

TypeScriptとEsBuildのネイティブサポート

V3まではTypeScript及びビルドツールを使うために以下のプラグインを使用していましたが、V4以降ではデフォルトでTypeScriptとEsBuildがサポートされています。

  • serverless-esbuild
  • serverless-webpack
  • serverless-plugin-typescript

LambdaファンクションをTypeScriptで記述するとServerless Frameworkはそれを自動で検知してビルドしてAWSにデプロイしてくれます。このためにプラグインやデフォルトの設定は不要です。もし、EsBuildのカスタマイズをしたい場合は新たにserverless.ymlbuild セクションの指定が可能になりました。

build:
  esbuild:
    bundle: true
    minify: false
    external:
      - '@aws-sdk/client-s3'
    exclude:
      - '@aws-sdk/*'
      - '!@aws-sdk/client-bedrock-runtime'
    packages: external
    buildConcurrency: 3
    sourcemap:
      type: linked
      setNodeOptions: true

新たなDev modeの追加

V3までの場合の開発では、ローカルにLambdaファンクションをエミュレートする環境を構築するか、毎回AWS上にデプロイを行うかのどちらかでした。しかし、ローカルでの開発は実際のクラウド環境を完全に複製することは出来ず、その差異がが開発体験を悪化させていました。しかし、今回の追加されたserverless devコマンドを使用してDev Modeセッションを開始すると、AWS Lambdaのライブ関数がイベントをローカルのコードにリダイレクトし、ローカルで処理された結果をLambda関数に返します。これにより、クラウド上のリソースを使用しながら、ローカル環境で迅速なデバッグと開発が可能となります。

% serverless dev

Dev ϟ Mode

Dev Mode redirects live AWS Lambda events to your local code enabling you to develop faster without the slowness of deploying changes.

Docs: https://www.serverless.com/framework/docs/providers/aws/cli-reference/dev

Run "serverless deploy" after a Dev Mode session to restore original code.

Functions:
  hello: sls-v4-test-dev-hello (80 kB)

Endpoints:
  GET - https://xxxxxxxxx.execute-api.us-east-1.amazonaws.com/

✔ Connected (Ctrl+C to cancel)

デプロイなしでローカルコードに変更を即座に反映

ローカルのエディタ上でコードを変更すると、AWS上のイベントを通して即座に動作確認が可能となります。試しに、Lambdaファンクション内で定義した「Go Serverless v4! Your function executed successfully!」と返ってくるHTTPイベントのレスポンスを「Your function executed successfully!」に変更して、dev mode起動時に発行されたエンドポイントにリクエストを送るとすぐに反映されていました。

% curl https://u6yx2mn1ee.execute-api.us-east-1.amazonaws.com/
{"message":"Your function executed successfully!"}%

ログ、エラーなどがローカルから直接参照できる

ローカルのエディタ上のコードがエラーを吐いている場合には、コンソール上にリアルタイムにエラーログが表示されます。これにより素早いデバッグが可能となります。例えばローカルのコードにエラーが有る状態でコードを保存。先ほどと同じエンドポイントにリクエストを送ると以下のようにコンソール上にエラーが表示されます。

→ λ hello ── aws:apigateway:v2:get:/
─ /Users/xxxxxxx/src/sls-v4-test-2/handler.js:6
    ),
    ^

SyntaxError: Unexpected token ')'
    at wrapSafe (node:internal/modules/cjs/loader:1378:20)
    at Module._compile (node:internal/modules/cjs/loader:1428:41)
    at Module._extensions..js (node:internal/modules/cjs/loader:1548:10)
    at Module.load (node:internal/modules/cjs/loader:1288:32)
    at Module._load (node:internal/modules/cjs/loader:1104:12)
    at cjsLoader (node:internal/modules/esm/translators:346:17)
    at ModuleWrap.<anonymous> (node:internal/modules/esm/translators:286:7)
    at ModuleJob.run (node:internal/modules/esm/module_job:234:25)
    at async ModuleLoader.import (node:internal/modules/esm/loader:473:24)

Stageプロパティの拡張

V3以前のバージョンでもstageプロパティを使用して、開発者ごとに環境を分けたり、テスト・ステージ・本番環境を分けたりすることが可能でした。V4では、このstageプロパティ専用の設定項目が新たに追加され、より柔軟な環境管理ができるようになりました。例えば、paramsプロパティを用いることで、各環境ごとに異なる設定値を指定することが可能です。これにより、環境ごとの設定の管理が一層簡単かつ効率的になります。

service: billing
stages:
  prod:
    params:
      stripe_api_key: ${env:PROD_STRIPE_API_KEY}
  default:
    params:
      stripe_api_key: ${env:DEV_STRIPE_API_KEY}

Terraformとの統合

Serverless Framework V4では、HashiCorp Terraformとの統合が強化され、${terraform}変数を使ってTerraformの状態出力を簡単に取得できるようになりました。これにより、RDSやSQSなどの共有インフラをTerraformで管理し、アプリ固有のリソースはServerless Frameworkが担当するというハイブリッドな運用が可能です。

	
service: my-service
 
stages:
  default:
    resolvers:
      terraform:
        type: terraform
        backend: s3
        bucket: terraform-state
        key: terraform.tfstate
 
functions:
  helloWorld:
  handler: handler.hello
  environment:
    TERRAFORM_VARIABLE: ${terraform:outputs:users_table_arn}

HashiCorp Vaultとの統合

Serverless Framework V4では、人気のあるシークレット管理ツールであるHashiCorp Vaultとのシームレスな統合が可能な${vault}変数が導入されました。この機能により、デプロイ時にHashiCorp Vaultから安全にシークレットを取得でき、サーバーレスサービスのセキュリティと柔軟性が向上します。さらに、新しいステージ設定を活用して、各ステージごとに異なるVaultインスタンスを指定することが可能です。

service: my-service
 
stages:
  default:
    resolvers:
      vault:
        type: vault
        address: http://127.0.0.1:8200
        token: ${env:VAULT_TOKEN}
        version: v1
 
functions:
  helloWorld:
  handler: handler.hello
  environment:
    VAULT_VARIABLE: ${vault:secret/data/mongo/credentials.password}

Written by
CEO

堀家 隆宏

Takahiro Horike

  • Facebook->
  • X->
  • GitHub->

Share

Facebook->X->
Back
to list
<-