AWS Cloud Storage Day 取材レポート(7).[B-05] 日本から世界へ : オールクラウドでスモールスタート・スケーラブルなDMPを構築 ALBERTのプライベートDMP

AWS Cloud Storage Day取材レポート

#イベントレポート

#勉強会

#Amazon Redshift

#レポート

#Amazon S3

しんや

2013.09.27

この記事は公開されてから1年以上経過しています。情報が古い可能性がありますので、ご注意ください。

講師・概要紹介

講師

池内孝啓氏 (株式会社ALBERT システム開発部部長)

概要

株式会社ALBERT（アルベルト）は、DWHを自社で構築してサービス提供していましたが、クラウド上のDWHソリューションであるAmazon Redshiftのリリースを機に、AWS上で、データを解析、活用するプラットフォーム（プライベートDMP）構築サービスを開始しました。 Amazon S3とAmazon Redshiftを組み合わせることで、初期投資を行わずに数百GB~数百TBのデータを活用するDMPの構築が可能となり、更にDB、ストレージの運用コストの削減に成功しています。
本セッションでは、AWS 採用の背景、導入効果、および実際のアーキテクチャについてご紹介します。

セッション内容レポート

プライベート・DMPとは

本題に入る前に、ひとつお聞きしたいと思います。素朴な疑問ですが『ビッグデータビッグデータと言いますが、本当に、そんなにビッグデータ、持っていますか？』

ビッグデータは一体どこにあるのでしょうか。"ないところにはないし、あるところにはある"と言った感じなのでしょうか。また、溜まるところには溜まる、サービスや企業によって月間10万〜10億PV等と言った感じで規模もまちまち、様々だったりすると思います。また、少ないボリュームのデータに分析価値が無いという事でも無いと思います。分析価値自体がデータ量で変わるという事はありません。

また、ビッグデータにはどう立ち向かっていけば良いでしょうか。使う側からすれば、10万PV用のアーキテクチャと10億PV用のアーキテクチャが統一出来れば、これは嬉しい点でしょう。柔軟なサイジングが出来る事、また稼働後にスケール出来る事が重要なポイントになってきます。そういう意味では、データの置き場所、ストレージやデータベースが重要になってくると思います。

(写真：池内孝啓氏)

プライベートDMPは、2013年3月〜4月くらいから盛り上がりを見せています。ビッグデータ分析、データサイエンティスト、アドテク、DWH等など、色々なキーワードが最近賑わいを見せています。ブームになる前にバズってるのでは、というような感じですね。それがDMPです。

※(プライベート)DMPについては以下のページも参考になりそうなので列挙しておきます。

プライベートDMPの要素には以下のものがあります。5つが揃って『プライベートDMPを出来ている』と言えるのではないでしょうか。

データウェアハウス(DWH)
データマイニングエンジン
キャンペーンマネジメント
DSP
ビジネスインテリジェンス(BI)

(要素に関する詳細は、Albert様の解説ページがありますのでそちらをご参照頂く方が良いと思います。)

株式会社ALBERT ニュースリリース - ALBERT、データマネジメントプラットフォーム構築サービスを提供～ペタバイト規模対応、超並列、カラムナ型(*1)のクラウドデータベース、Amazon RedshiftをDWHに活用～

(そして、このタイミングで会社紹介及び自己紹介へ。)

メールマーケティングにおける、DMPの構成例を見てみましょう。こういった構成から導き出されるものとしては、登録名は男性だけど実は利用しているのは女性、という形も見えて来る事があります。行動ログを分析していると、メールのみでは見えない部分も見えて来ます。キャンペーンの施策としてはそういった部分も反映して行きます。

次いで、ビジネスに於けるプライベートDMP構築の問題を見て行きましょう。

ビジネス課題1: ステークホルダーが多い

データが出てこない、統合した各種データの出所が別々の企業である、データを活用したい部門もまた別々…というように、障壁が多過ぎて構想が頓挫するケースが見受けられます。

ビジネス課題2: 初期投資とリスクヘッジ

DMP構築にあたっては初期投資のインパクトはやはり大きいものです。また、計画が縮小、中止になった場合のリスクを考えると対応へ踏み止まってしまうのもわからないではありません。導入したとしても、活用出来るのか？という不安もある事でしょう。

これらの克服には、現実的なロードマップを敷く事が重要となります。徹底や縮小もビジネスサイズに合わせて行う事が出来れば、懸念しているようなリスクも軽減出来るでしょう。スモールスタートする事でリスクヘッジを抑え、"サンクコスト"(事業に投下した資金のうち、事業の撤退・縮小を行ったとしても回収できない費用)を作らないと言ったポイントも重要です。

そしてシステム編における問題も引き続き見て行きましょう。

システム課題1: ログデータの保持

取り決めの内容に関するものです。システムとして拡張出来るものなのか？また拡張時のコストはどれだけ掛かるのか？また、容量に限界はあるのか？そもそもバックアップはどうするのか？と言った点等です。

これらの点については、S3を活用する事で対応出来ます。S3は事実上の容量無制限、堅牢性も確保しています。運用も、ライフサイクルの設定で自動化が可能です。

システム課題2: データベース(DWH)の活用

運用しているデータが増えた時の問題です。そのような状況に直面した時の対応を考えているのか。パーティショニングやバックアップ、アーカイブ化に関する部分は？

こちらの点については、Amazon Redshiftで対応する事が出来ます。利用料としてミニマムで月900ドル(東京リージョンの場合)、初期投資不要でオンデマンド利用が可能です。運用開始後に容量や性能の拡張も行う事が出来ます。またRedshiftの補足事項としては、PostgreSQLインタフェースである事、カラムナ型の特性を活かしたパフォーマンス、S3と連携している点等が挙げられます。

これらの点から、システム構成に関しては拡張性が高く、運用コストの少ないアーキテクチャである事が重要であると考えます。

Amazon Redshift, S3がなぜ有効か

引き続き、RedshiftやS3の有効性について話を展開していきます。それぞれの利用想定ケースについて見て行きましょう。

S3のケースバイケース

これから利用するデータ: 購買ログ、会員マスタ、商品マスタ等。
→S3に格納して堅牢性を確保。
アーカイブしたいデータ: 古い商品マスタ、2年前の購買ログ、集計結果が存在する元のローデータ、特段用途はないが、捨てるには惜しいデータ等。
→Glacierに輸送して低コスト保存。
一部消失が許容されるデータ: 広告Impressionログ、Web閲覧ログ等。(※許容されるかどうかは分析方針や施策内容によります)
→S3 Reduced Redudancyを利用。
保持期間の定められたデータ: ユーザーID付き購買ログ、会員属性情報等。(※セキュリティポリシ、契約内容により決定)
→LifeCycleで保持期間経過後に自動削除。

これらの情報を整理していくと、用途別のストレージ選択の指針としては以下のような形に落ち着くのではと考えています。

S3に続いて、Redshiftについても利用想定ケースを見て行きましょう。

中規模案件や継続的な自社利用: 共用利用でコストを節約したい／CREATE DB, USERでロールを設定、セクション毎のRedshift導入を検討／リザーブドインスタンスを積極的に利用
大規模案件: 専有利用でパフォーマンス確保したい／案件の継続期間、契約期間に応じてリザーブドインスタンスの利用を検討したい
短期的なアドホック分析: Redshiftの一時的な利用をしたい／テーブル構成や容量に余裕があるのであれば、クラスタ数をミニマムにして維持したい

このように、色々な局面・種類のデータが存在しますが、これらを一手に管理・分析する事がAmazon Redshiftでは行えます。

Redshift、S3、そしてGlacierそれぞれを組み合わせた構成としては以下のような形となります。(写真参照)

AWSのもたらすビジネスインパクト

プライベートDMP事業に対し、AWSが与えるインパクトにはどのようなものがあるでしょうか。ビジネス編、システム編それぞれについて見ていきます。

ビジネス面では、初期投資が不要になる／原価算出の精緻化が図れる、と言うような点が挙げられます。見積が実績値を元に算出出来るようになり、スケールの段階も細かく刻める事が出来、余剰分を確保する必要が無くなったのが大きいです。どのくらいの盛り上がりを見せるかが読めない部分で、サイジングの対応をして行くのは大変だと思います。

システム面では、アーキテクチャの統一や運用・メンテナンスコストの低下等が上げられるでしょう。そしてこれも重要な点ですが、精神的な安定作用も見込めるようになったのは大きいと思います。