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
急激なDB書き込みが行われるサービスをリビルドした話
Search
takayuki.miura
February 20, 2023
Technology
0
640
急激なDB書き込みが行われるサービスをリビルドした話
takayuki.miura
February 20, 2023
Tweet
Share
More Decks by takayuki.miura
See All by takayuki.miura
TerraformをやめてCDKでReStartしたあと、 CDKをやめてCDK for TerraformでReStartした話
tmiura0203
0
980
実際にリビルドを完遂してみて
tmiura0203
0
580
Spring Bootという強すぎるフレームワークについて
tmiura0203
0
690
Other Decks in Technology
See All in Technology
20240725 LLMによるDXのビジョンと、今何からやるべきか @Azure OpenAI Service Dev Day
nrryuya
3
1.1k
GoとアクターモデルでES+CQRSを実践! / proto_actor_es_cqrs
ytake
1
150
CEL(Common Expression Language)で書いた条件にマッチしたIAM Policyを見つける / iam-policy-finder
fujiwara3
0
710
たくさん本を読んだけど 1年後には綺麗サッパリ!を乗り越えて 学習の鬼になるぞ👹
yum3
0
160
Azure OpenAI Service Dev Day / LLMでできる!使える!生成AIエージェント
masahiro_nishimi
3
740
LINE WORKSへ簡単通知!Incoming Webhookアプリの紹介
mmclsntr
0
110
地理情報とAPIのトレンド
nagix
0
160
サービス開発を前に進めるために 新米リードエンジニアが 取り組んだこと / Steps Taken by a Novice Lead Engineer to Advance Service Development
nologyance
0
180
データベース研修 分析向けSQL入門【MIXI 24新卒技術研修】
mixi_engineers
PRO
0
110
E2Eテスト自動化プラットフォームにおけるAIの活用
shift_evolve
0
180
ここがすごいよ! AWS Systems Manager!
saichan11
0
1.8k
スレットハンティングについて知っておきたいこと
hacket
0
130
Featured
See All Featured
Gamification - CAS2011
davidbonilla
78
4.9k
Become a Pro
speakerdeck
PRO
15
4.8k
Build your cross-platform service in a week with App Engine
jlugia
227
17k
実際に使うSQLの書き方 徹底解説 / pgcon21j-tutorial
soudai
149
45k
Building Better People: How to give real-time feedback that sticks.
wjessup
357
18k
The Success of Rails: Ensuring Growth for the Next 100 Years
eileencodes
35
6.3k
Sharpening the Axe: The Primacy of Toolmaking
bcantrill
26
1.6k
Helping Users Find Their Own Way: Creating Modern Search Experiences
danielanewman
26
2.1k
Designing on Purpose - Digital PM Summit 2013
jponch
113
6.6k
Pencils Down: Stop Designing & Start Developing
hursman
118
11k
XXLCSS - How to scale CSS and keep your sanity
sugarenia
245
1.2M
Visualizing Your Data: Incorporating Mongo into Loggly Infrastructure
mongodb
36
9.1k
Transcript
急激なDB書き込みが行われる サービスをリビルドした話 エキサイト株式会社 三浦 大幸 01
アジェンダ 自己紹介 ことの始まり DB書き込みでの負荷問題とその解決 今後の展望 まとめ 02
エキサイト株式会社 所属 バックエンド 技術スタック @miura0203 SNS 01 02 03 自己紹介
自己紹介 03 三浦 大幸 フロントエンド インフラ iOSアプリ
ことの始まり 04
サマーインターン前のある日 ことの始まり 05 インターンなにやる? WebPushのリビルドとかどうですか? いいね! (そういえばWebPushのリビルドして なかったな…)
サマーインターン前のある日 ことの始まり インターンなにやる? WebPushのリビルドとかどうですか? いいね! (そういえばWebPushのリビルドして なかったな…) 闇の開発の始まり 06
問題点 ユーザ情報が少なすぎて、WebPushの機能をフルに使えない WebPushを送信できるタイミングが決め打ちされている cron + ShellScript + PHPで無理やりデーモンを作っており、管理が難しい 配信開始から終了まで数時間掛かる DBからデータを取得
~ WebPush通知送信までの流れが複雑 通知送信後、DBに急激な書き込み負荷が掛かる などなど… ことの始まり 07
問題点 ことの始まり ユーザ情報が少なすぎて、WebPushの機能をフルに使えない WebPushを送信できるタイミングが決め打ちされている cron + ShellScript + PHPで無理やりデーモンを作っており、管理が難しい 配信開始から終了まで数時間掛かる
DBからデータを取得 ~ WebPush通知送信までの流れが複雑 通知送信後、DBに急激な書き込み負荷が掛かる などなど… 省略 08
DB書き込みでの負荷問題とその解決 09
DB書き込みでの負荷問題とその解決 10 DB書き込みでの負荷問題とその解決 通知の送信状況記録時 通知の受信状況記録時のDB書き込み負荷 のDB書き込み負荷
DB書き込みでの負荷問題とその解決 11 通知の受信状況記録時のDB書き込み負荷 DB書き込みでの負荷問題とその解決
問題点 ユーザ情報が少なすぎて、WebPushの機能をフルに使えない WebPushを送信できるタイミングが決め打ちされている cron + ShellScript + PHPで無理やりデーモンを作っており、管理が難しい 配信開始から終了まで数時間掛かる DBからデータを取得
~ WebPush通知送信までの流れが複雑 通知送信後、DBに急激な書き込み負荷が掛かる などなど… 12 DB書き込みでの負荷問題とその解決
問題点 ユーザ情報が少なすぎて、WebPushの機能をフルに使えない WebPushを送信できるタイミングが決め打ちされている cron + ShellScript + PHPで無理やりデーモンを作っており、管理が難しい 配信開始から終了まで数時間掛かる DBからデータを取得
~ WebPush通知送信までの流れが複雑 通知送信後、DBに急激な書き込み負荷が掛かる などなど… 13 DB書き込みでの負荷問題とその解決
問題点 14 ブラウザから受信通知を受け、並列で受信状況記録を行う 受信状況記録(並列) DB書き込みでの負荷問題とその解決 Push通知送信(並列) 受信通知(各ブラウザから)
問題点 15 並列での受信状況記録が急激すぎて、DBへの書き込みが高負荷に 受信状況記録(並列) DB書き込みでの負荷問題とその解決 Push通知送信(並列) 受信通知(各ブラウザから)
問題点 16 並列での受信状況記録が急激すぎて、DBへの書き込みが高負荷に 受信状況記録(並列) 必須 DB書き込みでの負荷問題とその解決 Push通知送信(並列) 受信通知(各ブラウザから)
解決策 17 この機能は必須だったので、別のサービスを噛ませることに 受信通知(各ブラウザから) DB書き込みでの負荷問題とその解決 Push通知送信(並列)
18 Amazon Timestream DB書き込みでの負荷問題とその解決
Amazon Timestreamとは? DB書き込みでの負荷問題とその解決 19 解決策 > Amazon Timestream は、高速かつスケーラブルなサーバーレス時系列データベースサービスです。1 日あたり
数兆件規模のイベントを最大 1,000 倍の速度でより簡単に保存および分析できます。Amazon Timestream は、容 量とパフォーマンスを調整するために自動的にスケールアップまたはスケールダウンするので、基盤インフラスト ラクチャの管理が不要です。 要は、書き込みにとても強い https://aws.amazon.com/jp/timestream/
解決策 20 Timestreamで直接の書き込みを受け、DBへは一定時間ごとに一括入力 受信状況記録(並列) 一括取得 一括入力 一括リクエスト 受信通知 (各ブラウザから) DB書き込みでの負荷問題とその解決
DB書き込みでの負荷問題とその解決 21 通知の送信状況記録時のDB書き込み負荷 DB書き込みでの負荷問題とその解決
問題点 22 数十万人 最終確認で、数十万人相当にWebPushを送ってみた DB書き込みでの負荷問題とその解決
問題点 DB書き込みでの負荷問題とその解決 数十万人 最終確認で、数十万人相当にWebPushを送ってみた 問題発生 23
問題点 24 DBのCPU使用率 送信開始 100 75 50 25 0 問題発生
(グラフはイメージです) DB書き込みでの負荷問題とその解決
問題点 25 既存処理はこうなっているが、リビルドに際し新しく機能を追加した DB書き込みでの負荷問題とその解決 受信通知(各ブラウザから) Push通知送信(並列)
問題点 26 Push通知送信時に、送信状況を記録する機能を追加 DB書き込みでの負荷問題とその解決 送信状況記録(並列) Push通知送信(並列) 受信通知(各ブラウザから)
問題点 27 並列での送信状況記録が急激すぎて、DBへの書き込みが高負荷に Push通知送信(並列) 受信通知(各ブラウザから) DB書き込みでの負荷問題とその解決 送信状況記録(並列)
解決策 28 Push通知送信(並列) 受信通知(各ブラウザから) DB書き込みでの負荷問題とその解決 「ユーザへの通知の送信状況記録」は、Push通知において必須要件ではないので削除 あったほうが便利ではあったが、負荷と天秤にかけた
解決 以上の仕組みで、現在は元気に動いている 29 DB書き込みでの負荷問題とその解決
今後の展望 30
Amazon Timestream Amazon SQS Timestreamは最適? 仕様・コスト・開発のしやすさなどから、SQSのほうが最適な可能性がある 今後の展望 31 検証し、必要に応じて変更
どこまでデータをとっておく? DBの負荷は減ったが、放っておくとデータ量自体は今後も増えていってしまう 今後の展望 32 適切なタイミングで、データを集計・削除する仕組みを入れてもいいかも?
まとめ 33
DBへの急激な書き込み負荷を抑えるには 本当に必要なデータなのか、改めて考える まとめ 34 直にDBに書き込むのではなく、Timestreamなど書き込み負荷に強い サービスを経由する データ書き込みが多いサービスはDB周りが結構シビアなので、「あったほうがいい」くらいの ものは削る必要がある場合も 書き込み負荷に強いサービスも種類があるので、最適なものを選ぶ