CastingONE、クライアント企業データのセキュリティ強化のためMySQLからPostgreSQL（AlloyDB）へ移行

CastingONEはクライアント企業の増加に伴い、単一スキーマで全クライアントのデータを管理する既存構成にセキュリティ上のリスクを感じるようになった。PostgreSQLにはRow Level Security（RLS）という、データを論理的に分割してアクセス制御できる仕組みがあり、これを使えば各クライアント企業のデータを行単位で分離できる。そこでMySQL（Google Cloud SQL）からPostgreSQL（Google Cloud AlloyDB）への移行を決定した。移行先のAlloyDBはPostgreSQLと完全互換性を持ちながら、Cloud SQLと比較してパフォーマンスとコストの両面で優れていると判断されて選ばれた。バックエンドはGo言語・クリーンアーキテクチャで構成されており、MySQLRepositoryに倣う形でPostgresRepositoryを実装し、go generateコマンドで自動同期する仕組みを整えた。

移行方式として、新旧DBへ同時に書き込むDual Writer構成も検討されたが、MySQLとPostgreSQLではAuto Incrementの採番値が異なる可能性があり、データ整合性を保証できないという理由から採用を見送った。最終的に、QA期間で入念なテストと永続化層テストの強化を行ったうえで、一度の切り替えで本番移行する方針を選んだ。

スキーマはpgloaderで変換した上でインデックス名やシーケンスの命名などを手作業で調整し、データ移行は次の4ステップで構成された。

• CSVエクスポート: MySQLのデータをGCSへ出力（read replicaを使い並行処理、約1時間）
• CSVダウンロード: GCE上のローカルSSDへ取得（約7分）
• CSV変換: PostgreSQL形式へ並行処理で変換（約7分）
• インサート: 外部キー制約を一時的に外してインポート（約1時間）

約6人のエンジニアが約半年かけて計画・実装を進め、本番切り替え前に4回のリハーサルを実施して手順を検証した。

本番切り替え後、稼働当初は軽微なエラーが発生したものの、その後は基本的に安定して稼働している。狙い通りPostgreSQLのRLSを導入でき、クライアント企業ごとにデータを行単位で論理分割してアクセス制御する体制が実現した。記事中に移行によるコスト削減額やパフォーマンス改善の具体的な数値は示されていない。