こんにちは、技術部SRグループの菅原です。
最近、Ninja650からNinja1000に乗り換えました。パワーがあるせいで３速発進・４速発進が平気でできてしまい、シフトワークがどんどん下手になっています。精進したいものです。
この記事では、Amazon RDS/Auroraをクローンするシステムを作った話を書きます。
Amazon RDS/Auroraをクローンするシステム
サービス開発を行っていると、調査や検証でプロダクション環境で使われているデータベースが必要になることがあります。開発環境やステージング環境にもデータベースは存在するのですが、プロダクション環境のデータでしか再現しないバグの調査や、プロダクション環境のデータ量でのスキーマ変更の負荷の検証など、開発環境やステージング環境のデータベースではできない作業も多いです。しかし、オペレーションミスや個人情報へのアクセスを考えると、プロダクション環境のデータベースで直接作業をすることは大きなリスクを伴います。
Amazon Auroraのクローン作成機能を使うと、プロダクション環境に影響を及ぼさないクローンを作成できるのですが、個人情報にアクセスできてしまう点は解決できません。また、クローンの作成や削除には強力なIAMの権限が必要なため、管理者がクローンを作成して利用者に渡すような手間が発生していました。
そこで、それらの問題を解決し、開発者が手軽にプロダクション環境のデータベースを触れるように、Amazon RDS/Auroraをクローンするシステムを作成しました。
クローン作成の手順は以下の通りです。
- SlackでRubotyに対して
@ruboty rds clone db-cluster:my-cluster db.t3.small 4hというコマンドを送る- 普段からChatOpsでデプロイが行われていること、作成したクローンDBの情報を共有しやすいことなどからインターフェースとしてSlackを利用しました
- RubotyがBarbequeのジョブを起動する
- Barbequeのジョブがクローンを作成する
- Auroraの場合はクローン作成機能、RDSの場合はスナップショットから復元
- クローンDBのマスターユーザーのパスワードを変更する
- クローンDBのデータをマスキングする
- セキュリティグループを変更して、社内ネットワークからクローンDBにアクセスできるようにする
データのマスキングには同僚の@mozamimyが作ったDumptruckという社内ツールを利用しており、以下のようなJsonnetの設定ファイルに従ってデータをマスキングします。
{
database: 'db_name',
except: ['secure_%'], // `secure_`プリフィックスのテーブルはクローンDBにコピーしない
rules: [
{
table: 'users',
transforms: [
{
column: 'tel',
value: "lpad(id, 12, '0')", // SQLでデータをマスキング
inline_sql: true,
},
{
column: 'email',
value: "concat(id, '@example.com')",
inline_sql: true,
},
],
},
],
}
作成したクローンDBは、利用後に開発者が自分で削除するか、利用期限が切れるとバッチ処理が自動的にクローンDBを削除します。
開発者が自分でDBの削除やパラメータの変更を行えるようにするため、クラスタIDやインスタンスIDには rcc- というプレフィックスを付け、IAMの対象リソースをrcc-*とした権限を開発者に付与しています。
まとめ
Amazon RDS/Auroraのクローンが手軽にできるようになったことにより、プロダクション環境のデータの調査や、データベースのパフォーマンスの検証がはかどるようになりました。また、データのマスキングを設定ファイルで管理することにより、どのカラムに秘匿情報が入っているかもわかりやすくなったと思います。プロダクション環境のデータベースを使った作業は管理者やSREに作業が集中しがちなので、このような形でなるべく開発者に権限を委譲していきたいです。
