RedshiftのゼロETLと動的データマスキングを使った本番データ参照運用紹介

背景

• 本番DBのデータを参照する場合、日次で作成される機密情報をマスキングした参照用DB(以下マスクDB)を使ってデータ参照してきた

ツール導入前の課題

• マスクDBは毎朝作成されるが、最新データが当日朝までしか含まれておらず、当日の最新データを参照する場合、社内手続きを経てSREチームが本番DBを確認する必要があり、お客様への回答や障害復旧調査に時間を要することがあった
• 直接本番のDBに対してクエリを実行するため、DB負荷リスクを考慮した調査用クエリを作成する必要があった

どのような状態を目指していたか

• 本番DBの最新データがすぐ参照できる
• 本番DBへのクエリ負荷上昇を発生させないようにして、最新のデータが含まれるマスクDBを用意する

• Bytebaseが提供するデータマスキング機能
• データベース基本機能としてのVIEW

• 本番DBへの変更が最小限になっていること
• 本番DBへの負荷が最小限になっていること

• 本番DBへの変更が最小限
  • 拡張バイナリログ(binlog)を有効化する設定をAuroraのパラメータグループから設定変更するだけだったので本番DBへの変更が最小限に抑えられる
• 本番DBへの負荷が最小限になる
  • Redshiftへのデータ同期はbinlogレプリケーションなので本番DBへの負荷は最小限に抑えられる

改善したかった課題はどれくらい解決されたか

• 動的データマスキングにより機密情報がマスキングされた状態で本番DBの最新データを取得できるようになり、お客様からの問い合わせや障害調査のスピードが改善された
• 本番DBからリアルタイムで同期されたマスクDBに対してクエリを実行するため、本番DBへの負荷が最小限に抑えられた

どのような成果が得られたか

• リアルタイムの本番データを安全に参照できるようになった

AuroraからRedshiftへ同期するテーブルの選出はテーブルのフィルタリングパターンが仕様で100個までしか作れず、正規表現を利用して効率的なパターンを組んでRedshiftにテーブルを追加する必要があった。