700億件のリアルタイム分析の実現と運用の実態
•Download as PPTX, PDF•
0 likes•534 views
Vertica Unify APAC 2021の発表資料です。
Recommended
More Related Content
Similar to 700億件のリアルタイム分析の実現と運用の実態
Similar to 700億件のリアルタイム分析の実現と運用の実態 (20)
700億件のリアルタイム分析の実現と運用の実態
- 1. 700億件のリアルタイム分析 の実現と運用の実態 みらい基盤課 上原 賢也 / 山本 瑛治 株式会社イルグルム
- 2. 0. 紹介 1. 広告効果測定とは？ 2. ヒト軸分析をどうやって実現したのか？ • ヒト軸分析を実現するための要素 • ヒト軸分析を実現するための 「分析」基盤/インフラ課題 • 全てを満たすことができた 「分析」基盤/インフラ 3. 導入から5年しての運用の実態 • 製品の選定ポイントと比較 • 学習コスト • 運用コスト 4. Vertica Eonモードの導入 ・アドエビスとは？ ・マーケティングの今 ・自己紹介 ・会社紹介 ・アドエビスとは • 導入の要件 • システム構成 • v9とv10の違い アジェンダ
- 3. 3 略歴 上原 賢也 2006年 日本発ECオープンプラットフォーム「EC-CUBE」の開発 2009年 広告運用「THREe」のインフラ基盤の設計・構築 2012年 全社の品質管理・インフラの導入・運用をメインで実施 2015年 ベトナム子会社へ出向し、オフショア開発拠点の立ち上げ 2019年 日本に帰国し、主にインフラ面から基盤戦略全般を担当 2020年 岡山大学大学院自然科学研究科電子情報システム工学専攻 卒業 2020年 株式会社イルグルム 入社 以後、インフラエンジニアとして業務に従事。 直近ではVerticaEonの設計・運用等に携わる。 略歴 自己紹介 Katsuya Uehara 山本 瑛治 Eiji Yamamoto
- 4. 4 会社概要 株式会社イルグルム YRGLM Inc. 【大阪本社】 大阪府大阪市北区梅田2-4-9 ブリーゼタワー13F 【東京本社】 東京都千代田区有楽町2-2-1 X-PRESS有楽町12F 【子会社】 株式会社イーシーキューブ（大阪市北区） 【子会社】 株式会社スプー（東京都千代田区） 【子会社】 株式会社トピカ（東京都新宿区） 【子会社】 YRGLM VIETNAM COMPANY LIMITED（ベトナム社会主義共和国） 設立 2001年6月4日 代表者 代表取締役 岩田 進 事業内容 マーケティングDX支援サービスの提供 広告効果測定プラットフォーム「アドエビス」 運用型広告レポート自動作成ツール「アドレポ」 広告代理店向けクラウド案件管理ツール「アドナレッジ」 広告代理店マッチングプラットフォーム「アドフープ」 EC特化型CX向上プラットフォーム「eZCX」 ECオープンプラットフォーム「EC-CUBE 東京証券取引所マザーズ上場（3690）
- 11. 11 計測 広告効果測定 アクセス解析 View計測 LPO クリック計測/SEO計測 経路分析 動画広告 記事広告 ディスプレイ 広告 コンテンツ マーケティング 純広告 自然検索 アフィリエイト 広告 リスティング 広告 リターゲティン グ広告 ダイレクト SNS LP TOP コンテンツ CV 活用 外部連携 BI/レポーティング MR/CRM/SFA 広告配信/運用管理 リサーチ/モニター 3rd Party Data EC/通販支援ツール TV/オフライン施策 分析 レポーティング 施 策 軸 ユ ー ザ ー 軸 デモグラフィック カスタマージャーニー 分析 チャネル別集計 アトリビューション 分析 アドエビスはあらゆるマーケティングの効果をメディア・デバイス・代理店を横断して測定、 マーケティング活動の成果最大化をサポートするサービスです。 「アドエビス」が提供する３つのソリューション
- 17. データ×組み合わせ 爆発 17
- 18. 18 媒体軸分析 ヒト軸分析 軸の件数 媒体の数 ※広告の場合、約150万程度 行動パターン ※組み合わせ爆発発生 データ量 10万件～1000万件程度 ※１日単位の事前集計済データ 100億件〜 ※事前集計無しの全行動履歴 要求される 処理速度 数秒〜数十秒 新たな課題 - 媒体軸とヒト軸のデータの違い
- 21. 21 一致したヒト 2/3 が購入 という行動パターンに一致した/しないヒトは？ 広告A 閲覧 広告B クリック 検索流入 広告B クリック 検索流入 購入 購入 広告A 閲覧 検索流入 購入 広告A 閲覧 広告B クリック 検索流入 広告A 閲覧 広告B クリック 一致しなかったヒト 1/3 が購入 広告A閲覧 検索流入 → 計測対象ユーザー 広告A 閲覧 1.行動パターンに合致する「ヒト」の抽出
- 22. 22 • 媒体軸：事前に集計可能 • ヒト軸：事前に集計不可能 – 全行動履歴データは 年間 数百億レコード – 全行動履歴データを 行動パターンに起こすと、何倍にもデータが膨れ上がる – 事前に集計するためには、時間、リソースの両方が足りない ログ ファイル 計測 サーバ 全行動履歴データ リアルタイム分析・ 閲覧用 ※数百億レコード 全行動履歴データ 検査/加工/集計 ※数百億レコード ログ ファイル 計測 サーバ … 全行動履歴取得 ※広告閲覧/広告クリック/検索流入/ サイト閲覧/コンバージョンetc… 計測対象ユーザー 計測対象ユーザー ？？？ Hadoop Postgre SQL 集計データ閲覧用 ※数百万レコード ※集計データ アドエビス 管理画面 アドエビス ご契約者様 2.全行動履歴のリアルタイム集計
- 23. 23 日々増加する計測対象ユーザー • ご契約者数 • ご契約者様の計測対象ユーザー 日々増加する計測ポイント • 顕在層→潜在層 への計測拡大 近い将来、リソースが限界に 2015/11/28 2015/12/7 2015/12/16 2015/12/25 2016/1/3 2016/1/12 2016/1/21 2016/1/30 2016/2/8 2016/2/17 2016/2/26 2016/3/6 2016/3/15 2016/3/24 2016/4/2 2016/4/11 2016/4/20 2016/4/29 2016/5/8 2016/5/17 2016/5/26 2016/6/4 2016/6/13 2016/6/22 2016/7/1 2016/7/10 2016/7/19 広告クリック数 3.リニアなスケーラビリティ 全リニア（直線的）にスケールアウト する仕組みが必要 ex) ・サーバ1台で10.0秒 ・サーバ2台で 5.0秒 ・サーバ3台で 3.3秒
- 24. 24 1.行動パターンに合致する 「ヒト」の抽出 × ○ △ × 2.全行動履歴のリアルタイム集計 × △ △ ○ 3.リニアなスケーラビリティ × ○ ○ ○ 社内にあったデータ分析基盤では全てを解決できない
- 25. 25
- 27. 27 SELECT ユーザID, アクセス時間, アクション, 広告ID FROM all_log MATCH (PARTITION BY ユーザID ORDER BY アクセス時間 DEFINE 広告A閲覧 AS アクション = ‘広告閲覧' AND 広告ID = 'A', 検索流入 AS アクション = '検索流入‘ その他 AS … PATTERN P AS (広告A閲覧 (広告A閲覧|検索流入|その他)*? 検索流入) ROWS MATCH FIRST EVENT); ユーザID アクセス時間 アクション 広告ID ユーザ1 2016-07-26 12:00 広告閲覧 A ユーザ1 2016-07-26 12:02 検索流入 ユーザ1 2016-07-26 12:03 購入 ユーザ2 2016-07-26 12:00 広告閲覧 A ユーザ2 2016-07-26 12:01 広告クリック B という行動パターンに一致したヒトの抽出 広告A閲覧 検索流入 →
- 28. 28 テーブル レコード件数(億) 所要時間(ms) 全行動履歴(半年分) 55.80 380.042 ご契約者様 レコード件数(億) 所要時間(ms) A様 5.58 12,034.691 B様 4.81 C様 2.88 D様 2.15 E様 1.83 各テーブル別の レコード件数 ご契約者様別の 全行動履歴テーブル レコード件数 （上位５件） ex) SELECT count(ご契約者様) FROM 全行動履歴; RDBでは捌ききれなかった大量データも高速に集計可能
- 31. 導入から5年 運用の現場は？
- 37. 37 取得リクエスト 取 得 取 得 取 得 Trasfar Batch 取 得 取 得 取 得 Archive AC Batch Hadoop クラスタ （Hive） Sync Batch Sync Server Cross Device Analysis Batch EMR CORE DB SSAPI接続 SSAPI すべてのチャネル ユーザープロファイル AD エビス LOG エビス SEO エビス LPO エビス Dynamo DB 3pas AD Master AD Master AD Master DMP 設定 JSON BatchA DMPDMP CSV Vertica クラスタ CORE DB Vertica Sync 参照DB （PostgreSQL） Refdb To Vertica Daily Batch Syncid To Verticca User Attribution To vertica Cross Device Update Batch S3 （前日分） メンテナンス制約との闘い いろんな機能から 参照されて・・・
- 38. 38 リソースプール検討の話 並列数や、CPU/メモリ等で制御はしてみたがコントロールは簡単ではない サービス毎にスケールアウト戦略がとりづらい・・・ USER A （CPU25%） ロングクエリ実行 USER B （CPU25%） ロード実行 一般User ショートクエリ General Pool パラレルプロセス数 Memory 同時実行可能数 CPU 50% Pool for USER A パラレルプロセス数 Memory 同時実行可能数 CPU 25% Pool for USER B パラレルプロセス数 Memory 同時実行可能数 CPU 25%
- 42. 42 機能毎に必要な要件を整理 NO 提供I/F 機能名 CRUD データ更新頻度 並列事項数 実行タイミング サービス・機能例 対象サブクラスタ C R U D 01 画面 アドホック検索 － 〇 － － 90分内(ニアリアル) N 常時 A 画面検索用 Subcluster 1 02 レポート＋フィルタ － 〇 － － 前日 M 常時 B 画面検索用 Subcluster 1 03 レポート － － － － 前日 N 常時 C,D (不要) 04 マスタ管理 〇 〇 〇 〇 － N 常時 E 画面更新処理用 Subcluster 4 05 バッチ 処理系バッチ(ニアリアル) 〇 〇 〇 〇 － 設定数 定時 F バッチ用 Subcluster 3 処理系バッチ(日時) 〇 〇 〇 〇 － 設定数 定時 G バッチ用 Subcluster 3 06 READ系バッチ － 〇 － － － 設定数 定時 H バッチ用 Subcluster 3 07 レポート生成 － 〇 － － － 設定数 定時 I カスタムレポート用 Subcluster 2 08 API 単一テーブルAPI － 〇 － － 90分内(ニアリアル) N 常時 K API用 Subcluster 5 09 集計データAPI － 〇 － － 前日 N 常時 API用 Subcluster 5 10 ローデータAPI － － － － 前日 N 常時 － (不要)
- 44. 44 • 事業の伸長と拡張設計は大事 • でも、運用しないと分からないことが多い • 利用状況は調査できるようにしておこう！ SQLのログやアクセスログだけでは不十分 まとめ
- 45. 45 • メンテナンス制約との闘い。しかし止められないシステム • アクセスバーストによる負荷増、サービス間での影響 • データ量依存によるクラスタ増（コンピュートとストレージが一体） • ライセンス（初期データ設計のミスで過剰データ量） • ファシリティ電源容量足りへん問題 • データ構造の再設計にかかる時間と容量が足りない・・・ これらの課題いくつかは運用でカバーしてきたが そろそろ疲れてきたのである 長く運用してくると出てくる課題たち
- 47. 47 次の基盤を比較、調査検証した結果、AWS上で稼働する「Vertica EONモード」を採用。 NO 基盤名 a b c d e f g 備考 1 オンプレミス Vertica Enterpriseモード △ 〇 ✖ ✖ 〇 △ ✖ リソースを分割できず。 2 オンプレミス RDB ✖ 要件をクリアできず 3 クラウド Vertica EONモード 〇 ◎ ◎ ◎ △ 〇 〇 採用。 4 クラウド Vertica Enterpriseモード 〇 〇 〇 〇 〇 △ ✖ リソースを分割できず。 5 クラウド（DWH） 〇 ✖ インスタンス費が高額。 6 クラウド（MapReduceソリューション） ✖ 処理速度に不安。クロデバ分析利用。 調査検証内容 (a) 要件クリア (b) イニシャル・ランニング費用 (c) 環境構築コスト (d) スケールアウト/イン/アップ/ダウン (e) 単一/並列稼働時の性能 (f) 運用/対障害時のオペレーション (g) 将来的なシステム拡張性 上記課題を解決するソリューションを模索 比較検討基盤 (1) オンプレミス Vertica Enterpriseモード (2) RDBMS (3) AWS Vertica EONモード (4) AWS Vertica Enterpriseモード (5) DWH (6) Mapreduce ＋ S3
- 49. 49 アーキテクチャー比較 Enterpriseモード（従来アーキテクチャー） AWS S3 ROS用ボリューム EC2 EBS ROS用 ローカル ボリューム ノード① EC2 EBS ROS用 ローカル ボリューム ノード② EC2 EBS ROS用 ローカル ボリューム ノード③ EC2 EBS ROS用 ローカル ボリューム ノード④ EC2 EBS ROS用 ローカル ボリューム ノード⑤ 計算ノードとストレージの役割をセットでノード構成。 構成単位のノードを追加することでスケールアウトを実現。 Eonモード（新アーキテクチャー） 計算ノードとストレージを分離し、計算ノードのみ追加で スケールアウトを実現。 特徴 • 様々なインフラ環境にデプロイ可能（オンプレ、仮想環境、クラウド環境） ※Eonモードは、AWS環境とPure Storage環境（オンプレ）のみサポート（2019年9月現在） • 常に高いSLAを必要とする要件に最適なアーキテクチャー（繁忙期と閑散期の切れ目がないユ ースケースに最適） • 広範囲の対象データを高速処理する必要がある要件に最適なアーキテクチャー（すべ てのデータを高速ストレージにストアするため） EC2 With Storage Cache ノード① EC2 With Storage Cache ノード② EC2 With Storage Cache ノード③ EC2 With Storage Cache ノード④ EC2 With Storage Cache ノード⑤ 特徴 • 繁忙期などの需要増加に合わせて迅速に計算ノードを追加可能（クラウドコスト削減 ） • 計算ノードを追加時のデータリバランスは不要 • サブクラスタ機能（計算ノードグループ）を利用することでSLAに合わせた設計が可能 • 同時実行処理を更に強化したクランチスケーリング機能 • 安価なAWS S3を利用することでストレージ費用を削減 • 高速分析処理が必要なデータ用にインテリジェントキャッシュ機能を提供（S3への 処理遅延を補完） 処理 リソース拡張 処理 リソース拡張
- 51. 51 初回キャッシュ作成時は、Vertica Enterpriseモードより約179％性能劣化、 DEPOTキャッシュ構築後は、2.61％性能向上でクエリを処理。 DEPOTキャッシュ後のキャッシュヒット率は100％となり、Enterpriseと同性能を実現。 Node1 Node2 Node3 Node4 B A C D DEPOT キャッシュ 必要なデータ キャッシング 4 Shard の場合 Shard A 利用 Shard B 利用 Shard C 利用 Shard D 利用 Shared storage S3
- 52. 52 シャード/ノード数を変え、単実行で実施した結果 DEPOTキャシュの動きと 単実行速度を確認 ⇒ DEPOTキャッシュ構築時は179％性能劣化が見られる。初回のみキャッシュ構築時。 ⇒ DEPOTキャッシュ構築後にデータの整理を実施。その間にアクセスが発生した場合はさらに性能が劣化290％の劣化が見られる。 ⇒ DEPOTキャッシュ構築後は2.61％性能向上が見られる。 DC内オンプレミス環境 カスタムレポートクエリ実施 Vertica EONモード環境 カスタムレポートクエリ実施 キャッシュ無し(構築) キャッシュ構築後整理中 キャッシュ有り 42.2s / トランザクション 118s / トランザクション 165s / トランザクション 41.1s / トランザクション ⇒ ノード追加時DEPOTキャッシュ作成。オーバーヘッドを0にする！
- 54. VerticaEONモードの導入
- 55. 55 VerticaEON 導入にあたって 常時アクセスが発生しうる機能と、 決まった時刻にのみアクセスが発生 する機能のデータソースとして導入 EON提供機能 要件 対処方法 • SSAPI(APIを用いたデータ提供) • データエクスポート(決まった時間 にデータを集計、出力)
- 56. 56 VerticaEON 導入にあたって 常時アクセスが発生しうる機能と、 決まった時刻にのみアクセスが発生 する機能のデータソースとして導入 EON提供機能 要件 対処方法 クラスタをスケールさせ、過不足なく 稼働させたい 要件① 特定ノード障害時のサービス影響をな くしたい 要件② • SSAPI(APIを用いたデータ提供) • データエクスポート(決まった時間 にデータを集計、出力)
- 57. 57 VerticaEON 導入にあたって 常時アクセスが発生しうる機能と、 決まった時刻にのみアクセスが発生 する機能のデータソースとして導入 EON提供機能 要件 対処方法 クラスタをスケールさせ、過不足なく 稼働させたい 要件① 特定ノード障害時のサービス影響をな くしたい 要件② • SSAPI(APIを用いたデータ提供) • データエクスポート(決まった時間 にデータを集計、出力) EONのサブクラスタ機能を利用 対処① ノードの前にLBを設置し、耐障害性を 担保 対処②
- 58. 58 VerticaEON 導入イメージ • プライマリクラスタ1 : セカンダ リクラスタn の構成 • セカンダリクラスタは、用途ご とにサブクラスタを分ける(常時 起動用、バッチ実行時用… etc) • 必要に応じたスケールイン/スケール アウトを実現(対処1) • 各クラスタの前にNLBを置くことで、 アクセスを分散させ、ノードに対す る耐障害性を担保(対処2)
- 59. 59 VerticaEON 導入イメージ • プライマリクラスタ1 : セカンダ リクラスタn の構成 • セカンダリクラスタは、用途ご とにサブクラスタを分ける(常時 起動用、バッチ実行時用… etc) • 必要に応じたスケールイン/スケール アウトを実現(対処1) • 各クラスタの前にNLBを置くことで、 アクセスを分散させ、ノードに対す る耐障害性を担保(対処2) 導入として左部を構築
- 60. 60 VerticaEON 構成図 1. プライマリクラスタ(R/W)1つ、 セカンダリクラスタ(R only)1つ 2. 各クラスタは3 ノードで構成 3. 各クラスタに対するアクセスは、 NLBを用いてバランシング 4. クエリの処理高速化のために、 DEPOTキャッシュを毎晩実施 5. 環境はCloudFormationで構築
- 61. 61 VerticaEON 構成図 耐障害性 1. クラスタ内のノードに対する障害 は、3ノードで冗長化 2. クラスタが丸ごと落ちた場合は、 CloudFormationを用いて、別サ ブネットでクラスタを再構築 ※データはS3に保存してあるため、 クラスタへの障害影響を受けない
- 62. 62 VerticaEON Version9 -> Version10へ Vertica v10.0.1 にて、Large Clusterの 機能が更新 ※Large Cluster: Control nodeを複数用意することで、 大量ノード管理に伴う処理負荷を下げる機能 旧:サブクラスタ内にControl nodeが必ず あるとは限らない 新: サブクラスタ内にControl nodeが必ず 一つはある ∴ Primaryのサブクラスタが故障しても、 Secondaryのサブクラスタのみでサービ ス維持が可能に！ https://www.vertica.com/docs/10.0.x/HTML/Content/Authoring/NewFeatures/10.0/10.0.1/Eon.htm?tocpat h=Vertica%2010.0.x%20New%20Features%20and%20Changes%7CNew%20and%20Changed%20in% 20Vertica%2010.0.1%7C_____5#4 v9 -> v10へのバージョンアップを実施
- 63. 63 VerticaEON VersionUP 作業イメージ • Blue/Green デプロイ (あらかじめv10環境を作成して おき、リリース作業はアクセス の切り替えのみ実施) 所感 • Blue/Green デプロイのため、リ リース作業が楽 • CloudFormationで環境を作成し ているため、リリース時に障害 が起きた場合でも環境の再構築 が容易 • データはS3で管理しているため、 移行が容易(s3 sync)
- 64. 64 VerticaEONを使ってみて 1. オンプレミスと違い、自由に スケールイン/スケールアウト 可能 2. v10.0.1以降であればPrimary のサブクラスタが落ちてもサ ービス継続可能 3. DEPOTキャッシュを用いれ ば処理は十分高速 4. リリース時に気軽に Blue/Green デプロイできる のは、オンプレミスにはない 強み
- 67. Q&A Join the Vertica Academy: academy.vertica.com
- 68. Thank You
- 69. 予備スライド