Upgrade to Pro
— share decks privately, control downloads, hide ads and more …
Speaker Deck
Features
Speaker Deck
PRO
Sign in
Sign up for free
Search
Search
アクセス解析基盤のデータストア選定奮闘記 CloudNative Days Winter 20...
Search
yumu
November 26, 2024
0
200
アクセス解析基盤のデータストア選定奮闘記 CloudNative Days Winter 2024 船上LT会
yumu
November 26, 2024
Tweet
Share
More Decks by yumu
See All by yumu
minneのショート動画基盤の設計と運用改善 カバーとGMOペパボが語る、クリエイターの創作・表現活動を支える技術
yumu
0
2
Railsアプリから何を切り出す?機能分離の判断基準 Kaigi on Rails 2025
yumu
2
3.5k
影響を広げる力研修 GMOペパボ2025新卒エンジニア研修
yumu
0
870
分散オブジェクトで遊ぼう!〜dRubyで作るマルチプレイヤー迷路ゲーム〜 関西Ruby会議08
yumu
1
1.2k
Ruby×AWSで作る動画変換システム 東京Ruby会議12
yumu
2
3.5k
Google Cloudで作るニアリアルタイムアクセス解析基盤 GDG DevFest Tokyo 2024 LT
yumu
1
3.5k
minneのShoryuken活用 Kaigi on Rails 2024 スポンサーLT
yumu
3
2.2k
Rubyでも動画変換簡単にできるよ TokyuRuby会議15スポンサーLT
yumu
0
150
文系の私が新卒エンジニアになるまで
yumu
4
1.1k
Featured
See All Featured
Become a Pro
speakerdeck
PRO
29
5.6k
A designer walks into a library…
pauljervisheath
209
24k
The Invisible Side of Design
smashingmag
302
51k
The Cult of Friendly URLs
andyhume
79
6.7k
The Pragmatic Product Professional
lauravandoore
36
7k
Automating Front-end Workflow
addyosmani
1371
200k
Documentation Writing (for coders)
carmenintech
76
5.1k
Rebuilding a faster, lazier Slack
samanthasiow
84
9.3k
For a Future-Friendly Web
brad_frost
180
10k
Exploring the Power of Turbo Streams & Action Cable | RailsConf2023
kevinliebholz
36
6.1k
Done Done
chrislema
186
16k
VelocityConf: Rendering Performance Case Studies
addyosmani
333
24k
Transcript
アクセス解析基盤の データストア選定奮闘記 yumu 2024.11.26 CloudNative Days Winter 2024 船上LT会 1
2 自己紹介 GMOペパボ minne事業部 プロダクト開発チーム 2023年 新卒入社 湯村 美吹香 Yumura Mifuka バックエンドが主戦場ですが、フロントやインフラもや
ります!クラウドネイティブになりたい。 • あだ名 : yumu • 好きな漫画 : メイドインアビス • X : @myumura3
3 minneの仕組み minneとは minne(ミンネ)は、ハンドメイド作品を「買いたい人」と「売りたい人」をつなぐ国内最大 のハンドメイドマーケットです。パソコンやスマートフォンを使って、簡単にハンドメイド作 品を販売・購入できます。
4 アジェンダ 1. アクセス解析リニューアルの背景 2. データストアの検討 1. 使い慣れた選択肢 2. クラウドサービス
3. なぜFirestoreを選んだのか 3. 実装してわかったこと
5 1. アクセス解析リニューアルの背景
6 これまでのアクセス解析
7 アクセス解析リニューアルの背景 • データ反映が1日おき • 表示できる指標が限定的 これまでの課題 理想の姿 • リアルタイムで数値を確認
• より多くの指標を提供
8 既存のログ収集基盤 Rails App Fluentd Pub/Sub Dataflow BigQuery minne bigfoot
9 これまでのアクセス解析アーキテクチャ DAG BigQuery Elasticsearch 集計クエリ実行・書き込み データ取り込み(Rake)
10 アーキテクチャ検討の基準 • ログ収集基盤との親和性 • 大量の行動ログを捌ける • 数分以内での更新 • レスポンス速度
• 値の正確性 • コスト効率 • 運用コスト • 将来の拡張性
11 2. データストアの検討
12 最終的なアーキテクチャ
13 使い慣れた選択肢 Pros Cons MySQL • 運用ノウハウが豊富 • NoSQLのように高速ではな い
• データの内容的にRDBである 必要がない Redis • 高速な読み書きが可能 • カウンター処理との相性がい い • データの永続化の運用が面倒 Elasticsearch • 検索が高速 • スケーラビリティが高い • 全文検索は不要
14 クラウドサービス Pros Cons BigQuery • 大規模データの分析に適して いる • クエリコストが高い
Cloud Storage • 大容量データに適している • コスト効率が良い • CSVなどのファイル処理が必 要 Cloud Bigtable • リアルタイムデータ処理に適 している • 小規模データセットでは過剰 • コストが高い DynamoDB • 高速な読み書きが可能 • コストが安い • Google Cloud側に置きた い
15 なぜFirestoreを選んだのか • NoSQLデータベース • フルマネージドで運用が楽 • コスト面での優位性 ◦ 読み書きベースの従量課金
• BigQueryとの連携がサポート済み
16 3. 実装してわかったこと
17 Firestoreを使ってみてわかったこと • よかった点 ◦ 想定通りの処理速度 ◦ 運用がとてもシンプル • はまったポイント🌀
◦ 一定期間にドキュメントを更新できる回数に制限がある ◦ データ構造の設計が難しい
18 Thank You! Thank You! GDG DevFest Tokyo 2024(11/30)でもLTします!