負の連鎖を断ち切るべく「やらないこと」を明確化
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年先から逆算した全体計画や社内調整が可能となり、事業成長とデータの不確実性を切り分けることに成功したと述べた。
