グノシーのアクセスログ解析基盤のアーキテクチャ(仮)
ログを集める。
なぜログ集める?
実施した施策の反応をみるため
プロダクトのブラッシュアップ
エラー時の原因調査
怖い人に詰められたときに証拠となる記録を出すため
ログを貯めることが顧客に提供する価値がある(Papertrail,macharel,etc...)
実施した施策の反応をみるため, プロダクトのブラッシュアップ
分析用途
APIサーバー -> S3,Lambda
ログはどう流れていくか
fluentd -> S3 or BQへ
ETL or batch で
Re:dashは朝回で毎日見る
普段の一次置き場はS3とBQ
必要に応じてDBにロードして、Re:dashで可視化
プロダクト改善用途
どういうログ
ユーザー行動ログ
広告のインプレッション
どう使われる?
ユーザーに最適な情報を届ける為
digdag presto
airflow in AWS
digdab on ECSで行っている
運用して思うところ
AWSにどっぷり浸かっている
ログや分析用途のDB,S3bucketは各所に散らばっているので、カオス
分析用途で使うログのスキーマ管理については悩ましい
データは自由に触れる一方、パーティションは指定せず、フルスキャンクエリ実行し太郎が定期的に出現する。
まとめ
Re:dash
プロダクト改善用途
月間数千億リクエストをさばく広告配信システムの構成(仮)
Dynalystについて
RTBのしくみ
DSPs、SSP
bid request
100ms以内
c4.4xlarge x ピーク100台(US,JP)
c5インスタンスも導入
LB -> EC2 -> ElastiCache -> DynamoDB,Aurora(master,slave)
Scalaを採用した理由
チャレンジ
家族製、メンテナンス性
ハイパフォーマンス
JAVAの資産が使える
Scalaの知見の塊
並列処理が書きやすい
Futureという概念
例: RDBから複数のテーブルを引きつつ、DynamoBDも引く
ログはkinesis streamsに流す
Producer -> stream -> consumer -> DynamoDB,S3
kinesisに投げるときはFrouend
Kinesis Producer Library
Kinesis Consumer Library
ユーザーデータはDynamoDBへ
HashKeyとRangeKeyを組み合わせる
HashKeyを引けばRangeKeyでソートされた複数レコードが返る。
ホットパーティション問題
対策
データが登録された時期ごとにわける
DynamoDBのキャッシュ
レイテンシの削減
DynamoDBReadCapacityの削減
ホットパーティション問題の緩和
EC(memcached)の採用
シンプル、高速
マルチスレッドで動く
DynamoDBAcccelratorはクエリキャッシュは自動更新されないので、
使用せず、DynamoDBstream ~ lambda Functionでキャッシュを削除で自前で実装。
ログ集計
3TB/day
ApacheSpark on Amazon EMRを利用
高い信頼性は設計がすべて
単一障害点を作らない
クラウドを浸かってるならクラウドネイティブなベストプラクティスに寄せる
アプリはできるだけステートレスに
ステートを持つ部分をマネージド・サービスに寄せる
ソリューションアーキテクトに相談する
とはいえ不足の自体は起こる
Datadogを使用
リクエストが詰まったらHTTP204返す
今後やっていきたいこと
AutoScaling
AkkaHTTP