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