RDBMSの苦手なことを 如何に乗り越えていくか / challenge-to-rdbms

# 参考資料
- イミュータブルデータモデル(入門編)
- https://www.slideshare.net/kawasima/ss-40471672
- イミュータブルデータモデル(世代編)
- https://www.slideshare.net/kawasima/ss-44958468
- スタースキーマ（基礎）
- https://zenn.dev/pei0804/articles/star-schema-design
- ディメンション・モデリング
- https://zenn.dev/pei0804/articles/dimensional-modeling
- 失敗から学ぶRDBの正しい歩き方
- https://amzn.to/3vfD5nJ

Transcript

1. RDBMSの苦手なことを 如何に乗り越えていくか ～ ハイトラフィック・ビックデータ対策 ～ PHPカンファレンス沖縄@2021
2. 多くの問題は
 
 RDBMSで解決できる
 What is it?
3. しかしRDBMSは銀の弾丸ではない
 
 
 What is it?
4. しかしRDBMSは銀の弾丸ではない
 ↓
 得手不得手を理解する
 What is it?
5. 今日はRDBMSの外の話
 
 
 What is it?
6. 大量のログデータを
 
 如何に上手く集計するか
 What is it?
7. 突然のハイトラフィック
 
 システム障害を如何に乗り越えるか
 What is it?
8. ECサイト…
 
 チケットの予約…
 What is it?
9. 現実の問題を
 
 如何に乗り越えるか
 What is it?
10. AWSの前提でお話します
 
 
 What is it?
11. AWSの前提でお話します
 ↓
 とはいえ、応用のできる話です
 What is it?
12. 1. 自己紹介
 2. 大量のデータを集計したい
 3. 突然のハイトラフィックでサービス障害
 4. ロック待ちの悪夢
 5. まとめ
 あじぇんだ
13. 1. 自己紹介
 2. 大量のデータを集計したい
 3. 突然のハイトラフィックでサービス障害
 4. ロック待ちの悪夢
 5. まとめ
 あじぇんだ
14. 自己紹介
 曽根 壮大（36歳）
 Have Fun Tech LLC 代表社員
 
 そ　 ね　　 たけ とも
 • 日本PostgreSQLユーザ会 勉強会分科会 担当
 • 3人の子供がいます（長女、次女、長男）
 • 技術的にはWeb/LL言語/RDBMSが好きです
 • コミュニティが好き
16. 本書きました

17. 1. 自己紹介
 2. 大量のデータを集計したい
 3. 突然のハイトラフィックでサービス障害
 4. ロック待ちの悪夢
 5. まとめ
 あじぇんだ
18. 人類に必要なのは
 
 ログデータからいい感じのテーブルを作る
 大量のデータを集計したい
19. 結論
 
 これができれば苦労しない
 大量のデータを集計したい
20. いい感じのテーブルを作る
 
 
 大量のデータを集計したい
21. いい感じのテーブルを作る
 ↓
 これがRDBMSだけで出来ないとき
 大量のデータを集計したい 出来たらRDBMSだけで良いのです
22. RDBMSの責務を超えるとき
 
 
 大量のデータを集計したい
23. RDBMSの責務を超えるとき
 
 • 集計クエリが難しすぎる
 • 集計クエリが終わらない
 • ログデータがDBに保存できない量
 大量のデータを集計したい
24. RDBMSの責務を超えるとき
 
 • 集計クエリが難しすぎる
 • 集計クエリが終わらない
 • ログデータがDBに保存できない量
 大量のデータを集計したい
25. 集計クエリが難しいときは
 
 設計が悪いか無知かのどちらか
 大量のデータを集計したい
26. 17章 複雑なクエリ “複雑なクエリが生まれるには理由があ ります。その理由はクエリを紐 解くこと で見えてきますが、おもに次の2つに分 けられるでしょう。” • 無知ゆえの豪腕 スキル不足に起因した、力技による解 決としての複雑なクエリ • 腐ったテーブルの腐ったクエリ テーブル設計に問題を抱えており、目 的を達成するため結果的に 複雑に なったクエリ
27. 良い設計とはなにか
 
 
 大量のデータを集計したい
28. 良い設計とはなにか
 ↓
 先人から学ぶ
 大量のデータを集計したい
29. レポートの先人に学ぶ
 
 
 大量のデータを集計したい
30. 大量のデータを集計したい
31. 大量のデータを集計したい
32. この話で3日ぐらい話せるので
 
 詳しくは @pei0804 にきいてください 
 大量のデータを集計したい
33. 良いクエリは
 
 良い設計に宿る
 大量のデータを集計したい
34. RDBMSの責務を超えるとき
 
 • 集計クエリが難しすぎる
 • 集計クエリが終わらない
 • ログデータがDBに保存できない量
 大量のデータを集計したい
35. リソースの資源には限界がある
 
 
 大量のデータを集計したい
36. リソースの資源には限界がある
 ↓
 制約と成果の関係が大事
 大量のデータを集計したい
37. 制約と成果の関係の例
 
 • いつまで・どうやって・何がほしい
 ◦ いつまで → 時間がどれだけ使える？
 ◦ どうやって → リソース、手段
 ◦ 何がほしい → 成果物はなにか
 大量のデータを集計したい
38. 多くの場合、リソースとして
 
 時間が犠牲になるし、時間で限界が来る
 大量のデータを集計したい
39. Batchの突き抜け
 ||
 特定のタイミングまでにBatchが終わらない
 大量のデータを集計したい
40. Batchが遅くなる理由
 
 
 大量のデータを集計したい
41. Batchが終わらない
 
 • 集計クエリが終わらない
 ◦ 結果がでかすぎる
 ◦ 集計対象がでかすぎる
 ◦ SQLが巨大すぎる
 大量のデータを集計したい
42. スコープを小さくする
 
 
 大量のデータを集計したい
43. スコープを小さくする
 ↓
 それができればRDBMSで戦える
 大量のデータを集計したい
44. RDBMSの責務を超えるとき
 
 • 集計クエリが難しすぎる
 • 集計クエリが終わらない
 • ログデータがDBに保存できない量
 大量のデータを集計したい
45. でかいデータと如何に戦うか
 
 
 大量のデータを集計したい
46. でかいデータと如何に戦うか
 ↓
 スコープが小さく出来ない
 大量のデータを集計したい
47. 適切なミドルウェアを選ぶしかない
 
 
 大量のデータを集計したい
48. 最近作った例
 
 
 大量のデータを集計したい
49. S3 大量のデータを集計したい json file json file json file json file Redshift Spectrum Redshift Aurora external tablesで Redshiftに読み込む 集計クエリ S3のfileを取り込む
50. Redshift Spectrum
 
 外部データをSQLで取り込む機能
 大量のデータを集計したい
51. external tables
 
 　外部のデータベースのテーブルを
 自分のテーブルのように参照する機能
 大量のデータを集計したい
52. これでログとRDBのマスタを
 
 Redshift上でJOINして集計できる
 大量のデータを集計したい
53. データストアを増やすときは
 
 最小限にすること
 大量のデータを集計したい
54. 1. 自己紹介
 2. 大量のデータを集計したい
 3. 突然のハイトラフィックでサービス障害
 4. ロック待ちの悪夢
 5. まとめ
 あじぇんだ
55. 鳴り続けるalert…
 
 飛び交う怒号と絶望のtimeout…
 突然のハイトラフィックでサービス障害
56. RDBMSの死は
 
 サービスの死
 突然のハイトラフィックでサービス障害
57. ハイトラフィックは突然やってくる
 
 
 突然のハイトラフィックでサービス障害
58. ハイトラフィックは突然やってくる
 ↓
 如何にハイトラフィックに備えるか
 突然のハイトラフィックでサービス障害
59. ハイトラフィックに備える
 
 ◦ スケールアップは全てに効く
 ◦ 正しくキャッシュを活用する
 ◦ ボトルネックを敢えて作る
 突然のハイトラフィックでサービス障害
60. ハイトラフィックに備える
 
 ◦ スケールアップは全てに効く
 ◦ 正しくキャッシュを活用する
 ◦ ボトルネックを敢えて作る
 スケールアップがもっとも効率良く問題を解決できる オンプレでは難しいクラウドを使うメリット 突然のハイトラフィックでサービス障害
61. 突然のハイトラフィックでサービス障害
62. 限界が来る前に
 
 改善を始めましょう
 突然のハイトラフィックでサービス障害
63. ハイトラフィックに備える
 
 ◦ スケールアップは全てに効く
 ◦ 正しくキャッシュを活用する
 ◦ ボトルネックを敢えて作る
 突然のハイトラフィックでサービス障害
64. キャッシュは麻薬
 
 
 突然のハイトラフィックでサービス障害
65. 16章 キャッシュ中毒 “キャッシュは前述のとおり、採用することで データの参照が高速化されます。 これは、省略した計算処理量が多ければ多 いほど劇的な効果を発揮します。 この効果は絶大で、前述のとおりその効果に 魅了される人も少なくありません。 また、キャッシュは一度使い始めると辞める ことが難しく、魅力と辞めることの難しさ、つ まり中毒性の高さから 「キャッシュは麻薬」と 比喩されることもあります。”
66. 16章 キャッシュ中毒 キャッシュしたデータの状態を意識する ことが難しく、参照時にどの状態なのかコード 側からは直感的に把握し辛い • キャッシュと元データの整合性を合わせる必要 がある • キャッシュの生存期間を決める必要がある • キャッシュを正しく読み取る必要がある
67. 16章 キャッシュ中毒 キャッシュしたデータのデバッグが難しく、どの データがキャッシュされているかを 把握し辛い • 参照されたタイミングのキャッシュがどの データか把握が難しい • どのデータがキャッシュされたか 把握が難しい • どこまでキャッシュされているのかの把握 が難しい • 意図しない結果となった場合、原因が キャッシュなのか元データの破損なのか 判断が難しい
68. キャッシュは最後の手段
 
 
 突然のハイトラフィックでサービス障害
69. ハイトラフィックに備える
 
 ◦ スケールアップは全てに効く
 ◦ 正しくキャッシュを活用する
 ◦ ボトルネックを敢えて作る
 突然のハイトラフィックでサービス障害
70. 防壁（ボトルネック）を作る
 
 
 突然のハイトラフィックでサービス障害
71. ボトルネックを作る例
 
 ◦ ログインにスリープを入れて待たせる
 ◦ 特定の処理でランダムに失敗させる
 ◦ オリンピックチケット方式
 突然のハイトラフィックでサービス障害
72. 　サービスを止めないことが目的で
 
 トラフィックを捌くのは手段
 突然のハイトラフィックでサービス障害
73. 　サービスを止めないことが目的で
 
 トラフィックを捌くのは手段
 突然のハイトラフィックでサービス障害 例えば在庫が限定される商品は在庫を捌くのが目的なので 在庫が無くなった後は全て 503でも究極良いし、誰に売っても良い
74. 全てがロック待ちで死んだりする
 
 
 突然のハイトラフィックでサービス障害
75. 1. 自己紹介
 2. 大量のデータを集計したい
 3. 突然のハイトラフィックでサービス障害
 4. ロック待ちの悪夢
 5. まとめ
 あじぇんだ
76. どんな優秀なシステムも
 
 排他ロック一つで落とせる
 ロック待ちの悪夢
77. 設計する上で
 
 ロックを意識する
 ロック待ちの悪夢
78. 論理設計で
 
 INSERTとDELETEだけで設計する
 ロック待ちの悪夢
79. ロック待ちの悪夢 https://www.slideshare.net/kawasima/ss-40471672 https://www.slideshare.net/kawasima/ss-44958468
80. ロック待ちの悪夢 https://soudai.hatenablog.com/entry/2018/05/01/204442
81. 13章 知らないロック “ロックはRDBMSを使ううえで重要な機能で す。必要不可欠であるからこそ、 正しい知識を持つことが重要です。 とくに今回のように、「今まで使ってきた RDBMSでは◦◦だったから別のRDBMSは □□なはずだ」と決め付けて実装するのは危 険です。”
82. 14章 ロックの功罪 “RDBMSの特性を理解していない場合、 並 列処理の部分で問題が発生します。 正しくトランザクションを理解し、 ロックを使いこなしましょう。 　ただし、当然ながらロックの多用は 並列度を下げ、パフォーマンスの問題になり ます。題名の「ロックの功罪」とはまさに、こ の毒にも薬にもなるロックの責務のことなの です”
83. RDBMSを使う上で
 
 ロックの種類と粒度を意識する
 ロック待ちの悪夢
84. 1. 自己紹介
 2. 大量のデータを集計したい
 3. 突然のハイトラフィックでサービス障害
 4. ロック待ちの悪夢
 5. まとめ
 あじぇんだ
85. RDBMSは
 
 とても強力なソフトウェア
 まとめ
86. だからこそ、正しく使うことが大切です
 
 
 まとめ
87. だからこそ、正しく使うことが大切です
 ↓
 多くのことはRDBMSで解決できます
 まとめ
88. 「知識がある」と「実践できる」には
 
 大きな絶対的な差がある
 まとめ
89. 知識 ＊ 経験 = できる！
 
 
 まとめ
90. 正しい知識を
 
 実践で活かしていくの自分たちです
 まとめ
91. 世の中をソフトウェアで良くしていく
 
 
 まとめ
92. ご清聴ありがとうございました
 
 
 まとめ