1. Copyright
(C)
DeNA
Co.,Ltd.
All
Rights
Reserved.
DeNAでのVertica運⽤用
March
25,
2015
Shota
Suzuki
Analy;cs
Solu;on
Gr.
Analy;cs
Infra
Dept.
DeNA
Co.,
Ltd.
2. Copyright
(C)
DeNA
Co.,Ltd.
All
Rights
Reserved.
⾃自⼰己紹介
! 鈴鈴⽊木
翔太
⁃ 所属
• システム本部分析基盤部分析ソリューションGr
! 経歴
⁃ 2013年年に新卒でDeNAに⼊入社
(新卒2年年⽬目)
⁃ ⼊入社以来Vertica関連の調査、運⽤用、ツール開発
2
3. Copyright
(C)
DeNA
Co.,Ltd.
All
Rights
Reserved.
アジェンダ
! Vertica導⼊入の経緯
! 利利⽤用の仕⽅方
! 導⼊入初期にはまったこと
! 利利⽤用拡⼤大に伴い⽣生じた問題
3
12. Copyright
(C)
DeNA
Co.,Ltd.
All
Rights
Reserved.
公式ドキュメント以外ほぼ情報がない
! 当時国内にほとんど情報はなかった…
⁃ BigQueryやRedshiftについてはググれば情報はか
なりでてくるのに
⁃ 海外ではカンファレンスも開催されている
! 最初はCommunity
Editionで保守もなくひたす
らドキュメントを読み検証してました
! はまりどころ多数
12
13. Copyright
(C)
DeNA
Co.,Ltd.
All
Rights
Reserved.
データの投⼊入時に注意すること
! ⼤大量量のデータ投⼊入でINSERTは遅いのでCOPYか
INSERT
SELECTを使う
! データ投⼊入時に⽋欠損が⽣生じることがある
⁃ 型が⼀一致していないレコードは捨てられてしまう
⁃ ABORT
ON
ERRORをオプションとしてつけるこ
とによりエラーの検知
⁃ COPY
REJECTED
DATA
and
EXCEPTIONSなど
をつかいデバッグを⾏行行う
13
14. Copyright
(C)
DeNA
Co.,Ltd.
All
Rights
Reserved.
テーブル定義変更更時の注意事項
! カラムをテーブルに追加したい
⁃ 末尾にしか追加できません
! 型の変更更を⾏行行いたい
⁃ 分散キー(segment
key)に⼊入ってるカラムの型は
変更更ができない
• プロジェクションを作り直すことにより分散キーから外してALTERを⾏行行う
• 新しくテーブルを作り直しSELECT
INSERTでデータを⼊入れ直すときにキ
ャストを⾏行行う
14
15. Copyright
(C)
DeNA
Co.,Ltd.
All
Rights
Reserved.
利利⽤用者の拡⼤大に伴い様々な問題発⽣生
! 増え続けていくデータ
! リソースが⾜足りずクエリが実⾏行行できない
! メタデータへのアクセスが異異常に遅い
! サービスの成⻑⾧長につれて遅くなるクエリ
15
16. Copyright
(C)
DeNA
Co.,Ltd.
All
Rights
Reserved.
16
各⽉月でのスキーマ毎のデータ量量
増え続けていくデータ
17. Copyright
(C)
DeNA
Co.,Ltd.
All
Rights
Reserved.
なぜ使⽤用容量量が増え続けるのか
! アナリストが⾃自主的に容量量に気を配ってくれない
⁃ データの取り込みをしている⼈人と利利⽤用者が違って
いるのであまり容量量を意識識しない
⁃ 本来の分析に集中したい
⁃ データ整備に時間をなるべく割きたくない
! Hadoopとは絶対的な容量量が違う
⁃ Hadoopのように全てを⼊入れておけるわけではない
⁃ 保持期限の設定、必要データの選択が必要
17
18. Copyright
(C)
DeNA
Co.,Ltd.
All
Rights
Reserved.
スキーマ、テーブル単位で容量量の⾒見見える化
18
ユーザにどの程度度使ってい
るのか意識識してもらう
・急激にデータが増える
ことは減った
・どのデータをどの程度度
持つのか利利⽤用ユーザが考
えるようになった
19. Copyright
(C)
DeNA
Co.,Ltd.
All
Rights
Reserved.
ある⽇日から突然JOBが
実⾏行行できなくなったん
ですけど・・・
19
20. Copyright
(C)
DeNA
Co.,Ltd.
All
Rights
Reserved.
リソースが⾜足りずクエリが実⾏行行できない
! 導⼊入からしばらくはリソースの管理理をあまり⾏行行
っていなかった
! あるクエリが⻑⾧長時間リソースの占拠をしており
、他のクエリはキューに⼊入ったままで実⾏行行でき
なくなっていた
! ⼀一⼈人が無茶茶なクエリを実⾏行行すると全体に迷惑が
かかる
20
21. Copyright
(C)
DeNA
Co.,Ltd.
All
Rights
Reserved.
リソースの制御により暴暴⾛走を防ぐ
! Resource
Poolによる制限
⁃ メモリ、並列列度度、実⾏行行時間、優先度度等を管理理できる
⁃ 独⾃自に定義してどのユーザに割り当てるのか設定可
能
⁃ 設定を⾏行行わないとdefault
poolが使⽤用される
! ユーザ単位でもメモリの量量や実⾏行行時間は別途制
御することができる
21
Resource
Poolを適切切に設計することで多
くのユーザに安全に使ってもらえる
22. Copyright
(C)
DeNA
Co.,Ltd.
All
Rights
Reserved.
Resource
Pool設計の考えかた
! Resource
Poolの数が増えすぎるとリソースの管
理理が難しくなるのであまり増やしすぎない
! メモリの最⼤大使⽤用量量、キューへのたまり具合を
⾒見見ながらチューニングを⾏行行う
! 重要なクエリについてはリソースをあらかじめ
わけて確保することにより実⾏行行を保証する
22
23. Copyright
(C)
DeNA
Co.,Ltd.
All
Rights
Reserved.
dnやdtでスキーマ、
テーブル⼀一覧を出すの
が異異常に遅い
23
24. Copyright
(C)
DeNA
Co.,Ltd.
All
Rights
Reserved.
メタデータへのアクセスが遅かった原因
! Community
Edition時にパフォーマンス向上を
期待してパラメータの変更更を⾏行行っていた
⁃ MaxROSPerStratum、SortWorkerThreads
! これが原因で平常時でもCPUが使われておりパ
フォーマンスの劣劣化に
! デフォルトの設定に戻したところ平常時のCPU
使⽤用率率率は下がりメタデータへのアクセス速度度改善
! Change_̲under_̲support_̲guidanceを変える場
合は悪影響のおそれがあるので相談した⽅方が良良い
24
25. Copyright
(C)
DeNA
Co.,Ltd.
All
Rights
Reserved.
徐々に遅くなっていくクエリ
! サービスリリース当初はデータも⼩小さく⾼高速に集
計が⾏行行えていた
! リリース後ユーザ数の増加、蓄積されたデータ量量
の増加により徐々に定常クエリが遅くなっていく
! アドホックな分析をするにもデータがでかく即座
に結果をえられない
25
データが⼤大きくなってくると
何も考えず作ったテーブルでは限界に
26. Copyright
(C)
DeNA
Co.,Ltd.
All
Rights
Reserved.
プロジェクション
! Verticaではクエリを⾼高速化するためにプロジェ
クションを理理解しておくことが重要
! 並び順、分散キー、圧縮の⽅方法を指定すること
が可能
! ⼀一つのテーブルに対して複数のプロジェクショ
ンが作成できる
! 特定のクエリに特化したプロジェクションを作
成することでクエリの⾼高速化が⾏行行える
26
27. Copyright
(C)
DeNA
Co.,Ltd.
All
Rights
Reserved.
プロジェクションの改善
! テーブル数が多くすべてを⾒見見るのはつらいので、
遅いクエリに対してプロジェクションの作成を⾏行行う
! Explainの結果を⾒見見ながらプロジェクションを考え
る
⁃ SORT,
SEGMENT,
ENCODINGの指定
⁃ ⼩小さなマスターテーブルはJOINを考え全ノードに分
散させずにおく
⁃ ENCODINGは絞り込みに使うカラムをRLEに
27
28. Copyright
(C)
DeNA
Co.,Ltd.
All
Rights
Reserved.
Database
Designer
! データの特性、実⾏行行されるクエリから良良さそう
なプロジェクションを⾃自動で作成できる
! 全てを⼿手作業で作成するのは難しいし、時間が
かかりすぎるのでDatabase
Designerの利利⽤用
! 作成された物についておかしな物がないか⼀一度度
確認してから本番にデプロイする
28
Database
Designerの利利⽤用によって
プロジェクションの作成が簡単に
29. Copyright
(C)
DeNA
Co.,Ltd.
All
Rights
Reserved.
監視の重要性
! 利利⽤用者も管理理者もまだなれていないシステム
! バッドノウハウ的な物がまだあまりないのでど
こで問題が起きるかわからない
! 問題発⽣生時にすぐ調査できるように様々な⾓角度度
から情報を集めておいたほうがよい
29
30. Copyright
(C)
DeNA
Co.,Ltd.
All
Rights
Reserved.
DataCollectorによる情報の収集
! Vertica⾃自⾝身で様々な情報の取得を取得している
! システムテーブルの中⾝身はDataCollectorで取得
した情報を参照している物が多い
! 保存期間が短いので適宜のばす
⁃ SET_̲DATA_̲COLLECTOR_̲POLICY
! システムテーブルは内部ではファイルアクセス
をしており遅いので⼯工夫が必要
⁃ 別途テーブルにコピーして⾼高速にアクセス
30
31. Copyright
(C)
DeNA
Co.,Ltd.
All
Rights
Reserved.
その他の監視
! スロークエリの⼀一覧を出し常に改善を⾏行行う
! ベンチマーククエリを定期実⾏行行してクラスタに
負荷がかかっていないか調べる
! CPU,
memory,
IO,
network
⁃ Sarでデータの取得
⁃ 負荷調査
31
32. Copyright
(C)
DeNA
Co.,Ltd.
All
Rights
Reserved.
まとめ
! データが必要以上に増えすぎないような⼯工夫
⁃ どのサービスでどのくらいの量量を使っているか⾒見見え
る化を⾏行行い、利利⽤用ユーザにも注意を払ってもらうこ
とが必要
! リソースを制御することで安全に多くの⼈人が使える
⁃ Resource
Poolを適切切に設計することでいけてない
クエリの与える影響範囲を限定的に
! パラメータ変更更による悪影響の恐れ
⁃ Change_̲under_̲support_̲guidanceを変更更するとき
には事前に相談をした⽅方がよい
32
33. Copyright
(C)
DeNA
Co.,Ltd.
All
Rights
Reserved.
まとめ
! プロジェクション作成によるクエリの⾼高速化
⁃ 遅いクエリにはプロジェクションを作成してくク
エリを⾼高速化できる
⁃ Database
Designerを使⽤用すると⼿手軽にプロジェ
クション作成ができ便便利利
! 問題発⽣生時に調査しやすいようデータはいろい
ろな⾓角度度から集めておく
33