論理レプリケーション vs バッチETL：同期スタイルの選び方

「データを同期する」で何を解決しているのか？

チームがデータを別のシステムにコピーするのは、仕事が一箇所で完結することが稀だからです。営業は CRM に、決済は請求ツールに、業務は社内ダッシュボードにいるかもしれません。サポートはツールを行ったり来たりせずに全体像を見たいし、リーダーは実際の出来事と一致するレポートを欲しがります。

「信頼できる同期」は説明は簡単でも維持は難しいものです：正しいレコードが届き、重要なものが欠けず、更新が有用な速度で反映されること。「十分に速い」は仕事によって違います。詐欺検知なら数分が必要かもしれませんし、月次の財務報告なら数時間で問題ないでしょう。

同期が壊れると、多くの場合はレコード欠落、重複、フィールドの陳腐化、あるいは部分的な更新（例：注文ヘッダが届いたが行アイテムが届かない）として現れます。

役に立つ考え方は「イベント」と「スナップショット」です。

イベントは個々の変更を指します：「注文 #1842 が作成された」「ステータスが shipped に変わった」「返金が発生した」。差分を基にした手法はイベントを移動させることが多く、ほぼリアルタイムの振る舞いをサポートできます。

スナップショットは定期的なコピーです：「毎晩、昨日の注文をコピーする」など。バッチETLはたいていこの方式です。単純にはなりますが、データの鮮度は落ちます。

論理レプリケーションとバッチETLに関する多くの議論は本質的にこの選択に関するものです：継続的なイベントが必要なのか、定期的なスナップショットで十分か？

論理レプリケーションとバッチETLを簡単に説明すると

論理レプリケーションは、ソースデータベースが発生した変更を流れるように送ります。テーブル全体をコピーする代わりに「行が追加された」「行が更新された」「行が削除された」といった変更を発行します。宛先はそれらを順に適用するので、ソースと近い状態を保てます。

バッチETLはスケジュールに沿ってスナップショットを取得します。ジョブがデータを抽出し（多くは「最後の実行以降のすべて」）、必要なら変換して宛先にロードします。レプリケーションがライブ更新に近いとすれば、バッチETLは「毎時間（あるいは毎晩）チェックして追いつく」ような感覚です。

通常、稼働場所も異なります。レプリケーションはデータベースの変更ログの近くで継続的に動きます。バッチETLは定期実行して止まり、また実行するジョブです。

どちらにしても、信頼に関する同じ問いには答えなければなりません：

• 削除はどう表現して、宛先に“幽霊”行が残らないようにするか？
• 同じ変更が二度到着したらどう扱う（冪等性）？
• 多数の行が短時間で変わるとき、順序はどう保つか？
• 再起動や再デプロイの間に変更を見逃さないには？
• 「ジョブが成功した」だけでなく、欠落をどう検出するか？

例：注文が作成され、その後ステータスが「pending」→「paid」へ変わり、さらに返金される。レプリケーションは3つの変更イベントを送ります。日次スナップショットは最終的なステータスしか捉えないかもしれません（バッチ処理を中間状態を保持するように設計しない限り）。

鮮度とレイテンシ：どれだけリアルタイムに近い必要があるか

レプリケーションとバッチETLを比較する前に、業務的な言葉で「十分に新しい」を定義してください。数字で始めます：「サポートはデータが最大5分古くても対応できる」や「財務は前日の合計で十分」など。

鮮度は利用時点でのデータの古さ、レイテンシはソースの変更が宛先に反映されるまでの遅延です。平均レイテンシが低くても、同期が頻繁に止まると実際には「古い」データになり得ます。

レイテンシが実際にどこから来るか

単純な同期でも複数の遅延が積み重なります：検知（変更を認識する時点）、転送（データの移動）、処理（変換や重複排除）、適用（宛先への書き込みとインデックス作成）。

一定のトリクル（レプリケーションや頻繁なマイクロバッチ）は鮮度を安定させますが、同期を一日中運用する必要があります。スケジュールされたバッチは考えやすい代わりにスパイクを生みます：深夜2時に負荷が集中し、次の実行までデータは古くなります。

ほぼリアルタイムが役立つのは、人が素早く判断したり顧客が結果をすぐ見る必要がある場合です。サポートのダッシュボードは新しい注文をすぐに表示して、担当者が在庫切れの約束をしないようにするべきです。一方で主な利用が週次レポートや月次請求であれば、すべての小さな更新を即時に反映する複雑さは成果を改善しません。

実用的な判断方法：

• 同期データの利用者は誰で、どんな意思決定をするか？
• データが15分古かったら何が壊れるか？
• 継続的に運用するコストはどれくらいか（インフラ／オンコール）？
• 宛先が最も空いている時間はいつか？
• 誰にどんな鮮度を約束して伝えるか？

障害復旧：何かが壊れたあと正しい状態へ戻す

同期は劇的に失敗することは稀で、地味な失敗が多い：サーバ再起動、ネットワークの一瞬の切断、ロード中のジョブクラッシュなどです。目標は「絶対に失敗しない」ではなく「正しい最終状態に復旧する」ことです。

典型的な障害モードは、ソースの停止、宛先の停止、処理中のジョブクラッシュ、制約違反の悪いデータ、などです。

論理レプリケーションでは、復旧は通常保存された位置（ログオフセットなど）から変更を再生することです。宛先がダウンしている間は変更が溜まり、復旧後に順番どおりに適用されます。レプリケーションスロット（または同等の仕組み）を管理して、長期障害時に永遠に成長しないようにすることが重要です。

バッチETLでは、復旧は通常時間ウィンドウを再実行することです（例：「昨日を再ロード」や「直近2時間を再実行」）。運用は単純なことが多いですが、ロードロジックが二度実行しても安全である必要があります。

信頼を壊す最大の問題は部分書き込みです。バッチの70%を書き込んでクラッシュすると、重複や欠落が残ることがあります。両方式で有効なパターン：

• 入力を何度適用しても同じ状態になる冪等なロードにする。
• 安定した主キーでのアップサートを優先する。
• 成功コミットのあとでのみ「最後に処理した」マーカーを進める。
• 拒否された行は検査・再実行できる場所に保管する。

バックフィル（履歴のやり直し）は痛みが出やすいところです。月単位のデータを再処理する必要がある場合、バッチETLの方が勝つことが多いです。レプリケーションでもバックフィルは可能ですが、通常は別経路（まずスナップショットを取り、その後変更を適用）になるので、事前にテストしておく価値があります。

例：注文の同期が行アイテムを書いたがヘッダを書き込む前にクラッシュしたとします。注文ごと（あるいはバッチごと）に1トランザクションのアップサートを使えば、半分だけ同期された注文が残るのを防げます。

スキーマ進化：データモデルが変わったらどうなるか

スキーマ変更で多くの同期は静かに信頼を失います。パイプラインは動き続けても、下にあるデータの意味が変わり続けることがあります。レプリケーションはデータベースレベルで壊れやすく、ETL は変換やレポート段階で後から壊れることが多いです。

追記的な変更は扱いやすい：新しいカラム、新しいテーブル、任意フィールド。消費者がそれらを「追加情報」として扱い、デフォルトが合理的なら通常は問題になりません。罠は、下流のすべての利用者が新しいフィールドに気づくとは限らない点です。

壊す（破壊的）変更は危険です：名前変更、型変更、カラム削除、値の意味変更。これらはすぐにジョブエラーを起こすか（速い失敗）、データが届いてから誤りに気づく（遅い失敗）ことがあります。

安全に進化させる方法

移行が終わるまで互換性を保つこと：

• スキーマやペイロードにバージョンをつける（v1, v2）ので旧版と新版が共存できるようにする。
• 旧・新両方のフィールドをしばらく残す互換期間を設ける。
• 新しい形に依存するロジックを切り替える前にバックフィルする。
• 誰も参照していないことを確認してからフィールドを削除する。

マッピングが壊れる箇所

実際の壊れ方はシステム間の接着部分で起きます。例：ETL が orders を customer_id で customers と結合しているところが、client_id に名前が変わると結合がすべて NULL になるなどして、無自覚に誤った行を作ることがあります。

脆弱なスポットを監視してください：型キャスト、キーが変わらないことを前提にした結合、status が特定の値の集合であることを前提とした下流ルールなどです。

セキュリティと所有権：誰が何を同期できるか

セキュリティの課題は両方式で似ていますが、リスクの現れ方が異なります。レプリケーションは継続的に広範な読み取り権限で動くことが多く、バッチETL は一度に大きなスライスを引くことがあります。どちらでも、同期に必要な最小限の権限を与えることを目指してください。

人のログインではなく専用のサービスアカウントを使い、必要なテーブルやカラム、ビューだけに読み取り権限を与え、接続元を制限します。可能なら、宛先に渡すべきでないデータを除外済みの「同期用ビュー」を公開してください。

機密フィールドは驚きを生みます。宛先がレコードを必要としてもすべての情報を必要とするわけではありません。個人連絡先、支払い情報、内部メモなどを省くかマスク／トークン化するか早めに決めてください。データは転送中に暗号化し、シークレットはパイプライン設定に置かずシークレットストアで管理します。

所有権は後々の争いを避けます：

• 各フィールドのソース・オブ・トゥルースを決める（テーブル単位ではなくフィールド単位で）
• 宛先が書き戻し可能かどうかを定義する
• 競合をどう扱うか（最終書き込みが勝つ、ターゲット編集を無視、手動レビュー）
• 宛先にコピーしたデータの保持ルールを決める

監査も信頼の重要な要素です。誰がアクセスしたか、何が変わったか、いつ着地したかを答えられるべきです。簡単な実践としては、追跡可能な同期実行IDとタイムスタンプを運ぶことで、更新を端から端まで追跡できます。

同期を信頼し続けるために何を監視するか

同期が火曜日のある日にランダムで信頼できるものであるには、監視が必要です。方式に関わらず、どれだけ遅れているか、どれだけ失敗しているか、数字が妥当かを知らせる必要があります。

毎日の健診シグナル3つ：

• ラグ／レイテンシ：宛先がソースにどれだけ遅れているか
• エラー率：失敗、再試行、デッドレターや「失敗行」への投入
• スループット：1分あたりの処理行数やイベント数、急なゼロ近辺への低下

次に、サイレントな問題を捕まえる小さなデータ品質チェックを加えます。重要なテーブル（orders, invoices, tickets 等）をいくつか選び、再現可能に検証します。昨日ソースに1,240件の注文があったなら、宛先が1,180件なら理由が必要です。

よくカバーできるチェック例：

• 日別（重要フィードは時間別）での行数
• 合計が一致するか（金額の合計、有料注文数）
• 必須フィールドのNULL率（email, status, timestamp）
• キーの一意性（order_id の重複がない）
• 削除の真実性：キャンセルや削除されたレコードが下流でも消えているか（あるいはマークされているか）

一貫性の問題はしばしばギャップに隠れます：遅れて到着する更新、削除の欠落、順序が乱れて適用されるイベントなど。最古の未処理タイムスタンプを追跡し、定期的にレコードをサンプリングして最新バージョンが存在するか確認してください。

アラートは単純で実行可能にします。閾値を設定（例：ラグが15分超、エラー率が1%超、スループットが10分間ベースラインを下回る）し、ランブックで：最初に何を確認するか、安全にどうリプレイするか、正しい状態に戻ったと確認する方法を示します。

どの同期アプローチを選ぶかのステップバイステップ

データを誰が使うかをはっきりさせてください。財務レポート、サポートのダッシュボード、自動価格ルールは同じテーブルを異なる目的で使います。意思決定が時間に敏感なら、遅いデータは迷惑どころか誤りになります。

シンプルな意思決定プロセス：

1. Name the consumers and their decisions.
   • 依存する画面やレポート、プロセスを挙げ、それらが何に影響するかを明確にします。
2. Set targets, not vibes.
   • 鮮度（秒／分／時間）、正確性（許容できる誤差）、コスト（インフラ、工数、運用負荷）を合意します。
3. Pick the simplest pattern that meets the targets.
   • ほぼリアルタイムや確実な変更捕捉が必要ならレプリケーションを。数分おきで良ければマイクロバッチを。報告や履歴スナップショットなら夜間バッチを。ハイブリッドはよく使われます。
4. Plan recovery.
   • どこまで遡れるか、バックフィルはどう実行するか、ロードが冪等であるかを決めます。
5. Define trust checks and ownership.
   • 健全性を証明する検証（件数、合計、最終更新時刻、スポットチェック）を選び、誰が通知を受け誰が修正するかを決めます。

具体例：サポートが顧客対応中に注文ステータスを必要とするなら分単位での鮮度が重要なので、レプリケーションかマイクロバッチが適します。財務が日次の収益数字を必要とするなら夜間バッチで十分です。

信頼性を損なうよくある間違い

最大の罠は「新鮮＝正しい」と仮定することです。パイプラインは数秒の遅延でも、結合が変わった、フィルタが追加された、行が重複した、などで間違うことがあります。検証をしなければ、ダッシュボードが変になるか顧客苦情が来るまで気づきません。

削除もまたよく見落とされます。どちらの方式でも「削除」が何を意味するか明確にする必要があります。システムA がハードデリートしているのにシステムB が挿入と更新しかしていないと、レポートは時間とともに乖離します。ソフトデリートでも同期が削除フラグやタイムスタンプを運ばなければ扱いにくくなります。

繰り返し現れるミス：

• 鮮度だけを重視して基本的な件数・合計・スポットチェックを省く
• 挿入と更新は同期するが、削除やマージ、非活性状態を扱わない
• カラム名が変更・分割・型変更されたときに静かに壊れるハードコーディングされたマッピング
• 履歴データの修正が必要なときのバックフィル計画がない
• ジョブ失敗だけをアラートし、ラグや欠落、ゆっくり進むドリフトは監視しない

例：CRMが顧客を「inactive」にマークして削除しないとします。ETLが status = active の顧客のみコピーしていると、1か月後には定着率が過大評価されます。すべては新鮮に見えても、正確性は既に崩れているのです。

同期を「完了」と呼ぶ前の簡単チェックリスト

数値で合意された「完了」、明確な所有権、そして復旧が証明されていること。初日には問題なかった同期も、本番での変更や障害が出てくると徐々にずれていきます。

• 鮮度の約束を文書化する。 目標遅延、測定方法、逸脱時の対応を定義する。
• ソース・オブ・トゥルースを明示する。 主要フィールド（ステータス、価格、メール等）についてどのシステムが優先か、片方向か双方向かを記載する。
• 復旧をエンドツーエンドでテストする。 障害をシミュレートして、重複や欠落なしにリプレイできるか確認する。
• スキーマ変更ルールを用意する。 誰が承認し、どうロールアウトし、名前変更・型変更・削除をどう扱うか決める。
• 監視は実行可能であること。 ラグ、エラー率、コアデータチェックを追い、アラートがオンコールに次の手順を示すこと。

現実チェック：delivery_instructions が orders に追加されたら、それが自動で同期されるのか、大きな失敗を起こすのか、安全に無視されるのかが明確になるプロセスを持つべきです。

現実的な例：2つのシステム間で注文を同期する

PostgreSQL に保存された注文データがあり、サポートは「注文はどこにある？」という問いに即答するライブダッシュボードを、財務は決算や報告のための安定した日次数値を必要としています。

彼らは一方に無理をさせる代わりに混合アプローチを採りました。

サポート向けには論理レプリケーションを使い、新規注文やステータス更新がダッシュボード用の読み取り最適化されたDBに素早く反映されるようにします。財務向けには業務終了後に1回、バッチETLを実行します。日次バッチは確定した注文をレポーティング用データウェアハウスにロードし、税や割引、返金のビジネスルールを適用して日次スナップショットを出します。

その後スキーマ変更があり、プロダクトチームが refund_reason を追加しました。サポートは即時に欲しがります。レプリケーションは新しいカラムを素早く通せます。日次バッチはまずオプション扱い（デフォルトは「unknown」）にして、レポートロジックが準備できるまで待ちます。

ある日サポートの宛先が3時間ダウンしました。復旧後、レプリケーションは保存された位置から追いつきます。重要なのは「再開した」だけでなく「正しい」ことです：アウトage のウィンドウに対して注文数を検証し、いくつかの最近の注文をエンドツーエンドでスポットチェックします。

各朝、彼らは短いシグナルセットを確認して数字を信用します：レプリケーションラグ、過去24時間のソース対宛先の注文数、財務テーブルの重複、バッチの成否とロード行数、そして両方のシステムで高額注文のサンプル検証。

次の一手：同期を可視化し運用しやすくする

アプローチ（あるいはハイブリッド）を選んだら、本当の仕事はその同期を日常的に人が信頼できるものにすることです。1つの測定可能な目標を製品指標のように扱ってください。多くのチームの最初の目標は鮮度（どれだけ新しいか）か正確性（どれだけ誤りが少ないか）のどちらかです。

小さく始めてください：1つのテーブル、1つのイベントストリーム、あるいは1つの重要なワークフロー（注文やチケットなど）。その経路を安定させてからパターンを複製します。問題を素早く検出・修正できないまま拡大すると、より大きな混乱が早く広がります。

非技術チーム向けの実用的な「同期ステータス」ビューには通常、現在のラグ対目標、最後の成功同期時刻、最後の失敗、今日処理したボリュームと期待範囲、ステータスが赤になったときの簡単な対応手順が含まれます。

内部管理画面を素早く作るなら、AppMaster (appmaster.io) のようなノーコードプラットフォームは、スキーマやワークフローが進化してもすべてを書き直さずに監視ビューを出荷・調整する手助けになります。