trocco®を利用する方が相互理解を深め、それぞれの企業が持つ経験やノウハウを共有しあう場として開かれるtrocco®ユーザ会。
毎回、日頃trocco®を利用している方に登壇いただき、trocco®の使い方や具体的な活用事例についてお話いただいています。
第5回ユーザ会には、キュービック株式会社のテックリードである尾﨑勇太氏に登壇いただきました。
キュービック株式会社はデジタルメディア事業と集客支援事業を17年にわたり展開し、データ分析やコンテンツフィッティングの分野でリーダーシップを発揮しています。
今回はそのキュービック様が、trocco®の強みやtrocco®とRedshiftを導入したときのエピソードに触れながら、成果集計処理を改善したコンテンツマーケティングの分析基盤構築についてお話しいただきました。
第4回の内容も知りたいという方はこちらをご覧ください。
登壇者と登壇者所属企業の紹介
尾﨑勇太 氏 /株式会社キュービック テクノロジーエキスパートセンター Tech Lead
日本コンピュータシステム株式会社、株式会社ヒトメディアにてアプリケーションエンジニアとして管理業務を中心に従事。株式会社SHIFTにてQAエンジニアとして従事した後、株式会社キュービックにテックリードとしてジョイン。
新規プロダクト開発や横串での組織課題の解決を推進しつつ、直近ではデータエンジニアとしてデータ分析基盤のリニューアルとDWH化を担当し、本格的なデータ活用を見据えた内部統制を管掌。
株式会社キュービック
17年にわたりデジタルメディア事業と集客支援事業を展開し、データ分析やコンテンツフィッティングの分野でリーダーシップを発揮している業界のトップランナー。成功報酬型のビジネスモデルを採用し、検索エンジンを通じて比較サイトやSEO結果を提供しています。
また、長期インターンプログラムを推進し、全従業員の3分の1以上が長期インターンとして活躍している点も業界で高く評価されています。
https://cuebic.co.jp/
〜成果集計処理を劇的に改善！〜troccoとAmazon Redshiftで挑んだコンテンツマーケティングの分析基盤構築
キュービック社のtrocco®の活用状況と尾﨑氏が考えるtrocco®の強み・弱み
尾﨑勇太 氏：「まず、私の考えるtrocco®の強みについて解説します。
trocco®のコネクタの豊富さは非常に注目すべきポイントです。データウェアハウスと連携できる点、そしてデータウェアハウスを更新できる点、そして、実際にtrocco®をどのようにキュービックで活用しているかを簡単に紹介します。
ビジネスモデルを説明するのは難しいかもしれませんので、転送設定の例を挙げて説明します。」
尾﨑勇太 氏：「たとえば、GoogleやYahoo!といった広告媒体から毎日の広告の運用レポートを取得した際に、独自の分析項目をカスタム変数に設定し、広告媒体別に異なるレポート項目を共通化して、生データをRedshiftに送ります。
その後、データマート機能を使用して整形したデータを再度格納し、BIツールを使用して結果を出力し、広告業者や媒体の担当者が実際のデータを元に運用調整を行います。
trocco®では実現できない機能が一部あったため、Oasisという独自のインターフェースも開発しました。」
ここで差がつく成果集計
尾﨑勇太 氏：「次に、実際の成果集計について話します。
成功報酬型のビジネスモデルにおいては、自社メディアからクライアント先に送客したユーザーが特定の条件を満たさないと、報酬がもらえません。
そのため、日々の売上成果を確認しながら、施策を打ち、PDCAサイクルを回すことが重要です。このプロセスでは、既存のアーキテクチャが役立ちますが、数点の課題も浮かび上がります。」
尾﨑勇太 氏：「社内データ基盤であるCBA（CUEBiC Analytics）の担当範囲は、広告媒体とASP（Affiliate Service Provider）からの成果レポートの収集と整形、BIツールへの分析データの可視化です。CBAの老朽化によりビジネス要求に分析基盤が耐えられなくなってきたため、DX戦略の一環としてデータウェアハウス化を推進することになりました。リソース課題としてもRubyエンジニアのアサインが単価の高騰によりネックになっていたため副次的にローコード化を行いスキルの軟化を図りました。
具体的には、既存の社内データ基盤であるCBAのリニューアルを行い、trocco®とRedshiftを主軸にデータ抽出からデータ整形までを行う形にリアーキテクトを行いました。trocco®では実現できない機能が一部あったため、先ほど紹介したOasisをスクラッチで開発しました。
実際に策定したアーキテクチャはこちらです。」
尾﨑勇太 氏：「先ほど示したキュービックアナリティクスの部分は、trocco®とRedshiftに置き換わった形で、集計の設定の部分だけがAmazon Auroraを経由しています。さらに、BIツールTableauから自動でデータ連携を行なっており、運用者は日々のデータをスプレッドシートに取り込むことができます。集計ロジックに関してはRedshiftのストアドプロシージャを採用することで、転送設定だけでなく、集計処理を簡素化するとともにSQL単独では実現が難しい複雑な集計もカバーできるようになりました。
前衛的な使い方ですが、データマート定義からストアドプロシージャの関数を呼び出すことで、集計処理の分離が可能となります。これはBigQueryのプロシージャと同等の機能であるため、他のデータウェアハウスでも代替が可能であり、多くの分析ユーザーにとって嬉しい機能であり、幅広い可能性を秘めています。」
尾﨑勇太 氏：「実際の導入成果としては、集計ミスの削減と数字の信頼性向上が実現でき、エンジニアリング工数も8人月から4人月に削減されました。さらに、Rubyを使えないエンジニアでも利用できるようになったため、全体的な工数の削減に寄与しています。
ローコード化により64%の工数削減が実現でき、残りの36%はデータ設定のインターフェースであるOasisのみとなり、Railsにかかるコストが大幅に削減されました。
当初はローコードツールにより自動化を検討していましたが、機能的な制約が存在したため、Google Driveへのレポートの格納等の手動での運用やOasisのように部分的なスクラッチ開発が必要となりました。ローコードツールで実現できないからといって挫折するのではなく、全体最適を意識しつつ運用にフィットするものを選定して行くことが重要ではないでしょうか？今回はスクラッチ開発となったスコープに関しても今後のtrocco®の機能充足により更なるローコード化が進む見込みです。」
Redshift始めました
尾﨑勇太 氏：「次に、Redshiftの活用事例について解説します。
キュービックはRedshiftを導入しましたが、Redshiftにはややこしい部分があります。具体的には、Redshift ProvisionedとRedshift Serverlessの2つが存在し、サービス名は同じでも違いがあるという点です。
Redshift Serverlessは自動でスケールしてくれるため、急な負荷にも対応しやすいです。」
尾﨑勇太 氏：「運用時に当初使用していたRedshift Serverlessではコストとパフォーマンスの両方で課題に直面しました。パフォーマンス面ではRubyのアクティブレコードからの書き込み速度の劣化、コスト面では定常的なデータ収集だけで想定コストを消化してしまうことがわかりました。
代替策として24時間のオンデマンド接続を想定した定額のRedshift ProvisionedのRA3へのプラン変更を検討することになりました。しかし、RA3への移行によって更なる速度劣化が発生することも予見されたため速度比較を行った上で適切なプラン選択を行うことにしました。
まず、Rubyのアクティブレコードへの書き込み速度の劣化に対してはRedshift Serverlessに集計に必要なマスタデータを持つことをやめ、Auroraに責務を移行しました。そしてFederated Queryを使用して外部スキーマを定義し、Auroraの情報をRedshift Serverlessから参照する形に変更しました。
検証時に思わぬ落とし穴があり、Redshift Serverlessには公開IPがないためAuroraでIP制限を行なっていた関係で検証用の環境を新たに建てる必要がありました。
次にRedshift ServerlessとRedshift ProvisionedのRA3を比較するためにRedshift Provisionedを生成することにしました。Redshift ServerlessからRedshiftのRA3への移行はスナップショットから容易に作成できる見込みでしたが、選択可能なノードが適正プランを大きく超えるものであったためゼロから手動でデータ移行を行いました。
Redshift Serverlessにはクラスターの復元というボタンがありますが、このボタンでデフォルトで選択できるnodeは16nodeであるため、毎月発生する費用が100万円以上になってしまうと言う課題がありました。これを克服する代替案として、実際にnodeを手動で生成して、データをRedshift Serverlessから移行するという作業を行いました。」
尾﨑勇太 氏：「それでもデータ移行が手間であるため、trocco®の転送設定を使用して、転送元をRedshift Serverless、転送先をRedshiftに設定し、テーブルを選択して移行するというフローを採用しました。」
尾﨑勇太 氏：「データ移行後にtrocco®のワークフロー機能で広告と成果のレポートの収集と集計の速度比較を行い、その結果、今回はRedshift RA3の方が優れたパフォーマンスを発揮しました。差分はデータベース接続のオーバーヘッドによるものなので、常時高負荷がかかるような処理の場合はRedshift Serverlessに軍配が上がる可能性が高いです。」
キュービック社のtrocco®導入についてくわしく知りたい方はこちらもご覧ください。
さいごに
trocco®を提供する株式会社primeNumberは、trocco®を利用している方に向けた交流や勉強のための会を開いております。
第5回のユーザ会はオフラインで開催し、発表内容にコメントをしながら視聴したり参加者の方からいただいた質問にリアルタイムで回答するなど、和気あいあいとtrocco®の活用について知見を共有しました。
trocco®をすでに利用されている方の中で他社の事例にご関心をお持ちの方は、ぜひ担当のカスタマーサクセスまでお問い合わせください。
また、データの連携・整備・運用を効率的に進めていきたいとお考えの方や、プロダクトにご興味のある方はぜひ資料をご覧ください。
