- Infisicalは1日に5,000万件以上のSecretを処理するプラットフォームへと急成長
- 利用量の増加に伴いスタックを継続的にアップグレードする必要があり、最近ではMongoDBからPostgreSQLへのデータベース全体の移行を実施
- この移行には、新技術の採用、データベーススキーマの作成、ロジックの再構成、クエリの書き換え、数百万件（あるいは数十億件）のデータレコードをPostgreSQLへ移すという複雑な工程が含まれていた
開始段階
- Infisicalを最初に構築した際、チームが最も慣れているスタックとしてMongoDB + Mongoose ORMを選択
- 当初はInfisical CloudというマネージドSaaSの提供により注力しており、ユーザーが製品をセルフホストするケースはあまり想定していなかった
なぜMongoDBではなかったのか？
- MongoDBは初期段階ではうまく機能していたが、製品のユースケースがマネージドサービスの枠を超えるにつれ、欠点が目立ち始めた
- 多くの組織がInfisical CloudではなくInfisicalのセルフホストを好み、一部ではオンプレミス要件を満たす必要があった
- MongoDBの制約と使い勝手の問題により、PostgreSQLへの移行を決定
なぜPostgreSQLを選んだのか？
- 新しいデータベースを検討するにあたり、管理のしやすさ、トランザクション対応、リレーショナル機能などが重要な要素として考慮された
- 内部ストレージと外部ストレージソリューションの間で検討したが、最終的にPostgreSQLを選択
- PostgreSQLは活発なコミュニティ、豊富なドキュメント、多様なソリューションと拡張機能を備え、ほとんどのクラウドプロバイダーでマネージドサービスが提供されている
ORMについて
- PostgreSQLを選んだ後、アプリケーションがデータベースとどうやり取りするかを決める必要があった
- Mongoose ORMに近い体験を提供するツールを探し、Knex.jsクエリビルダーを使うことにした
- Knex.jsはシーディングとマイグレーションのツールを提供しており、TypeScript対応のために独自のZod統合作業を行うことで、満足できる水準に達した
移行計画
- コードの書き換えが終盤に差しかかった頃、MongoDBのデータをPostgreSQLへ最小限の中断でマッピングする移行作業をどう進めるかを検討
- 重要インフラの役割を担うInfisicalではダウンタイムを一切許容できず、移行期間中は書き込みを禁止するという妥協を選んだ
大移動
- 移行準備のため、詳細なチェックリストと想定タイムラインを作成
- 移行は6時間にわたって読み取り専用で実施され、データ移行後にDNSを新しいインスタンスへ切り替えた
結果
- 移行はデータ損失なく順調に進み、顧客への影響が最小限のいくつかの機能不具合を36時間以内に修正
- プラットフォームはJOINを活用したクエリ最適化により性能が向上し、データベースコストも50%削減
- PostgreSQL導入によってデータ検証が改善され、Infisicalはセルフホストがはるかに容易になった
結論
- MongoDBからPostgreSQLへの移行という決断は容易ではなく、慎重な計画と議論を経て3〜4か月を要した
- このような大規模プロジェクトに挑戦する前に、ユースケースと実装を深く検討することを勧める
1件のコメント
Hacker Newsの意見
Postgres と MongoDB を大規模に運用した経験があるあるユーザーは、両方のデータベースが好きだとしつつも、Postgres の高可用性（HA）と水平スケーリング支援の欠如は理解できないと述べている。Postgres のセットアップは毎回固有で、これを補うためにさまざまな拡張機能やスクリプトを使う必要があると指摘している。こうした拡張機能はしばしばバグが多く、ドキュメントも不足していると付け加えている。Postgres のメジャーバージョンにおけるファイル形式変更のため、アップグレードが非常に困難だとも述べている。MySQL が HA/シャーディングで Postgres よりはるかに優れている点に驚いている。
MongoDB から PostgreSQL へのマイグレーション経験を技術的な観点から説明したブログ記事が共有されている。この記事は例やグラフを含み、より技術的でビジネス寄りの内容は少ないと言及されている。
PostgreSQL がデータベース界を席巻していると述べるユーザーは、著者たちが最初にデータモデルに適していないアーキテクチャを選んだと指摘している。リレーショナルデータを非リレーショナルストレージに入れると、常に問題を引き起こすだろうと述べている。
MongoDB と Mongoose ORM を選んだ理由が、機能開発の速度を高めるために最適化された選択だったと主張する文と、Tony Hoare の「早すぎる最適化は諸悪の根源である」という引用を使ってその選択を正当化する文のあいだにある矛盾を指摘している。
ドキュメント指向データベースは新しいプロジェクトには適していないと考えるユーザーは、MongoDB のライセンス費用とホスティング費用が増加し、機能開発は停滞すると予想している。
MongoDB が原因で発生した問題のために Postgres へ移行した経験があるユーザーは、その決定に非常に満足していると述べている。MongoDB が SQL の代わりに JavaScript を使うのが不便だったとも付け加えている。
実際のリライト過程で発生した問題についての議論が欠けていると指摘するユーザーは、クエリが等価に実現されたのか、両方のデータベースで読み書きできるようにプロダクトをどう構成したのか、マイグレーション中にバグが見つかったのか、クエリを 1:1 で移行できたのかといった質問をしている。
MongoDB を使ったことがあるユーザーは、ドキュメント指向データベースが一部のユースケースに適していることは認めつつも、Mongoose を使わなければならないと気づいた時点でリレーショナルデータベースへの移行を検討すべきだと述べている。ほとんどの場合、Mongoose は既存プロジェクトに追加するものであり、最初から必要ならリレーショナルデータベースを使うべきだと助言している。
MongoDB を使うプロジェクトを引き継いだユーザーは、BSON 形式は好ましくないが、JSON API からデータベースまで同じスキーマを使える点は気に入っていると述べている。Go や Rust でのデータ指向プログラミングにも向いていると付け加えている。MongoDB は読み取り中心の処理にしか適していないと結論づけ、書き込みが多い場合には MongoDB はあまり役に立たないと述べている。
技術的な理由よりもライセンス上の問題が PostgreSQL へ移行した主因だったと述べるユーザーは、JOIN を使ったクエリ最適化によって性能向上を経験したと共有している。データがキー・バリュー・ストアに適した形でモデル化されていなかったため、適切な種類のストレージへ移行することが決定的な理由になったと述べている。