顧客が本当に必要だったもの - パフォーマンス改善編 / Make what is needed

by soudai sone

Slide 1

Slide 1 text

【ハイブリッド開催】わたし史上、最高のチューニング顧客が本当に必要だったもの    - パフォーマンス改善編 

Slide 2

Slide 2 text

What is it?

Slide 3

Slide 3 text

結論：仕様を正しく変更するのが    一番パフォーマンスに効く  What is it?

Slide 4

Slide 4 text

What is it?

Slide 5

Slide 5 text

ずっと同じことを言ってる      What is it?

Slide 6

Slide 6 text

ずっと同じことを言ってる  ↓  今日はもうちょっと具体例の話  What is it?

Slide 7

Slide 7 text

1. 自己紹介  2. 複雑な仕様がRDBを殺す  3. 特効薬 : 仕様を削る  4. まとめ  あじぇんだ

Slide 8

Slide 8 text

1. 自己紹介  2. 複雑な仕様がRDBを殺す  3. 特効薬 : 仕様を削る  4. まとめ  あじぇんだ

Slide 9

Slide 9 text

自己紹介  曽根壮大（40歳）  Have Fun Tech LLC 代表社員  株式会社リンケージ CTO 兼 COO    そ  ● 日本PostgreSQLユーザ会勉強会分科会担当  ● 3人の子供がいます（長女、次女、長男）  ● 技術的にはWeb/LL言語/RDBMSが好きです  ● コミュニティが好きたけ  ね  とも 

Slide 10

Slide 10 text

1. 自己紹介  2. 複雑な仕様がRDBを殺す  3. 特効薬 : 仕様を削る  4. まとめ  あじぇんだ

Slide 11

Slide 11 text

複雑な仕様がスロークエリや    ロングトランザクションを生む  複雑な仕様がRDBを殺す

Slide 12

Slide 12 text

複雑な仕様がRDBを殺す

Slide 13

Slide 13 text

複雑な仕様がRDBを殺す

Slide 14

Slide 14 text

これは本当に闇が深い      複雑な仕様がRDBを殺す

Slide 15

Slide 15 text

ECサイトの例      複雑な仕様がRDBを殺す

Slide 16

Slide 16 text

ECサイトの例  ↓  購入のボタンがめちゃ重い  複雑な仕様がRDBを殺す

Slide 17

Slide 17 text

1. 商品の在庫を確保  2. ポイントの利用  3. クーポンの利用  4. キャンペーンの確認  5. 決済処理  6. 配送手続き処理  7. ポイント付与  8. 購入履歴の追加  9. 通知処理  複雑な仕様がRDBを殺すこれを全部 1つのトランザクションまとめる

Slide 18

Slide 18 text

1. 商品の在庫を確保  2. ポイントの利用  3. クーポンの利用  4. キャンペーンの確認  5. 決済処理  6. 配送手続き処理  7. ポイント付与  8. 購入履歴の追加  9. 通知処理  複雑な仕様がRDBを殺すこれを全部 1つのトランザクションまとめるいきなりUPDATEとかでロックを取ると後続が詰まる

Slide 19

Slide 19 text

1. 商品の在庫を確保  2. ポイントの利用  3. クーポンの利用  4. キャンペーンの確認  5. 決済処理  6. 配送手続き処理  7. ポイント付与  8. 購入履歴の追加  9. 通知処理  複雑な仕様がRDBを殺すこれを全部 1つのトランザクションまとめる処理の数だけクエリを投げて集計する

Slide 20

Slide 20 text

1. 商品の在庫を確保  2. ポイントの利用  3. クーポンの利用  4. キャンペーンの確認  5. 決済処理  6. 配送手続き処理  7. ポイント付与  8. 購入履歴の追加  9. 通知処理  複雑な仕様がRDBを殺すこれを全部 1つのトランザクションまとめる処理の数だけクエリを投げて集計する無理に1回のクエリで対応しようとして、超複雑なクエリが生まれる

Slide 21

Slide 21 text

Slide 22

Slide 22 text

1. 商品の在庫を確保  2. ポイントの利用  3. クーポンの利用  4. キャンペーンの確認  5. 決済処理  6. 配送手続き処理  7. ポイント付与  8. 購入履歴の追加  9. 通知処理  複雑な仕様がRDBを殺すこれを全部 1つのトランザクションまとめる外部APIだったりする

Slide 23

Slide 23 text

1. 商品の在庫を確保  2. ポイントの利用  3. クーポンの利用  4. キャンペーンの確認  5. 決済処理  6. 配送手続き処理  7. ポイント付与  8. 購入履歴の追加  9. 通知処理  複雑な仕様がRDBを殺すこれを全部 1つのトランザクションまとめる外部APIだったりするしかも時々めちゃレスポンスが遅い ISUCON9の予選問題がこれ

Slide 24

Slide 24 text

1. 商品の在庫を確保  2. ポイントの利用  3. クーポンの利用  4. キャンペーンの確認  5. 決済処理  6. 配送手続き処理  7. ポイント付与  8. 購入履歴の追加  9. 通知処理  複雑な仕様がRDBを殺すこれを全部 1つのトランザクションまとめるここも外部APIだったりする失敗したりするとロールバックでやり直しここが終わってやっと画面遷移が終わる

Slide 25

Slide 25 text

全部を同時実行する必要はない      複雑な仕様がRDBを殺す

Slide 26

Slide 26 text

全部を同時実行する必要はない  ↓  ユーザが知りたいのは購入できた事実  複雑な仕様がRDBを殺す

Slide 27

Slide 27 text

1. 商品の在庫を確保  2. ポイントの利用  3. クーポンの利用  4. キャンペーンの確認  5. 決済処理  6. 配送手続き処理  7. ポイント付与  8. 購入履歴の追加  9. 通知処理  複雑な仕様がRDBを殺す在庫を確保できば後続は非同期にできる

Slide 28

Slide 28 text

1. 商品の在庫を確保  2. ポイントの利用  3. クーポンの利用  4. キャンペーンの確認  5. 決済処理  6. 配送手続き処理  7. ポイント付与  8. 購入履歴の追加  9. 通知処理  複雑な仕様がRDBを殺す後続で処理して失敗したら購入を取り消す

Slide 29

Slide 29 text

1. 商品の在庫を確保  2. ポイントの利用  3. クーポンの利用  4. キャンペーンの確認  5. 決済処理  6. 配送手続き処理  7. ポイント付与  8. 購入履歴の追加  9. 通知処理  複雑な仕様がRDBを殺す商品次第ではここさえ確定できれば、あとは非同期にできる

Slide 30

Slide 30 text

ロングトランザクション対策      複雑な仕様がRDBを殺す

Slide 31

Slide 31 text

ロングトランザクション対策  ↓  分割する  複雑な仕様がRDBを殺す

Slide 32

Slide 32 text

？？？「でも全部同じテーブルなんですよ」      複雑な仕様がRDBを殺す

Slide 33

Slide 33 text

複雑な仕様がRDBを殺す

Slide 34

Slide 34 text

？？？「でも全部同じテーブルなんですよ」  ↓  ライフサイクルに合わせてテーブルは分割  複雑な仕様がRDBを殺す

Slide 35

Slide 35 text

ちゃんと正規化する    責務を正しく分ける  複雑な仕様がRDBを殺す

Slide 36

Slide 36 text

ここまでシンプルな実装を目指しましょうと強調してきましたが、「シンプルな実装」とはなんでしょうか。RDBMSを使う上でシンプルな実装のヒントは正規化です。正規化のコツは次のように表現できます。   ● 事実だけを保存する   ● 重複がない  ● 不整合がない  ● nullがない  これらを意識して設計していくとシンプルな設計に近づいていきます。  また正規化を行う際はここまで説明したとおり、種別と状態を考えることも重要です。ライフサイクルが違うデータは往々にして状態や種別が異なります。場合によってはnullになるようなカラムやUPDATEが必要なレコードは状態を持っている可能性があります。こうしたテーブルが見つかった場合はより深く考察する必要があります。   https://agilejourney.uzabase.com/entry/2022/07/28/103000

Slide 37

Slide 37 text

そして最後にINDEXの数にも注目しましょう。主キーは必ずありますが、外部キー制約とユニーク制約を除いたINDEXは主に検索のために必要なINDEXです。検索のWHEREの対象の数だけそのテーブルの責務が大きいといえ、4つ以上の INDEXが必要な場合も同じく深く考察する必要があります。隠れた状態をWHEREで絞り込んでいたり、種別をWHEREで絞り込んでいるケースが見えてくることがあります。   このようにシンプルな設計を目指して考察を繰り返していくことが重要です。そして同じくらい重要なこととして認識すべきはイージーとシンプルは両立できる、ということです。シンプルを目指し考察を繰り返すことがまさにデータモデリングであり、変化に強い設計につながっていくのです。   https://agilejourney.uzabase.com/entry/2022/07/28/103000

Slide 38

Slide 38 text

複雑な仕様がRDBを殺す

Slide 39

Slide 39 text

1. 自己紹介  2. 複雑な仕様がRDBを殺す  3. 特効薬 : 仕様を削る  4. まとめ  あじぇんだ

Slide 40

Slide 40 text

特効薬：仕様を削る

Slide 41

Slide 41 text

ずっとこれ言ってる      特効薬：仕様を削る

Slide 42

Slide 42 text

ずっとこれ言ってる  ↓  代表格を紹介します  特効薬：仕様を削る

Slide 43

Slide 43 text

ページャの原罪      特効薬：仕様を削る

Slide 44

Slide 44 text

ページャの原罪  ↓  ページャの業は深い  特効薬：仕様を削る

Slide 45

Slide 45 text

1つ目    対象総件数の表示  特効薬：仕様を削る

Slide 46

Slide 46 text

特効薬：仕様を削る

Slide 47

Slide 47 text

特効薬：仕様を削るこのcount(*)が不要なクエリを生む

Slide 48

Slide 48 text

特効薬：仕様を削る今はGoogleも表示していない

Slide 49

Slide 49 text

sql_culc_found_rows の呪い      特効薬：仕様を削る

Slide 50

Slide 50 text

sql_culc_found_rows の呪い      特効薬：仕様を削る MySQLで全体件数を取得するために使われていた MySQL 8.0.17で非推奨になった

Slide 51

Slide 51 text

通知の未読件数とかも一緒    基本的には未読かどうかわかれば良い  特効薬：仕様を削るアプリ 999 数字は不要

Slide 52

Slide 52 text

INDEXが活用できないcount()は    めちゃめちゃ遅い  特効薬：仕様を削るテーブルスキャンだから

Slide 53

Slide 53 text

INDEXが活用できないcount()は    めちゃめちゃ遅い  特効薬：仕様を削るテーブルスキャンだから複雑な検索フォームの場合テーブルスキャンになるケースで刺さる

Slide 54

Slide 54 text

2つ目    最終ページのリンク  特効薬：仕様を削る

Slide 55

Slide 55 text

特効薬：仕様を削る

Slide 56

Slide 56 text

ORDER BYの    LIMIT OFFSETに刺さる  特効薬：仕様を削る

Slide 57

Slide 57 text

特効薬：仕様を削る

Slide 58

Slide 58 text

特効薬：仕様を削る

Slide 59

Slide 59 text

最終ページに行きたい？    昇順、降順で良い  特効薬：仕様を削る

Slide 60

Slide 60 text

そもそもユーザが必要なのは    検索フォームだったりする  特効薬：仕様を削る

Slide 61

Slide 61 text

そもそもユーザが必要なのは    検索フォームだったりする  特効薬：仕様を削るこれもこれで闇が深いが … 部分一致とかORとか…

Slide 62

Slide 62 text

これらは単純に仕様を消せば    実装不要でパフォーマンスも改善する  特効薬：仕様を削る

Slide 63

Slide 63 text

特効薬：仕様を削る

Slide 64

Slide 64 text

What is it? 必要最小限を提供する

Slide 65

Slide 65 text

本当に必要なモノだけを    実装していますか？  特効薬：仕様を削る

Slide 66

Slide 66 text

1. 自己紹介  2. 複雑な仕様がRDBを殺す  3. 特効薬 : 仕様を削る  4. まとめ  あじぇんだ

Slide 67

Slide 67 text

複雑な仕様がRDBを殺す

Slide 68

Slide 68 text

      まとめ Simple is Beautiful     

Slide 69

Slide 69 text

      まとめ Simple is Beautiful  ↓  常に追求した者だけが辿り着ける 

Slide 70

Slide 70 text

      まとめ本当に必要なモノを実装する     

Slide 71

Slide 71 text

      まとめ本当に必要なモノを実装する  ↓  そのためにプロダクト、ドメインと向き合う 

Slide 72

Slide 72 text

      まとめ

Slide 73

Slide 73 text

      まとめ質を追求した結果    パフォーマンスは後からついてくる 

Slide 74

Slide 74 text

良いソフトウェアを作ろう    目の前のプロダクトに向き合おう  まとめ