本番稼働中のMySQLからPostgreSQLへの移行記録：マルチテナント化を実現するための技術的挑戦
本記事は、クラウド管理システム「ショップカウンター エンタープライズ」（SCE）のマルチテナント化に伴い、本番環境で稼働していたデータベースをMySQLからPostgreSQLへ完全に移行したプロセスを詳細に記している。
【背景と目的】マルチテナント化を実現するためには、「Row Level Security (RLS)」というDB層での二重防御が必須であった。このRLS機能はPostgreSQLの宣言的な機能であり、MySQLでは擬似的に実現する必要があるため、データベースエンジンそのものの移行（MySQL $\rightarrow$ PostgreSQL）が避けられなかった。
【移行戦略と技術的選択】データ移行手段として、pgloaderや自前スクリプトも検討されたが、最終的には「ActiveRecord経由のコピー」を採用した。これは、開発チームが日常的に使用するRailsのORM（Object-Relational Mapping）を経由することで、アプリのバリデーションや暗号化処理といったプロダクト固有のロジックを維持しつつ、RDBMS間の差異吸収レイヤーを利用できるというメリットがあったためである。
【段階的な移行プロセス】本番環境への影響を最小限に抑えるため、以下の段階的戦略が取られた。1. `database.yml`を3-tier構成に変更し、MySQLとPostgreSQLの両方への接続準備を行う。2. 開発・テスト環境でPostgreSQLコンテナを起動させ、Railsアプリが空のDBに対して動作する状態を作る。3. 環境変数（`USE_POSTGRESQL`）を利用することで、アプリケーション全体の接続先を本番デプロイ前に切り替え可能にする。4. MySQL用のマイグレーションファイルをPostgreSQL用に修正・整備し、スキーマを構築した。
【課題と教訓】移行過程では、ロケール起因の並び順崩れや、Railsの単一テーブル継承（STI）に起因するデータ取りこぼしの障害が発見され、再発防止策が講じられた。筆者はこの経験から、「プロダクト要件に基づいたローカル環境でのロケールの意識的な選択」「ActiveRecordの規約外モデルへの注意」「検証スクリプトと移行実装の分離」という重要な教訓を得た。
背景
マルチテナント化とは、単一のシステム環境内で複数の顧客（テナント）が独立したサービスを利用できる構造を指します。この実現には、データレベルでの分離保証（RLSなど）が必要であり、本記事ではその要件を満たすためにMySQLからPostgreSQLへの大規模なDBエンジン移行という技術的課題に直面しました。
重要用語解説
- Row Level Security (RLS): データベースの機能の一つで、特定のユーザーやロールがアクセスできるデータ行を制限する仕組み。マルチテナント環境において、各テナントが他のテナントのデータを見られないように保証するために必須となる。
- ActiveRecord: Ruby on Railsで使用されるORM（Object-Relational Mapping）ライブラリ。データベースとのやり取りをオブジェクト指向で行えるため、RDBMS間の差異吸収やビジネスロジックの適用に利用された。
- マルチテナント化: 単一のアプリケーションインスタンスとデータベース環境内で、複数の独立した顧客（テナント）がサービスを利用できる構造設計のこと。データ分離とセキュリティが最大の課題となる。
今後の影響
本件は、大規模なレガシーシステムを最新のクラウドネイティブなアーキテクチャへ移行する際の具体的な手順書として極めて価値が高い。特に、段階的な環境切り替え（3-tier config）や、既存ロジックを維持したデータコピー戦略は、今後のエンタープライズシステムのDX推進における重要な参考事例となる。