RDSとAppSync構成の整理

整理

• Aurora Serveless V1のサポート
  • Aurora Data APIを使ったアクセス
• Aurora Serveless V1以外の場合、Lambdaを挟む必要がある
  • RDS x Lambdaのアンチパターン
    • RDS Proxyはあるが、ピン留め問題など考慮しないといけないことは多い

https://dev.classmethod.jp/articles/rds-proxy-avoid-session-pinning/#toc-11

何かしらのアプリケーションフレームワークやライブラリを利用してRDS Proxyに接続する場合、フレームワーク/ライブラリが自動的に発行するSET文によってピン留めが発生することも考えられるので要注意です。自動的にSET文を発行するようなフレームワーク/ライブラリを利用する場合はSET文が自動実行されないように調整しつつ、SET文を初期化クエリの方に移動させる必要があるかもしれません。ただし、自動発行されるSET文が変更しているパラメータが文字コードや照合順序だけであれば、同一アプリケーション間ではDB接続を共有できるので、初期化クエリへの移動は不要です。RDS Proxyを利用される際は、フレームワークの初期化処理の内容について再確認しておくと良いでしょう。

• App Sync自体の辛さ
  • JSと比較しての、VTLの辛さ
  • ミューテーション、クエリ、およびサブスクリプションのリクエスト実行時間30秒で引き上げ不可能 参考

RDBを使う場合、Fargate x NestJS構成が採用されやすい気がする(要出典)理由

• GraphQLはApollo Serverの勢いがある
• AppSyncが対応しているAurora Serveless V1は本番ワークロードで使われるケースが少ない
  • 制約はここら辺 ここら辺
  • RDSやv1以外を利用する場合、LambdaとRDSの相性の悪さがある
• 事例の多いFargate NestJS構成で良くね？となる
• Aurora Serverless v1の辛み
  • MySQL 5.7縛り(8系から結構進化しているので 2倍高速とかある..)
  • マルチAZ構成取れない(
  • 0ACUまで縮退。V1の場合は、一定時間アクセスがないと一時停止し、アクセスがあると起動する。
    • ユーザー向けには不向き。社内でのみ使うアプリケーション、開発やステージング環境で使うならあり