[VerticaUnity]700億件のリアルタイム分析の実現と運用の実態

VerticaUnity2021登壇資料
大量のマーケティングデータ分析アーキテクチャの話

Transcript

1. 700億件のリアルタイム分析 の実現と運用の実態 みらい基盤課 上原 賢也 / 山本 瑛治 株式会社イルグルム
2. 0. 紹介 1. 広告効果測定とは？ 2. ヒト軸分析をどうやって実現したのか？ • ヒト軸分析を実現するための要素 • ヒト軸分析を実現するための 「分析」基盤/インフラ課題 • 全てを満たすことができた 「分析」基盤/インフラ 3. 導入から5年しての運用の実態 • 製品の選定ポイントと比較 • 学習コスト • 運用コスト 4. Veritica 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）
5. 広告効果測定ツール売上シェアNO.1「アドエビス」
6. 広告効果測定？アドテク? 効果測定領域とそれを取り巻くテクノロジーについて
7. 7 アドテクノロジー メディア 広告を表示する領域を提供 広告配信 メディアに、場合によってはある ロジックに従って広告を配信 効果計測 配信された広告がどの程度の効果、 収益を上げたのかを評価 略称 アドテク、アドテック、など
8. 8 広告配信 サービス キュレーション サービス 広告代理店 および ツールベンダ ツールベンダ
9. 9 アドテク業界で生き残るためには 最新の技術が必要とされる アドエビスも常に新たな技術を 取り入れていかないといけない
10. アドエビスとは？ マーケティングの今
11. 11 計測 広告効果測定 アクセス解析 View計測 LPO クリック計測/SEO計測 経路分析 動画広告 記事広告 ディスプレイ 広告 コンテンツ マーケティング 純広告 自然検索 アフィリエイト 広告 リスティング 広告 リターゲティン グ広告 ダイレクト SNS LP TOP コンテンツ CV 活用 外部連携 BI/レポーティング MR/CRM/SFA 広告配信/運用管理 リサーチ/モニター 3rd Party Data EC/通販支援ツール TV/オフライン施策 分析 レポーティング 施 策 軸 ユ ー ザ ー 軸 デモグラフィック カスタマージャーニー 分析 チャネル別集計 アトリビューション 分析 アドエビスはあらゆるマーケティングの効果をメディア・デバイス・代理店を横断して測定、 マーケティング活動の成果最大化をサポートするサービスです。 「アドエビス」が提供する３つのソリューション
12. 12 これまでとこれからの施策評価
13. 13 60% 40% スマートフォンの普及によるマルチデバイス化 クロスデバイス コンバージョン 単一デバイスで コンバージョン （出典） criteo「2016年度下期クロスデバイス・コマースレポート」 クロスデバイス
14. 14 不明ユーザー 同一ユーザー IDで特定 それぞれのデバイスでログインしていれば、 同一人物だとシステム上扱える これまでのクロスデバイス分析
15. 15 不明ユーザー 同一ユーザー IDで特定 それぞれのデバイスでログインしていれば、 同一人物だとシステム上扱える これまでのクロスデバイス分析 しかし、複数デバイスで確実に ログインしてくれるようなサイトは少ない
16. 16 不明ユーザー 同一ユーザー 同一ユーザー 機械学習で 同一ユーザーを類推 これまでのクロスデバイス分析
17. データ×組み合わせ 爆発 17
18. 18 媒体軸分析 ヒト軸分析 軸の件数 媒体の数 ※広告の場合、約150万程度 行動パターン ※組み合わせ爆発発生 データ量 10万件～1000万件程度 ※１日単位の事前集計済データ 100億件〜 ※事前集計無しの全行動履歴 要求される 処理速度 数秒〜数十秒 新たな課題 - 媒体軸とヒト軸のデータの違い
19. 19 全行動履歴を ヒト軸で リアルタイムに どのように実現したか？
20. 20 1.行動パターンに合致する「ヒト」の抽出 （軸の件数） 2.全行動履歴のリアルタイム集計 （データ量） 3.リニアなスケーラビリティ （処理速度）
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.リニアなスケーラビリティ × ◦ ◦ ◦ 社内にあったデータ分析基盤では全てを解決できない
26. 26 1.行動パターンに合致する「ヒト」の抽出 Match関数 2.全行動履歴のリアルタイム集計 高スループット/低レイテンシ性 3.リニアなスケーラビリティ シェアードナッシング方式による超並列アーキテクチャー
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では捌ききれなかった大量データも高速に集計可能
29. 29 ※約80億レコードの実データを投入 ※クエリ種別、データ容量を変え25パターンのクエリを使用 ※3ノード、5ノード、10ノードにて検証 （参考）導入前の検証結果
30. 30 ログ ファイル 計測 サーバ 全行動履歴データ リアルタイム分析・ 閲覧用 ※数百億レコード 全行動履歴データ 検査/加工/集計 ※数百億レコード ログ ファイル 計測 サーバ … 全行動履歴取得 ※広告閲覧/広告クリック/検索流入/ サイト閲覧/コンバージョンetc… 計測対象ユーザー 計測対象ユーザー Vertica Hadoop Postgre SQL 集計データ閲覧用 ※数百万レコード ※集計データ アドエビス 管理画面 アドエビス ご契約者様 Vertica を導入することで、ヒト軸分析を行えるようになった！ 行動パターンに合致す る「ヒト」の抽出 全行動履歴のリアルタ イム集計 リニアな スケーラビリティ
31. 導入から5年 運用の現場は？
32. 32 増え続けるデータ 増え続ける利用ニーズ 膨れ上がる運用コスト 性能の維持・・
33. 33 データ量増加 100億件→700億件 (顧客分析データのみ) 100億 300億 700億 2017年 2018年 2019年
34. 34 倍々でデータ量 増えてるんですけど
35. 35 ログ ファイル 計測 サーバ 全行動履歴データ リアルタイム分析・ 閲覧用 ※数百億レコード 全行動履歴データ 検査/加工/集計 ※数百億レコード ログ ファイル 計測 サーバ … 全行動履歴取得 ※広告閲覧/広告クリック/検索流入/ サイト閲覧/コンバージョンetc… 計測対象 ユーザー 計測対象 ユーザー Vertica Hadoop Postgre SQL 集計データ閲覧用 ※数百万レコード ※集計データ アドエビス 管理画面 アドエビス ご契約者様 APIデータ 提供 外部データ 取り込み 全アクセス の横断分析 不正アクセ ス傾向分析 調査基盤 もっと早く 柔軟に 成果を上げたい 利用ニーズ増大
36. 36 なんでもできる 魔法のハコ じゃないんだよ
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%
39. データ量増、CPU/メモリに 余裕があっても ノードを追加しないと いけない事態に・・ 39 プロジェクション 増やしたくても DISK容量 足りない・・ CPU /メモリ DISK 処理 リソース拡張 ついでに 電源容量が・・ スケールアウトの課題 ノード① CPU /メモリ DISK ノード② CPU /メモリ DISK ノード③ CPU /メモリ DISK ノード④
40. 40 なんでもできる 魔法のハコ じゃないんだよ
41. 41 データ増による性能劣化の課題 プロジェクション見直し
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 常時 － (不要)
43. 43 対象データ開始日 (何日前) 指定期間 日数 1ヶ月 2ヶ月 3ヶ月 4ヶ月 5ヶ月 6ヶ月 7ヶ月 8ヶ月 9ヶ月 10ヶ月 11ヶ月 12ヶ月 1年前 2年前 未来を含む期間指定 のアクセス 1年前と比較 ※ 件数をヒートマップで表示 データの参照期間、操作履歴を分析
44. 44 • 事業の伸長と拡張設計は大事 • でも、運用しないと分からないことが多い • 利用状況は調査できるようにしておこう！ SQLのログやアクセスログだけでは不十分 まとめ
45. 45 • メンテナンス制約との闘い。しかし止められないシステム • アクセスバーストによる負荷増、サービス間での影響 • データ量依存によるクラスタ増（コンピュートとストレージが一体） • ライセンス（初期データ設計のミスで過剰データ量） • ファシリティ電源容量足りへん問題 • データ構造の再設計にかかる時間と容量が足りない・・・ これらの課題いくつかは運用でカバーしてきたが そろそろ疲れてきたのである 長く運用してくると出てくる課題たち
46. これらの課題を解決するため 基盤リプレースを検討！
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
48. 48 やっぱりVertica手放せない Eonモードがいけてそう
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への 処理遅延を補完） 処理 リソース拡張 処理 リソース拡張
50. 50 新しいレベルでのワークロードの分離と柔軟性
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 Strage S3
52. 52 シャード/ノード数を変え、単実行で実施した結果 DEPOTキャシュの動きと 単実行速度を確認 ⇒ DEPOTキャッシュ構築時は179％性能劣化が見られる。初回のみキャッシュ構築時。 ⇒ DEPOTキャッシュ構築後にデータの整理を実施。その間にアクセスが発生した場合はさらに性能が劣化290％の劣化が見られる。 ⇒ DEPOTキャッシュ構築後は2.61％性能向上が見られる。 DC内オンプレミス環境 カスタムレポートクエリ実施 Vertica EONモード環境 カスタムレポートクエリ実施 キャッシュ無し(構築) キャッシュ構築後整理中 キャッシュ有り 42.2s / トランザクション 118s / トランザクション 165s / トランザクション 41.1s / トランザクション ⇒ ノード追加時DEPOTキャッシュ作成。オーバーヘッドを0にする！
53. 53 ・耐障害性 ⇒ EONは同一ラックに格納を 前提で設計！ ・物理データの再配置 ⇒不要に！キャッシュの クリアとウォームアップは必要 ・柔軟なスケールアップ、アウト ⇒ノード半分落としたらクラス タ落ちるのが難点 ・リソースの分離 ・更新処理と運用が楽に ・ファシリティ地獄からは解放 ・コスト ⇒必要な時に必要な分へ ？
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 デプロイできる のは、オンプレミスにはない 強み
65. 65 ・耐障害性 ⇒ EONは同一ラックに格納を 前提で設計！ ・物理データの再配置 ⇒不要に！キャッシュの クリアとウォームアップは必要 ・柔軟なスケールアップ、アウト ⇒ノード半分落としたらクラ スタ落ちるのが難点 ⇒サブクラスタの機能を用いる ことで、実現可能 ・リソースの分離 ・更新処理と運用が楽に ・ファシリティ地獄からは解放 ・コスト ⇒必要な時に必要な分へ ？ ⇒v10.0.1以降では、Primary のサブクラスタの機能を用い ることで、実現可能 ⇒CloudFormationを用いて環 境を構築し、NLBを用いてアク セスの可用性を高めれば、 AZレベルの障害が起きても素 早いサービス復旧が可能 オンプレミスからEONへのリプレイスを実施予定!
66. 66 求められるニーズに着実に 答えようとする Verticaの進化はありがたい。 最後に・・・
67. Q&A Join the Vertica Academy: academy.vertica.com
68. Thank You
69. 予備スライド