はじめに
課題提起
サーバレス開発の普及により、多くの開発者がAWS SAMやServerless Frameworkのようなフレームワークを活用しています。しかし、これらのツールをどのように選べば良いのか迷うことも多いのではないでしょうか?
記事の目的
本記事では、AWS SAMとServerless Frameworkを比較・検討し、それぞれの特徴や適用シナリオを解説します。この記事を読むことで、あなたのプロジェクトに最適なツールを選択できるようになります。
背景と全体像
サーバレスアーキテクチャの成長
サーバレスアーキテクチャは、近年非常に人気のあるアーキテクチャの選択肢となりました。それには、サーバレスによる様々なメリットがあるからです。
1. 技術トレンドとしての進化
クラウド技術は、大きく3つのステージを経て進化してきました:
- 仮想サーバ(VM): クラウドリフトで最も移行が容易ですが、VM自体の管理が必要です。
- コンテナ: 軽量な仮想化技術により、アプリケーションの移植性が向上しました。
- サーバレス: 実行コード以外の部分をすべてCSP(クラウドサービスプロバイダー)に委ねることで、運用管理負荷を軽減し、開発効率を向上させています。
2. ビジネス的なニーズの後押し
企業は近年、以下の要件を重視するようになりました:
- 開発速度の向上: 実行環境の管理から解放され、アプリケーション実装に集中できる。
- コスト効率: サーバレスは「使った分だけ課金される」従量課金モデルのため、余剰リソースを削減できる。
- スケーラビリティ: トラフィック量に応じた自動スケーリングにより、パフォーマンスとコストの最適化を実現。
これらの特徴が、迅速な開発・リリースが求められる変化の速いシステムで特に活用されています。
3. 技術的な魅力
サーバレスには、以下のような技術的メリットがあります:
- スケーリングの自動化: 同時実行性が自動で確保され、オートスケーリングが組み込まれています。
- 開発生産性の向上: 開発者はサーバ管理を気にせず、本質的なアプリケーションロジックに集中できます。
- モダンなアーキテクチャとの相性: サーバレスは、マイクロサービスやイベント駆動型アーキテクチャとの親和性が高い。
4. クラウドベンダーの推進と相性
AWS Lambdaをはじめとするサーバレス関連サービスがエコシステムを形成しており、クラウドネイティブなシステムをサーバレスで構築できるようになっています。Google Cloud FunctionsやAzure Functionsも同様に、積極的な推進を進めています。
例えば、API Gateway + Lambda + DynamoDBの組み合わせで、フルマネージドなAPIを簡単に構築可能です。さらに、イベント駆動アーキテクチャの採用により、システム全体の効率が大幅に向上しています。
5. 実務で広がる採用事例とその可能性
サーバレスアーキテクチャは、スタートアップだけでなく、大企業や官公庁でも採用が広がっています。
サーバレスの導入により、変化の早い業務要件や予測が難しいトラフィックに対応した柔軟なシステム設計が可能になります。一方で、常時接続が必要なリアルタイム通信や、専用インフラの要件がある場合には、コンテナや仮想サーバが選ばれるケースもあります。
サーバレスはその特性を生かし、特に変動するトラフィックや迅速なリリースが求められるシステムにおいて有力な選択肢であり、今後も採用が広がると期待されています。
もちろん、サーバレスがすべての状況に適するわけではありません。たとえば、常時接続が必要なリアルタイムアプリケーションでは、コンテナや仮想サーバの方が有利な場合があります。しかし、サーバレスはその手軽さと効率性により、今後も広がり続ける重要な選択肢となるでしょう。
AWS SAMとServerless Frameworkを対象とする理由
サーバレスアーキテクチャを構築するためのツールは数多く存在しますが、その中でもAWS SAMとServerless Frameworkが注目される理由は次の通りです。
1. 市場シェアと採用実績
AWS SAMはAWS公式ツールとして、サーバレス開発における「標準」としての地位を確立しています。一方、Serverless Frameworkはマルチクラウド対応の先駆けとして、幅広い環境で採用されており、サーバレス開発の「事実上のデファクトスタンダード」と言えます。
2. ユースケースの幅広さ
- AWS SAM: AWS専用のプロジェクトで高い信頼性と最適な統合を提供。
- Serverless Framework: AWS以外のクラウドや、カスタマイズ性を求めるユースケースに対応可能。
両ツールは、異なるニーズに応える形で幅広いプロジェクトで活用されています。
3. 開発者の支持と充実したエコシステム
AWS SAMはAWS公式の強力なサポートとアップデートが特徴。一方、Serverless Frameworkは豊富なプラグインエコシステムと活発なコミュニティによる拡張性で支持されています。この2つは、サーバレス開発における選択肢として特に実用性が高いツールです。
4. なぜこの2つに絞るのか
数あるサーバレスツールの中で、AWS SAMとServerless Frameworkを取り上げる理由は、どちらもサーバレス開発の主要なニーズ(AWS特化 vs マルチクラウド対応)を包括的にカバーしているからです。この2つを比較することで、読者はプロジェクト要件に最適なツールを選択するための基準を見つけやすくなります。
まとめ
AWS SAMとServerless Frameworkは、それぞれの強みと採用実績から、サーバレス開発の中心的なツールとして広く利用されています。本記事では、これらの2つのツールに絞ることで、読者が具体的で実用的な選択基準を理解できるようにします。
記事で取り上げるポイント
-
実装と開発効率
実際のアプリケーションを作る際のテンプレート構造やコード量、開発効率に影響する要素を比較。 -
デプロイと運用の柔軟性
デプロイの効率性や運用中の制約、拡張性の違いを検証。 -
AWSサービスとの統合力と柔軟性
AWS SAMのAWS専用設計と、Serverless FrameworkのAWS外サービスやプラグイン対応力を比較。 -
適用シナリオとプロジェクト規模への適応性
小規模から大規模までのユースケースで、どのような状況に適しているかを考察。
詳細な解説・分析
実装と開発効率
実装と開発効率
1. はじめに
-
テーマの概要:
サーバレスアプリケーションを構築する際、テンプレートやコードの構造が開発効率に与える影響は大きいです。本章では、AWS SAMとServerless Frameworkの実装スタイルを比較します。 -
ゴール:
両ツールでの記述方法を具体例で示し、それぞれの開発効率を評価します。
2. 比較に用いるサンプルアプリケーション
アプリケーション概要:
サーバーレスアーキテクチャを活用したタスク管理アプリケーションを構築します。このアプリケーションは、AWSの代表的なサービスを用いて以下の機能を提供します。
データ操作: DynamoDBをデータストアとして利用し、タスク情報を管理。
リアルタイム通知: DynamoDB Streamsを活用して、タスクの状態変更を検知し、SNSで通知。
API提供: API Gatewayを通じてRESTfulなエンドポイントを公開。
データ構造
DynamoDBに以下のようなデータを保存します
{
"id": "1",
"task": "Write Code",
"status": "In Progress"
}
エンドポイント
メソッド | URL | 機能 |
---|---|---|
GET | /task?id={id} | 指定IDのタスクを取得 |
POST | /task | タスク情報を登録または更新 |
通知機能
- タスクのstatusがDoneに変更された場合、メールで通知します
AWS SAMとServerless Frameworkの両方で実装し差異を検証
3. AWS SAMの実装スタイル
-
テンプレート:
DynamoDBテーブルの作成と、エンドポイントの設定を含むAWS SAMテンプレート(YAML形式)を提示します。
AWSTemplateFormatVersion: '2010-09-09'
Transform: AWS::Serverless-2016-10-31
Description: >
sam-task-app - A simple task management application with DynamoDB, API Gateway, and SNS.
Resources:
TaskTable:
Type: AWS::DynamoDB::Table
Properties:
TableName: TaskTable
AttributeDefinitions:
- AttributeName: id
AttributeType: S
KeySchema:
- AttributeName: id
KeyType: HASH
BillingMode: PAY_PER_REQUEST
StreamSpecification:
StreamViewType: NEW_AND_OLD_IMAGES
TaskApiFunction:
Type: AWS::Serverless::Function
Properties:
Handler: task-api/app.lambdaHandler
Runtime: nodejs18.x
CodeUri: task-api/
Environment:
Variables:
TABLE_NAME: TaskTable
Policies:
- DynamoDBCrudPolicy:
TableName: TaskTable
Events:
TaskApi:
Type: Api
Properties:
Path: /task
Method: any
StreamHandlerFunction:
Type: AWS::Serverless::Function
Properties:
Handler: stream-handler/app.lambdaHandler
Runtime: nodejs18.x
CodeUri: stream-handler/
Environment:
Variables:
TOPIC_ARN: !Ref NotificationTopic
Policies:
- Statement:
Effect: Allow
Action: sns:Publish
Resource: !Ref NotificationTopic
Events:
StreamEvent:
Type: DynamoDB
Properties:
Stream: !GetAtt TaskTable.StreamArn
StartingPosition: TRIM_HORIZON
NotificationTopic:
Type: AWS::SNS::Topic
Properties:
Subscription:
- Protocol: email
Endpoint: xxx@gmail.com
-
記述の特徴:
- AWSリソースを詳細に設定可能
- CloudFormationを活用するため、他のAWSリソースとの連携がスムーズ
4. Serverless Frameworkの実装スタイル
4.1 テンプレート構造の特徴
-
テンプレート:
DynamoDBテーブルとエンドポイントを定義するServerless Frameworkのテンプレート(YAML形式)を提示します
org: neclogoiclabs
app: sls-task-app
service: sls-test
package:
individually: true
exclude:
- ./**
plugins:
- serverless-plugin-common-excludes
- serverless-plugin-include-dependencies
- serverless-iam-roles-per-function
provider:
name: aws
runtime: nodejs18.x
region: us-east-1
functions:
apiHandler:
handler: src/api/index.apiHandler
package:
include:
- src/api/**
events:
- http:
path: task
method: any
iamRoleStatements:
- Effect: Allow
Action:
- dynamodb:GetItem
- dynamodb:PutItem
Resource:
!GetAtt TaskTable.Arn
streamHandler:
handler: src/stream/index.streamHandler
package:
include:
- src/stream/**
environment:
TOPIC_ARN: !Ref TaskNotificationTopic
events:
- stream:
type: dynamodb
arn:
Fn::GetAtt: [TaskTable, StreamArn]
iamRoleStatements:
- Effect: Allow
Action:
- sns:Publish
Resource:
- !Ref TaskNotificationTopic
resources:
Resources:
TaskTable:
Type: AWS::DynamoDB::Table
Properties:
TableName: TaskTable
AttributeDefinitions:
- AttributeName: id
AttributeType: S
KeySchema:
- AttributeName: id
KeyType: HASH
BillingMode: PAY_PER_REQUEST
StreamSpecification:
StreamViewType: NEW_AND_OLD_IMAGES
TaskNotificationTopic:
Type: AWS::SNS::Topic
Properties:
TopicName: TaskNotificationTopic
Subscription:
- Protocol: email
Endpoint: xxx@gmail.com
-
記述の特徴:
- 記述量が少なく、直感的に理解可能
- AWS特化部などは追加機能(プラグイン)
比較結果のまとめ
5.1 設定と制約
項目 | AWS SAM | Serverless Framework |
---|---|---|
設計 | AWS専用設計でAWSサービス連携が容易 | マルチクラウド対応でカスタマイズ性が高い |
ポリシー設定 |
DynamoDBCrudPolicy などのポリシーテンプレートあり |
IAMポリシーを手動で記述する必要がある |
制約 | AWS以外のサービスはサポート外 | AWS外のリソースやプラグインに対応可能 |
5.2 実装と開発効率
項目 | AWS SAM | Serverless Framework |
---|---|---|
ローカル開発 |
sam local でAWS環境を忠実に再現可能 |
プラグインなどによるローカルテストが必要 |
デプロイフロー | CloudFormationベース | 抽象化層でカスタマイズの余地がある |
適したプロジェクト | AWS向けで詳細な設定が必要なケース | 小~中規模や迅速なプロトタイピングに最適 |
5.3 プロジェクト規模と用途
AWS SAMを選ぶべき状況
- AWSサービスをフル活用し、複雑な依存関係を考慮する場合
- 長期的な運用や企業内での標準化が求められる場合
- 高忠実度なローカルテストや堅牢なデプロイフローを重視する場合
Serverless Frameworkを選ぶべき状況
- 短期間でのプロトタイピングや軽量アプリケーションを構築する場合
- AWS以外のリソースやプラグインの活用が必要な場合
- 設定の簡便さや迅速なデプロイを優先する場合
6. 結論
AWS SAMとServerless Frameworkは、それぞれ異なる強みを持つツールです。選択肢はプロジェクト要件や規模に応じて検討すべきです。
-
AWS SAM:
- 強み: AWS環境専用の設計で、AWSリソース間の高い統合性と信頼性を提供
- 適したケース: AWSリソースをフル活用したい中~大規模プロジェクトや、AWS標準ツールでの長期運用を重視する場合
-
Serverless Framework:
- 強み: 記述の簡潔さ、プラグインによる拡張性、マルチクラウド対応
- 適したケース: 短期間でのプロトタイピングや小~中規模プロジェクト、AWS以外のツールやリソースとの統合が必要な場合
選択の指針
- AWS環境に深く依存した設計を必要とするなら、AWS SAMを選ぶべき
- 迅速な開発やAWS外リソースとの連携が求められる場合、Serverless Frameworkが候補
参考リンク
AWS SAM
-
- AWS SAMの概要、セットアップ、詳細なリファレンスが記載されています。
-
- CLIツールのソースコードと最新リリース情報が確認できます。
-
AWS公式: Serverlessアプリケーションモデルの概要
- AWS公式のSAM概要ページで、主な機能やユースケースが解説されています。
-
AWS公式ブログ: AWS SAMによるサーバーレスアプリケーションのデプロイ
- SAMの実用例やベストプラクティスが紹介されています。
-
- 日本語で書かれた初心者向けの記事が多数掲載されています。
Serverless Framework
-
- Serverless Frameworkの設定方法やプラグイン情報が網羅されています。
-
Serverless Framework GitHubリポジトリ
- ソースコードと最新リリース情報、問題解決のためのIssueトラッカー。
-
- 最新機能やユースケース、業界トレンドなどが紹介されています。
-
Serverless FrameworkのAWSチュートリアル
- AWS環境でのServerless Frameworkの使用方法が詳しく解説されています。
-
「Serverless Framework入門」Qiita記事
- 日本語で書かれた記事が豊富で、チュートリアルや実例が参考になります。