Edited at

Architecture Night #1 参加メモ


グノシーのアクセスログ解析基盤のアーキテクチャ(仮)

ログを集める。

なぜログ集める?

実施した施策の反応をみるため

プロダクトのブラッシュアップ

エラー時の原因調査

怖い人に詰められたときに証拠となる記録を出すため

ログを貯めることが顧客に提供する価値がある(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