急激なDB書き込みが行われるサービスをリビルドした話

by takayuki.miura

Slide 1

Slide 1 text

急激なDB書き込みが行われるサービスをリビルドした話エキサイト株式会社　三浦大幸 01

Slide 2

Slide 2 text

アジェンダ自己紹介ことの始まり DB書き込みでの負荷問題とその解決今後の展望まとめ 02

Slide 3

Slide 3 text

エキサイト株式会社所属バックエンド技術スタック @miura0203 SNS 01 02 03 自己紹介自己紹介 03 三浦大幸フロントエンドインフラ iOSアプリ

Slide 4

Slide 4 text

ことの始まり 04

Slide 5

Slide 5 text

サマーインターン前のある日ことの始まり 05 インターンなにやる？ WebPushのリビルドとかどうですか？いいね！（そういえばWebPushのリビルドしてなかったな…）

Slide 6

Slide 6 text

サマーインターン前のある日ことの始まりインターンなにやる？ WebPushのリビルドとかどうですか？いいね！（そういえばWebPushのリビルドしてなかったな…）闇の開発の始まり 06

Slide 7

Slide 7 text

問題点ユーザ情報が少なすぎて、WebPushの機能をフルに使えない WebPushを送信できるタイミングが決め打ちされている cron + ShellScript + PHPで無理やりデーモンを作っており、管理が難しい配信開始から終了まで数時間掛かる DBからデータを取得 ~ WebPush通知送信までの流れが複雑通知送信後、DBに急激な書き込み負荷が掛かるなどなど… ことの始まり 07

Slide 8

Slide 8 text

問題点ことの始まりユーザ情報が少なすぎて、WebPushの機能をフルに使えない WebPushを送信できるタイミングが決め打ちされている cron + ShellScript + PHPで無理やりデーモンを作っており、管理が難しい配信開始から終了まで数時間掛かる DBからデータを取得 ~ WebPush通知送信までの流れが複雑通知送信後、DBに急激な書き込み負荷が掛かるなどなど… 省略 08

Slide 9

Slide 9 text

DB書き込みでの負荷問題とその解決 09

Slide 10

Slide 10 text

DB書き込みでの負荷問題とその解決 10 DB書き込みでの負荷問題とその解決通知の送信状況記録時通知の受信状況記録時のDB書き込み負荷のDB書き込み負荷

Slide 11

Slide 11 text

DB書き込みでの負荷問題とその解決 11 通知の受信状況記録時のDB書き込み負荷 DB書き込みでの負荷問題とその解決

Slide 12

Slide 12 text

Slide 13

Slide 13 text

Slide 14

Slide 14 text

問題点 14 ブラウザから受信通知を受け、並列で受信状況記録を行う受信状況記録（並列） DB書き込みでの負荷問題とその解決 Push通知送信（並列）受信通知（各ブラウザから）

Slide 15

Slide 15 text

問題点 15 並列での受信状況記録が急激すぎて、DBへの書き込みが高負荷に受信状況記録（並列） DB書き込みでの負荷問題とその解決 Push通知送信（並列）受信通知（各ブラウザから）

Slide 16

Slide 16 text

問題点 16 並列での受信状況記録が急激すぎて、DBへの書き込みが高負荷に受信状況記録（並列）必須 DB書き込みでの負荷問題とその解決 Push通知送信（並列）受信通知（各ブラウザから）

Slide 17

Slide 17 text

解決策 17 この機能は必須だったので、別のサービスを噛ませることに受信通知（各ブラウザから） DB書き込みでの負荷問題とその解決 Push通知送信（並列）

Slide 18

Slide 18 text

18 Amazon Timestream DB書き込みでの負荷問題とその解決

Slide 19

Slide 19 text

Amazon Timestreamとは？ DB書き込みでの負荷問題とその解決 19 解決策 > Amazon Timestream は、高速かつスケーラブルなサーバーレス時系列データベースサービスです。1 日あたり数兆件規模のイベントを最大 1,000 倍の速度でより簡単に保存および分析できます。Amazon Timestream は、容量とパフォーマンスを調整するために自動的にスケールアップまたはスケールダウンするので、基盤インフラストラクチャの管理が不要です。要は、書き込みにとても強い https://aws.amazon.com/jp/timestream/

Slide 20

Slide 20 text

解決策 20 Timestreamで直接の書き込みを受け、DBへは一定時間ごとに一括入力受信状況記録（並列）一括取得一括入力一括リクエスト受信通知（各ブラウザから） DB書き込みでの負荷問題とその解決

Slide 21

Slide 21 text

DB書き込みでの負荷問題とその解決 21 通知の送信状況記録時のDB書き込み負荷 DB書き込みでの負荷問題とその解決

Slide 22

Slide 22 text

問題点 22 数十万人最終確認で、数十万人相当にWebPushを送ってみた DB書き込みでの負荷問題とその解決

Slide 23

Slide 23 text

問題点 DB書き込みでの負荷問題とその解決数十万人最終確認で、数十万人相当にWebPushを送ってみた問題発生 23

Slide 24

Slide 24 text

問題点 24 DBのCPU使用率送信開始 100 75 50 25 0 問題発生（グラフはイメージです） DB書き込みでの負荷問題とその解決

Slide 25

Slide 25 text

問題点 25 既存処理はこうなっているが、リビルドに際し新しく機能を追加した DB書き込みでの負荷問題とその解決受信通知（各ブラウザから） Push通知送信（並列）

Slide 26

Slide 26 text

問題点 26 Push通知送信時に、送信状況を記録する機能を追加 DB書き込みでの負荷問題とその解決送信状況記録（並列） Push通知送信（並列）受信通知（各ブラウザから）

Slide 27

Slide 27 text

問題点 27 並列での送信状況記録が急激すぎて、DBへの書き込みが高負荷に Push通知送信（並列）受信通知（各ブラウザから） DB書き込みでの負荷問題とその解決送信状況記録（並列）

Slide 28

Slide 28 text

解決策 28 Push通知送信（並列）受信通知（各ブラウザから） DB書き込みでの負荷問題とその解決「ユーザへの通知の送信状況記録」は、Push通知において必須要件ではないので削除あったほうが便利ではあったが、負荷と天秤にかけた

Slide 29

Slide 29 text

解決以上の仕組みで、現在は元気に動いている 29 DB書き込みでの負荷問題とその解決

Slide 30

Slide 30 text

今後の展望 30

Slide 31

Slide 31 text

Amazon Timestream Amazon SQS Timestreamは最適？仕様・コスト・開発のしやすさなどから、SQSのほうが最適な可能性がある今後の展望 31 検証し、必要に応じて変更

Slide 32

Slide 32 text

どこまでデータをとっておく？ DBの負荷は減ったが、放っておくとデータ量自体は今後も増えていってしまう今後の展望 32 適切なタイミングで、データを集計・削除する仕組みを入れてもいいかも？

Slide 33

Slide 33 text

まとめ 33

Slide 34

Slide 34 text

DBへの急激な書き込み負荷を抑えるには本当に必要なデータなのか、改めて考えるまとめ 34 直にDBに書き込むのではなく、Timestreamなど書き込み負荷に強いサービスを経由するデータ書き込みが多いサービスはDB周りが結構シビアなので、「あったほうがいい」くらいのものは削る必要がある場合も書き込み負荷に強いサービスも種類があるので、最適なものを選ぶ