#DynamoDB
- 事例
- shazm
- super boalのpromotion
- earth networkds
- 天気の予測サービス
- shazm
- hash + rangekey
- ex. hash : user / range : category id
- local secondary index
- 1 tableあたり5つまでであればパフォーマンス劣化が無い?
- operation系
- admin-free
- サービスの成長に従い設定やprovisionの手間がかかるようになる
- 障害対応のための管理コスト
- 等
- admin-free
- 性能
- server-side latency across all APIs
- agerage : < 3ms
- TP90 < 4.5ms
- RTBの事例
- 20ms(bits req/res) + 20ms(queues and buffering in AWS) + 40ms(<-> DynamoDB)
- AdRolの事例
- 4つのregionを使用して7Billion req/day
- 350GB / region
- region間のlatency : < 3ms
- 99.5% end to end latency : < 10ms
- 運用スタッフが居ないらしい
- server-side latency across all APIs
- 用途
- データを大量に蓄積
- 大規模トラフィックに対する負荷分散処理
- DynamoDB使用事例としては国内最大規模らしい
- 事例
- ファルキューレの紋章
- ユーザー数70万人
- GREE Platform -> Android独自Platform?
- 最初はDynamoDBだけ使用。後にMySQLとのハイブリット構成
- 大激闘キズナバトル
- ユーザー数15万人
- 20 vs 20 のチームカードバトル
- 最初からDynamoDB + MySQLのハイブリッド構成
- データのメインストレージ:DynamoDB
- 集計用、ランキング用データベース : MySQL
- AWS料金比率
- ec2 : 75%
- dynamodb : 11%
- ピーク時間帯で同時接続数6,000程度
- maxの接続数設定はこの約3倍らしい
- ピーク時間帯で同時接続数6,000程度
- rds : 4%
- ファルキューレの紋章
- 苦労したこと
- トランザクションが無い
- SQS+楽観的ロックで代替
- バックアップ
- スキーマ設計上、ジャーナルの概念を用いて対応
- 検索、集計が弱い
- MySQLで補完
- ソースコードの品質を上げなければいけなくなった
- 並列分散処理上でのトランザクション処理?
- RDBMS脳→NoSQL脳への教育
- トランザクションが無い
- データ集計処理
- DynamoDB -> MySQLへのレプリケーション
- DynamoDBに対する更新処理がある場合は、DynamoDBへのリクエストに並行してSQL経由でMySQLに書き込み
- SQSの性能を絞る事でMySQLへの同時書き込み数を調整できる
- DynamoDB -> EMR -> MySQL / DynamoDB
- DynamoDB -> MySQLへのレプリケーション
#EMR ##overview
- 使用ジョブの内訳
- Hiveが半分くらいらしい
- design pattern
- transient cluster
- つど起動
- 頻度が少ない( < 1時間に1回)処理や、アドホックな処理に向いてる
- alive cluster
- インスタンスを立ち上げっぱなしで処理
- 解析処理の頻度が多い場合に向いてる
- マルチテナント的なクラスタを用意する場合はこちらの方が向いてる
- transient cluster
- best practice
- input〜output の利用空間効率を高めることが大事
- 特定のMapper/Reducerに処理が偏ったりして、全体の使用効率のアンバランスが起きている状態
- clusterのsizing
- memory / cpu / io
- データファイルのサイズに処理時間が依存するので、一般論的にはMapperの数が多い(node数が多い)ほど処理はスケールする
- S3上のデータはsplitできない
- S3上のファイル数 = Mapper数
- 大きすぎるファイルは避ける(splitされない)
- さりとて小さすぎるファイルは避ける
- 各Mapタスクの起動に約2秒かかるらしい
- S3DistCpを使ってマージできるらしい
- CPU/memory使用率を監視して、チューニングをする
- フルで使われていればスロットを増やす
- スカスカなのであれば減らす
- input〜output の利用空間効率を高めることが大事
- kg_kpi
- KLabの30以上のソーシャルゲームのデータを蓄積したDWH。らしい。
- S3にデータを蓄積
- 分析用サーバーにEC2
- データ解析にEMR
- Apacheのアクセスログの解析などに使用してる
- データ保存にRDS
- KLabの30以上のソーシャルゲームのデータを蓄積したDWH。らしい。
- log
- emrを用いて生ログをmsgpackフォーマットに変換
- 4 columnの定形スキーマのフォーマットに変換
- MRJobを使用
- ユーザーの滞在時間、ログイン回数などを集計
- たまにhourly UU/PV
- たまに特定pathへのアクセス数
- パフォーマンス
- 変換前:1日分の集計に30分以上
- 変換後:1日分は数分程度
- Hiveで解析可能かどうか検証中
- emrを用いて生ログをmsgpackフォーマットに変換
- だいたいredshift seminarの内容と同じ
- QA
- regionをまたいだredshift間のreplicationはできる?
- できない。
- いったんS3に置く→Bucket copy で対応いただければ
- regionをまたいだredshift間のreplicationはできる?
- AWSは海外のサービス向けに使用しているらしい
- 導入前の課題
- 集計系はEMRを使用
- 集計が遅い
- 単体テストが行いづらい
- 本質的にMapReduceアルゴリズムを実行する必然性が無い(SQLで良い)
- ログがあちこちに分散されていて探しにいくのが面倒くさい
- redshift
- 用意したクラスタ
- 300GB / day * 60 = 16TB
- 古いデータは定期的に削除
- 8XL * 2 の構成
- ロードの性能
- 毎時10GB超のファイルをロード
- 実行時間はおよそ40sec以内
- EMRから2週間でreplace完了
- 20分かかったqueryが1分程度で終わるように
- 現在は、すべての情報をRedshiftに保存
- 用意したクラスタ
- 困ったこと
- テーブル作成後のスキーマ変更が難しい
- 新しいテーブル作成→コピー
- 週に1度、30分のメンテナンスがある
- 構造的なデータはそのままでは入れられない
- 結構高い(商用DWHよりは安い)
- 8XL * 2 で$10,000くらい
- テーブル作成後のスキーマ変更が難しい
- 事例1 : ADreco
- レコメンドバナー特化型DSP service
- redshift + S3 + Glacier
- S3に保存したログをredshiftにcopy
- 古いデータはGlacier
- 関連度や特徴量?の抽出の基になる数字をredshift上で計算
- アルゴリズムの実行はEMRやオンメモリで?
- レコメンドバナー特化型DSP service
- 事例2: private DMP
- DWH基盤としてredshiftを使用
- 技術トピック
- テーブルのカラムごとに圧縮方式が指定できる
- データの出現パターンに応じて最適なものを選ぶ必要がある
- optimizerがある?
- テーブルのカラムごとに圧縮方式が指定できる
- QA
- redshift以外で検討したDBはあるか?
- 最初はHive環境をEC2上で構築してみた
- 管理コスト、パフォーマンス面でRedshiftを使用
- realtime 演算のキャッシュ的な使い方でRedisを使っているところも多い
- 計算プラットフォームに何か使っているか?
- スクラッチでJavaで書くことが多い
- 他にRやMahoutとか
- redshift以外で検討したDBはあるか?