スナップショットから始まる
エージェントのインストールも、レプリケーションも、CDC も不要。AWS がすでに取得しているスナップショットが元データです — 別アカウントのデータベースでも同じです。
自社の AWS アカウントで稼働本番稼働 1 年以上
本番データベースは
分析の存在を知らなくていい。
Data Pump は AWS が毎日取得しているスナップショットから始まります。エクスポートし、整理し、カタログ化する — 出来上がるのは Athena で検索できるデータです。稼働中のデータベースには一切接続しません。
スナップショットは時間を止めた複製です。すべてはそこから取り出されます — クエリが本番に触れることはありません。どのテーブルがあるかを調べるときでさえも。
テーブル 1 つの経路
AWS がスナップショットを取得
RDS が Parquet でエクスポート
exported/{cluster}/{export}/pagila/public.payment/Data Pump が整理して名前を付け替え
catalog/{cluster}/pagila.pagamentos/検索する軸で再パーティション
catalog/{cluster}/pagila.pagamentos/ano=2024/mes=03/Glue がカタログ化
5 つの段階、どれもデータベースの中では起きない
スナップショットが完成すると、パイプラインは自動で動き出します。通知からカタログまで、人の介入はありません。
データのある場所でエクスポート
クロスアカウント構成では、エクスポートは取得元アカウントで実行され、自社のバケットに直接書き込まれます。生データが二度流れることはありません。
取り込む対象は自分で決める
データベースを選び、テーブルを絞り込み、技術的な名前は付け替えられます。`tb_pgto` はレイク上で `payments` になります。
問い合わせる軸で分割する
年と月で再パーティションしたテーブルなら、Athena はクエリに必要な範囲だけを読みます — テーブル全体ではありません。
データベースが捨てるものを残す
長期履歴は実行のたびに消去されません。Postgres から古いデータを削除しても、ここでは検索できたままです。
何が起きたかを示す
各実行は段階、更新されたテーブル、各コンポーネントのバージョンを記録します。失敗したときは、エラーがそのまま見えます。
代わりの手段は、止められないデータベースに手を入れること
稼働中の Postgres からデータを取り出す方法には、どれも代償があります。スナップショットから始める方法が、その代償が最も小さいものです。
直接クエリする、またはレプリケーションする
- 分析クエリがアプリケーションと競合する
- レプリカにはデータベース側の設定と保守する人が必要
- CDC には専用のエージェント、コネクタ、監視が必要
- データベースへのネットワーク経路がセキュリティ上の例外になる
- 削除されたデータは一緒に消える
スナップショットから始める
- データベースへの新しい接続は一切発生しない
- AWS はすでにスナップショットを取得している — その費用は元から存在する
- 取得元には何もインストールしない。別アカウントでも同じ
- ネットワーク経路が不要 — パイプラインが読むのはファイルであってデータベースではない
- 履歴は削除を生き延びる
管理画面は自社のインフラの中に置かれる
Data Pump はすべて顧客の AWS アカウントで動きます — コンソールも含めてです。データが当社を経由することは一切ありません。
取得元とデータベース
どのクラスタをレイクに流すか、どのデータベースを取り込むかを指定します。テーブル一覧はエクスポート自体から取得されます。
パーティション
各テーブルの再パーティション方法と、取り込み済みの行がデータベース側で変更されたときの扱いを設定します。
実行履歴
各実行を段階ごとに追い、更新されたテーブルと失敗した箇所を、その段階のログとともに確認できます。
自社環境で動かしてみませんか
導入はすべて打ち合わせから始まります。アカウント、リージョン、VPC、取得元データベースを確定したうえで、その構成に合わせたパッケージをお渡しします。汎用のインストーラーはありません。環境をお知らせいただければ、適した構成をご提案します。