SAM × Dockerでサーバーレス開発が超捗った話

個人活動でやってるサーバーレスアプリケーションの開発をSAMに置き換えたら、開発環境が激変！？実際にどんな変化があったのか紹介します！

Transcript

1. AWS SAM × Dockerで サーバーレス開発が超捗った話 チームラボ株式会社 ゆっきー 2022年8月9日 JAWSコンテナ支部 初心者編 #7
2. アジェンダ • 自己紹介 • 開発中のアプリとサーバーレスアーキテクチャ採用の理由 • 初期の開発環境 • 初期の環境の問題点 • AWS SAMとは？ • 改善点 • 現状の課題 • まとめ 2
3. 自己紹介 • 吉野敬太郎 (ゆっきー) • チームラボ株式会社 パッケージチーム • 新卒1年目(2022新卒) • 学生団体のお手伝いとかしてる @Yu_yukk_Y 3 ※当LTで話す内容、及び本資料とその内容は 　チームラボ株式会社が行っている全ての活動とは関係ございません。
4. 開発中のアプリとサーバーレスアーキテクチャ採用の理由 • Nexus Square • 出身大学の学生間の 情報格差を無くすアプリ(最初はQA) • 学生団体Nexus Squareが開発・運営 • 今月リリース予定 4
5. 開発中のアプリとサーバーレスアーキテクチャ採用の理由 • 利用者数の上限が低い (最大3000人程度) • 開発メンバーが少ない (現状コード書いてるのは2人) • サーバー運用に常時コミット出来ない • お金もない 従量課金・サーバーの管理不要な サーバーレスアーキテクチャが合っている 5
6. 現状のアーキテクチャ(ざっくり) フロントエンド QAサーバ メタデータサーバ 6
7. 初期の開発環境 Github Actions とりあえず Githubにpush テスト コンテナビルド デプロイ (AWS CLI) 残りのリソースは 手動で構築 7 Lambdaの コードのみ更新
8. 初期の環境の問題点 - ローカルで試せない • 動作確認は単体テスト頼り ◦ 全てのソースコードにわざわざmain関数を書いて一つずつロー カル実行(×Docker) ◦ pytestの自動単体テスト • 本当に動くのかデプロイするまでわからない • フロントの開発用ローカルサーバは別途用意(Fast API) 8
9. 初期の環境の問題点 - コンテナの良さを活かしきれてない • 開発にコンテナを使った理由は以下の通り ◦ LambdaへのコンテナデプロイはZipファイルアップロードよりも 楽だった ◦ CI / CDとの相性もよかった • 環境ごとに差分なく実行できる、などの メリットを活かしきれていない 9
10. 初期の環境の問題点 - Lambdaのコード以外は手動更新 • Lambdaに適応するIAM Policy、API Gatewayの各種設定、、など など、都度手動で設定する必要あり • Blue / Greenデプロイと相性悪い • 開発初期の今はいいけど今後どうしよう、、？ 10
11. そこで、AWS SAMを導入してみた 11
12. AWS SAMとは？ • サーバーレスアプリケーション構築用のオープンソースフレーム ワーク • Lambda、API Gatewayといったサーバーレスリソースを迅速にデ プロイできる • IAMポリシーとかも管理・作成できる！ • APIのローカル実行も可能！ コンテナのビルド・デプロイも 自動でやるよ！！ ※著作権的に載せなかった、ちゃんとした AWS SAMのキャラクターはこちら 12
13. SAM導入後の開発環境 Github Actions ローカルで試してから Githubにpush テスト ビルド&デプロイ (基本SAM) これらは 他のCFnテンプレートで 管理 13
14. 改善点 - ローカルでAPIが実行できるようになった • リポジトリにpushする前に動作確認ができるようになった ◦ ローカルでは、Docker Composeで 別途DynamoDB localのコンテナを立てておく • 精神的安定度が増した 14
15. 改善点 - ローカルとデプロイ先で差分ない実行環境 • ローカルでもコンテナビルド&実行 ◦ Lambda用のimageを自動でビルド&実行 ◦ デプロイ先と差分のないAPI実行が可能に ◦ 大量のDockerfileを楽々管理 • コンテナのメリットを活かしきれる 15
16. 改善点 - Lambdaのコード以外も一括更新できるように • LambdaのIAMポリシーやAPI Gatewayの各種設定も 一括で更新できるようになった • 今までの苦労はいったい、、？ 16
17. 現状の課題 - Blue/Greenデプロイにエイリアスが使えない • 通常、Lambdaはエイリアスという機能を用いて バージョン管理や開発用・本番用バージョンを管理できる • 、、が、SAMだと上手く使えない ◦ CloudFormationのテンプレートが競合するため バージョンごとにLambda, API Gatewayを作成する Cognito, DBなどはSAMで管理しない 現状の対策 17
18. 現状の課題 - 手元で簡単にデプロイ出来てしまう • ローカルからコマンド一発で簡単にデプロイできて便利 ◦ だが、一方で思わぬ事故に繋がる可能性も、、 デプロイはGithub Actions経由で デプロイ専用のIAM ロールを用いる(OIDC) 開発用IAMユーザにCloudFormationの制限を加える 現状の対策 18
19. まとめ • AWS SAMの導入で開発環境が大きく改善した ◦ ローカルでコンテナを用いたAPI実行が簡単にできるようになっ た ◦ LambdaとAPI Gateway、およびその周辺リソースが管理できる ようになった • 運用していく中でまた気づくこともあるかもしれない ◦ まずは運用頑張る、、！ 19