今まで生き残ってきたRDBMSとこの先10年戦えるデータストア戦略 / Database now and in the past

Developers Summit 2022の登壇資料です。

# 参考リンク
- https://eh-career.com/engineerhub/entry/2018/12/11/110000
- https://soudai.hatenablog.com/entry/2017/12/27/080000
- https://soudai.hatenablog.com/entry/2021/12/31/114009

Transcript

1. 今まで生き残ってきたRDBMSと この先10年戦えるデータストア戦略 ～ 次の10年を見据えたシステム開発 ～ Developers Summit 2022
2. 今日、話さないこと
 
 
 What is it?
3. 具体的なhowの話はしません
 
 
 What is it?
4. • 具体的なデータベースの選び方
 • パフォーマンス・チューニングのこと
 • データベース監視やバージョンアップ戦略などの 運用をするために必要なこと
 • データモデリングなどの設計に関すること
 今日は話さない具体的なhowの例
5. 今日のテーマ
 
 
 What is it?
6. この10年の歴史から
 
 次の10年を見据えた審美眼を身につける
 What is it?
7. あなたの目の前にあるデータベースが
 
 10年後、どうなっているか
 What is it?
8. 次の10年後のために
 
 なぜ、データベースが重要か
 What is it?
9. そして世の中のデータベースが
 
 これからどうなっていくか
 What is it?
10. そういう話をします
 
 
 What is it?
11. 1. 自己紹介
 2. この10年のデータベースの変化
 3. データベースのこれから
 4. 明日から現場で戦うために必要なこと
 5. まとめ
 あじぇんだ
12. 1. 自己紹介
 2. この10年のデータベースの変化
 3. データベースのこれから
 4. 明日から現場で戦うために必要なこと
 5. まとめ
 あじぇんだ
13. 自己紹介
 曽根 壮大（37歳）
 Have Fun Tech LLC 代表社員
 
 そ　 ね　　た け と も
 • 日本PostgreSQLユーザ会 勉強会分科会 担当
 • 3人の子供がいます（長女、次女、長男）
 • 技術的にはWeb/LL言語/RDBMSが好きです
 • コミュニティが好き
14. 1. 自己紹介
 2. この10年のデータベースの変化
 3. データベースのこれから
 4. 明日から現場で戦うために必要なこと
 5. まとめ
 あじぇんだ
15. 最初にとても大切なこと
 
 
 この10年のデータベースの変化
16. データベースは
 
 サービスの中心にある
 この10年のデータベースの変化
17. この10年のデータベースの変化 Web Server API Server 社内管理 Server データベース ブラウザ スマホ 社用PC 複数のサービスから 参照されることも珍しくない
18. データベースの寿命は
 
 アプリケーションよりも長い
 この10年のデータベースの変化
19. この10年のデータベースの変化 データベース データベース SNS SNS ECサービス Before After
20. この10年のデータベースの変化 データベース データベース Before After SNS ECサービス ECサービス 利用者減による サービス撤退
21. この10年のデータベースの変化 データベース データベース Before After 旧・ECサービス サービスが順調に成長したが 技術的な課題が積み重なった状態 新・ECサービス データベースの構造はそのままに アプリケーションだけをリプレイス
22. “一番最初にお伝えすべきことは、デー タベースの寿命はアプリケーションよりも 長いということです。これはどういうことで しょうか？
 想像してみてください。例えば、新しく SNSのサービスをリリースしたとします。 このSNSは1年、2年と順調にユーザー数 を増やしていきます。そして、獲得した ユーザーをより活用するため、新たにEC サービスをローンチしたとしましょう。 
 このECサービスがリリースされた瞬間か ら、SNSの会員データはECサービスと共 有されることになります。”
 https://eh-career.com/engineerhub/entry/2018/12/11/110000
23. そして、10年続くデータベースは
 
 珍しくないということ
 この10年のデータベースの変化
24. その前提の上で
 
 この10年の変化を振り返る
 この10年のデータベースの変化
25. この10年のデータベースの変化 “今と過去の差分を見ると未来が想像できる”
 　　 　
 
 小賀 昌法
 • トラボックス 社長室
 • CARTA HD Tech Boardアドバイザリ
 • 日本CTO協会 理事

26. 大体10年前のデータベースに
 
 関わるイベントを振り返る
 この10年のデータベースの変化
27. • Oracle Database 11g Release 1 のリリースは2007/9
 ◦ バージョン 11.2.0.4 でも2020/12/31でサポート終了
 • Oracle Database 12c Release 1 のリリースは2013/7
 ◦ バージョン 12.1.0.2 は 2022/7/31 でサポート終了
 ◦ 12.2.1の延長として18c(12.2.0.2)、19c(12.2.0.3)がリリース
 • Oracle Cloudの東京リージョンの開始は2019/5/8
 ◦ Oracle Cloudでのみ21cを提供している(2022/02/15現在)
 OracleDBのこれまで状況
28. • 2010/1/27/ SunがOracleに買収された
 ◦ MySQL 5.5のリリースは2010/12/15 → 2018/12 EOL
 ◦ MySQL 5.6のリリースは2013/2/5 → 2021/2 EOL
 ◦ MySQL 5.7のリリースは2015/10/21 → 2023/10 EOL予定
 ◦ MySQL 8.0のリリースは2018/4/19 → 2026/4 EOL予定
 • この10年でMySQLは無くなるのでは？という懸念は払拭された
 ◦ 現在もユーザーコミュニティも活発に活動中
 ◦ 3ヶ月毎に機能リリースがされ、パワフルな進化をしている
 MySQLのこれまで状況
29. • PostgreSQL 9.2のリリースが2012年9月10日
 • これまではバージョンの表記がx.y.zのx.yがメジャーバージョンであったが、 PostgreSQL 10(9.6のNext)からxがメジャーバージョンに変更
 • PostgreSQLは毎年、メジャーバージョンをリリース
 ◦ リリースされてから5年間サポート
 ◦ 2022/11/10のPostgreSQL 10がEOL
 • パラレルクエリ、パーテーション、ロジカルレプリケーション、マテリアライズド・ ビューなど商用DBで期待されるような機能が次々と追加された
 PostgreSQLのこれまで状況
30. この10年での最も大きな変化
 
 
 この10年のデータベースの変化
31. この10年での最も大きな変化
 ↓
 クラウドの台頭
 この10年のデータベースの変化
32. • Amazon Web Service
 ◦ 東京リージョンのサービスインは 2011/03/02 
 ◦ Amazon Aurora MySQLがリリースされたのは 2014/10 
 ◦ Amazon DynamoDB がリリースされたのは 2012/3/1 
 • Microsoft Azure
 ◦ 東京リージョンのサービス開始は 2014/02/26 
 ◦ Azure Cosmos DBがリリースされたのは 2017年 
 • Google Cloud Platform
 ◦ 東京リージョンのサービス開始は 2016/11/8 
 ◦ Google Cloud Spannerの論文は2012年には発表されていたが、一般ユーザが利用でき るようになったのは2017年から
 クラウドの台頭
33. クラウドによって変わったこと
 
 
 この10年のデータベースの変化
34. • フルマネージドサービスによるDevOpsの実現
 ◦ RDBMSのフルマネージドサービスによるDBAの開放
 ◦ Redisなどの提供によるNoSQLの普及
 ◦ インフラの調達が容易になり、スケールアップ、シャーディングなどの 選択肢がより充実した
 • AWS S3のような高可用性でElasticにスケールするオブジェクトストレージ の出現
 ◦ logを簡単に、適切に、大量に保存できる
 ◦ 大規模なデータをクラウドに保存する時代の到来
 クラウドによるデータベースの変化 その1
35. • 一定の規模までに対するインフラアーキテクチャのパターン化
 ◦ 本当の大規模・高負荷以外は対応できる
 ◦ クラウドベンダーの提供するホワイトペーパーを適切に活用すること が勘所になった
 • クラウドベンダー独自の技術によるNewSQLの到来
 ◦ NewSQLもクラウドベンダーが提供する答えの一つ
 • ビジネスのコアにより注力できるよう変化
 ◦ ビジネスの実現する上でのインフラのボトルネックがほぼ皆無
 ◦ つまりよりソフトウェアの開発速度がビジネスの速度を決める
 クラウドによるデータベースの変化 その2
36. クラウドによって変わったこと
 
 
 
 この10年のデータベースの変化
37. クラウドによって変わったこと
 ↓
 ソフトウェアがより重要になり
 ビジネスの変化が早くなった
 この10年のデータベースの変化
38. この10年で変わらなかったこと
 
 
 この10年のデータベースの変化
39. データベースは
 
 サービスの中心にある
 この10年のデータベースの変化
40. 置く場所は変わったが
 
 重要性は変わらない
 この10年のデータベースの変化
41. 1. 自己紹介
 2. この10年のデータベースの変化
 3. データベースのこれから
 4. 明日から現場で戦うために必要なこと
 5. まとめ
 あじぇんだ
42. 世界は常に変化していく
 
 
 データベースのこれから
43. 世界は常に変化していく
 ↓
 技術も変化していく
 データベースのこれから
44. 
 
 
 “技術の進歩は「螺旋」である”
 
 
 @t_wada
 
 
 データベースのこれから
45. 
 “技術の変化の歴史は一見すると振り子に見える
 
 でも実はらせん構造。同じところに戻ってこない
 
 差分とそれを可能にした技術が重要”
 
 
 https://speakerdeck.com/twada/worse-is-better-understanding-the-spiral-of-technologies-2019-edition?slide=10 
 データベースのこれから
46. この10年で生き残った技術
 
 
 データベースのこれから
47. この10年で生き残った技術
 ↓
 データモデリングとRDBMS
 データベースのこれから
48. この10年で生き残った技術
 ↓
 データモデリングとRDBMS
 データベースのこれから そもそも何十年も生き残っているし、インフラの進化によって、 理論上は出来るがパフォーマンスがボトルネックだったような設計も可能 になってきた
49. 変わっていないようにみえて
 
 螺旋を上がっている
 データベースのこれから
50. • 商用DBはより堅牢・高速・高機能に
 ◦ INDEXの自動作成などは当たり前に
 ◦ クラウドプラットフォームとセットにすることでハードウェアも合わせて チューニングされる
 ◦ アクセス制限、logなどの観点でもセキュアに
 ◦ Amazon AuroraもOSSベースの商用DBと言える
 • OSS RDBMSも進化
 ◦ 一般的に必要な機能は出揃っている
 ◦ 豊富な事例とコストメリットで広く普及
 RDBMSの技術の螺旋
51. • 商用DBはより堅牢・高速・高機能に
 ◦ INDEXの自動作成などは当たり前に
 ◦ クラウドプラットフォームとセットにすることでハードウェアも合わせて チューニングされる
 ◦ アクセス制限、logなどの観点でもセキュアに
 ◦ Amazon AuroraもOSSベースの商用DBと言える
 • OSS RDBMSも進化
 ◦ 一般的に必要な機能は出揃っている
 ◦ 豊富な事例とコストメリットで広く普及
 RDBMSの技術の螺旋 最新版を使うだけで高速化などのメリットを享受できる 商用DBもOSS DBも塩漬けにせずにバージョンアップ戦略が大事 またAWSなどでもサポート終了したバージョンは強制終了している
52. クラウドによって変わったこと
 
 
 データベースのこれから
53. クラウドによって変わったこと
 ↓
 フルマネージドの功罪
 データベースのこれから
54. 制限されたRDBMS
 
 制限されたリソース
 データベースのこれから
55. • ハードウェアリソースの制限
 ◦ クラウドと言えど無限ではない
 ▪ インスタンスサイズの限界など
 ◦ CPU、Network I/O、Disk I/O の上限はオンプレの方が高い
 ▪ しかし自分でメンテナンスすることとトレードオフ
 • ソフトウェアの制限
 ◦ 事前にチューニングされているが反面、制限がある
 ◦ 使えない機能・拡張がある
 ◦ ソースコードに手を入れれない
 フルマネージドの制限
56. • ハードウェアリソースの制限
 ◦ クラウドと言えど無限ではない
 ▪ インスタンスサイズの限界など
 ◦ CPU、Network I/O、Disk I/O の上限はオンプレの方が高い
 ▪ しかし自分でメンテナンスすることとトレードオフ
 • ソフトウェアの制限
 ◦ 事前にチューニングされているが反面、制限がある
 ◦ 使えない機能・拡張がある
 ◦ ソースコードに手を入れれない
 フルマネージドの制限 これらの制限とトレードオフで、 エラスティックなスケーラビリティと バックアップ設計やHA構成の フルマネージドなどの運用面のメリットがある
57. クラウドの台頭によって
 
 データベースの利用者と開発者の
 境界線がより明確になった
 データベースのこれから
58. データベースソフトウェアは
 
 より豊富に、より便利に
 データベースのこれから
59. 今後、この流れは加速していく
 
 
 
 データベースのこれから
60. 今後、この流れは加速していく
 ↓
 どの巨人の肩に乗るのか
 どのデータストアと共に歩むのか
 データベースのこれから
61. 世界は常に変化していく
 
 
 データベースのこれから
62. 如何に自分たちの
 
 ビジネスに注力するか
 データベースのこれから そのためには必要な課題解決の手法を見直す必要がある その課題のライフサイクルと将来の課題を見越した設計は 人しかできない
63. パフォーマンスやデータ量では無く
 
 変更に強いことが重要になる
 データベースのこれから
64. パフォーマンスやデータ量では無く
 
 変更に強いことが重要になる
 データベースのこれから 既存の設計手法の活用であれば正規化などのデータモデリング
65. パフォーマンスやデータ量では無く
 
 変更に強いことが重要になる
 データベースのこれから 新しい選択肢であれば NewSQLや クラウドインフラデザインパターンを活用したデータ設計 既存の設計手法の活用であれば正規化などのデータモデリング
66. そして、10年続くデータベースは
 
 珍しくないということ
 この10年のデータベースの変化
67. クラウドにあるデータベースが
 
 10年間運用される
 データベースのこれから
68. • 常に追従が必要なバージョン
 ◦ 本来はあるべき姿がオンプレ時代は臭いものに蓋をしていた
 • データは基本的に追加なので増加していく
 ◦ サービスが成長すればするほどデータ容量は増える
 ◦ エラスティックにストレージは増強できるので容量は問題ない
 ◦ コストは？ビジネスの成長と比例している？
 ▪ 無料利用ユーザが増えてストレージを圧迫したり
 ▪ 無限にログを残してストレージを圧迫したり
 • クラウドで解決できないパターンの時はどうする？
 10年後のクラウドのデータベース
69. • 常に追従が必要なバージョン
 ◦ 本来はあるべき姿がオンプレ時代は臭いものに蓋をしていた
 • データは基本的に追加なので増加していく
 ◦ サービスが成長すればするほどデータ容量は増える
 ◦ エラスティックにストレージは増強できるので容量は問題ない
 ◦ コストは？ビジネスの成長と比例している？
 ▪ 無料利用ユーザが増えてストレージを圧迫したり
 ▪ 無限にログを残してストレージを圧迫したり
 • クラウドで解決できないパターンの時はどうする？
 10年後のクラウドのデータベース • クラウドを活用して最適解を出すタイプ • クラウドで解けない問題を打開していくタイプ あなたはどちらを目指す？または両方？
70. この問題は
 
 すでに始まっている
 データベースのこれから
71. 1. 自己紹介
 2. この10年のデータベースの変化
 3. データベースのこれから
 4. 明日から現場で戦うために必要なこと
 5. まとめ
 あじぇんだ
72. 問題の本質は変わらなくて
 
 問題の解き方が変わっていく
 明日から現場で戦うために必要なこと
73. 求められる品質は上がっていくし
 
 変化の速度も上がっていく
 明日から現場で戦うために必要なこと
74. データは常に増えていくし
 
 ビジネスは常に変化する
 明日から現場で戦うために必要なこと
75. この現実と如何に戦うか
 
 
 明日から現場で戦うために必要なこと
76. この現実と如何に戦うか
 ↓
 変化に強い設計が肝要
 明日から現場で戦うために必要なこと
77. ”データベースよりアプリケーションのほうが絶対的に 変化に強いです。 テストコードも書きやすいし、振る 舞いのテストもしやすいし、振る舞いの変更もしやす いしです。 
 　そしてデプロイもデータベースに比べて簡単です。 データベースだとデプロイするときに、ロックのことを 考えなきゃいけないですし、マスター・スレーブのデー タの整合性を考えないといけません。
 　例えば同じことが、トリガーやストアドとアプリケー ションで出来ることが同じ場合、なぜアプリケーション が良いかというと圧倒的に元に戻しやすいし、変更し やすいからです。 
 　だからこそシステムの柔軟性を意識する際にRDBと アプリケーション側の責任分界点を意識することが大 切です。”
 https://soudai.hatenablog.com/entry/2017/12/27/080000
78. ”データベースにビジネスロジックを持たせ ることは悪手です。だからこそRDB側には 事実のみを保存することを意識することが 大切です。 
 　ただしアプリケーション側でデータを守ろう とすると、バグとヒューマンエラーにめちゃく ちゃ弱いです。
 　そこで変わってしまっては困るデータの事 実はRDBMSの制約の機能で守るのです。 ここがアプリケーションとRDBの責任分界点 です。”
 https://soudai.hatenablog.com/entry/2017/12/27/080000
79. ”データベースにビジネスロジックを持たせ ることは悪手です。だからこそRDB側には 事実のみを保存することを意識することが 大切です。 
 　ただしアプリケーション側でデータを守ろう とすると、バグとヒューマンエラーにめちゃく ちゃ弱いです。
 　そこで変わってしまっては困るデータの事 実はRDBMSの制約の機能で守るのです。 ここがアプリケーションとRDBの責任分界点 です。”
 https://soudai.hatenablog.com/entry/2017/12/27/080000
80. プロダクトやビジネスの課題を
 
 ソフトウェアの力で解決する
 明日から現場で戦うために必要なこと
81. それらを実現するために必要なこと
 
 
 明日から現場で戦うために必要なこと
82. それらを実現するために必要なこと
 ↓
 目の前のプロダクトと向き合う覚悟
 明日から現場で戦うために必要なこと
83. 明日から現場で戦うために必要なこと https://soudai.hatenablog.com/entry/2021/12/31/114009
84. 
 
 “手を動かした者だけが、世界を変える”
 
 
 
 株式会社はてな id:onishi
 明日から現場で戦うために必要なこと
85. プロダクトやビジネスの課題を
 
 ソフトウェアの力で解決する
 明日から現場で戦うために必要なこと
86. 1. 自己紹介
 2. この10年のデータベースの変化
 3. データベースのこれから
 4. 明日から現場で戦うために必要なこと
 5. まとめ
 あじぇんだ
87. データベースの寿命は
 
 アプリケーションよりも長い
 まとめ
88. 10年後も変わらずデータベースは
 
 サービスの中心にある
 まとめ
89. クラウドの覇権は続くが
 
 どの巨人の肩にどのように乗るかが大事
 まとめ
90. データモデリングの基本を守ることが
 
 ビジネスの変化についていくための勘所
 まとめ
91. 技術で問題を解決しよう
 
 
 まとめ
92. ご清聴ありがとうございました
 
 
 まとめ