はじめに
SalesNowでデータエンジニアをしているトツです。
SalesNowでは、以下の2つのサービスを展開しています。
-
SalesNowDB
- 企業データベースメディア
-
SalesNow
- 企業データベースSaaS
本記事では以下の二つのサービス間のデータ同期にPostgreSQLの論理レプリケーションを活用していることについて、導入までの経緯を紹介します。
PostgreSQLにはAmazon Auroraを使用しています。
※詳細な構成や設定方法、運用に関しては記載しておりません。
論理レプリケーションとは
論理レプリケーションとは、データベース間のデータ複製を物理レプリケーションに比べて柔軟に行うことが可能なレプリケーション方式です。
物理レプリケーションがデータベース全体を物理的に同期するのに対して、論理レプリケーションは同期対象をスキーマ、テーブル、カラム、レコード単位で絞るなど柔軟な複製が可能です。
また、論理的な複製方式のため複製元と先でDBバージョンが不一致の場合でも使用可能です。
これらの特徴によって、物理レプリケーションの用途がHAやDR構成に向くのに対し、論理レプリケーションの用途は異なる構成のDB間でのデータ連携に向いています。
当技術の詳細やサンプルは、以下を参考にしていただければと思います。
- 第31章 論理レプリケーション(PostgreSQL公式ドキュメント)
- 論理レプリケーション解説 ～ 仕組み、設定方法 ～
- Using PostgreSQL logical replication with Aurora
導入までの経緯
導入理由は、以下の二つを満たすためです。
- サービスが互いのパフォーマンスに影響を与えない
- サービス間で共通のデータは単一管理
この二つの必要性を理解するために、SalesNowとSalesNowDBのデータベースの歴史について解説しておきます。
2つのサービスで扱っているデータはリリース初期段階でほとんどが同一であったため、当時は共通のデータベースを使用していました。
しかし、サービスが成長して機能やユーザーが増えるにつれて読み書き負荷がアンバランスになり、SalesNowDB関連による負荷が別サービスであるSalesNowのパフォーマンスに致命的な影響を与える状況にまで陥りました。（パフォーマンス依存問題）
これを解消するために、別データベースとして切り出されたという背景があります。
パフォーマンス依存問題は解消しました。しかし、独立させたことで各々が別の形に変化を遂げ、それらに合わせたデータ整形や更新処理が必要になりました。そこに、SalesNowが扱うデータの種類と量の増加スピードが早くなっていることが相まって開発コスト増加が次の課題になりました。（幸い中の不幸、、？）
これを解消するために論理レプリケーションで同一データのみレプリケーションすれば、パフォーマンス独立性を保ちつつ開発コスト増加を抑えることができると考え導入に至りました。
サービス間のレプリケーション構成
以下のようにSalesNowをパブリッシャー、SalesNowDBをサブスクライバーとしています。
レプリケーション対象テーブルは、現状は求人情報やニュース情報等の比較的更新頻度が高いイベント系テーブルにしています（追々マスタ系テーブル等も対象にしていく予定）。
まとめ
本記事では、論理レプリケーションを使用することで、開発コストを大幅に高めることなくデータベースのパフォーマンス独立生も保ったまま、複数サービス間でデータを同期させていることについて紹介しました。
論理レプリケーションの設定方法や触ってみた系の記事は多く存在しますが、活用に至るまでの具体例を紹介している記事はほとんど見たことがないので、本記事に記載した内容は貴重な情報だと思います。導入検討中の方や同じような問題に直面している方々の参考に少しでもなれば幸いです。
論理レプリケーションの導入により発生した新たな課題とそれらの解消方法といった運用ノウハウも需要があれば記事にするかもしれません。
Discussion