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
今まで生き残ってきたRDBMSとこの先10年戦えるデータストア戦略～ 次の10年を見据えたシステム開発 ～Developers Summit 2022
View Slide
今日、話さないこと What is it?
具体的なhowの話はしません What is it?
● 具体的なデータベースの選び方 ● パフォーマンス・チューニングのこと ● データベース監視やバージョンアップ戦略などの運用をするために必要なこと ● データモデリングなどの設計に関すること 今日は話さない具体的なhowの例
今日のテーマ What is it?
この10年の歴史から 次の10年を見据えた審美眼を身につける What is it?
あなたの目の前にあるデータベースが 10年後、どうなっているか What is it?
次の10年後のために なぜ、データベースが重要か What is it?
そして世の中のデータベースが これからどうなっていくか What is it?
そういう話をします What is it?
1. 自己紹介 2. この10年のデータベースの変化 3. データベースのこれから 4. 明日から現場で戦うために必要なこと 5. まとめ あじぇんだ
自己紹介 曽根 壮大（37歳） Have Fun Tech LLC 代表社員 そ ね た け と も ● 日本PostgreSQLユーザ会 勉強会分科会 担当 ● 3人の子供がいます（長女、次女、長男） ● 技術的にはWeb/LL言語/RDBMSが好きです ● コミュニティが好き
最初にとても大切なこと この10年のデータベースの変化
データベースは サービスの中心にある この10年のデータベースの変化
この10年のデータベースの変化Web ServerAPI Server社内管理Serverデータベースブラウザスマホ社用PC複数のサービスから参照されることも珍しくない
データベースの寿命は アプリケーションよりも長い この10年のデータベースの変化
この10年のデータベースの変化データベース データベースSNS SNS ECサービスBefore After
この10年のデータベースの変化データベース データベースBefore AfterSNS ECサービス ECサービス利用者減によるサービス撤退
この10年のデータベースの変化データベース データベースBefore After旧・ECサービスサービスが順調に成長したが技術的な課題が積み重なった状態新・ECサービスデータベースの構造はそのままにアプリケーションだけをリプレイス
“一番最初にお伝えすべきことは、データベースの寿命はアプリケーションよりも長いということです。これはどういうことでしょうか？ 想像してみてください。例えば、新しくSNSのサービスをリリースしたとします。このSNSは1年、2年と順調にユーザー数を増やしていきます。そして、獲得したユーザーをより活用するため、新たにECサービスをローンチしたとしましょう。 このECサービスがリリースされた瞬間から、SNSの会員データはECサービスと共有されることになります。” https://eh-career.com/engineerhub/entry/2018/12/11/110000
そして、10年続くデータベースは 珍しくないということ この10年のデータベースの変化
その前提の上で この10年の変化を振り返る この10年のデータベースの変化
この10年のデータベースの変化“今と過去の差分を見ると未来が想像できる” 小賀 昌法 ● トラボックス 社長室 ● CARTA HD Tech Boardアドバイザリ ● 日本CTO協会 理事
大体10年前のデータベースに 関わるイベントを振り返る この10年のデータベースの変化
● 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のこれまで状況
● 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のこれまで状況
● 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のこれまで状況
この10年での最も大きな変化 この10年のデータベースの変化
この10年での最も大きな変化 ↓ クラウドの台頭 この10年のデータベースの変化
● 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年から クラウドの台頭
クラウドによって変わったこと この10年のデータベースの変化
● フルマネージドサービスによるDevOpsの実現 ○ RDBMSのフルマネージドサービスによるDBAの開放 ○ Redisなどの提供によるNoSQLの普及 ○ インフラの調達が容易になり、スケールアップ、シャーディングなどの選択肢がより充実した ● AWS S3のような高可用性でElasticにスケールするオブジェクトストレージの出現 ○ logを簡単に、適切に、大量に保存できる ○ 大規模なデータをクラウドに保存する時代の到来 クラウドによるデータベースの変化 その1
● 一定の規模までに対するインフラアーキテクチャのパターン化 ○ 本当の大規模・高負荷以外は対応できる ○ クラウドベンダーの提供するホワイトペーパーを適切に活用することが勘所になった ● クラウドベンダー独自の技術によるNewSQLの到来 ○ NewSQLもクラウドベンダーが提供する答えの一つ ● ビジネスのコアにより注力できるよう変化 ○ ビジネスの実現する上でのインフラのボトルネックがほぼ皆無 ○ つまりよりソフトウェアの開発速度がビジネスの速度を決める クラウドによるデータベースの変化 その2
クラウドによって変わったこと ↓ ソフトウェアがより重要になり ビジネスの変化が早くなった この10年のデータベースの変化
この10年で変わらなかったこと この10年のデータベースの変化
置く場所は変わったが 重要性は変わらない この10年のデータベースの変化
世界は常に変化していく データベースのこれから
世界は常に変化していく ↓ 技術も変化していく データベースのこれから
“技術の進歩は「螺旋」である” @t_wada データベースのこれから
“技術の変化の歴史は一見すると振り子に見える でも実はらせん構造。同じところに戻ってこない 差分とそれを可能にした技術が重要” https://speakerdeck.com/twada/worse-is-better-understanding-the-spiral-of-technologies-2019-edition?slide=10 データベースのこれから
この10年で生き残った技術 データベースのこれから
この10年で生き残った技術 ↓ データモデリングとRDBMS データベースのこれから
この10年で生き残った技術 ↓ データモデリングとRDBMS データベースのこれからそもそも何十年も生き残っているし、インフラの進化によって、理論上は出来るがパフォーマンスがボトルネックだったような設計も可能になってきた
変わっていないようにみえて 螺旋を上がっている データベースのこれから
● 商用DBはより堅牢・高速・高機能に ○ INDEXの自動作成などは当たり前に ○ クラウドプラットフォームとセットにすることでハードウェアも合わせてチューニングされる ○ アクセス制限、logなどの観点でもセキュアに ○ Amazon AuroraもOSSベースの商用DBと言える ● OSS RDBMSも進化 ○ 一般的に必要な機能は出揃っている ○ 豊富な事例とコストメリットで広く普及 RDBMSの技術の螺旋
● 商用DBはより堅牢・高速・高機能に ○ INDEXの自動作成などは当たり前に ○ クラウドプラットフォームとセットにすることでハードウェアも合わせてチューニングされる ○ アクセス制限、logなどの観点でもセキュアに ○ Amazon AuroraもOSSベースの商用DBと言える ● OSS RDBMSも進化 ○ 一般的に必要な機能は出揃っている ○ 豊富な事例とコストメリットで広く普及 RDBMSの技術の螺旋最新版を使うだけで高速化などのメリットを享受できる商用DBもOSS DBも塩漬けにせずにバージョンアップ戦略が大事またAWSなどでもサポート終了したバージョンは強制終了している
クラウドによって変わったこと データベースのこれから
クラウドによって変わったこと ↓ フルマネージドの功罪 データベースのこれから
制限されたRDBMS 制限されたリソース データベースのこれから
● ハードウェアリソースの制限 ○ クラウドと言えど無限ではない ■ インスタンスサイズの限界など ○ CPU、Network I/O、Disk I/O の上限はオンプレの方が高い ■ しかし自分でメンテナンスすることとトレードオフ ● ソフトウェアの制限 ○ 事前にチューニングされているが反面、制限がある ○ 使えない機能・拡張がある ○ ソースコードに手を入れれない フルマネージドの制限
● ハードウェアリソースの制限 ○ クラウドと言えど無限ではない ■ インスタンスサイズの限界など ○ CPU、Network I/O、Disk I/O の上限はオンプレの方が高い ■ しかし自分でメンテナンスすることとトレードオフ ● ソフトウェアの制限 ○ 事前にチューニングされているが反面、制限がある ○ 使えない機能・拡張がある ○ ソースコードに手を入れれない フルマネージドの制限これらの制限とトレードオフで、エラスティックなスケーラビリティとバックアップ設計やHA構成のフルマネージドなどの運用面のメリットがある
クラウドの台頭によって データベースの利用者と開発者の 境界線がより明確になった データベースのこれから
データベースソフトウェアは より豊富に、より便利に データベースのこれから
今後、この流れは加速していく データベースのこれから
今後、この流れは加速していく ↓ どの巨人の肩に乗るのか どのデータストアと共に歩むのか データベースのこれから
如何に自分たちの ビジネスに注力するか データベースのこれからそのためには必要な課題解決の手法を見直す必要があるその課題のライフサイクルと将来の課題を見越した設計は 人しかできない
パフォーマンスやデータ量では無く 変更に強いことが重要になる データベースのこれから
パフォーマンスやデータ量では無く 変更に強いことが重要になる データベースのこれから既存の設計手法の活用であれば正規化などのデータモデリング
パフォーマンスやデータ量では無く 変更に強いことが重要になる データベースのこれから新しい選択肢であれば NewSQLやクラウドインフラデザインパターンを活用したデータ設計既存の設計手法の活用であれば正規化などのデータモデリング
クラウドにあるデータベースが 10年間運用される データベースのこれから
● 常に追従が必要なバージョン ○ 本来はあるべき姿がオンプレ時代は臭いものに蓋をしていた ● データは基本的に追加なので増加していく ○ サービスが成長すればするほどデータ容量は増える ○ エラスティックにストレージは増強できるので容量は問題ない ○ コストは？ビジネスの成長と比例している？ ■ 無料利用ユーザが増えてストレージを圧迫したり ■ 無限にログを残してストレージを圧迫したり ● クラウドで解決できないパターンの時はどうする？ 10年後のクラウドのデータベース
● 常に追従が必要なバージョン ○ 本来はあるべき姿がオンプレ時代は臭いものに蓋をしていた ● データは基本的に追加なので増加していく ○ サービスが成長すればするほどデータ容量は増える ○ エラスティックにストレージは増強できるので容量は問題ない ○ コストは？ビジネスの成長と比例している？ ■ 無料利用ユーザが増えてストレージを圧迫したり ■ 無限にログを残してストレージを圧迫したり ● クラウドで解決できないパターンの時はどうする？ 10年後のクラウドのデータベース● クラウドを活用して最適解を出すタイプ● クラウドで解けない問題を打開していくタイプあなたはどちらを目指す？または両方？
この問題は すでに始まっている データベースのこれから
問題の本質は変わらなくて 問題の解き方が変わっていく 明日から現場で戦うために必要なこと
求められる品質は上がっていくし 変化の速度も上がっていく 明日から現場で戦うために必要なこと
データは常に増えていくし ビジネスは常に変化する 明日から現場で戦うために必要なこと
この現実と如何に戦うか 明日から現場で戦うために必要なこと
この現実と如何に戦うか ↓ 変化に強い設計が肝要 明日から現場で戦うために必要なこと
”データベースよりアプリケーションのほうが絶対的に変化に強いです。 テストコードも書きやすいし、振る舞いのテストもしやすいし、振る舞いの変更もしやすいしです。 そしてデプロイもデータベースに比べて簡単です。データベースだとデプロイするときに、ロックのことを考えなきゃいけないですし、マスター・スレーブのデータの整合性を考えないといけません。 例えば同じことが、トリガーやストアドとアプリケーションで出来ることが同じ場合、なぜアプリケーションが良いかというと圧倒的に元に戻しやすいし、変更しやすいからです。 だからこそシステムの柔軟性を意識する際にRDBとアプリケーション側の責任分界点を意識することが大切です。” https://soudai.hatenablog.com/entry/2017/12/27/080000
”データベースにビジネスロジックを持たせることは悪手です。だからこそRDB側には事実のみを保存することを意識することが大切です。 ただしアプリケーション側でデータを守ろうとすると、バグとヒューマンエラーにめちゃくちゃ弱いです。 そこで変わってしまっては困るデータの事実はRDBMSの制約の機能で守るのです。ここがアプリケーションとRDBの責任分界点です。” https://soudai.hatenablog.com/entry/2017/12/27/080000
プロダクトやビジネスの課題を ソフトウェアの力で解決する 明日から現場で戦うために必要なこと
それらを実現するために必要なこと 明日から現場で戦うために必要なこと
それらを実現するために必要なこと ↓ 目の前のプロダクトと向き合う覚悟 明日から現場で戦うために必要なこと
明日から現場で戦うために必要なことhttps://soudai.hatenablog.com/entry/2021/12/31/114009
“手を動かした者だけが、世界を変える” 株式会社はてな id:onishi 明日から現場で戦うために必要なこと
データベースの寿命は アプリケーションよりも長い まとめ
10年後も変わらずデータベースは サービスの中心にある まとめ
クラウドの覇権は続くが どの巨人の肩にどのように乗るかが大事 まとめ
データモデリングの基本を守ることが ビジネスの変化についていくための勘所 まとめ
技術で問題を解決しよう まとめ
ご清聴ありがとうございました まとめ
soudai
devops_vtj
matsuihidetoshi
prashantspol
eiki
ramimac
n1ru4l
line_developers
yusuke
yukihiromori
saboyutaka
pyama86
mamohacy
chriscoyier
addyosmani
jakevdp
lara
holman
ammeep
mclloyd
marcduiker
tanoku
stephaniewalter