はじめに
AWS SAM 便利ですよねー.
テンプレートの記述量も少なく最小限の記述で、API Gateway + Lambda + DynamoDBといったようなサーバレスアーキテクチャを構築できるので私もサーバレスアーキテクチャを検証したい際には手軽に作れておすすめしたいです。
しかし、いざ使ってみるといかのケースでは、合わなかったりとユースケースを間違えると手戻りなどが発生するため、今回はStack を使ってみてイマイチだったケースを3つ紹介します。
[ケースその１] バージョン指定の問題について
SAMを利用している際、バージョンやエイリアスを設定するにはAutoPublishAliasが設定されている必要があります。
しかし、だからといってバージョン管理できるるかっていったらそういうわけでもなく、AWS::Lambda::AliasとAWS::Lambda::Versionが作成されるだけになります。
これの何が問題かと言うと、以前上げた記事↓を見ていただければ幸いですが、
スタックが更新する度に「新しいAWS::Lambda::Versionを作成 → Lambdaのエイリアスに最新バージョンを更新する → 古いAWS::Lambda::Versionを削除」といった挙動になるのでバージョン管理できないってことなんですよね。
対処方だと、更新前に手動でバージョンを発行するとかですかね。
スタックで管理されていないバージョンをポイントごとで作成していざ問題があったら1つ前のバージョンに戻すとかはありかと。
まぁ、SAMで管理していた旧バージョンの保持方法も↑の記事でまとめてますので、よろしければ見ていただければ幸いですm(_ _)m
[ケースその2] 複数ステージでアプリケーションを管理したい場合
StageNameも一つしか定義できないため、APIバージョン v1・v2 ... など、1つのAPIゲートウェイで複数ステージを管理するといったことも私が調べた限りではできないものとかんがえます。
もし、無理やりやる方法わかる方いましたらご教授お願いします。。m(_ _)m
また、API デプロイIDもその１と同様に新しいデプロイメントを生成 → 古いデプロイメントを削除といったこともあるのでデプロイIDのバージョン管理もできないので、1つ前に戻すといったこともできません。
[ケースその3] 細かい設定をする場合
やはり、AWS SAMの1番の特徴は、Cloudformation などの定義を抽象化したことで、テンプレートへの記述量を最小限に、サーバレスアーキテクチャを構築することができる点だと思います。
これは、抽象化したもの全般に言えることではあるのですが、細かい設定を施すとどうしても記述量が多くなってしまったり追加のリソースなど細かくかつ独自で作るリソース数が増えていくと管理しにくくなっていくものかと思います。
したがって、アーキテクチャがシンプルな場合はAWS SAMを使って、運用方針が決まっていて細かく正確に作りたいとなるとCloudFormationで1つ1つちまちま作成していく必要があるのかなと思います。
終わりに
今回はAWS SAMを使わない方がいいケースを紹介しました。
一番いいケースとしては、完成系がどのようになるのか、運用どうするのか、スタックの更新頻度どれくらいになるのかといった内容についてヒアリングしたのち、ツールを選定いただければと思います。