La Grande Migration de MongoDB vers PostgreSQL : comment Infisical a r�ussi le passage ?
La Grande Migration de MongoDB vers PostgreSQL : comment Infisical a r�ussi le passage
quelles sont les raisons qui l'ont motiv�e � quitter MongoDB et pourquoi s'est-elle orient�e vers PostgreSQL ?
Infisical, une plateforme en pleine croissance, traite d�sormais plus de 50 millions de secrets par jour. Ces secrets sont des configurations d�applications et des donn�es sensibles envoy�es aux �quipes, aux pipelines CI/CD et aux serveurs/applications qui en ont besoin. Face � cette croissance, Infisical a d� mettre � jour sa pile technologique. R�cemment, Infisical a effectu� une migration compl�te de sa base de donn�es de MongoDB � PostgreSQL. Ce processus complexe a n�cessit� une r�flexion approfondie, l�adoption de nouvelles technologies, la cr�ation de nouveaux sch�mas de base de donn�es, la r��criture de requ�tes et la migration de millions (voire de milliards) d�enregistrements vers PostgreSQL. Voici l�histoire de la d�cision d'Infisical de passer de MongoDB � PostgreSQL et de la mani�re dont ils l'ont r�alis�e.
Pourquoi avons-nous migr� ?
D�but avec MongoDB
Lorsque nous avons initialement construit Infisical, nous avons choisi MongoDB + Mongoose ORM, car cette combinaison pr�sentait le moins de surcharge et nous permettait de livrer rapidement des fonctionnalit�s de qualit�. � l��poque, nous �tions davantage concentr�s sur Infisical Cloud, notre offre SaaS g�r�e. Nous n�avions pas anticip� autant d�utilisateurs auto-h�berg�s du produit, et il n�avait donc pas �t� con�u dans cette optique.
Limitations de MongoDB
Bien que MongoDB ait bien servi Infisical au d�but, il a montr� ses limites lorsque notre produit a �volu� au-del� du service g�r�. De plus en plus d�organisations, notamment celles op�rant � l�intersection de la conformit� et de la s�curit�, ont pr�f�r� l�auto-h�bergement d�Infisical plut�t que d�utiliser Infisical Cloud. D�autres avaient des exigences sur site � respecter. La demande croissante pour l�auto-h�bergement nous a amen�s � quitter MongoDB au profit de PostgreSQL.
Probl�mes avec MongoDB
Voici quelques-uns des probl�mes que nous avons rencontr�s avec MongoDB :
- Transactions difficiles � configurer : la mise en place de transactions avec MongoDB n��tait pas triviale, car elle n�cessitait l�ex�cution de MongoDB en mode cluster avec diverses configurations. Cela rendait difficile la r�alisation d�un simple POC d�Infisical, car cela exigeait une configuration de production de MongoDB ;
- Manque de support pour les transactions : MongoDB ne prenait pas en charge les transactions de mani�re native, ce qui posait des probl�mes pour les op�rations critiques ;
- Structure de base de donn�es sans sch�ma : bien que la flexibilit� de MongoDB soit un avantage, elle a �galement entra�n� des probl�mes de conception de sch�ma. La conception sans sch�ma a rendu difficile la gestion des versions et la maintenance.
Pourquoi PostgreSQL ?
Lors de notre recherche d'une nouvelle base de donn�es, nous avons commenc� par dresser la liste des aspects qui nous importaient le plus : facilit� de gestion (c'est-�-dire configuration, d�ploiement et mise � l'�chelle inclus), support int�gr� des transactions et capacit�s relationnelles. Dans le cadre de nos d�lib�rations, nous nous sommes �galement demand� si nous devions ou non cr�er notre propre syst�me de stockage int�gr� ou opter pour une solution de stockage externe.
Voici ce que cela signifie pour chaque option :
- stockage int�gr� : Nous pourrions int�grer un syst�me de base de donn�es comme SQLite directement dans Infisical et poursuivre une strat�gie de r�plication horizontale pour r�duire la latence en �vitant les sauts de r�seau suppl�mentaires. Dans ce mod�le, la mise � l'�chelle du syst�me impliquerait de d�ployer plusieurs instances d'Infisical et de les faire communiquer entre elles par le biais d'un algorithme de consensus comme Raft. Bien que cela semble �tre une excellente solution puisque les clients n'auraient pas besoin de connecter des d�pendances pour faire fonctionner Infisical, l'�cosyst�me d'outils pour ex�cuter cette vision semblait immature et l'effort d'ing�nierie requis pour cela semblait rien de moins que d�mesur� ;
- stockage externe : Nous pouvions simplement remplacer MongoDB par une ou plusieurs autres bases de donn�es telles que PostgreSQL ou MySQL et utiliser leurs capacit�s d'extension int�gr�es. Bien que cette solution n'ait pas totalement �limin� les frictions associ�es au besoin de d�pendances externes pour utiliser Infisical, nous avons estim� qu'elle offrait d�j� des avantages significatifs du fait qu'il ne s'agissait pas de MongoDB. Lorsqu'il s'est agi de prendre en charge une ou plusieurs bases de donn�es, nous avons estim� que le fait de prendre en charge plusieurs bases de donn�es reviendrait � se priver des avantages uniques de chaque solution ; cela ajouterait �galement � nos frais g�n�raux d'ing�nierie.
Apr�s m�re r�flexion, nous avons choisi PostgreSQL. En plus d'une communaut� dynamique, d'une documentation compl�te et d'une myriade de solutions et d'extensions disponibles, nous avons surtout appr�ci� sa nature open source et le fait que la grande majorit� des fournisseurs de cloud proposent des services g�r�s de PostgreSQL.
Cela signifiait surtout que les utilisateurs d'Infisical pouvaient plus facilement auto-h�berger notre plateforme sur n'importe quel fournisseur de cloud et la coupler avec le service g�r� PostgreSQL correspondant. De plus, compte tenu de la large adoption de cette base de donn�es, nous �tions convaincus que les utilisateurs auraient moins de difficult�s � l'utiliser dans le cadre d'Infisical.
Qu'en est-il de l'ORM ?
Apr�s avoir choisi PostgreSQL, nous devions d�terminer comment notre application interagirait avec la base de donn�es. D'embl�e, nous voulions quelque chose de comparable � notre exp�rience avec MongoDB o� nous avons utilis� l'ORM Mongoose. Nous avons donc commenc� � �valuer les candidats sur la base de la maturit�, de la visualisation et du support de migration, et du niveau d'abstraction appropri� ; nous avons principalement consid�r� Drizzle ORM, Prisma ORM, TypeORM, et Knex.js, un constructeur de requ�tes.
Finalement, nous avons d�cid� d'utiliser Knex.js, un g�n�rateur de requ�tes, au lieu d'un ORM pour garder un meilleur contr�le sur la base de donn�es. M�me s'il est vrai que l'utilisation de SQL brut serait plus polyvalente avec le moins d'abstraction possible, nous avons estim� que cette approche serait beaucoup trop sujette aux erreurs et franchement encombrante � maintenir, surtout sans un support TypeScript appropri�. De plus, en plus d'�tre proche de SQL brut, Knex.js �tait livr� avec sa propre bo�te � outils pour l'ensemencement et la migration, avait un �cosyst�me mature avec une excellente documentation et des r�ponses pour presque toutes les requ�tes possibles. Avec le travail d'int�gration de Zod, nous avons r�ussi � atteindre un niveau satisfaisant pour le support de TypeScript.
Apr�s avoir choisi la base de donn�es et l'ORM, nous avons lanc� un processus qui allait finalement aboutir � la r��criture de dizaines de structures de donn�es et de centaines de requ�tes dans l'ensemble de l'application.
Comment a �t� planifi� la migration ?
Vers la fin de la r��criture du code, nous avons commenc� � r�fl�chir � la mani�re dont nous allions mener l'op�ration de migration pour mapper nos donn�es MongoDB vers PostgreSQL avec un minimum d'interruption de la plateforme Infisical Cloud.
�tant donn� le r�le critique d'Infisical dans l'infrastructure des clients, nous avons imm�diatement exclu la possibilit� d'un temps d'arr�t absolu. Nous avons d� faire un compromis en interdisant les op�rations d'�criture pendant la br�ve fen�tre de migration (c'est-�-dire que les clients ne seraient pas en mesure de cr�er ou de mettre � jour la configuration de l'application) en �change d'une garantie plus �lev�e de l'int�grit� des donn�es. Ce compromis semblait acceptable �tant donn� que les clients r�cup�raient principalement des secrets d'Infisical et, dans une bien moindre mesure, mettaient � jour la configuration de leur application seconde par seconde.
Ensuite, en ce qui concerne l'op�ration de migration proprement dite, nous avons d� extraire les donn�es de MongoDB, les transformer soigneusement et les r�ins�rer dans PostgreSQL. Lors de l'audit de la s�quence de migration, nous avons d� relever des d�fis tels que s'assurer que les diff�rentes structures arborescentes de NoSQL �taient correctement transform�es en leurs �quivalents relationnels ; cela �tait particuli�rement d�licat pour les structures de donn�es telles que les dossiers qui comportaient des consid�rations r�cursives. Nous avons �galement constat� que nous avions besoin d'un moyen persistant de stocker et de faire correspondre les identifiants de MongoDB � ceux de PostgreSQL ; le faire en m�moire n'aurait pas fonctionn� compte tenu de la quantit� de donn�es que nous avions � traiter. Finalement, nous avons d�cid� d'utiliser le magasin clef-valeur LevelDB pour faciliter le stockage des identifiants et les op�rations de recherche. Gr�ce � lui, nous avons transf�r� les donn�es table par table dans PostgreSQL.
Le processus de migration
La migration elle-m�me s�est d�roul�e dans une fen�tre de six heures, pendant laquelle seules les op�rations de lecture �taient autoris�es sur la plateforme. Nous avons ex�cut� le script de migration pour d�placer les donn�es de MongoDB vers PostgreSQL, v�rifi� qu�aucune donn�e n��tait perdue et, si tout s�est bien pass�, nous avons bascul� le DNS vers la nouvelle instance. Des plans de secours �taient bien s�r en place en cas de probl�me.
En fin de compte, la migration vers PostgreSQL a �t� un succ�s et a permis d�am�liorer notre plateforme. Nous esp�rons que cette exp�rience pourra �tre utile � d�autres personnes envisageant une migration similaire.
Source : Infisical
Et vous ?
Quelles sont les principales diff�rences entre MongoDB et PostgreSQL en termes de mod�le de donn�es ? De fa�on plus g�n�rale, quelles sont les avantages et inconv�nients de chaque approche (document store vs. relationnel) ?
Voir aussi :
R�pondre avec citation
Partager