Serverless Frameworkの有償化に伴いAWS CDKとAWS SAMへの移行について検討してみた
この記事は公開されてから1年以上経過しています。情報が古い可能性がありますので、ご注意ください。
データアナリティクス事業本部のueharaです。
今回は、Serverless Frameworkの有償化に伴いAWS CDKとAWS SAMへの移行について検討してみたいと思います。
はじめに
2023年の10月に、Serverless FrameworkがV.4から有料化されることが発表されました。
ライセンス費用を支払いV.4を利用するというのも1つの手ではあるのですが、今回はAWS CDKとAWS SAMへの移行を検討してみたいと思います。
結論
まずは、移行を検討した結果の表を以下にまとめます。
個別の内容については以降の章で説明を実施します。
| フレームワーク | 利用コスト | 移行コスト | メリット・デメリット | Serverless Frameworkからの移行の総論 |
|---|---|---|---|---|
| Serverless Framework V.4 | 有償 | 低 | メリット ・V.4への更新に伴う変更差分のみの確認で済む デメリット ・ライセンス料金がかかる ・料金体系が結構複雑（見積りがし辛い） |
※移行しない |
| AWS CDK | 無償 | 高 | メリット ・AWS謹製のため無償で利用できる ・CDK Migrateがある（※ただし注意事項有り） ・並行開発もしやすい デメリット ・移行工数がそれなりに大きい ・yamlベースの定義からTypescriptやPythonに変換する必要がある ・準備するスクリプト等が多く小規模なデプロイには過剰 |
中〜大規模アプリケーションであれば最有力候補 |
| AWS SAM | 無償 | 中 | メリット ・AWS謹製のため無償で利用できる ・serverless.ymlの定義をある程度流用できる ・yamlベースの定義のため、Serverless Frameworkに慣れていると記載が簡単 デメリット ・小規模開発向けのフレームワークのため、共同開発がし辛い ・AWS CDKの方が情報が多い（トラブルシュートしやすい） ・複雑な構成が定義しにくい |
小規模アプリケーションなら有り（AWS CDKより楽） |
総論に記載していますが、「移行コストを考えると別にライセンス料を払っても良いよ」という方はV.4を利用し、そうでない場合は小規模アプリケーションならAWS SAMに、中〜大規模アプリケーションであればAWS CDKへの移行を検討するのが良いと思います。
移行無し（Serverless Framework V.4を利用）について
メリット
言わずもがなですが、V.4への更新に伴う変更差分のみの確認で済むため移行工数は最小になります。
デメリット
冒頭でも述べたように、V.4の利用にはライセンス料金がかかります。
サブスクリプションはServerless Framework DashboardまたはAWSマーケットプレイスから購入可能です。
多くの企業ではAWSマーケットプレイス経由で購入するのが社内手続きの申請上は楽なのかなと推察しますが、Serverless Framework Dashbordからの場合は年間購入も簡単にできるので、その場合はライセンス費用が安くなります。（参考）
※AWSマーケットプレイスで年間契約の割引を適用したい場合は、AWSマーケットプレイスのプライベートオファー機能（公開されていない条件での契約・購入）を利用する必要があります。
| Units | 通常費用 | 中小企業割引 | 年間契約割引 | 中小企業割引+年間契約割引 |
|---|---|---|---|---|
| 15 Credits | $60/Month | $48/Month | $48/Month | $38/Month |
| 50 Credits | $175/Month | $131/Month | $140/Month | $105/Month |
| 300 Credits | $750/Month | $375/Month | $600/Month | $300/Month |
なおこの「Credits」という単位は serverless.yml ファイルのregion, stage, serviceパラメータの組み合わせによって定義されるようです。
※分かりやすく言えば、CloudFormationスタックの数になります。
したがって、例えば開発者やチケット毎の検証環境を stage で分けている場合は、その分Creditsが嵩むという形になります。
また、 service もどのように分割するかで総Credit数が変わってきますので、この辺は見積りのし辛さに繋がってくるのかなと思います。
例えば region として 東京, シンガポール を用意し、 stage として prod, stg, dev, user1, user2 があり、 service として xxx, yyy がある場合、単純に掛け算をすると2x5x2の20 Creditsとなります。
また、Serverless Dashboardの機能を使うと、トレース50,000あたりで1 Credit、メトリクス400万あたりで1 Credit必要となるようです。（CLIのみの利用であればこちらは課金対象外です）
AWS CDKへの移行について
メリット
AWS謹製のため無償で利用できます。
そもそもAWS側が自社のサービスを利用してもらうために開発しているものですので、そのようなバックボーンがあるのはやはり強力だと思います。
また、AWS CDKにはCDK Migrateというものがあり、これを利用することでCloudFormationスタックからAWS CDKアプリケーションを作成することができますので、Serverless Frameworkでデプロイしたスタックから移行することができます。
$ cdk migrate --language typescript --from-scan --stack-name "myCloudFormationStack"
ただし、移行に関する注意点もあるので、詳しくはAWS公式のドキュメントをご確認ください。
例えば、移行したものは「L1コンストラクトで定義される」というものがあります。（CloudFormationのテンプレートベースから移行するので、当然と言えば当然かもしれません）
ここでは詳細な説明は割愛しますが、AWS CDKは抽象化の概念としてL1〜L3とConstructのレイヤーが分かれています。
（引用元）
L1はほぼCloudFormationの設定値を書く形でプロパティを設定する必要があるので、普通に開発する分にはコードがシンプルになるL2を使うケースが多いのかなと思います。
この場合、リソースによっては「移行したものはL1で書かれており移行後の通常開発はL2が使われている」というような平仄が取れない状況も発生する可能性があります。
また、AWS CDKはディレクトリのパスの切り方が開発・運用のしやすさの面で非常に重要になって来ますので、単にCDK Migrateで移行したプロジェクトの状態が最適なものになっているとは言えません。（CDK Migrateを利用した場合、1つの .ts ファイルに全てのリソースが記載されます）
上記より、CDK Migrateはあくまで「今後は追加の開発はほぼ想定してない/あっても少ない改修」くらいの状況であれば良いのかなと思いますが、Serverless FrameworkからAWS CDKに移行する銀の弾丸ではないことをご留意ください。
また、TypescriptやPythonというプログラミング言語でリソースを定義できるという都合上、変数の管理やファイル分割がしやすく、中〜大規模アプリケーション開発に向いていると言えます。
デメリット
メリットの裏返しになる部分が多分にありますが、デメリットとしてまず移行工数が高いことが挙げられます。
Serverless Frameworkではyamlで定義していたものを、AWS CDKではTypescriptやPythonなどプログラミング言語ベースに変換する必要があるので、移行工数はそれなりに高くなると思います。
また別のデメリットとして、AWS CDKはデプロイのため記載しないといけないスクリプトファイルが多かったり、リソースもクラスや関数で定義していく必要があるので小規模のアプリケーションに対しては少々過剰であることが挙げられます。
例えば cdk init --language typescript コマンドを使用して my-cdk-ts-project ディレクトリに作成されたプロジェクトは以下のようになっています。
my-cdk-ts-project
├── .git
├── .gitignore
├── .npmignore
├── README.md
├── bin
│ └── my-cdk-ts-project.ts
├── cdk.json
├── jest.config.js
├── lib
│ └── my-cdk-ts-project-stack.ts
├── node_modules
├── package-lock.json
├── package.json
├── test
│ └── my-cdk-ts-project.test.ts
└── tsconfig.json
ファイルは多いですがきめ細やかにリソースの定義や設定ができるため、中〜大規模アプリケーション向けかなと思います。
AWS SAMへの移行について
メリット
AWS CDKと同様、AWS謹製のため無償で利用できます。
また、Serverless Frameworkからの移行の大きなメリットとして serverless.yml の定義をある程度流用できたり、Serverless Frameworkに慣れていると記載が簡単ということが挙げられます。
例えば、同じLambda関数をデプロイするServerless FrameworkとAWS SAMの記述はそれぞれ以下の通りです。
functions:
MyLambdaFunction:
handler: handler/test_func.lambda_handler
runtime: python3.9
name: "uehara-test-lambda"
role: MyLambdaFunctionRole
package:
patterns:
- 'handler/test_func.py'
Resources:
MyLambdaFunction:
Type: AWS::Serverless::Function
Properties:
FunctionName: "uehara-test-lambda"
Role: !GetAtt MyLambdaFunctionRole.Arn
CodeUri: handler/
Handler: test_func.lambda_handler
Runtime: python3.9
細かな違いはありますが、どちらもyamlベースで記載されているのでServerless Frameworkに慣れている人はAWS SAMもすぐに書けると思います。
また、IAM RoleなどはどちらもCloudFormationベースで記載をするので、Serverless Frameworkの記載内容をAWS SAMにそのまま流用することができます。
resources:
Resources:
MyLambdaFunctionRole:
Type: AWS::IAM::Role
Properties:
RoleName: "uehara-test-lambda-role"
AssumeRolePolicyDocument:
Version: '2012-10-17'
Statement:
- Effect: Allow
Action: sts:AssumeRole
Principal:
Service:
- lambda.amazonaws.com
ManagedPolicyArns:
- arn:aws:iam::aws:policy/service-role/AWSLambdaBasicExecutionRole
Resources:
MyLambdaFunctionRole:
Type: AWS::IAM::Role
Properties:
RoleName: "uehara-test-lambda-role"
AssumeRolePolicyDocument:
Version: '2012-10-17'
Statement:
- Effect: Allow
Action: sts:AssumeRole
Principal:
Service:
- lambda.amazonaws.com
ManagedPolicyArns:
- arn:aws:iam::aws:policy/service-role/AWSLambdaBasicExecutionRole
また、AWS SAMは最小で必要になるのが設定ファイルであるsamconfig.tomlとテンプレートファイルであるtemplate.yamlのみなので、準備も非常に楽です。
したがって、アプリケーションの規模がそこまで大きくなければServerless Frameworkからの移行はAWS SAMの方が簡単だと思います。
デメリット
小規模開発向けのフレームワークのため、共同開発がし辛いというのが挙げられます。
AWS SAMでは template.yaml とスタックが1対1なので、例えば1つのスタックでリソースをデプロイしたい場合は同じ template.yaml を複数人で触ることになるので競合が多発する可能性があります。
※以下のように、yqを使うことで無理やり分割することは可能です。
テンプレートを細かく分割してスタックをネストさせることもできますが、それはそれで管理の大変さがあります。
また、テンプレート内の変数の扱いについてもServerless Frameworkほど柔軟ではなく、痒いところに手が届くPluginも無いため、複雑な構成が定義しにくい感触があります。
その他、AWS SAMはAWS CDKと比較し情報が少なくトラブルシュートし辛いといったこともデメリットとして挙げられます。
その他参考
以前Lambda+Glue+Step Functionsの構成をServerless Framework, AWS CDK, AWS SAMでそれぞれデプロイしたブログを以下にまとめてますので、それぞれのフレームワークの書きっぷり等の参考にして頂ければと思います。
最後に
今回は、Serverless Frameworkの有償化に伴いAWS CDKとAWS SAMへの移行について検討してみました。
参考になりましたら幸いです。
