Not Enterpriseな会社でRedshiftを使ってみた

7,973 views

Published on

Published in: Self Improvement

Not Enterpriseな会社でRedshiftを使ってみた

  1. 1. Not Enterpriseな会社で Redshiftを使ってみた
  2. 2. 星野 豊 (@con_mame) クックパッド株式会社 インフラストラクチャー部 AWS / MySQL / DataStore etc... http://d.conma.me/ http://facebook.com/conmame
  3. 3. BIG DATA
  4. 4. 世はまさにビッグデータ ログ アクセスログ 行動ログ 購入・決済ログ クリック・動線
  5. 5. ビッグデータ
  6. 6. DWH / BI tool
  7. 7. 数千万∼数億
  8. 8. (  ゚д゚)  ・・・        (つд⊂)ゴシゴシ        (;゚д゚)  ・・・        (つд⊂)ゴシゴシゴシ       _̲,  ._̲   (;゚  Д゚)  …!?
  9. 9.     ∧_̲∧   ⊂(#・ω・)  置き場所が無い!     /      ノ∪     し―-‐‑‒J  |l|  |                     ⼈人ペシッ!!                 __                 \    \                      ̄ ̄
  10. 10. Redshift
  11. 11. Redshift?
  12. 12. Redshift? データウェアハウス フルマネージド 拡張性が高い 数TB∼数PB カラムナ型 リーズナブル?
  13. 13. Architecture
  14. 14. 使ってみた
  15. 15. BI tool 市場動向 ユーザ動向 サイト回遊 マーケティング 商品開発
  16. 16. それだけじゃない
  17. 17. Original tool ユーザ動向 検索ワード動向 監査 サポート developer more user
  18. 18. COOKPAD的Redshift 行動ログ 検索ログ ユーザ属性 会員情報 監査ログ
  19. 19. Redshiftを選んだわけ MySQL Instance バックアップ -> 自前 容量 -> 増え続ける クエリ実行速度 -> レコード数の増加と共に遅くなる 運用負荷 -> パーテショニングなどのスクリプト作成 RDS 容量 -> 増やしやすいが増え続ける クエリ実行速度 -> レコード数の増加と共に遅くなる
  20. 20. Redshiftを選んだわけ KVS 容量 -> メモリサイズに引っ張られる 検索性 -> 柔軟なクエリは使えない 運用負荷 -> バックアップなどは自前 Redshift クラスタを拡張しやすい バックアップ・スナップショット自動 リカバリも簡単 SQLが使える
  21. 21. スケジュール 検証∼RI購入 2 weeks speed / backup / operation / specific 様々なメトリクスで測定 最初は監査ログは考慮していなかった RI購入∼ログ収集開始 XL * 2 1 week
  22. 22. 1日の検証が終わったらSnapshotを作成してクラスタを Delete クラスタをDeleteするのでSnapshotのS3保存料金はかかる がクラスタを起動しているより安い 検証開始時はSnapshotからクラスタを起動 データ メタデータ (ユーザ・クラスタスペック・台数) FQDN ・ Parameter Group Snapshotに必要なデータが全て入っているのですぐに検証を 再開出来る ただし、Security Groupは毎回Modifyする
  23. 23. app app app fluent proxy fluent proxy manage Separate audit from general logs DataPipline support TREASURE DATA
  24. 24. app / manage server -> fluent-proxy 通常のログと監査用ログは別proxyへ fluentd-plugin -> S3 30分毎にS3にUpload S3 -> Redshift copyを発行
  25. 25. Development
  26. 26. staging
  27. 27. DB 複数のDBを作成 development many development tables production many tables (Each system)
  28. 28. User Root User Management All DB and Cluster Service User Each Service and WLM User Group Development User
  29. 29. 1つのクラスタに複数のDB 開発用のDB 複数サービス用のテーブル サービス・用途ごとに異なるクエリ 実行時間 対象データ
  30. 30. Work Load Management
  31. 31. Redshiftへのクエリはキューごとに管理される キュー毎に並列度が設定されている defaultでは1つのキュー・5並列 並列度を超えた場合は先行クエリが終わるのを待つ キューの識別 ユーザ クエリグループ サーバリソースは全てのキューで共有
  32. 32. 最優先 アプリケーションから発行されるクエリ 並列度高め 優先度低 バッチなどから発行されある程度時間がかかってい いもの どうにもこうにも時間内に収まらない場合はクラス タサイズアップも検討 最低 開発用
  33. 33. Parameter Group -> WLM Max 8キュー (default キュー含) 並列度合計 15 Superuserキュー 並列度1 (設定不可) wildcard production_a production_b Timeout statement_timeout Timeoutとstatement_timeout 短い方優先 default queue
  34. 34. 1. Superuserでログインしていて、クエリグルー プでSuperuserを指定している場合はSuperuserキ ューで実行 2. ログインユーザがユーザグループに含まれて いる場合は、一番最初にマッチするユーザグルー プで指定されているキューで実行 3. ユーザグループに存在しておらず、クエリグ ループが指定されている場合は、最初にマッチし たクエリグループのキューで実行 4. どれにも当てはまらない場合はデフォルトキ ューで実行 ユーザグループ > クエリグループ
  35. 35. http://bit.ly/15PNAvD ユーザグループ クエリグループ
  36. 36. Access Control
  37. 37. クエリやデータのロード状況を確認したい 実行計画 クラスタリソース状況 クエリ毎のリソース使用状況・実行時間
  38. 38. ViewQueriesInConsole Describe*
  39. 39. redshift:get*
  40. 40. Resource Type ARN Cluster arn:aws:redshift:ap-northeast-1:123456789012:cluster:oreore- cluster Parameter Group arn:aws:redshift:ap- northeast-1:123456789012:parametergroup:oreore-pm-group Security Group arn:aws:redshift:ap- northeast-1:123456789012:securitygroup:oreore-sg Snapshot arn:aws:redshift:ap-northeast-1:123456789012:snapshot:oreore- cluster/* Subnet Group arn:aws:redshift:ap- northeast-1:123456789012:subnetgroup:oreore-subnet
  41. 41. { “Statement": [ { "Action": [ "redshift:CreateClusterSnapshot" ], "Effect": "Allow", "Resource": [ "arn:aws:redshift:ap-northeast-1:123456789012:snapshot:oreore-cluster/*" } ] } 管理権限を細かくIAMユーザに割り当て可能
  42. 42. Query
  43. 43. Generate Compiled Code libpq and ODBC JDBC 事前にアクセスされそうなクエリは流しておく 最初の実行は数秒かかる プレースホルダに入る値が変わってもOK
  44. 44. Happening
  45. 45. キーワード ▲キーワード ▲キーワー ド... select substring(cast(substring(keywords from 5) as varchar(100)) from 9) from hoge;
  46. 46. _人人人人人人人人人人人人_ > Leader Node is DEAD <  ̄^Y^Y^Y^Y^Y^Y^Y^^Y^Y^Y^Y^ ̄
  47. 47. UTF8 な文字のバイト境界を下手にぶった切ると Leader Nodeが落ちてるぽいようで 切断されて数十秒繋がらなくなる 7月下旬に治った
  48. 48. Maintenance Window中でもCOPYが成功し てしまう 調査お願い中…
  49. 49. Maintenance Windowの時間でメンテナン スが告知されている場合はCOPYを実行し ないように改良
  50. 50. Conclusion
  51. 51. ユーザ動向だけじゃない 監査ログにも 最初は複数システムまとめてもOK WLMはしっかりと メンテナンス動向は要確認 Watch Forum
  52. 52. Thank you!!

×