Developers Summit 2023 セッションレポート（AD）

老朽化した情報基盤の刷新は課題がいっぱい！キュービックのデータウェアハウス構築秘話

【10-B-3】データウェアハウス構築時のアンチパターンを克服したサクセスストーリー

2023/04/14 12:00

　デジタルメディア事業を手がけるキュービックでは、広告成果の情報などを管理する基幹システムの老朽化に伴い、新しいデータウェアハウス構築を計画した。長年使う中で技術負債が蓄積し、現在のビジネス要求にも耐えられず、初期開発メンバーがすでにいない中で今後このまま維持するのは難しいという判断からだ。だが、その道のりは平坦とならず、プロジェクトチームは多くの壁にぶち当たることになった。キュービックCTOの加藤彰宏氏と同テックリードの尾﨑勇太氏が、今はタイムリーな意思決定を支える情報基盤に生まれ変わった同基盤の示唆に富む構築・運用話を披露した。

データウェアハウス構築プロジェクト、始動

　デジタルメディア事業を主軸に、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の担当者と膝をつき合わせて議論し、要件を最大限に叶える合理的なアーキテクチャを模索した。

負の連鎖を断ち切るべく「やらないこと」を明確化

　2022年5月、導入フェーズに移行した同社は、検討フェーズで明らかになった運用やエンジニアリングの課題を解消するべく、アーキテクチャの改善に乗り出した。

　「最初に考えたのは、S3やAWS Glueの代わりにtroccoのデータマート機能でRedshiftの生データにクエリを投げて、データの整形と集計を行うシンプルな構成。さらに、整形と集計のロジックをtrocco内にSQLを直書きするのではなくRedshiftのストアドプロシージャーとして切り出すことにした。これにより、プロシージャー関数を呼び出すだけというロジックの分離が実現し、運用者は広告やASPの設定や更新、エンジニアはSQL更新やRedshiftのスキーマ設計と役割分担が明確にできると考えた」（尾﨑氏）

　うまくいくように思えたが、ここでもまた新たな壁にぶつかった。1つは、データ転送問題だ。加藤氏たちは、Amazon RDS（CUEBiC Analyticsで使用）のデータからtroccoに転送するワークフロージョブと、Redshiftのデータを転送するワークフロージョブを実行して集計につなげようとしたが、troccoにはそれができなかった。そしてもう1つは、データマート問題だ。troccoのデータマート機能を使ってRedshiftのデータ更新を行うことにしたものの、troccoのUI上では単一のデータベースしか設定できないことが判明した。

　最終的に、データ転送についてはRDSのデータを事前にRedshiftと同期させてから、Redshiftにデータ集約することで問題を回避。また、データマートについてはRedshiftのデータベースはドメインごとに統合することで解決した。

　検討フェーズでの課題はある程度解消できた。しかし、新たに発生した問題から、現状のアーキテクチャでは以前と同様、場当たり的な更新を繰り返し、過去のアーキテクチャと同じ道を辿ることは容易に想像できた。

　危機感を覚えた加藤氏と尾﨑氏は負の連鎖を断ち切るべく、運用の本格化や事業／データ利活用の促進を目的とした2年先を見越してのアーキテクチャを設計。「やらないこと」を明確にして、課題が生じたときは安易に変更するのではなく、やらないこと以外で実現可能な項目を整理、実践することとした。

　「やらないことは、エンジニア部門との連携方法を整理し、経営層と合意形成を実施。たとえば、今回はスピード優先なのでTableauとGoogleスプレッドシートだけの簡易的な分析にする、troccoは技術負債を避けるためにデータ整形・集計に関するスクリプティングはせず、データ取得・連携に留めるといった具合だ」

　そう説明した尾﨑氏は、これら方針のおかげで、2年先から逆算した全体計画や社内調整が可能となり、事業成長とデータの不確実性を切り分けることに成功したと述べた。

業務フローの見直しが正解への近道

　体制を立て直すこと2回。改善フェーズに入り、あとはリリースを待つのみとなった2022年11月。加藤氏たちの前に再び課題が立ちはだかった。CUEBiC Analyticsの停止とtrocco✕Redshiftへの切り替えについて、関係者向けに説明会を行った際に、CUEBiC Analytics停止反対の声が多数上がったのだ。ヒアリングしたところ、業務フローの中で使いたい機能があるというのが大半だった。

　そこで加藤氏たちは、CUEBiC Analyticsを並行稼働しながら、出そろった要望を対応可能なものと対応できないものとに分類。全体最適のための優先度を説明しつつ、調整を重ねた。

　併せて、過去に挙がっていた要望のうち、業務フローを改善することで解決でき、しかも改善することでメリットが得られるものを整理。たとえば、BIツールに出力したあとはチームごとに独自集計するといった非効率な業務フローを改善できないか検討した。

　こうしてようやくアーキテクチャの方向性が固まり、アップデートが実施された。運用者からの要望を受けて、CUEBiC Analyticsで慣れ親しんだユーザーインターフェイスでデータ設定部分を新基盤に追加。また、Tableau Server REST APIからGoogleスプレッドシートに必要なデータをインポートするツールを作成し、運用者の学習コストを低く抑えながら新しい環境への移行を進めた。

　業務フローを意識した改善は、業務効率の改善にもつながった。エンジニアは運用保守および開発に、DX推進チームは業務設計運用サポートに、事業部はデータの設定・更新・分析により注力できるようになったと尾﨑氏は述べる。

　「要望は尽きることなく、すべてを新アーキテクチャで網羅することは不可能だ」。そう話す尾﨑氏は、アーキテクチャ改善で気付いたポイントを2つ挙げた。

　1つは、業務フローの見直しが正解への近道という点だ。「実は当初、ASPもtroccoとのAPI連携でデータ取得を自動化するなど、アーキテクチャ側の改善にばかり目を向けていた。しかし実際は、ASPのAPI数が想定よりも少なく、そもそもASP周りのデータがデータベースに保持されておらず、むしろ変更によって業務側のスピードが低下する恐れが出てきた」。尾﨑氏はそう説明しながら、ASPに関してはAPI連携をやめてGoogleドライブに成果データなどを格納したあとのフローを自動化する方向に切り替えたという。

　2つめは、運用ミスを救済する仕組みを実装することだ。「既存のRDSでは運用ミスでデータが再取り込みされる不具合があった。こうした不具合を解消することも重要だが、暫定的な対策をすぐに実行できる体制を設けておくことも大切だ」。この不具合については、任意の期間のデータが再度取り込まれた場合は、Redshiftの本番テーブルのデータを削除し、その後に中間テーブルのデータを挿入するという処理で対応できるようにしたという。