AWS Aurora AWS Data Migration Serviceを活用した …...AWS Aurora ・AWS Data Migration...

AWS Aurora・AWS Data Migration Serviceを活用した

デジタルマーケティングプラットフォーム構築

© Macromill, Inc. 1

株式会社マクロミルテクニカル・ソリューション本部部長佐藤哲朗

～マクロミルが独自開発したデータ分析システム（Web行動データ× 調査意識データ）の構築ノウハウ～

2© Macromill, Inc.

1. 会社概要/自己紹介

2. デジタルマーケティングプラットフォーム構築1. リサーチ要件の変化

2. 現行システム構成

3. 方策検討

4. 最先端サービス（ Aurora/DMS ）の採用まで

3. クラウドならではの注意事項1. オンプレとの違い､ Aurora/DMS導入での注意事項

4. 今後のAWSに対する要望・期待

Agenda

3© Macromill, Inc.

１．会社概要

社名株式会社マクロミル（英文社名:Macromill, Inc.）

設立 2000年1月31日

所在地国内（品川、大阪、新宿、名古屋、仙台）

海外 13か国、34拠点

社員数約1,700人

連結売上高 2016年6月期 32,504百万円

代表代表執行役グローバルCEO スコット・アーンスト

グループ会社

• 株式会社エムキューブ

• 株式会社エムプロモ

• 株式会社電通マクロミルインサイト

• 株式会社マクロミルケアネット

• MetrixLab B.V.（オランダ）

• Macromill Embrain Co., Ltd.（韓国）

• Oxyme B.V.（オランダ）

• Precision Sample, LLC（アメリカ）

事業内容

•マーケティングリサーチ事業

•グローバルリサーチ事業

•デジタルマーケティングリサーチ事業

•データベース事業

•セルフ型リサーチASP事業

•その他マーケティングに関するコンサルティング業務

4© Macromill, Inc.

マクロミルグループ沿革

2000年1月設立

2001年12月社名（商号）を株式会社マクロミルに変更

2004年1月東証マザーズ上場

2005年4月東証一部上場

2010年8月 Yahoo! Value Insight（株）

マーケティングリサーチ事業承継

2011年4月中国においてマクロミルチャイナ設立

2012年8月韓国法人マクロミルエムブレイン設立

2013年12月電通マクロミルインサイト設立

2014年4月東証一部上場廃止

10月オランダ法人MetrixLab B.V. 子会社化

12月マクロミルケアネットを設立

22013 2014

（単体）

2001 2002 2003 2004 2005

（連結）

2006 2007 2008 2009 2010 2011 2012 2015

売上高（百万円）

28,761

17,120

21,380

106379

851

2,077

3,613

5,179

6,392

7,4137,755

7,353

12,210

14,229

上場

Yahoo! Value

Insight

韓国

中国

電通

グローバル

創業者オペレーション BC2017年3月東証一部再上場

5© Macromill, Inc.

マクロミルのビジネスモデル

マーケティングリサーチに必要なデータはパネルのアンケート回答から成り立っている

6© Macromill, Inc.

リサーチサービスエレメント

北米2,400万人

南米400万人

日本500万人

オセアニア300万人

韓国350万人

欧州2,200万人

中国1,000万人

東南アジア500万人

その他アジア400万人

アフリカ50万人

意識データ

視聴データ

WEB行動データ

購買データ3210 4

公的統計データSNSデータ

EC購買データセンサーデータ

ソリューション

リサーチャーパネル• 日本120万人、韓国110万人、ヨーロッパ130万人、米国

500万人など900万人超の自社パネル

160名コンサルテンィグ営業

170名

リサーチディレクター

170名リサーチャーとアナリスト

600名

海外スタッフ

New generation

Research×DIYNext

Questantミルトーク

MHS/QPR

Research×AccessLog

AccessMill

Traditional

Research×Online

QuickMillOrderMill

Research×Offline

CLTHUT

Research×Global

MetrixLab B.V.Macromill Embrain

Macromill China

データ

7© Macromill, Inc.

自己紹介

佐藤哲朗（さとうてつお）

■経歴2015年6月：マクロミル入社・WEB行動ログ分析サービス（AccessMill）・CRMアンケートサービス（AIRsMEMBERS）・DIYアンケートサービス（Questant）

それまで：SIer、ソフトウェア会社在籍・EC/通販パッケージ開発・オンラインゲーム開発・運用

■好きなAWSサービスRoute 53

8© Macromill, Inc.

リサーチ要件の変化 1/3

リサーチに求められる要件の変化

コンシューマ

・リアル店舗で商品購入

・TV広告で商品認知

リサーチ要件

・早い

・正しい（高品質）

・安い

・アンケート(意識)データ中心

コンシューマ

• リアル店舗、EC／通販で商品購入

• TV広告、WEB(広告)で商品認知

リサーチ要件

• 早い

• 正しい（高品質）

• 安い

• アンケート(意識)×WEB行動(事実)

データ中心

これからこれまで

9© Macromill, Inc.


あの広告を見た人の意識がどう変わったのか？

あの広告を見た人は商品を購入する気になったのか？

あの広告を見て商品を購入する気になった人は実際に購入したのか？

あのイベントに参加した人の商品認知度はどのように変化したのか？

広告､イベントによる認知度､好意度､意向度の変化は？

アンケート(意識)データ､WEB行動データ､購買データ…

各種データのマッチング､マージが必要

データを横に拡げ､データ価値を更に高める必要がある。

埋もれているデータの価値を見出すことも今まで以上に必要となる。

10© Macromill, Inc.


消費者の行動多様化に伴い､従来型リサーチからデジタルマーケティングを組合わせたリサーチへの変革が求められた。

これまで

モニタ会員

リサーチシステム

意識データ

モニタ会員

リサーチシステム

意識 × WEB行動データ

これから

WEB行動分析システム

ダッシュボード…

ターゲティング精度向上により､より質の高いリサーチが可能に。またWEB・TV広告による商品の認知・好意度変化も計測可能になる。


現行システム概要 1/4

2001年

アンケート：意識データ2TB

2007年

購買データ2TB

2015年

購買データ3TB

2013年

アンケート：意識データ GPS SP

2013年WEB行動データビッグデータ基盤

10TB

SNSTV



2001年


2007年

購買データ2TB

2015年

購買データ3TB

2013年



10TB

SNSTV



2001年アンケート：意識データ

2TB


2TB


3TB

2013年アンケート：意識データ GPS SP


10TB

SNSTV

弊社データセンター

弊社オフィス

モニタ会員

モニタサイト／アプリからアクセス

運用／管理



2001年


2007年

購買データ2TB

2015年

購買データ3TB

2013年



10TB

SNSTV



2TB


2TB


3TB



10TB

SNSTV


Tokyo

AmazonEC2

AmazonRDS

AmazonEC2モニタ会員運用／管理

購買データ



2001年


2007年

購買データ2TB

2015年

購買データ3TB

2013年



10TB

SNSTV




2TB


2TB


3TB



10TB

SNSTV

Tokyo

AmazonCloudFront

海外Region

海外Region

AmazonEC2

AmazonKinesis

AmazonS3

AmazonEMR

AmazonAurora

AmazonEC2

モニタ会員

非会員

運用／管理

AmazonCloudFront

AmazonEC2

AmazonCloudFront

AmazonEC2

タグ接触


２．方策検討 1/2

マッチングすべきデータ群

意識データ行動データ購買データその他データ

オンプレ・

クラウド

オンプレ AWSオンプレ AWS・・・

DBMS Oracle（RAC） Aurora／EMR Oracle MySQL・・・

データ量２TB１０TB

100億IMP／月５TB ・・・・

・DBMSも基盤もシステム特性も全てバラバラ・お客様からの要望も多様化・データ種類が増加する毎に運用コストも増加

システム事情に関係なく、システム化が急務


２．方策検討 2/2

考えられる方策とPros/Cons

Pros Cons

①全てのシステムをAWS移行・AWS内でデータを管理／分析可能・保守コスト低減可能

・移行コストが莫大・オンプレに最適化されたシステムがあり、

移行完了までのスケジュールも長期化

②DBMSのみAWS移行・同上

保守コストは①ほどではないが削減可能・Oracle（RAC）およびハードウェアに

依存しているシステムの移行コストが莫大・Oracle（RAC）同等サービスがAWSにない

③データ基盤構築・システム間でのデータ連携が容易・データアクセスをAPIのみに制限することでセキュリティ強化

・①ほどではないが、移行コストが莫大

④データのみを分析基盤に同期・現行システムへの影響なし・移行コストが莫大ではない

・データ管理が冗長・セキュリティ管理対象の増加

「④データのみを分析基盤に同期する方策」を採用、方法をブレイクダウン

検討すべき内容は、「DBMS」と「データ同期方法」の2点


２．Auroraの採用まで 1/3

①DBMS検討

意識データ行動データ購買データその他データ

データ量２TB １０TB

100億IMP／月５TB ・・・・

■要件

・キャパシティ

・データ増加量

・高可用性

・

・



MySQL

データ容量最大6TB

移行―

バックアップスナップショット

耐障害性可用性

Multi-AZ、レプリカDBからのフェイルオーバー



Aurora

データ容量最大64TB

移行

アプリケーションの運用停止時間が設けられれば、MySQLのスナップショットから容易に作成可能

バックアップ自動バックアップと任意の時点への復元可能

耐障害性可用性

・ストレージ自動修復（クラスタボリュームは複数AZに跨り、

各AZにデータコピーが持たれる）

・MySQLより高速なフェイルオーバー


２．DMS採用まで

②データ移行方法検討

■検討した方式

■要件

現行システムに

影響を出さない

ほぼリアルタイムに同期できる

様々なDBMSに

対応している

コールドバックアップ方式

EXP/IMP方式CDC方式直接参照方式



②データ移行方法検討（方式比較：マクロミル社内資料抜粋）

Pros Cons

①CDC方式・リアルタイムでデータ同期可能・Redoログを参照するため、現行シス

テム、DBへの影響が小さい

・現行DBにユーザ追加、REDOログ出力変更が必要

S3 or EC2

差分データ

CDCChangeDataCapture

マスク



Pros Cons

②EXP／IMP案・実績あり・テーブル数が多く非現実的（3万テーブル）・データサイズが非常に大きい（2TB）

データ領域：約800GB

1日の更新量：MAX約100GB

⇒ピーク4時間25GB/時間⇒ 56Mb/秒・差分抽出できないS3 or EC2

EXP

EXP

マスク




Pros Cons

③コールドバックアップ方式

・現行DBへの影響が最も小さい・データサイズが大きく、転送に時間を要する（2TB）※通信量（NW帯域）、通信料

・アーカイブファイルのロールフォワードであれば転送時間は短縮可能だが、AWS上にOracleが必要でありコストが高い

S3 or EC2

静止データ

静止データ

マスク




Pros Cons

④直性参照方式・現行DBへの影響が大きい・責任分界点が定義できない




Pros Cons

①CDC方式・リアルタイムでのデータ同期が可能・Redoログを参照するため、現行シス

テム、DBへの影響が小さい

・AIRsDBにユーザ追加、REDOログ出力変更が必要

②EXP／IMP案・QPRで実績あり・テーブル数が多く非現実的（3万テーブル）

・データサイズが非常に大きい（2TB）

データ領域：約800GB

1日の更新量：MAX約100GB

⇒ピーク4時間25GB/時間⇒ 56Mb/秒

・差分抽出できない

③コールドバックアップ方式

・AIRsDBへの影響が最も小さい・データサイズが大きく転送に時間要する（2TB）※通信量（NW帯域）、通信料

・アーカイブファイルのロールフォワードであれば転送時間は短縮可能だが、AWS上にOracleが必要でありコスト高い

④直性参照方式・AIRsDBへの影響が大きい・責任分界点が定義できない

リアルタイム転送を実現できる唯一の方法




②データ移行方法検討（ツール比較：マクロミル社内資料抜粋）

Pros Cons

①Attunity ・非常に高機能・AIRsDBの負荷を最低限に抑え

られる

・COREライセンスのため非常に高価初期3,600万円、保守年額1,000万円

②GoldenGate ・上記同様・Attunity同様にライセンス費用が莫大

③CDC ・Oracle標準機能であるため・同期先DBもOracleになるため、ライセンス費用が発生

マスクマスク



②データ移行方法検討（ツール比較：マクロミル社内資料抜粋）

Pros Cons

AWS DMS

Database Migration Service

・CDC同様・ライセンス料０・インスタンス・通信料のみ・MySQLのDDLレプリケーション非対応

など難点はあるものの、ビジネス要件に影響を及ぼすデメリットはない。

・AWSマネジメントコンソール上での操作のみで利用でき、導入障壁が低い

・同期先DBにOracle以外を選択可能

・サービス実績が少ない。

採用有事の際にオンラインで設定を元に戻せることは確認済み


２．デジタルマーケティングプラットフォーム概要図

DMS/AURORA連携図

AmazonAurora

AmazonDMS

AmazonRDS

AmazonRDS

VPCpeering

AIRs

オンプレ（AIRs/QPR）

QPR

AWSDirectConnect

VGWRouter

AWS(Lognos）

AWS(MHS）

オンプレ環境／別AWSアカウントから継続的にレプリケーション


２．デジタルマーケティングプラットフォーム構築総括

・短期間（約2か月）で構築完了

・既存システムの影響なし

・システム間は専用線で安全にデータ連携


３．クラウドならではの注意事項

AWS Data Migration Service の注意点

データソース・ターゲットのアーキテクチャの相違

同期エラー

FullLoad時のDB負荷とNW帯域



データソース・ターゲットのアーキテクチャの相違

・データソースにLOBカラムが含まれる場合、その取り扱いには注意が必要。

・データソースにより、データ移行時の型変換など調整が必要。

例えば、ソースデータベースがOracleで「Number型の値がNull」というデータを

MySQLのターゲットデータベースにレプリケーションする場合、『int型の０』として挿入される。




同期エラー

・何かしらの要因で同期タスクにエラーが生じ、タスクが停止した場合は

再開することができず、同期を最初からやり直すことになる。

そのため、Cloud Watchによる監視は必須。

・DMSインスタンスのディスクフルが発生すると、ログが出力されなくなり、

監視不能となる。




FullLoad時のDB負荷とNW帯域

同期開始後しばらくはソースデータベース、ネットワーク共に高負荷となる。

ソースデータベースが稼働中の場合は、テーブルの並列同期数の調整、標準

実装されているAPI経由でデータ同期タスクの縮小や停止で負荷調整が可能。




AWS Aurora の注意点

Amazon Aurora クラスターの必須アップグレード

スレーブに適用→マスター昇格して適用したものに入れ替え、といったことが

できません。クラスター内のすべてのノードインスタンスに適用されるため、

データベースへの接続不可時間帯が生じます。時間は30秒程度と短いですが、

稼働停止ができないサービスの場合は要注意です。

＊但し、ダウンタイムなしとの噂もあるため、詳細はAWS様まで問合せください。


コスト意識

セキュリティ意識

アプリ担当の範囲拡大


AWS利用者側の意識面（オンプレとの違い）


コスト意識

容易にインスタンスを稼働させられる、構成を変更できるといった利便性が

高い分、コスト意識が低くなりがち。

予期せぬスパイクにスケールアウトして可用性を高めることは容易だが、

オンプレと異なりインフラコストが変動費になる点は注意が必要。




セキュリティ意識

設定変更が容易なため、テスト時の一時的な処置のつもりで変えた設定が

残ったまま、開発環境だから、など危機感が低くなりがち。

AWS Config などで設定変更をフック、アラート発報など

仕組みの構築も有効だが、メンバーの意識付けが重要。




アプリ担当の範囲拡大

アプリ担当者も最低限のインフラ知識が必要であったが、クラウド最盛期の今、

アプリとインフラの垣根が崩壊した。

アプリ担当者に求められるスキルの範囲はますます拡大していくことになる。




４．今後のAWSに対する要望・期待

コスト低減サービスの根幹となっているEC2の利用料をS3並みに低減してほしい。（サーバーレス化も検討）

今後利用検討していくことになるであろう、Amazon Athenaの利用料も・・・。

トラブル撲滅バージニアリージョン障害によるOpsWoks管理下インスタンスのトラブルなど、リージョン間を

シームレスに繋ぎつつも、他リージョンのサービスに影響のあるようなトラブルを撲滅してほしい。

サービス拡張更なるサービスを拡張を行いオンプレを凌駕してほしい。

特に固定IPアドレスを割当てられないサービスには、固定IPアドレスが割当てられることを期待する。

また、スケールアウト性能向上や、FW/LBのサービス拡充を期待している。


ご清聴ありがとうございました。

AWS Aurora AWS Data Migration Serviceを活用した …...AWS Aurora ・AWS Data Migration...

Documents

Transcript of AWS Aurora AWS Data Migration Serviceを活用した …...AWS Aurora ・AWS Data Migration...