Transcript

• 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  
• 4. Copyright  (C)  DeNA  Co.,Ltd.  All  Rights  Reserved.   4  
• 5. Copyright  (C)  DeNA  Co.,Ltd.  All  Rights  Reserved.   Before  Ver>ca  分析環境   !  ログをHadoopへ格納   !  Hadoop上のデータに対しPig、 Hiveで分析を⾏行行う   5   ４PBのHadoop   クラスタ   ・⼩小さな集計でも時間がかかる   ・短いサイクルで仮説検証を繰り返すことが 難しい  
• 6. Copyright  (C)  DeNA  Co.,Ltd.  All  Rights  Reserved.   Ver>caの導⼊入   !  SQLで⾼高速な集計が可能   !  Facebook,  Zynga,  Twitter等  競合他社での⼤大規 模導⼊入実績   !  低容量量(1Tera  Byte)であれば無料料で使える   6  
• 7. Copyright  (C)  DeNA  Co.,Ltd.  All  Rights  Reserved.   Ver>caを導⼊入したところ   !  アドホックな分析⼯工数の削減   ⁃  数秒から数分で結果を得られる   !  内製BIツールの作成   ⁃  Verticaの⾼高速性を最⼤大限活かすためにBIツールの内 製   !  利利⽤用者の拡⼤大   ⁃  アナリストだけでなくエンジニア、企画も利利⽤用   7  
• 8. Copyright  (C)  DeNA  Co.,Ltd.  All  Rights  Reserved.   Ver>caの利利⽤用推移   8   容量量   台数   2013/08   2013/12   2014/04   2014/10   2015/01   評価版   1TB×4   5台   3台×4   11TB   18TB   25TB   9台   14台   性能の基礎 評価   新規サービ スに導⼊入   新規サービスで の利利⽤用拡⼤大   既存サービス での利利⽤用   2015/03   サーバスペック  :    CPU  16コア、memory  128GByte、network  1Gbpsx2(bonding)    　 　 　 　 　4TB  7.2K  rpm  x12  (RAID  10)  
• 9. Copyright  (C)  DeNA  Co.,Ltd.  All  Rights  Reserved.   Ver>caとHadoopの使い分け   9   ・新規サービス中⼼心   ・単純なSQLでの集計   ・データの⼤大きな 　 　 既存サービス   ・複雑な機械学習   それぞれ適した場⾯面で使⽤用  
• 10. Copyright  (C)  DeNA  Co.,Ltd.  All  Rights  Reserved.   Ver>caへのデータ格納経路路   10   Event   log   DB   (MySQL)   Log   Collector  
• 11. Copyright  (C)  DeNA  Co.,Ltd.  All  Rights  Reserved.   11   導⼊入初期にはまったこと  
• 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