【レポート】AWS Summit Tokyo 2017: [マクロミル] Amazon Aurora・AWS DMS を活用したデジタルマーケティングプラットフォーム構築～マクロミルが独自開発したデータ分析システム（Web 行動データｘ 調査意識データ）の構築ノウハウ #AWSSummit

『AWS Summit Tokyo 2017』が2017年5月30日(火)〜6月2日(金)、グランドプリンスホテル新高輪 品川プリンスホテル アネックスタワーで開催されています。

当エントリでは「Amazon Aurora・AWS DMS を活用したデジタルマーケティングプラットフォーム構築～マクロミルが独自開発したデータ分析システム（Web 行動データｘ 調査意識データ）の構築ノウハウ」をレポートしたいと思います。

• AWS Summit Tokyo 2017（2017年5月30日～6月2日）｜AWS

セッション概要

当セッションの登壇者及び概要は以下の通りです。

セッションレポート

以下、セッションのレポートです。

アジェンダ

• 会社概要
• デジタルマーケティングプラットフォームの構築
• 背景
• 検討
• Aurora DMSの採用理由
• 注意事項
• AWSへの要望と期待

会社概要

• 株式会社マクロミル
• マーケティングリサーチ＆コンサルティング
• 海外展開13カ国34拠点
• アンケート実施、分析レポートをクライアントに納品
• サービスエレメント
  • アンケートが主軸
• 意識データ
• 購買データ
• 視聴データ
• Web行動データ

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

• コンシューマの行動が多様化
• TVで認知→Webで認知
• アンケート(意識)データから、Webの行動データへ
• コンバージョンだけではなく、広告を見た人の意識データと組み合わせる
• データを横に広げてデータ価値を高める。埋もれた価値を引き出す。
• 行動の多様化からデジタルリサーチの変革を求められた

• 意識データと事実データを掛け合わせる。
• 精度向上、品質向上

• 2001にAIRsローンチ
  • 市場の発展に合わせてシステムにデータを蓄えてきた

 既存システムの構成

• AIRs
  • オンプレで今も稼働
  • Oracle
  • ハードウェアも使っている
  • 簡単に変更できない

• AccessMill
  • AWSで稼働
  • EC2からfluentd、kinesisを使ってAuroraへ
  • EMRで分析しやすいようにS3に出力

課題

• 各システムの構成はバラバラだった
• システム化が急務だった
• しかし全部を簡単には変えられない
• アプリケーションに手を入れるのはリスク
• データのみを分析基盤に入れることにした

DBMSと同期方法

• Auroraを選定
• 要件
  • キャパシティ 数テラバイト
  • データの増加
  • 高可用性、セキュリティ
• 当初はMySQLを検討
  • 最大容量6Tがネック
• Auroraは64T
  • MySQLのスナップショットから変換が可能
• バックアップ
  • マネージドサービスゆえ自動バックアップと任意の復元が可能
• 耐障害性
  • マルチゾーン
• MySQLよりフェイルオーバが早い

データ移行

• 要件
  • 現行システムに影響を出さない
  • リアルタイムに同期
  • 様々なDBMSに対応
• CDC方式 (Cange Data Capture)
  • リアルタイムで同期が可能
  • 現行システムへの影響が小さい
  • 些細な欠点：Supplimental Logの追加設定変更が必要

ツールの比較検討

• ライセンス費用、要件(ハイスペック過ぎ、不要な機能)
• AWS DMS(データマイグレーションサービス)を使用
  • ライセンス料不要、インスタンス通信料のみ
  • 有事の際にAMCですぐに止められる

構成

• LognosにDMSのインスタンス
  • オンプレからDirect Connect(専用線)で接続
  • その他サービスからはVPC Peeringを使って同期
• ネットワーク帯域だけではなくシステム/プロダクト内の帯域で調整
• Auroraの負荷が上がり、分析に影響が
  • 対策→読み込みエンドポイントを使うように
  • 自動でバランス
• 短期間(2ヶ月)で構築完了
  • 別途アプリケーション開発も実施したがそれは除く
• 既存システムに影響なし
• システム間は専用線で安全に

知り得たDMSの注意点

• アーキテクチャの相違
  • DBMSが異なるとカラム、型の違い
  • ラージオブジェクト、一定サイズを超えると同期ができない

• 同期エラー
  • 時々発生
    • なんとかしていただきたい
  • 再開ができない
    • 最初からやりなおす必要がある
    • 負荷がかかる
  • CloudWatchによる監視が必須
    • ディスクフルが発生するとログが出なくなり監視不能となる
• フルロードのDB負荷、NW帯域
  • 同期対象のテーブル制限
  • DBMSの設定で調整

• Auroraの注意点
  • クラスタの必須アップグレード
  • マスタスレーブどうちらもアップグレード必要なので、接続不可能時間が生じる
  • 30秒程度

オンプレとの違い

• コスト
  • 容易にインスタンスを稼働させられる
  • スケールアウトも容易
  • ただしインフラコストが変動費となることに注意
• セキュリティ意識
  • 操作が簡単すぎるが故の課題
  • ガバナンス(会社としての課題)

• アプリ担当の範囲拡大
  • アプリとインフラの垣根が崩壊しつつある
  • アプリはより大変に

要望、期待

• コスト低減
  • S3並みに低単価になると利用しやすい
  • サーバレス化も検討
  • EMRを使っている。Athenaも検討中。価格下げて
• トラブル撲滅
  • OpsWorksを使っているがN.Virginiaの障害の影響が出ることが
• サービス拡張
  • オンプレを凌駕してほしい
  • スケールアウトを1秒以内に
  • 交通機関並みの知名度。電車が止まったなら仕方ない。

最後に

• AWS経験エンジニア募集中
• 講演機会をくださったAWS、それからチームのメンバに感謝

感想

目的に合わせてオンプレやクラウドで個別に構築されてきたシステムを、統合的な分析を行うためにAWSでデータ基盤を整備、構築した事例が紹介されました。その検討過程や、得られた知見、ノウハウは貴重なものだと思います。大量のデータを持つユーザが、クラウドを利用するときの参考になるのではないでしょうか。