マーケティングテクノロジー勉強会

Copyright © EVERRISE CO.,LTD. All Rights Reserved.
マーケティングテクノロジー勉強会
How to 大量データ処理
~Hadoop/Redshift/Aerospike~
株式会社 EVERRISE
伊藤、中川

はじめに
本日は、お越しいただきありがとうございます。
講座を通じて、以下をご説明します。
① バッチ編
② トランザクション編
約 40 分程度の講座となりますが、よろしくお願い
いたします。

EVERRISE ご紹介
会社名： EVERRISE CO.,LTD.
代表：倉田宏昌
設立日： 2006 年 7 月 3 日
所在地：東京都港区六本木 4-11-13
ランディック六本木ビル 3F
Url ： http://www.ever-rise.co.jp/
事業内容： - 業務系システム構築
- Web システム構築
社員数： 33 人 ( 技術者約 25 名 )
会社名： EVERRISE VIETNAM CO.,LTD.
代表：山崎利崇
設立日： 2012 年 11 月 14 日
所在地：ベトナム　ホーチミン
DA KAO Center
Url ： http://www.everrise.asia
事業内容： - 業務系システム構築
- Web システム構築
社員数： 25 人 ( 技術者約 20 名 )

取引先一覧
・インターネット広告代理店
・配信事業社 (DSP / SSP / ADNW)
・メディアレップ
・総合代理店
・リサーチ企業
・ Web 系サービス提供企業

EVERRISE 社での開発・案件の事例
・ DMP 、アトリビューション分析
・スマートフォン向け独自アドネットワーク
・広告配信サーバカスタマイズ
・マーケティングオートメーションツール
※ アドテク系受託開発の会社です※

FAworks のご紹介
アドテク、 Web 系案件をご紹介！『 faworks 』で検索！

講師紹介
◆ 基本情報　伊藤孝 (38 歳 )
　 EVERRISE 取締役
　
　 Facebook 　 takashi.itou.er
◆ 経歴
　 1989 年頃　プログラムと出会う
　 1999 年 4 月　 PG として就職
　 2004 年～　物流・在庫コンサル
　 2006 年 6 月　 EVERRISE 起業
　 2006 年 9 月～　アド関連システム開発多数

アドテクブログもやってます！
http://www.ever-rise.co.jp/adtech-blog/
「アドテクブログ」で検索
サイバーエージェント、
リクルートをおさえて第一位

バッチ系処理

本パートでの要点
私は現役技術者では無いで、
SIer として
大量データ処理 ( バッチ ) を受託する際の
How to というか注意点
をご紹介させていただきます。
大量データ処理の歴史を振り返り、ご紹介します。

データベース時代の大量データ
某携帯キャリアの 2003 年頃、約 12 年前の話です。
契約者数： 4 千万
通話回数： 1 日 1 億回、月間で 30 億回
このデータを元に、個人宛てに請求書を発行する
システムを担当 ( 料金計算＋請求書作成 )
この処理を全て Oracle で実現する必要があった。

データベースは専用スパコンで驚異的なサーバスペック。
C 言語でカリカリにチューニング。
何と言っても驚きは、そのサーバの価格！
1 台 100 億円以上！
それでも、携帯契約者が毎日のように増加していたので、　
耐えられずに「もう 1 台 DB サーバを買う？」という議論
が出たが、さすがに即断はできなかったようで、
まずはデータ圧縮チームを結成！

Oracle 社員、プラチナ資格保有技術者で 20 名程度。
当時の想定単価：月額 200 万円
月額 200 万円 ×20 人 ×12 ヶ月＝約 5 億円
その技術者で
「データ圧縮とパラメータチューニング」
だけを、ひたすら実施。
結果、 100 億円のサーバ購入を回避！

Hadoop 時代の大量データ
弊社は 2008 年頃から Hadoop の利用を開始。
Amazon EMR の提供は 2009 年頃で、 Hive もない。
その頃に利用した苦労話を。
技術的に面白そうだからと、
弊社 CTO が「 Hadoop でやります！」
という前提で、あるアド系のシステムを受託。
( 本当は DB でも十分なデータ量でしたが・・・ )

文献はほとんどなく、 AWS 自体も不安定のなか、　
S3 、 EC2 でガリガリと作りこみました。
…結果は
リリースは、延期に次ぐ延期。
　 2 ～ 3 ヶ月間、担当者は休みなし。
　　リリース後も不具合連発！

どんな事象でハマったか？
数台で分散処理させる際、極まれに 1 台だけ失敗する
⇒ 根本原因不明。クラウドの特性上致し方ない？
S3 から処理対象ファイルを読み込むと、極まれにリストが欠損する
⇒ 当時の S3 バグ
エラーログ、実行ログが各サーバに分散して、処理が追えない
⇒ ログを追うためだけの処理を別途記載
エラー対策記述が集計ロジックの約 10 倍に

Amazon EMR ＋ Hive 時代の大量データ
2013 年頃、アトリビューション分析をいくつか受託開発。
Amazon EMR ＋ Hive 構成でそれなりに実装できました。
ただし
> 数台で分散処理させる際、極まれに 1 台だけ失敗する
等の問題は発生していました。
上記のようなエラー時の回避には慣れていたのですが、
「対策記述量の多さと HiveQL の癖に手こずる」
という問題は残りました。

Amazon Redshift 時代の大量データ
そこで 2014 年頃から Redshift 利用（現在メイン利用）
◆Redshift の良い点
・ Hive のような独自文法がほぼなく、
　副問い合わせなど複雑なクエリも実行可能
・集計指示出してからの結果が早い ( 数秒で可能 )
・ EMR で発生していた失敗がなく非常に安定
・既存 DB システムから容易に切り替え可能

Redshift を検証して分かっていること
ファイルの読み込みは方法次第で大きく変動
copy という機能で S3 からのファイルを取り込むことが基本だが、複数ファイル
を 1 ファイルにマージして取込むと大幅に時間短縮される。ただし、使用するノー
ドが複数のノードスライス (CPU コア数 ) を持つ場合は、その分だけファイルを分
割した方が早い。
データ量、処理量、ノード数の関係性がリニア
データ・処理量が増えても、ノード数やノードスライス数等を増やせば、処理時間
は一定を保てるので、計算が立つ ( 処理の組み方次第 ) 。一定閾値を超えると急激
にパフォーマンス悪化という状況は見られない。
いくつかの注意点がある
vacuum 処理をしないと select のパフォーマンスが低下する / ノードの停止がで
きず「停止＝削除」となる / PostgreSQL ベースなので mysql と文法が違う / サ
ポートしていない型も多い / etc

Redshift と TreasureData(TD) の弊社的比較
なぜ、 TD ではなく Redshift を利用しているのか？
１．弊社に Redshift 習熟者が多い
２． AWS 導入は検証済で容易 (TD は実績が少ない？ )
３． DWH 経験者がすぐに利用できる
４． HiveQL よりも生 SQL に近い
５． AWS 担当者に文句を言える ( 逆に TD に知り合いが居ない )

最初から Redshift にしておけば良かった！実例①
データ量は想定より増える
とある「 MA ツール」の開発例で、顧客ランク推移を月単位で見れれば
良かったはずが日単位でランクが変動を見たいと変更。過去 1 年間だけ
のデータ保持の想定が、前年度、前々年度との比較もしたい！と変更。
30 万ユーザの 12 ヶ月の月別の顧客ランク推移
30 万 ×12 ヶ月＝ 360 万レコード想定
30 万ユーザの 36 ヶ月の日別の顧客ランク推移
30 万 ×1095 日＝ 3 億 3 千万レコード

最初から Redshift にしておけば良かった！実例②
想定以上に「無茶をするユーザ」がいる
弊社「アドレポ」の実例。事前にサンプルを集め、調査・設計を実
施。 20 ユーザ位まではデータベースでも余裕なデータ・処理量と想定。
リリース後どうなったか？　　　　　　　　　　　　　　　　　
　 2 ユーザ目で「無茶する想定外ユーザ」が登場。
データ量が数倍、出力レポート量も 10 倍以上
その後、 5 ユーザ目に同様の「無茶するユーザ」が登場。　　　　　　
あっさりとデータベースが処理量でパンク。

大量データ処理を開発する時の教訓
データ・処理量的に見通しが立たない
または、すぐ増強が必要そうなものは
迷わず Redshift(TD 等 ) にしておくべき！

次に
続きまして
トランザクション編

マーケティングテクノロジー勉強会

More Related Content

What's hot

Viewers also liked

Similar to マーケティングテクノロジー勉強会

Recently uploaded

マーケティングテクノロジー勉強会