概要

Lambdaにアップするソース(zip)の中に、ローカル端末上でインストールしたdjangoのパッケージをそのまま格納してアップロード。

Lambda関数は指定のDBに対してdjango migrationを行うコードです。
しかし、実施すると以下のエラーになってしまいました。

{"statusCode": 500, "body": "{"error": "Migration failed", "details": "(1060, \"Duplicate column name 'type'\")", "makemigrations": "No changes detected\n", "traceback": "Traceback (most recent call

前提

少し前提を説明します。

実際に稼働しているDBからdumpした最新データファイルをそのまま対象のRDSにrestoreしました。

その際にエラーは無し。
稼働してるDBと比べて、django_migrationsテーブルの中身も一致、最新migrationが適用されていることも確認しました。

しかしLambda関数を叩くと上述のエラー。

エラーメッセージにある「type」カラムはすでに反映済み、そのmigrationファイルも適用済みでした。

Lambda関数の中にパッケージとして入れていたdjangoのバージョンは下記。

Django==4.2.11
django-cors-headers==3.10.0
PyMySQL==1.1.2
mysqlclient==2.2.7

原因

Lambda関数のzipに含めたDjangoのバージョン（4.2.11）が、本番環境のDjangoバージョン（5.1）と一致していなかったことが原因だったと思います。

Django 5.1で動いていた本番DBをダンプして復元したため、django_migrationsテーブルにはDjango5.1のマイグレーション記録が含まれていた
しかしDjango 4.2.11のマイグレーションファイルで実行しようとしたため、マイグレーション状態に不整合が発生した
"Duplicate column name 'type'" エラーは、Django 5.1で既に適用済みのマイグレーションを、Django 4.2.11が再度適用しようとしたために発生した

解決方法

以下のパッケージをLambdaLayerにアップロード、Lambda関数からこちらを参照する形としました。

Django==5.1
django-cors-headers==3.10.0
PyMySQL==1.1.2
mysqlclient==2.2.7

これでDjangoのバージョンを本番環境と一致し、
正常にマイグレーションができるようになったのだと思われます。

Lambda環境でのパッケージ検索順序

Djangoは以下の順序でマイグレーションを検出します。

sys.path の各ディレクトリから /migrations/ を探す
/var/task/ が最初に検索される（カレントディレクトリ）
/opt/python/ はその後（Lambda Layer）

解決後の構成

/var/task/ にはアプリケーションのマイグレーションのみ
/opt/python/ にDjango 5.1（本番と同じバージョン）を配置
Lambda関数のzipからはDjangoパッケージを削除
アプリケーションコードとライブラリを明確に分離

これにより、バージョンが一致し、正常に動作するようになりました。

今回はちょっと検証してみたくて触っていただけだったので、簡単に実験できるようことを重視して、Djangoのバージョン違いなどあまり気にせず実施してしまっていました。

バージョンやLambdaLayerを使うことなど、実際に稼働しているものと同じ条件にするとエラーの原因がわかりますね。

参考

mysqlclientをLambdaLayerで扱う際にはちょっと注意が必要です。
以前以下の記事でも紹介したのでご参考までに。