はじめに
バックエンド構成をAPI Gateway + Lambda + DynamoDBで構築し、モバイルアプリから呼び出すAPIを実装しました。
実際に構築・運用してみて、メリットだけでなく注意すべき点も多くわかったため、参考にしていただけると嬉しいです！
サーバーレス構成の特徴
「API Gateway + Lambda + DynamoDB」のサーバーレス構成では、従来のEC2やECSのようにインフラチームとバックエンドチームを分ける必要がなく、同じチームで一貫して対応するのが一般的です。
これにより以下のメリットがあります。
- チーム間の調整コストが減り、工数を削減できる
- インフラとバックエンドの境界がなくなり、依存関係なく構築・運用・保守ができる
また、IaC（Terraform、SAMなど）で構築すれば、環境の再現性も高く、構築自体の難易度はそこまで高くありません。EC2やECSベースのWeb基盤と比べると、管理すべきリソースが少ない点も利点です。
負荷試験は必須
サーバーレス構成では、スケーリングが自動で行われるため「負荷対策は不要」と思われがちですが、各サービスにはスロットリングの上限が存在します。上限に達するとリクエストが拒否されるため、事前に限界値を把握しておくことが非常に重要です。
CloudWatchダッシュボードを作成することで、各サービスの性能やボトルネックを可視化できます。
負荷試験ツールとしては、AWS公式の Distributed Load Testing（DLT） を利用すると、インフラの構築なしに手軽に負荷試験を実行できます。
スロットリングへの対処
負荷試験の結果、各サービスでスロットリングが発生した場合は、以下の対応を検討しましょう。
| サービス | 対処方法 |
|---|---|
| API Gateway | Service Quotasで上限緩和を申請し、ステージのスロットリングレートを引き上げる |
| Lambda | Service Quotasで同時実行数の上限緩和を申請する |
| DynamoDB | Lambda側でのキャッシュ導入、テーブル設計の見直し、DAXの検討など |
| CloudWatch Logs | Service Quotasで上限緩和を申請する |
API GatewayやLambda、CloudWatch LogsはService Quotasから上限緩和を申請すれば対応できますが、DynamoDBについてはテーブル設計やアーキテクチャレベルでの対応が必要になるため、本番リリース後に問題が発覚しても手遅れになりかねません。
だからこそ、負荷試験を事前に実施して上限を把握しておくことが重要です。
また、API Gateway/Lambdaの秒間リクエスト数はCloudWatch Logsから把握できるため、ダッシュボードによるメトリクス監視だけでなく、ログの観点からも性能を調査しましょう。
Lambdaのパフォーマンス改善
Lambdaはスロットリングの上限緩和だけでなく、以下の観点でパフォーマンスを改善できます。
- コールドスタートを減らす: Provisioned Concurrency（プロビジョニングされた同時実行）を設定し、ウォームスタートの状態を維持する
- インメモリキャッシュの活用: ハンドラ関数の外側で初期化処理やキャッシュを保持することで、ウォームスタート時に再利用できる
- メモリサイズの引き上げ: メモリを増やすとCPUも比例して割り当てられるため、処理速度が向上する場合がある
- 処理の最適化: 不要な処理の削除、外部API呼び出しの並列化、SDK初期化の効率化など
DynamoDBのテーブル設計は慎重に
DynamoDBはNoSQLデータベースであるため、RDBMSと比べて以下のような制約があります。
- 複雑なJOINができない
- トランザクションに制限がある
- 柔軟な検索（複数条件でのクエリなど）が難しい
これらの制約は後から対処しづらいため、テーブル設計の段階でDynamoDBで要件を実現できるかどうかを十分に検証しておく必要があります。
要件によっては、Aurora Serverlessなど別のデータベースサービスを検討する判断も重要です。
コストについて
「API Gateway + Lambda + DynamoDB」は、リクエストが少なければコストは非常に安く抑えられます。特にトラフィックが少ない環境や、利用量に波があるユースケースでは大きなメリットです。
ただし、CloudWatch Logsのログ転送量には注意が必要です。ログの保存・転送コストは見落としがちですが、リクエスト数が多い環境では無視できない金額になります。
コストを抑えるためには、以下の対策が有効です。
- API Gatewayのアクセスログは必要な場合のみ有効化し、不要であればエラーログに絞る
- Lambdaのログ出力は最小限にとどめる
- CloudWatch Logsの保持期間を適切に設定する
まとめ
「API Gateway + Lambda + DynamoDB」のサーバーレス構成は、インフラ管理の手間が少なく、コストも抑えやすい優れたアーキテクチャです。一方で、実際に構築・運用してみると、サーバーレスならではの注意点も多くあります。
- 負荷試験は必須：自動スケーリングでも上限はある。事前に限界値を把握しておく
- スロットリング対策：サービスごとに上限緩和やアーキテクチャの見直しが必要。特にDynamoDBは設計段階での対応が重要
- Lambdaのパフォーマンス：コールドスタート対策やメモリ調整で改善の余地がある
- DynamoDBの制約：NoSQLの特性を理解し、テーブル設計の段階で実現可能性を検証する
- コスト管理：従量課金で安価だが、CloudWatch Logsのコストは見落としやすい
サーバーレスはEC2やECSと比べて、各サービスの上限やNoSQLの制約など、機能面での制限が多い構成です。この記事で取り上げた問題はあくまで一例であり、プロジェクトの要件やトラフィック特性によっては、他にも想定外の課題が発生する可能性があります。
IaCで手軽に環境を構築できるからこそ、「簡単に作れる＝問題も少ない」と油断しがちですが、本番リリース前に十分な検証を行い、サーバーレス特有の制約を把握しておくことが安定運用への近道です。