メインコンテンツにスキップ

AWSプラットフォームへのデプロイ時の注意点

以下では、さまざまなAWSプラットフォームにデプロイする際に直面する可能性のある注意点について説明します。

AWS RDS Proxy​

Prisma ORMはAWS RDS Proxyと互換性があります。ただし、RDS Proxyが接続をピン留めする方法により、Prisma ORMで接続プーリングに使用してもメリットはありません。

「プロキシへの接続は、ピン留めとして知られる状態になる可能性があります。接続がピン留めされると、セッションが終了するまで、後続の各トランザクションは同じ基盤となるデータベース接続を使用します。他のクライアント接続も、セッションが終了するまでそのデータベース接続を再利用できません。セッションは、Prisma Clientの接続がドロップされると終了します。」 - AWS RDS Proxy Docs

プリペアドステートメント（任意のサイズ）または16 KBを超えるクエリステートメントは、RDS Proxyにセッションをピン留めさせます。Prisma ORMはすべてのクエリにプリペアドステートメントを使用するため、Prisma ORMでRDS Proxyを使用してもメリットはありません。

AWS Elastic Beanstalk​

AWS Elastic Beanstalkは、インフラストラクチャを抽象化し、AWSにアプリケーションを迅速にデプロイできるようにするPaaSのようなデプロイメントサービスです。

Prisma Clientを使用してAWS Elastic Beanstalkにアプリをデプロイする場合、Prisma ORMはPrisma Clientコードをnode_modulesに生成します。これは通常、package.jsonで定義されたpostinstallフックで行われます。

Beanstalkはpostinstallフックでファイルシステムへの書き込み機能を制限しているため、プロジェクトのルートに.npmrcファイルを作成し、次の構成を追加する必要があります

.npmrc
unsafe-perm=true

unsafe-permを有効にすると、npmがrootとして実行されるようになり、ファイルシステムアクセスの問題を回避し、postinstallフックのprisma generateコマンドがコードを生成できるようになります。

エラー：@prisma/client がまだ初期化されていません​

このエラーが発生するのは、AWS Elastic BeanstalkがdevDependenciesをインストールしないため、Prisma CLIを認識しないためです。これを解決するには、次のいずれかの方法があります

  1. prisma CLIパッケージをdevDependenciesではなくdependenciesに追加します。（その後npm installを実行してpackage-lock.jsonを更新してください）。
  2. または、AWS Elastic BeanstalkインスタンスにdevDependenciesをインストールします。これを行うには、AWS Elastic Beanstalk NPM_USE_PRODUCTION環境プロパティをfalseに設定する必要があります。

AWS RDS Postgres​

AWS RDS PostgresでPrisma ORMを使用する場合、マイグレーションまたはランタイム中に接続の問題や次のエラーが発生する可能性があります

Error: P1010: User <username> was denied access on the database <database>

原因​

AWS RDSはデフォルトでSSL接続を強制し、Prismaはデータベース接続文字列をrejectUnauthorized: trueで解析します。これには有効なSSL証明書が必要です。証明書が正しく構成されていない場合、Prismaはデータベースに接続できません。

解決策​

この問題を解決するには、DATABASE_URL環境変数を更新してsslmode=no-verifyオプションを含めます。これにより、厳密なSSL証明書検証がバイパスされ、Prismaがデータベースに接続できるようになります。次のように.envファイルを更新してください。

DATABASE_URL=postgresql://<username>:<password>@<host>/<database>?sslmode=no-verify&schema=public

これが機能する理由​

sslmode=no-verify設定は、pg-connection-stringパッケージを介してrejectUnauthorized: falseをSSL構成に渡します。これにより、厳密な証明書検証が無効になり、PrismaがRDSデータベースとの接続を確立できるようになります。

注​

sslmode=no-verifyを使用することは応急処置になりますが、SSL検証をバイパスするため、本番環境のセキュリティ要件を満たさない場合があります。そのような場合は、有効なSSL証明書が適切に構成されていることを確認してください。

AWS Lambda アップロード制限​

AWS Lambdaは、デプロイパッケージのアップロード制限を定義しており、これには以下が含まれます

Lambdaのデプロイパッケージ（.zip）のサイズ制限は50MBです。デプロイパッケージを準備するときは、最終的な.zipをできるだけ小さくするために、関数が本番環境で必要としないファイルを削除してください。これには、一部のPrisma ORMエンジンバイナリが含まれます。

不要なPrisma ORMエンジンの削除​

Prisma CLIは、本番環境では不要な追加のエンジンバイナリをダウンロードします。次のファイルとフォルダーを削除できます

  1. node_modules/@prisma/enginesフォルダー全体（Prismaエンドツーエンドテストで使用されるサンプルbashスクリプトを参照してください）

  2. node_modules/.prisma/clientフォルダーの開発プラットフォーム用のローカルエンジンファイル。たとえば、Debian（native）で開発し、AWS Lambda（rhel-openssl-3.0.x）にデプロイする場合、スキーマは次のbinaryTargetsを定義する場合があります

    binaryTargets = ["native", "rhel-openssl-3.0.x"]

    このシナリオでは

    • AWS Lambdaで使用されるエンジンファイルであるnode_modules/.prisma/client/query-engine-rhel-openssl-3.0.xを保持します

    • ローカルでのみ必要なnode_modules/.prisma/client/query-engine-debian-openssl-1.1.xを削除します

    注：Node.js 18以前を使用する場合、AWS Lambdaの正しいbinaryTargetはrhel-openssl-1.0.xです。rhel-openssl-3.0.xは、Node.jsバージョン18より大きい場合の正しいbinaryTargetです。