Recommended
Recommended
More Related Content
What's hot
What's hot (20)
Similar to Vertica eonモードの活用シーン
Similar to Vertica eonモードの活用シーン (20)
More from Kaito Tonooka
More from Kaito Tonooka (15)
Vertica eonモードの活用シーン
- 3. 計算ノードとストレージの分離（ディカップリング） でパフォーマンス＆運用性の向上 リニアにスケールするインフラストラクチャー ワークロードの変化、季節性、またはロードの ピーク時間にあわせて伸縮自在にスケーリング 分析ワークロードの分離 特定のノード群をサブクラスターと指定してワーク ロードを分離し、マルチテナンシーをサポート データベース運用の簡素化 ノードリカバリの改善、優れたワークロードバラン シング、より高速なプロビジョニングを提供 計算ノードの休止 計算ノードが不要なときに休止状態にすることで、分析 能力をより効率的に停止および供給 Vertica Eonモード 共有ストレージ Compute Node Compute Node Compute Node Compute Node Compute Node Cache Cache CacheCache Cache Google CLOUD PLATFORM 3
- 4. パブリッククラウド or オンプレミス？ ◼ トータルコスト ◼ “ノイジーネーバー”問題 ◼ 新しいスキルが必要 ◼ マイグレーション ◼ ガバナンスリスク– 「シャドウIT」 4 V.S. 長所 短所 最適な環境を選定し、柔軟な設計ができることが重要 ◼ 可変ワークロードのリソース制御 ◼ 規模の経済 ◼ 高可用性と冗長性 ◼ エコシステム ◼ スピードとコラボレーション
- 5. ノード2 ノード3ノード1 ノード１ EC2 EC2 with Storage Cache ■Enterpriseモード（従来アーキテクチャー） 計算ノードとストレージの役割をセットでノード構成。構成単位 のノードを追加することでスケールアウトを実現 要件に応じて自由に選択できるアーキテクチャー EBS ROS用 ローカル ボリューム ノード2 EC2 EBS ROS用 ローカル ボリューム ノード3 EC2 EBS ROS用 ローカル ボリューム EC2 EBS ROS用 ローカル ボリューム EC2 EBS ROS用 ローカル ボリューム ノード4 ノード5 EC2 with Storage Cache EC2 with Storage Cache 処理 リソース 拡張 EC2 with Storage Cache EC2 with Storage Cache ノード4 ノード5 処理 リソース 拡張 ■Eonモード（新アーキテクチャー） 計算ノードとストレージを分離し、計算ノードのみ追加でス ケールアウトを実現。 共有ストレージ ヘビークエリが他の ユーザーの処理に悪 影響 ノード追加時 データ再分散に 時間が掛かる 同時実行処理す うをリニアに増 強したい ストレージコス トを削減したい 均一なワークロードと固定されたパフォーマンスの要件向け のアーキテクチャ 共有ストレージから独立した計算ノードスケーリングするこ とで、クラウドの経済性と動的なワークロードを実現 ライセンスはそのままで アーキテクチャを切り替え可能 5 ストレージの サイジングを 柔軟にしたい 異なるスペック のサーバーを 利用したい 計算ノードの アップグレード や入れ替え
- 7. Node Node NodeNode ケース１）繁忙期に処理能力を増強 計算ノードを拡張（高速スケーリング＆リバランス不要） Node Node NodeNode 追加ノードをすばやくスピンアップして、実行 する必要があるときに驚異的な高速パフォーマ ンスを維持することが可能： • 同時実行クエリの強化 • 同時ロードの強化 それぞれのアクティビティにはそれぞれ 独自のサブクラスターが用意されており、 必要に応じてジョブに最適なインスタン スタイプをプロビジョニング SUN MON TUES WED THU FRI SAT x1 x2 x4 コンピューティング キャパシティー データロード アドホック分析 四半期クローズレポート ダッシュボード 計算ノード 追加 削除 7
- 8. スプリットブレイン問題：セカンダリサブクラスタ 8 プライマリサブクラスタのみ、クォーラムに参加 します。 # primary nodes UP >= 50% x # all primary nodes + 1 Nodes in SECONDARY subclusters do not participate in Quorum. Therefore, they can be dropped without impacting the overall cluster. セカンダリサブクラスタは、クォーラム に参加しません。クラスター全体に影響 を与えることなく削除できます。
- 9. サブクラスター 9 Compute Node cache Compute Node cache Compute Node cache Compute Node cache Compute Node cache Compute Node cache Compute Node cache Compute Node cache プライマリサブクラスター（制御権あり） - 起動に時間が掛かる - 51％以上のノードを稼働する必要あり - カタログの更新を管理 - データロードとカタログ管理に最適 - 常時稼働の用途 - 少なくとも1つは稼働する必要あり セカンダリサブクラスター（制御権なし）: - カタログの永続化がなく、デプロイが高速化 - クエリー（読み取り）に最適 - エフェメラル（必要に応じて追加） - より速くコミットする
- 10. Eonモード展開パターン 10 Compute Node cache S3 Bucket Compute Node cache Compute Node cache Compute Node cache Compute Node cache Compute Node cache Compute Node cache Compute Node cache Compute Node cache Compute Node cache Compute Node cache Compute Node cache Compute Node cache Compute Node cache Compute Node cache Compute Node cache Compute Node cache Compute Node cache Data Load (ETL) Dashboard Application Support Analytics and ML プライマリサブクラスタ クラスターのバックボーンと して常時稼働。 セカンダリサブクラスタ すべてのクエリ操作に使用され、 必要に応じて起動/削除。
- 11. 事例：The Trade Desk インターネット広告のRTB（Real-Time Bidding）の激しい競争業界で成功す るために必要なスケーラビリティ、安定性、パフォーマンスを提供 課題 ▪ 世界最大のデータドリブン型のデジタル広告キャンペーンサービ スを提供するにあたり、スケーラブルで、柔軟性があり、高速で、 管理しやすい分析プラットフォームが必要でした。 結果 ▪ 費用効率の高いクラウド導入（容易なキャパシティー計画） ▪ 容易な管理機能（セルフサービス機能やWebUIなど） ▪ 毎日40,000レポートの生成 ▪ 大容量データ、パフォーマンス、多様なワークロードを安定処理 ▪ シームレスな統合のためのSQLインターフェイスとHadoopファイ ル形式のサポート ユーザーの行動履歴を分析し、 適切な広告を表示 11 広 告 主 代 理 店 タ ー ゲ ッ ト TradeDesk DSP (Demand-Side Platform） 広告 配信 配信
- 12. • １時間あたり十億データをロード • ２つのEnterpriseモードのクラスタ 50ノード/2PB/オンプレミス • １つのEonモードのクラスターM 256ノード/8 PB/AWS環境 • DBA３人で大規模Verticaを管理 • 1秒あたり1,000万の広告サ ポートし、購入者と販売者 をマッチング • 毎日40,000レポートを安定 して生成 RTB分野のバイヤーをサポートし、ブランドの 効率的なターゲティングで広告費用を最適化。 しかし、広告費用の支出はクライアントのタス クの一部に過ぎず、広告効果の透明性も鍵とな ります。コンバージョンまでレポートします。 上記の厳しい要件をVerticaは解決してくれまし た。 技術的な解決 評価ビジネスバリュースケーラビリティ 12
- 14. ケース2）確実なパフォーマンスのSLAが必要 サブクラスタを使用したワークロードの分離＆同時実行処理の強化 Node Node NodeNode データサイエンス（機械学習など）ダッシュボード データロード 月間レポート（バッチ処理） Node Node NodeNode Node Node NodeNode Node Node NodeNode 14
- 15. 同時実行処理の増強 15
- 16. アーキクチャ概要と機械学習アプローチ 過去のログデータ （デバイス機器など） • データベース • CRM • 製造データ （80以上のデータソース） データ 取り込み 予兆検知モデ ルに基づいた アラート メンテナンス の計画 Philips バリュー データ分析 （機械学習） 分析ツール＆手法 故障の予兆がある医療機器をアラート表示 ライブのログデータ （医療機器のログ） 16
- 17. Node Node Node オブジェクトストレージ（S3など）にデータを維持 し、ホットデータとして利用する最近のデータは キャッシュに保存。 キャッシュ上にデータがない場合、オブジェクトス トレージに直接クエリ処理を実行 Node ケース３）オブジェクトストレージでコスト削減 ストレージコストを抑えてホットデータ中心に分析 Aug-18 2017 Jul-18 Aug- 18 Aug- 18 Aug- 18 Aug- 18 Amazon S3とEBS コスト差 約5倍 ホットデータ以外はオブジェクトストレージを 利用することでコスト削減 17
- 18. Node NodeNode ケース３）応用編：データレーク用途 Aug-18 2017 Jul-18 Aug- 18 Aug- 18 Aug- 18 Verticaノードライセンス ＋ オブジェクトストレージ ＝ パフォーマンスよりもキャパシティーを重視 18 ■特徴 • Verticaの標準分析機能（機械学習など）を提供 • ストレージの柔軟な利用 • １ノード構成からスモールスタート可能
- 19. AWSベースのコスト比較 前提条件 ▪ データサイズ 100TB ▪ 利用状況 - 通常運用時、ダッシュボード用途のみ： 6ノード必要 - 四半期末の際、レポートや分析用途：30 ノード必要 $0 $10,000 $20,000 $30,000 $40,000 $50,000 $60,000 $70,000 $80,000 $90,000 Enterprise モード Eon モード (固定) Eon モード (変動) $$$per3monthquarter 3カ月のコスト比較（AWS） storage compute 19 AWS Resource Costs Resource Monthly Cost r4.4xlarge $766.76 EBS per GB $0.100 S3 per GB $0.023 19
- 20. 統合分析ウェアハウス 分散したデータレイク上のデータを統合 データウェア ハウス Hadoop Amazon S3 外部テーブル オブジェクト ストレージ 外部テーブル データレイク（Hadoop/オブジェクトストレージ） Flex Table通常テーブル 構造化データ 半構造化データ Eonモード 共有ストレージ データレイク
- 21. ロードマップ 21
- 22. ロードマップ ▪ コア技術 - クエリの処理を高速化する「クランチス ケーリング」 - 大規模クラスター - ライフサイクルマネジメント– ノードの管理 - Spreadの負荷を軽減する3番目のネットワーク チャネル - 確定的なサブスクリプションによるレイ アウトによるデポ効率化 - サブクラスターのリソースプール設計 - TMとデータロードのペアリング
- 23. ロードマップ ▪ 運用の柔軟性 - セカンダリなしでプライマリのリバイブ - 必要に応じてサブクラスターを追加 - 異なるサイズのクラスターにリバイブ - Shard数の変更
- 24. ロードマップ ▪ 使いやすさ - サブクラスターの管理 - ロードバランサーグループの管理 ▪ 拡張性 - EonモードのVerticaをより多くのオブ ジェクトストレージプラットフォーム
- 25. ありがとうございました。 25