かとうです。よく行くサウナは鶯谷のサウナセンターです。*1
こちらの記事はGunosy Advent Calendar 2020の1日目の記事です。 昨年最後の記事はkoid CTOの Lead Engineer はじめました でした。 今年もよろしくお願いいたします。
さて、今回は「長年稼働しているサービスの全体感をすばやく把握するには」ということを書いていきたいと思います。 気づけばGunosyに入社して丸5年がたちまして本日で6年目になるのですが、これまで開発だけでなく採用担当やVPoEなど様々なポジションを担当させていただきました。 現在VPoEも続けておるのですが、合わせてGunosyの収益を支える重要なプロダクト、Gunosy Adsの開発責任者を2月くらいから担当しております。
Gunosy Adsはリリースしてからすでに7年ほど稼働している、社内的にも非常に歴史の長いプロダクトです。 社歴は4-5年ほどありつつ、間接的にかかわることはありましたが、直接担当するのは今回が初めて、*2しかも責任者、ということで果たして務まるのか不安だったのですが現在何とかやっております（あくまで自分では、という感じですが）
引き継ぎやドキュメントなどはありつつも、前置きにもあるように兼務もありつつの担当なので、100％時間が使えない中で自分がボトルネックになることなくプロダクトの全体像をつかむ必要があります。
そしてGunosy Adsというプロダクトはグノシーやニュースパスなどのメディアから広告をリクエストされ、社内外の広告運用の担当やセールスメンバーなどが利用します。すなわち日頃の運用改善にかかわるステークホルダーが非常に多いプロダクトとなります。また、いちユーザーとしてとりあえず触ってみる、ということが難しい性質もあります。
そんな状況下なので、まずはメディア・運用・セールスと円滑にコミュニケーションをプロダクトの全体像をつかむ必要があると考え下記4ポイントに絞り、上から優先的に理解に努めました。
- ログのスキーマ
- RDBのスキーマ
- 問い合わせ対応/開発相談
- ローカル開発環境
ログのスキーマ
どんなサービスでもログは重要ですが、広告配信システムにおいてのログは収益にもかかわるためとりわけ重要な存在です。 そのため、まずは広告リクエスト、インプレッション、クリック、コンバージョンなどの基本的なログやその他のログ*3のスキーマの把握に努めました。
GunosyではS3に保管されているログをredashからAmazon Athenaを通じて様々なダッシュボードを構築しています。 ログに残された各種数値を理解するうえで普段見ているダッシュボードを構成するクエリのなかでも、
- GROUP BYしているカラム
- JOIN しているカラム
に注目すると重要なカラムが何なのかがわかってきます（例えばキャンペーンIDなど）。
RDBのスキーマ
ログの理解と似ているといえば似ていますが、管理画面などから設定されたキャンペーンの情報など重要な情報が詰まっています。
Gunosy AdsではAmazon Aurora（MySQL）を利用しており、これもログと同様にredashから参照することができます。 ログと比較して、種類（テーブル）が膨大なため、よく参照されるであろうテーブルにあたりをつけるうえで先にログの把握をしておいたのは正解でした。
問い合わせ対応/開発相談
ログ、RDBの理解が進むと、周辺のチームからの問い合わせや、開発の相談にスムーズに対応できます。
問い合わせは配信結果に対する質問が多いため、すぐにわからなければredashでログを見てみることで回答を得ることができ、開発の相談ではRDB、ログそれぞれにどのようなスキーマの変更が生じるかのあたりがつくため、おおよその開発工数を見積もるうえで参考になります。
そうはいっても最初は自信をもって回答することのできないことも多かったですが、頼れる開発メンバーが親切に教えてくれたので、以前より回答できる幅がグッと増えてました。
ローカル開発環境
最後かよ、というツッコミはありそうですがログ・RDBの理解だけでは見えない部分はドキュメントや各種ソースを読んでいく必要があります。
最近はブラウザのGitHub上でコードジャンプができちゃったりするのでcloneせずともなんとかなってしまう時もありますが、やはり手元で動作の確認などができる方が速いですね。 また、問い合わせの対応なので気づいたところやちょっとした修正であれば自らcommitしてPRをレビューしてもらいリリースできますし。
5年前と比較して、docker composeで簡単にローカル開発環境を用意できるようになっていたため、最初にやっておいてもよかったかもしれません。整えてくれたエンジニアに感謝です。
おわりに
前職がアドテク業界、担当するまでに間接的には関りがあったというアドバンテージがあったり、急に責任者として歴史もあり規模も大きいサービスの理解に努めなければならない、といったケースはそんなに多くないかもしれませんが、人材の流動性の高い業界ですのですでに稼働中のプロダクト開発に途中から参加するというケースは多いかと思います。
手っ取り早くサービスの全体感をつかむうえでこのようなアプローチもあるよ、ということでいつか誰かのお役に立てば幸いです。
明日はazihsoynがflutter webの管理画面の話を書いてくれるようです。楽しみですね！
