マーケティングプラットフォーム開発のエンジニアを務める

2014年の8月にフロムスクラッチに中途入社しました。もともとは大学院時代に宇宙工学科で人工衛星の開発をしていて、電子回路とか機械とか含めてプログラムを書いていました。

そのあと、新卒で入った会社にエンジニアとして3年と少し働きまして、転職し、今に至ります。

現在はB→Dashというプライベートマーケティングプラットフォームの開発チームのリーダーを務めています。開発メンバーは社員では5名、あとは業務委託の方が20名くらいですね。

本当の成果を残すためのマーケティングプラットフォームを作る！

このプライベートマーケティングプラットフォームの構想の背景にはたくさんの問題意識があったんです。

ひとつは我々がSEOやWeb広告の領域でお客様とお付き合いする中で、そもそもWebマーケティングを本当の意味で戦略的にできている会社さんってすごく少ないなと。

目的から落とし込んで戦略を立案し、効果をしっかりと分析してマーケティングを展開できている、そんなケースは今までほとんど見てきていません。

例えばWebの広告効果の分析の際にも、アクセス数の増加を見るだけではなく、そこから獲得したユーザーの受注率までを見て判断する必要があります。

他にも「繰り返し購入」がある商材であれば、1度の購入で判断するのではなく「リピーター率」までを追いかけなければどの施策が1番良かったのかわかりません。

こういった部分まで網羅的にカバーして、更に顧客の管理までができるようなプラットフォームを実現したい、というのがB→Dashの構想です。

売上・顧客管理までを「一気通貫」で行うための大量のデータ集計が課題

この仕組みの中では、購買や顧客にまつわる全てのデータを取り込んで、ひとつのデータベースにまとめて分析する必要があります。するとデータ量が膨大になり、分析処理もかなり大掛かりなものになります。

この分析を実現するためのデータ管理方法を模索していた時に、今までのリレーショナルデータベースでは処理しきれないという課題がありました。

一般的な企業さんが大量のデータを処理するときは、1日ごとにバッチ処理をして次の日にデータを見る形になるかと思います。でもB→Dashで実現したい集計のパフォーマンスを出すためには、その方法だとダメなんですね。

バッチ処理の場合は、集計の方法があらかじめ決まっているから効果的なんですよね。でも今回はそうではなくて、毎回自由にカスタマイズした集計をかけたいので、事前のバッチ処理では不可能です。

ユーザーが何を集計するか、事前にはわからないので、我々はほとんど「生」の、大量のデータに集計をかける必要があります。

この場合、リレーショナルデータベースでは全くパフォーマンスが出ないと想定できました。ちょっと遅い、というレベルではなくて、全く結果が返ってこないことになる可能性がありました。

求めていたスピード感とパフォーマンスを実現するRedshiftとの出会い

その課題解決のために、いろいろ方法を模索していきました。

サーバーの観点だと、そもそもオンプレミスでやるのか、レンタルサーバーなのか、データセンターなのか。最終的には我々の求めているスピード感を出すために、クラウドでいこうと決めました。そしてAWSの、Redshiftを選択したんです。

どうしてもオンプレミスだと、まずサーバーの設計を固めてからサービスの実装を始めないとダメですよね。後で「変えたいな」と思ってもできないので、非常に神経と時間を使う部分です。

クラウドの場合はとりあえずサーバーを立ててみて、後で修正することも可能です。スモールスタートで初めて、必要に応じて増やしていける。そういったスピード感が魅力でした。

もうひとつ重視したのは、パフォーマンスです。

Hadoop集計も分散処理をしてくれるので、バッチ処理は早くなるんですが、立ち上がりが遅いんですよね。集計の度に立ち上げて処理をする、そのプロセス全体で考えると期待するパフォーマンスが出なかったんです。

結局リアルタイムで大量のデータを集計できるようにするにはRedshiftが一番良いという結論に至りました。ユーザーにとって使いやすい製品を実現するために、パフォーマンスを高くするということが、やはり最大のコミットポイントでした。

最優先すべきは、すべてのクライアントに最良のパフォーマンスを提供すること

B→Dashでは、Redshiftの中に全てのデータが蓄積されるような構造を作っています。Redshiftはインターフェースこそリレーショナルデータベースと似ているんですが、中身の仕組みは全然違うので、そこはテクニカルに対応する必要があります。

列指向型データベースになっているので、それに合わせて更新処理や、データの追加を行う必要がありますね。

今はクライアント様別にテーブルを分けていて、そのテーブルごとに集計をかけています。それが現状、一番パフォーマンスが出る方法です。今後、クライアント様がさらに増えていった時には、Redshiftのデータベース自体を分けることも考えています。

例えば現状だと、データ量が特に多いクライアント様がいると、そこに処理が集中してしまい、他のクライアント様へのパフォーマンスに影響が出ることも考えられます。

プライベートマーケティングプラットフォームをしっかりと機能させて、全て満足いただけるためには、パフォーマンスの高さにはとことんこだわっていきたいですね。その面で、Redshiftを選んだことは間違っていなかったと思います。（了）