So net

クラウド連携による BI 構築事例
www.so-net.ne.jp
April 6, 2011

ソネットエンタテインメント株式会社
サービス開発部
安田崇浩
So-net Entertainment Corporation
Service Development Department
Takahiro YASUDA
Copyright © 2011 So-net Entertainment Corporation, All rights reserved.

本日の発表の概要

• 広告配信の事業を行っています

• この事業にとって BI(≒データ分析による意思決定) は重要です

• BIシステムの機能は、蓄積、分析、閲覧です

• 蓄積に Amazon Simple Storage Service (S3) を

分析に Amazon Elastic MapReduce を

閲覧に Salesforce Force.com のクラウドサービスを組み合わせて

システムを開発しました
2 Copyright © 2011 So-net Entertainment Corporation, All rights reserved.

自己紹介

• 氏名: 安田崇浩
• 所属: ソネットエンタテインメント株式会社サービス開発部
• 最近の開発
• 2006-2009
• ブログ解析のシステムを開発
• サービス名: 「Blog Keyword Visualizer」「近未来予報ツギクル」「バズク
ル」
• Amazon Web Services EC2 を活用
• 2010-2011
• 広告配信事業の分析システムを開発
• サービス名: アドネットワーク「TRUST CLICK」
• Amazon Web Services Elastic MapReduce, S3
Salesforce Force.com を活用


会社紹介

■ 社名ソネットエンタテインメント株式会社
■ 上場証券取引所東証1部 (証券コード:3789)
■ 設立 1995年11月
■ サービス開始 1996年 1月
■ 株主ソニーグループ 58.2%
(2010年9月末現在)
その他株主 41.8%
■ 資本金 79億65百万円 (2010年9月末現在)
■ 従業員数 445名 (単体 2010年12月末現在)
1,199名 (連結 2010年12月末現在)


会社紹介

会社名ソネット・メディア・ネットワークス株式会社
（英文表記： So-net Media Networks Corporation）
代表取締役穂谷野智
設立平成12年3月21日
所在地〒141-6009
東京都品川区大崎2丁目1番1号 ThinkPark Tower
tel. 03(5435)7930（代表） fax. 03(5435)7932

会社HP http://www.so-netmedia.jp/
事業内容インターネットマーケティング事業
株主ソネットエンタテインメント株式会社
持株比率 100％


広告配信事業のアドネットワークについて

• アドネットワークとは、複数のメディアサイトをネットワーク化して広告配信するサービスです。
• 通常のWEB広告（純広告）ではメディアサイトが特定される為、配信された広告は限られた
ユーザーにしか露出されません。
• 一方でアドネットワークでは多くのユーザーに対して広告を配信することが可能です。

AD
AD
AD AD
AD AD
AD アド AD
入稿
サーバ
AD
AD
AD
広告主様


広告配信事業のデータ分析の重要性

• 広告をどのメディアサイトに、どのバナーを、どのくらいの量で、どの時
間帯に、どのようなユーザーに配信するかの設定が重要です
• この設定によってアドネットワークのパフォーマンス（クリック率、コン
バージョン率）が変化します
• 広告の配信ログを分析し、この設定を決めています

AD
AD
時間帯
AD AD
AD サイト
AD
AD AD
入稿フリークエンシー配信
AD
クリエイティブ
AD
AD
広告主様広告配信設定


データ分析の要件

• 広告配信のデータ分析システムの要件は大きく３つ

• 蓄積

• 広告の配信ログを最低2年分を蓄積したい

• 分析

• 蓄積した広告配信ログに対して、集計、抽出など様々な分析を行い
たい

• 閲覧

• 広告配信の設定に役立てるために、分析結果をWebブラウザで閲覧
したい

蓄積


「蓄積」するデータの特徴

• 広告配信ログの特徴
• メディアサイトのページビュー (PV) に比例して増加
• メディアサイトの数 : 約6,000

• 広告配信ログのサイズ
• 1日間のログのサイズ ( gzip 圧縮済み)
• 10 GByte / 日
• 2年間のログのサイズ
• 10 GByte x 365日 x 2年間 = 7.2 TByte
• ログのサイズは、増加傾向


「蓄積」の要件と解決策

• 要件
• 2年間の広告配信ログ 7.2 TByte を保存したい
• クラウド利用前
• 10 TByteクラスの容量のストレージ製品が必要
• 初期投資: 数百万円～
• 運用費: 6U 以上のラックスペースによる運用が必要(数万円～）
• コストと効果のバランスが合わずストレージ製品は未導入
• 既存システムではログの一部の保存のみ実施
• 分析に制限が発生
• クラウド利用後
• 広告配信ログの保存先としてAmazon Simple Storage Service (S3) を利用
• 10 TByte の1カ月間の利用料金: 約1250 USD/month ≒ 10万円 / 月
• すべてのデータの分析が可能に

「蓄積」S3

• AWS Simple Storage Service (S3) に保存して問題ないか？
• 個人情報
• 広告ログ配信データは広告主様やメディアサイト様の顧客情報などの個
人情報は含まない
• US の S3 サーバーに保存しても問題がないデータ
• 信頼性
• 可用性(availability): 99.99% をSLAにより保証
• 耐久性(durability): 99.999999999%
• アクセスコントロール
• ACL : ファイル単位のRead, Write権限の設定
• Bucket Policy : Bucket単位のRead, Write権限の設定, IPアドレス制限
• Identity and Access Management(IAM)
• 特定のアクセス権を持ったユーザーを任意に作成


「蓄積」S3 の Region

• 利用している Region

• 「分析」でAWS Elastic MapReduce を利用しているため

US-East Region を利用

• アップロード時の転送速度

• 東京からUS-EastのS3へのアップロード速度は約200 ~ 500Kbps

• 10 GByte のファイルをアップロードすると

10GByte x 8 bit / 500Kbps = 約 45 時間

• Tips: 同時接続してもアップロード速度は変わらない


「蓄積」アップロード方法

• アップロード方法
• ファイルを一定のサイズに分割
• 合計10GByte のファイルを 50MByte x 200個に分割 AWS S3
• 同時接続でアップロード Upload
• JetS3t Toolkit を利用し、
分割
同時10接続でアップロード

• アップロード処理時間
• 50MByte x 8bit / 0.2 ~ 0.5Mbps x 200個 / 同時10接続 = 約4.5 ~ 11時間
• エラー処理
• HTTP エラーは、少なくない割合で発生
• リトライ処理の実装が重要。JetS3t Toolkit のリトライ実装を利用


「蓄積」S3 の URL 設計

• ログファイルのS3のURL設計
• スラッシュ / で区切り、日付で階層化
• AWS Management Console, S3Fox で閲覧する際に便利
• 例
• http://foo-bucket/title=bar/year=2011/month=01/day=01/001.gz
• http://foo-bucket/title=bar/year=2011/month=01/day=01/002.gz

• Amazon Elastic MapReduce の入力として URL prefix とワイルドーカー
ドが利用可能
• 年単位, 月単位, 日単位の入力が容易
• 例
• http://foo-bucket/title=bar/year=2011/*/*
• http://foo-bucket/title=bar/year=2011/month=01/*

「分析」


「分析」の要件

• 広告の配信ログのサイズ
• 1日: 10 GByte, 2年間: 7.2 TByte
• 分析の要件は大きく２つ
• 大量のデータの集計
• 統計解析ツール、データマイニングツールで解析が難しいサイズの
集計
• 例
• 数ヶ月間以上のユニークユーザー数など
• ツール向けのデータ抽出
• 統計解析ツール、データマイニングツール向けに条件を指定して、
データを抽出


「分析」の実行環境の検討

• 7.2 TByte のデータをREAD するとどのくらいの時間がかかるか？
• HDD の読み取り速度 : 50MByte/秒
• 7.2TByte ÷ 50 MByte/秒 = 40時間
• 大容量データの解析
• MapReduce
• コンピューター機器のクラスター上で、巨大なデータセットに対し
分散並列処理を行うのを支援する目的で、Googleによって考案さ
れたソフトウェアフレームワーク。(Wikipedia より)
• MapReduce の実行環境
• Apache Hadoop
• Apache の Open Source Project
• AWS Elastic MapReduce
• Amazon の Web Service

「分析」Apache Hadoop と AWS EMR

Apache Hadoop AWS EMR
形態 Open Source Project Web Service
サーバーリソース自前で構築したクラスタの On Demand で AWS の
サーバーリソースサーバーリソースを利用
初期費用クラスタ構築サーバー費なし
運用費用サーバー運用費 AWS EMR, S3 の利用料
入出力のストレー HDFS AWS Simple Storage
ジ Service(S3)


「分析」入出力のストレージの比較検討

入出力のストレージ HDFS AWS Simple Storage Service(S3)
• HDFS
• 自前で構築したクラスタ環境で動作する分散ファイルシステム
• ファイル管理する部分に単一障害点がある
• AWS Simple Storage Service (S3)
• インターネット用のストレージサービス
• 低コスト、高可用性(availability)、高耐久性(durability)
• 検討結果
• HDFS は、自社の運用経験が少ないためファイル損失の恐れあり
• HDFS を利用する場合、別のストレージ製品にファイルの保存の必要があ
ると判断
• データの性質や S3 の機能から AWS S3 上に保存しても問題ないと判断


「分析」利用環境の比較

サーバーリソース自前で構築したクラスタの On Demand で AWS の
サーバーリソースサーバーリソースを利用
初期費用クラスタ構築サーバー費なし
運用費用サーバー運用費 AWS EMR, S3 の利用料

• 状況
• MapReduce の処理が決まっておらず、必要なサーバー台数が不明
• 検討結果
• 数台-100台超まで柔軟にサーバー数を利用可能な AWS EMR を使用
• 現在のAWS EMR の利用状況
• 1時間毎 2台使用の処理から1ヵ月毎 80台使用の処理まで様々
• 利用するサーバー数にバラつきがあり、結果的に AWS EMR に向き


AWS EMR の所感

• 良い点
• MapReduce処理のサーバー数にバラつきがある場合、コストが最適化され
る
• Hadoop クラスタを構築、運用するインフラエンジニアが不要
• 集計処理ごとにコストが算出できるので、費用対効果がわかりやすい
• Reduce 処理でメモリ不足のエラーが発生した場合、メモリの大きいインス
タンスタイプに変更することで暫定対応が可能
• 悪い点
• サーバーリソースのモニタリング機能がないため、パフォーマンスチューニ
ングが難しい
• 現場の判断で EMR を実行しているため、月額の予算をオーバーすること
がある
• 開発時のデプロイと実行に時間がかかり、開発サイクルが少し遅い


「蓄積」と「分析」の連携



• 要件
• 広告配信ログを S3 にアップロードした後に、
そのログを入力とするMapReduce 処理を起動したい

• 解決策
• AWS Simple Queue Service (SQS) を利用


• AWS Simple Queue Service (SQS)
• AWS の Queue サービス
• 短い文字列のMessage を登録、参照、削除ができる
• 厳密なFIFO(First In First Out) ではない

• AWS Elastic MapReduce へ通知方法
• アップロードしたファイルの URL を Message として Queue に登録
• Queue を定期的に参照するバッチを実装
• Queue から参照した message に応じて、
AWS Elastic MapReduce を起動


「蓄積」と「分析」の連携の流れ

1. 2011/1/1 のログファイルを AWS
S3 にアップロード
• http://foo-
bucket/title=bar/year=2011/month=
01/day=01/001.gz
2. AWS SQS に message を登
• “http://foo-
bucket/title=bar/year=2011/mont
h=01/day=01/001.gz”
3. SQS から message を取得 (polling)
4. 2011/1/1 のユニークユーザーを
集計する AWS EMR の処理を起動


閲覧


「閲覧」の要件

• 要件
• 社員が利用する業務アプリケーション
• AWS Elastic MapReduce (EMR) で処理した結果を Web ブラウザで
表示
• 表示形式は、グラフ、表
• テータの閲覧権限の管理
• 広告配信の設定画面との連携

• 実装方法
• Salesforce Force.com を利用


「閲覧」Force.com

• Salesforce Force.com
• PaaS 型のクラウドサービス
• インフラ、データベース、インテグレーション、ロジック、ユーザーイン
ターフェースといった、クラウドコンピューティングモデルのアプリ
ケーション開発に必要とされる要素を備えている (Wikipedia より)

• 採用した目的
• 業務アプリケーションの開発生産性の高さ
• 認証、認可の機能の実装コストの削減
• アプリケーションサーバー, 認証サーバーの運用コスト削減


「閲覧」Force.com と AWS S3 のデータ連携

• 当初の設計方針
• AWS EMR が出力した AWS S3 上のデータを定期的に Force.com の DB
へインポート
• Force.com の DB のデータをレポート機能を利用して、グラフ表示

• Force.com の DB と容量の問題
• 初期データベースの空き容量は 1 GByte
• 1レコードで約 2 KByte 消費, 約 50 万レコードで 1 GByte 消費
• データベースの容量追加コストと想定利用容量のバランスが合わず


「閲覧」Ajax の利用

• 問題
• Force.com の DB を利用せず AWS S3
のデータを表示できないか？
• 解決策
• Ajax を利用
• JavaScript で
AWS S3 のデータを取得し、表示
• 良い点
• Force.com の追加DB を利用しないことによるコスト抑制
• 認証、ページのアクセス権の管理は Force.com の機能を利用
• AWS IAM を利用し、 IP アドレスによるアクセス制限が厳密に
• 悪い点
• Force.com のレポート機能が利用できない
• クロスドメイン問題 : saleseforce.com と s3.amazonaws.com

「閲覧」AWS Access Key, Secret Key の管理

• 問題
• AWS Access Key, Secret Key の管理をどうするか？
• AWS Access Key, Secret Key
AWS S3, SimpleDB, SQS 等に Read, WriteするためのID, Password
• Force.com に AWS から発行された Access Key, Secret Key を配置したく
ない

• 解決策
• AWS Identity and Access Management (IAM) を利用し、必要な権限のみ
保持したAccess Key, Secret Key を作成
• AWS Identity and Access Management (IAM)
• ユーザーの追加, アクセスリソース(S3 bucket)の制限, アクセス条件
(Read/Write, IPアドレス, アクセス時間)の制限など
• 例: 社内IPアドレスから S3 foo-bucket の Read のみ可能なユーザー

「閲覧」AWS Access Key, Secret Key in Force.com

• 次の権限を持ったAWS Access Key, Secret Key を AWS IAM で作成
• 社内のIPアドレス:202.0.113.0 から AWS S3 “foo-bucket” への Read 権限
• もし漏洩した場合、同じ社内の誰かからアクセスされる恐れ
• Secret Key はForce.com のロジック内で Hash 化


「閲覧」ID, Password

• Force.com から AWS S3 へアクセスする設計の場合

• 次の権限を持ったAWS Access Key, Secret Key を AWS IAM で作成
• Force.com の IP Address Range:202.0.113.0/24 から
AWS S3 “foo-bucket” への Read 権限
• もし漏洩した場合、他の Force.com ユーザーからアクセスされる恐れ


まとめ


「蓄積」のまとめ

• AWS Simple Storage Service (S3) を利用して、広告配信ログを「蓄積」

• 分割し、並列でアップロード


「分析」まとめ

• AWS Elastic MapReduce を利用して「分析」機能を実装
• AWS Simple Queue Service(SQS) を利用して
S3 へアップロード後に AWS EMR を起動


「閲覧」まとめ

• Salesforce Force.com を利用して「閲覧」機能を実装
• Ajax を利用し AWS EMR の出力データを Force.com の画面に表示


まとめ

• 広告配信ログのBIシステムを AWS S3, EMR, Salesforce Force.com を
組み合わせて構築しました
• AWS Simple Storage Service(S3), Elastic MapReduce (EMR)
• 大規模データを分析するシステム開発としては取り組みやすい
• 運用コストが低い
• Salesforce Force.com
• 業務アプリケーションの機能が揃っており開発速度は速い
• 技術サポートの対応が早い
• 運用コストが低い
• 様々なクラウドサービスの良い点を組み合わせることで、
要件にあったシステムを開発できる


END


So net

More Related Content

What's hot

Viewers also liked

Similar to So net

So net