生成AIを使ってPush通知機能の設計を進めていたとき、性能面で気になる構造に気付きました。
設計上、通知対象者1人を処理するために最大約11回、DBへ問い合わせる可能性がある状態でした。
| 通知対象者 | DBへの問い合わせ |
|---|---|
| 1人 | 約11回 |
| 100人 | 約1,100回 |
| 1,000人 | 約11,000回 |
今回は、本番で障害が起きた話ではなく、設計段階で問題に気付き、見直した話です。
1,000人で11,000回。何が問題なのか
DBへの問い合わせは、単純な計算1回ではありません。
アプリからDBへ問い合わせ、DBがデータを探し、結果を返す、というやり取りが発生します。
たとえば役所で1,000人分の情報を確認するとします。
本来なら、
この1,000人分の情報をまとめてください
と依頼できるところを、1人について11回ずつ窓口へ確認しに行くようなものです。
1,000人なら11,000往復です。
PCやサーバーがすぐ壊れるわけではありませんが、DBへの通信や検索、接続待ちが増え、他のAPI処理まで遅くなる可能性があります。
設計を見て気になったポイント
上がってきた設計を確認した時点で、対象者ごとの処理の中にDBアクセスが何度も入っていることが気になりました。
一つひとつの処理自体は自然です。
通知対象者を確認する
通知条件を確認する
端末情報を取得する
通知済みか確認する
結果を保存する
しかし、これらを対象者ごとに繰り返すと、
1人あたり約11回 × 対象人数
という形でDBへの問い合わせが増えていきます。
そこで人数を掛けてみると、100人で約1,100回、1,000人で約11,000回になることが分かり、設計を見直すことにしました。
1人ずつ通知しても、DBまで1人ずつ調べる必要はない
Push通知自体は、対象者ごとに送る必要があります。
しかし、通知に必要な情報まで毎回DBへ取りに行く必要はありません。
たとえば、
必要な情報をDBからまとめて取得
↓
対象者ごとにPush通知
↓
結果をまとめてDBへ保存
という設計にできます。
重要なのは、SQLを必ず何本にするかではなく、
対象人数が10倍になったとき、DBへの問い合わせ回数まで10倍になる構造を避けること
です。
AIを使った設計で感じたこと
今回の設計が「AIだから間違った」という話ではありません。
人間が設計しても同じ問題は起こります。
ただ、生成AIを使うと設計から実装まで非常に速く進みます。
そのため、
動くか
の確認だけで次へ進まず、
100人なら？
1,000人なら？
SQLは何回発行される？
ループ内でDBアクセスしていない？
と、別途確認する必要があると感じました。
AIには実装だけでなく、
性能面だけを監査してください
とレビューさせるのも有効です。
まとめ
今回、Push通知機能の設計段階で、
1人あたり最大約11回のDB問い合わせが発生する可能性がある構造
に気付きました。
今回の学びはシンプルでした。
「正しく動く」と「利用者が増えても耐えられる」は別。
AIを使うことで開発速度は上がります。
だからこそ、設計ができた後に一度、
「これ、100倍になったらどうなる？」
と確認することが、これまで以上に重要だと思います。