Zenn
🔺

約一年、Amplify を使い続けて得た知見

2023/12/23に公開
AWS
Amplify
tech

概要

実務にて、 AWS Amplify を約一年近く触りました。

Amplify と付き合って得た知見をまとめてみます。

前提

amplify cli を使用を前提としています。

まとめ

  • 認証とデータストア系は、 import オプションで Amplify 管理下に取り込もう
  • 外部ライブラリは、Lambda Layer で管理しよう
  • Amplify のカスタマイズは慎重に検討しよう
    • AWSリソースの手動運用や、独自 CDK （または Cloudformation）とのダブル運用も検討しよう

認証とデータストア系は、 import オプションで Amplify 管理下に取り込もう

Amplifyがサポートする AWSリソースは、 amplify add コマンドで手軽に作成できます。

amplify add で追加したAWSリソースは、Amplify 環境を複製する場合、全部コピーされます。

しかし、複数人開発などで開発環境を複製する場合では、一部のリソースは複製せず共有したいことがあります。

  • 主に Cognito , S3バケット、 DynamoDB

そもそもなぜ、複数人開発時に Amplify 環境を複製したくなるのか、こういったときにどうするべきかをまとめます。

複数人で、一つの開発環境を共有する問題

git でいう conflict が発生するような状況において、 Amplify では特に conflict は発生せず、最後にデプロイした情報で上書きされます。

これは、誰かが動作確認のためにデプロイしたコードを、他の誰かが上書きする可能性を示唆します。

幸い、 Amplify は同一構成の環境を簡単に複製できます。

そのため、開発者一人一人に個別の Amplify 環境を構築することで、上書き問題は解決出来ます。

一方で、そのまま複製する場合は、次に述べる注意点があります。

開発者一人一人、専用の Amplify 環境を作成する際の注意点

Amplify 環境を複製する場合、 amplify add で追加したAWSリソースは、全て新規作成と言いう形でコピーされます。

Lambda や API Gateway は望むところですが、一部のAWSリソースは開発者全員で共有したい場合があります。

  • 具体的には、 Cognito 、S3バケット、 DynamoDB 辺り

alt

◆Amplify 管理下から除外して複製を避ける

この問題は、 複製したくないAWSリソースを、予め Amplify 管理下から除外することで避けることが出来ます。

cognito の場合、 amplify remove auth コマンドで除外できます。

  • この際、cognito リソースは削除されず、Amplifyとのリンクが切れるだけ

詳細は、以下公式ドキュメントをご確認ください。

他のリソースも、公式ドキュメントを参考に、 Amplify 管理下から除外する（≒ Amplify とのリンクを切る）ことが出来ます。

しかし、S3 , Cognito , DynamoDB は、Amplify SDK から参照するために、Amplify 管理下において置きたい場合がほとんどだと思います。

◆複製したくないが、Amplify 管理下には置きたい場合

Amplify は、 amplify import コマンドにて、 AmplifyがサポートするAWSリソースを取り込むことが出来ます。

そして、 amplify import コマンドで取り込んだ AWSリソースは、Amplify 環境複製の際にコピーされません。

以下の公式ドキュメントにて、 cognito を複数の Amplify 環境で共有する手段の概要が記載されています。

まとめると ... ?

  • Amplify を使って複数人で開発する場合、開発者一人一人専用の環境を用意すると、開発が捗る
  • 開発環境複製の際、開発者全員で共有したい（≒複製したくない）リソースは、以下の手順で Amplify との関連を弱める
    • remove オプションで、Amplify 管理下から外す
      • AWS リソース本体は削除されない
    • import オプションで、Amplify 管理下に戻す
      • Amplify を使用する前から作成している AWSリソースも、 (Amplify サポート対象なら) 取り込み可能

importで取り込んだAWSリソースは、add で追加した時と違い、Amplify環境を複製してもコピーされません。

これで、気兼ねなく Amplify 環境を複製できます。

外部ライブラリは、 Lambda Layer で管理しよう

Lambda コードを開発する場合、npm などで外部のライブラリを追加することは頻繁にあります。

この時、外部ライブラリは、専用の LambdaLayer を設けて管理することで、開発効率が向上します。

Lambdaコードと一緒に管理する場合の問題点

Lambda 関数デプロイ時、Lambda 関数に付随する形でライブラリも一緒にデプロイされます。

これにより、以下の問題が発生します。

特に、マネジメントコンソールからコードを確認・編集できない点が問題です。

◆そもそもマネジメントコンソールからコードを確認・編集ことはあるのか

Amplify で管理するリソースが増えるにつれて、Amplify のデプロイ速度そのものが低下します。

  • ちょっとした変更でも、デプロイ完了までに数分要する

これは、一度のトライアンドエラーの度に、数分待たされることを意味します。

この時、マネジメントコンソールからコードを確認・編集できると、該当コードをさっと修正・手動デプロイして動作確認できます。

つまり、トライアンドエラーの速度が向上し、総じて開発効率が向上します。

◆マネジメントコンソールから編集する際の注意点

マネジメントコンソールから加えた編集は、 Amplify デプロイ時に全て上書きされます。

編集結果をAmplify 配下に取り込むには、問題のない事を確認できたコードを、Amplify 管理下の Lambda ソースコードにも反映させる必要があります。

マネジメントコンソール経由の編集は、時間のかかる amplify push を待ちたくないような、以下のようなユースケースで使用するものだとお考え下さい。

  • コードのちょっとした調整
  • 軽微なバグ修正
  • 頻繁に繰り返すトライアンドエラー

こうして満足のいくコードを作成できたら、変更箇所は忘れずに Amplify 管理下の Lambda ソースコードにも反映させましょう。

外部ライブラリ専用の LambdaLayer を設けて管理する

外部ライブラリ専用の LambdaLayer を設け、そこで外部ライブラリを管理します。

後は、外部ライブラリを使用したい Lambda関数に、 LambdaLayer を紐づけるだけです。

これにより、以下の効果が得られます。

  • Lambda関数本体と LambdaLayer は別々にデプロイできるようになる
  • Lambda関数本体のデータ量を軽量に保つことが出来る
    • Lambda関数のデプロイ速度が向上
    • (3MBを越えなければ) マネジメントコンソールからコードを確認・編集できる

公式ドキュメントに、Amplify cli から LambdaLayer を（作成方法を含め）Lambda 関数に関連付ける方法が記載されています。

まとめると ... ?

外部ライブラリは、専用の LambdaLayer を設けて管理しましょう。

これにより、開発効率が向上します。

  • Lambdaのマネジメントコンソールからコードをトライアンドエラーできる
    • 時間のかかる amaplify push を待たずにコードを試行錯誤できるため、開発速度が向上する

Amplify のカスタマイズは慎重に検討しよう

Amplify がサポートするAWSリソースは決して多くありません。

そのため、Amplify 未サポートのAWSリソースを Amplify で扱う手段がいくつか用意されています。

カスタマイズのつらみ

いざ上記手段でカスタマイズを試みると、以下のような問題に直面します。

  • 運用・保守が大変
  • Web上に情報が少ない
    • 公式ドキュメント
    • やってみた系の記事

これにより、 amplify の管理に大きく消耗することとなります。

◆運用・保守が大変

Amplify の実態は Cloudformation です。

そんな Amplify をカスタマイズするため、発生するエラーも、 Cloudformation 由来のものが中心となります。

当然、トラブルシュートに、 Cloudformation の知識が必要となります。

また、Amplify は、デプロイ時に発生したエラーのロールバックが非常に遅いです。

  • Amplify の実態が Cloudformation であることを思い出してください
  • Cloudformation を触ったことがある方なら覚えがあるかと思います

そのため、一回のトライアンドエラーに数分（下手するとそれ以上）の時間を要します。

◆Web上に情報が少ない

Amplify カスタマイズの「やってみた系」記事は決して多くありません。

そのため、トラブルシュート時やカスタマイズ実装時（特に override 系）は公式ドキュメントが頼りとなるのですが、公式ドキュメントだけでは解決出来ない問題も発生し得ます。

本当にカスタマイズする必要はあるのか

Amplify を使い始める動機の多くは「スモールスタート」にあると思います。

しかし、Amplify をカスタマイズした結果、カスタマイズやその後の運用・保守に消耗するようになります。

せっかくクラウドインフラを Amplify にまかせて機能実装に注力しようと Amplify を選択したのに、Amplify の管理に時間を取られる ... 。

これでは本末転倒です。

いきなりカスタマイズに走るのではなく、以下の代替案を検討することをお勧めします。

  • 手動運用
    • Amplify 未サポートのAWSリソースは、管理コンソールなどで手動作成する
    • 手順書を作成・適切に管理することで、誰でも対応できる
    • 更新頻度が少ない場合は有効
  • 独自 CDK,Cloudformation を Amplify に取り込まずに運用する
    • Amplify と 独自CDK,Cloudformation のダブル運用
    • デプロイの手間は多少増えるが、AWSリソースの依存関係を制御しやすい
      • AWSリソース依存関係にまつわる CloudFormation エラーにある程度対処できる
    • 以下の場合に有効
      • 更新するAWSリソースが多い
      • 頻繁にデプロイする

Amplify のカスタマイズは、 Ruby on Rails でいう、「レールから外れる」行為に相当します。

公式が用意したフレームワークを超えて機能を拡張するため、ある程度の技術力と覚悟が必要になります。

まとめると ...?

Amplify のカスタマイズは慎重に検討しましょう。

  • 以下の代替案ではダメですか？
    • AWSリソースの手動運用
    • 独自 CDK （または Cloudformation）とのダブル運用
  • カスタマイズの費用対効果は十分ですか？
    • カスタマイズで得られる価値は、カスタマイズ工数と、カスタマイズ後の運用・保守工数に見合っていますか？

おわりに

Amplify は、スモールスタートを切りたい場合において、非常に優れた選択肢だと思います。

上手に使いこなしたいものです。

自分は色々失敗して学びましたが、この知見が他の方の一助となれば幸いです。

参考記事

Discussion