データウェアハウス構築プロジェクト、始動
デジタルメディア事業を主軸に、SNSアニメなど新規事業を展開するキュービック。そんな同社の事業を支える基盤のひとつに、CUEBiC Analyticsがある。CUEBiC Analyticsは、広告やASP（Affiliate Service Provider）で取得した行動データやコンバージョン成果情報などを集約するデータ基盤だ。格納されたデータはERPのマスタデータ含む関連データと統合、加工および集計したのち、BIツールのTableau上に出力して、広告やメディア成果、売上など各種分析で活用される。そのCUEBiC Analyticsについて、2021年に策定された中長期IT戦略の一環で、各種SaaSデータを集中管理するためのデータウェアハウスに刷新することが決定。同社CTOの加藤彰宏氏と、テクノロジーエキスパートセンターでテックリードを務める尾﨑勇太氏がプロジェクトをリードすることになった。
刷新で一番の課題は、CUEBiC Analyticsの老朽化だ。同データ基盤は、新たなビジネス要求に耐えられないほど技術負債が蓄積され、品質も低下。開発初期メンバーもすでに在籍していない中で、複雑になりすぎた基盤を改善するのは難題に他ならなかった。
そこで同プロジェクトは2022年2月、身動きがとれない状態を解消して運用やアップデートの負担を軽減するようなアーキテクチャを目指して、製品や構成の検討を始めた。そして、広告関係のSaaSツールからデータを取り込む部分はトライアルの結果、広告媒体との親和性が高かったETLツール「trocco」を採用。データウェアハウス部分は、AWSを利用していたことからAmazon Redshiftに落ち着いた。
「troccoについては、最軽量のLightプランを契約して、データ取得に問題ないことを検証。細かい点はtroccoのカスタマーサクセスエンジニアと一緒に課題を摺り合わせながら調整を進めた。Redshiftについては、AWSのソリューションアーキテクトとともに設計を進めて、PoCを実施した。集計のエンジニアリング工数も、AWS Glueでスクリプティング要素をある程度削減できることが分かり、最終的にtroccoとRedshiftの組み合わせで構築することが決まった」
加藤氏は、「これが最善の選択」と当時は考えていたと振り返る。だが、しばらくして加藤氏は新アーキテクチャの問題に気付く。1つは、想定していた以上にクラウド関連の知見が必要となり、エンジニアリング工数も結果的に増えてしまったこと。もう1つは、ローコード化された情報をクラウド管理することでブラックボックス化が進んだことだ。特に2つめについては、AWS Glueを使っていた社内の別プロダクトでも担当エンジニア交代後、エラーの解消や更新がうまくいかなくなり、スクラッチで作り直すはめになったという事例が起きており、同様の問題が起こる可能性は高いと加藤氏は懸念。「そもそも、AWS Glueで整形しているデータはエンジニアリングで担保できるが、それ以外のデータでAWS Glueを介さずRedshiftと連携しているものは、何か問題が起きた際の調査や改善で手間が増えることが予想できた」（加藤氏）
なぜこのような問題が生じたのか。加藤氏は原因に、前提知識の不足から、実現したい要求をAWSやtroccoの担当者にうまく伝え切れなかったことを挙げる。そして、アイディアのブラッシュアップもしないまま、実現できそうなものを安易に進めてしまったと猛省する。
軌道修正に向けて、加藤氏たちは新アーキテクチャの改善点や要望について社内でヒアリングし、設計への反映を進めた。そして、AWSとtroccoの担当者と膝をつき合わせて議論し、要件を最大限に叶える合理的なアーキテクチャを模索した。
