こんにちは。広告システムを担当している飛田です。

私が所属するチームでは広告システムの開発だけではなく、開発の効率化や品質向上に繋がる改善業務をコツコツ取り組んでいます。
その中でも今回は"本番データをテスト環境で使えるようにする取り組み"についてご紹介します。

きっかけ

以前からチーム内で本番データを使ってテスト環境でテストしたいという要望がありました。

主に

デザインのバランスやスタイルが崩れていないか確認したい
ステークホルダーにリリース前に出来上がりをレビューしてもらいたい
テストデータを作るのが面倒

などが理由です。

現在もロードバランサに繋いでいないプロダクション検証用のサーバが手元にあるので、手動で反映させ動作確認をしています。

本番データでテストして良かったこと

実は検証用サーバで検証した時

データ量が多く表示までに時間がかかる
顧客が誤認してしまう表現になっている
コレじゃない感(WFの限界)

など、リリース前に気付くことができて良かった経験が多々あります。

課題

本番データをテスト環境で扱うには2点課題があります。

環境的な問題としてオンプレのテスト環境とプロダクション環境はネットワークのセグメントが異なっており、魔法をかけないと相互に疎通ができない
本番データを扱うことそのものがセンシティブな問題

やったこと

テスト環境とプロダクション環境両方からアクセスできるDBをオンプレに用意することが難しいため、クラウドサービスを利用することにしました。
広告系のシステムはサービス開始当初からずっとオンプレでの運用でしたが、最近Google Cloud Platformなどのクラウドサービスを利用し始めたこともあり、波に乗った感じです。

これでテスト環境からもプロダクション環境からもアクセス可能なDBを用意することができました。

次に本番データの問題です。流石にそのまま本番データを入れ込むのはリスクが高いので、何かしらの方法でマスキングをおこなう必要があります。
そこでデータの流し込みとFilterを使ったマスキングなどの制御が簡単にできるEmbulkを採用しました。

そして肝心のどのようなデータに対してマスキングするのかですが

弊社が定めている個人情報に当たるもの
メールのテスト誤送信を防ぐため、すべてのメールアドレス
リクエストのテスト誤送信を防ぐため、すべてのURL
ログインに必要なIDとパスワード
ユーザ権限で表示が制限されているもの

などの観点で精査しました。相談にのっていただいた関係者の方々ありがとうございます！！

ちなみに先日DBにデータの入れ込みが完了しました。テスト環境の参照先を変更して動作確認を行い、ほぼ想定通りに動いたのでとても満足しています。

まとめ

チームのためと思って始めた取り組みでしたが、Embulkでデータの流し込みが完了したときはめっちゃ達成感があってテンションageageでした。みんな喜んでくれるかな？すべてのデータを同期対象にできたわけではなく、日毎にシャーディングするテーブルの扱いをどうするかなど考えることはまだありますが、今後もコツコツ改善していきます。

余談ですが、広告サービス開発者全体の会議で今回の活動を取り上げてもらったのですが、たくさんの質問や他のサービスでもやりたいなど、フィードバックをたくさん頂けました。フィードバックを通してイケてない部分を見つけることもできたのでとても有難いです！

それではまた。