Upgrade to Pro
— share decks privately, control downloads, hide ads and more …
Speaker Deck
Sign up for free
Menu
Search
Features
All features
Private URLs
Password Protection
Custom URLS
Scheduled publishing
Remove Branding
Restrict embedding
Deck Collections
Notes
Features
All features
Private URLs
Password Protection
Custom URLS
Scheduled publishing
Remove Branding
Restrict embedding
Deck Collections
Notes
Explore
Featured decks
Featured speakers
Programming
Technology
Storyboards
Explore
Featured decks
Featured speakers
Programming
Technology
Storyboards
Pricing
Search
Sign in
Sign up for free
DBプラットフォームの変遷 - ベアメタル、VM、そしてコンテナへ
Search
Sponsored
·
Your Podcast. Everywhere. Effortlessly.
Share. Educate. Inspire. Entertain. You do you. We'll handle the rest.
→
tzkoba
May 20, 2020
Technology
5.6k
6
Share
Embed
Copy iframe code
Copy JS code
Copy link
Start on current slide
DBプラットフォームの変遷 - ベアメタル、VM、そしてコンテナへ
2020/5/20、Infra Study Meetup#2のLT資料です。
tzkoba
May 20, 2020
More Decks by tzkoba
See All by tzkoba
The State of Distibuted Database In Japan
tzkoba
1
1.6k
#CloudNativeDB NewSQLへの誘い
tzkoba
4
3.5k
Cloud Native時代のデータベース
tzkoba
13
16k
2020年DBプラットフォーム (超個人的)5大ニュース
tzkoba
0
1.3k
PostgreSQLプラットフォームの徹底比較(コンテナからクラウドまで)
tzkoba
6
12k
Kubernetesでストレージ?そもそも何に使えるの?
tzkoba
0
1.3k
データ損失を回避しよう 各DBの機能比較
tzkoba
3
2.4k
昨今のデータデバイス(アーカイブ編)
tzkoba
3
1.8k
理解して拡げる分散システムの基礎知識
tzkoba
21
11k
Other Decks in Technology
See All in Technology
安心して変更できるWebフロントエンドの作り方
pirosikick
4
2.2k
AIを活用するために決めた "やらないこと" - 価値に注目する / Not betting on AI
soudai
PRO
1
500
2026-09-09 【sigma_ucj#1】Sigma を IaC 管理したい! / IaC for Sigma
civitaspo
0
130
データ_AIの事業の勝敗をわけるもの
nek0128
0
260
幾何アルゴリズムで なめらかなピン操作を / iOSDC Japan 2026 / smoothpin
kazumanagano
0
340
MCPをつなげて作る組織横断のAIエージェント基盤(の開発工程)
tsubakimoto_s
0
110
アクセスキーこわい やめかたと漏らさない工夫
sassssan68
1
120
AIネイティブプロダクトで顧客価値を最大化するプロダクトエンジニアとFDEの協働
righttouch
PRO
0
280
SREは、MCPとAutopilotをこう使え!
kazumax55
2
730
SQL文一行も書けない人事がCortexもろもろを使って人事業務を楽にしてみる
ponponmikankan
1
240
積み重なった技術負債への挑戦 〜初手としての全社ゴト化〜
techtekt
PRO
0
720
Snowflakeのコスト最適化を支えるアーキテクチャ設計
ktatsuya
1
1.6k
Featured
See All Featured
BBQ
matthewcrist
89
10k
Build your cross-platform service in a week with App Engine
jlugia
234
19k
Max Prin - Stacking Signals: How International SEO Comes Together (And Falls Apart)
techseoconnect
PRO
0
460
Technical Leadership for Architectural Decision Making
baasie
3
570
"I'm Feeling Lucky" - Building Great Search Experiences for Today's Users (#IAC19)
danielanewman
230
23k
Building a A Zero-Code AI SEO Workflow
portentint
PRO
0
720
4 Signs Your Business is Dying
shpigford
187
23k
Cheating the UX When There Is Nothing More to Optimize - PixelPioneers
stephaniewalter
287
14k
Applied NLP in the Age of Generative AI
inesmontani
PRO
4
2.5k
Build The Right Thing And Hit Your Dates
maggiecrowley
39
3.4k
Practical Tips for Bootstrapping Information Extraction Pipelines
honnibal
25
2.1k
Optimizing for Happiness
mojombo
378
71k
Transcript
DBプラットフォームの変遷 - ベアメタル、VM、そしてコンテナへ - Infra Study Meetup #2 , 5/20
@tzkb
2 最近やっていること • July Tech Festa 2019 “Cloud Native開発者のための Database
with Kubernetes” • NewSQL関連のブログ投稿 “2020年現在のNewSQLについて” “NewSQLコンポーネント詳解” + =∞
3 1. 時は流れて - 2000年以降のDBプラットフォーム - 2. ベアメタルの時代 - 物理サーバ,
UNIX - 3. Exadataの衝撃 - 専用サーバという浪漫 - 4. VMの時代 - VM HAのとりこ - 5. そしてコンテナへ - 変化を求められるDBMS - アジェンダ
4 時は流れて - 2000年以降のDBプラットフォーム - 2000 2020 2010 2005 2015
HW: ベアメタル OS: UNIX DBMS: 商用DB ベアメタル Linux 商用DB/OSS-DB 仮想マシン Linux 商用DB/OSS-DB コンテナ OSS-DB VMware vSphere 4 Red Hat Enterprise Linux 5 Docker Kubernetes PostgreSQL 8 1. Oracle Exadata
5 ベアメタルの時代 - 物理サーバ,Unix - 2. • ハードウェアとOSはセットでベンダから買う時代。 • OracleなどのDBMSはオープンを標榜、様々なOSに対応していた。
• 巨大なDBサーバを数台並べて、HA構成。 • その後ダウンサイジングされたが、システム内で最も高価なのが、 DBサーバとストレージ。 2000年当時の サーバ室に並べられた IBM RS6000 SPが2台と ストレージのセット。 それぞれ冷蔵庫以上の大きさ。 ※画像出典 http://www.computinghistory.org.uk/det/6535/IBM-RS-6000-SP2-Type-7025/
6 Exadataの衝撃 - 専用サーバという浪漫 - 3. • DB専用機 Oracle Exadataが2008年に登場。
• 汎用的なサーバとOS、ストレージを選んで購入していた、DBエンジニアに 衝撃を与える。 • 「何もしなくても速い!」 (注)それまでに比べると、、、 • 国内でもInsight QubeというDBアプライアンスが開発・発売された。 今では当たり前の - カタログ見て簡単に選べる - すぐ使える(電源を入れれば) - 面倒な設定不要(それまでに比べれば) を実現。DBエンジニアの浪漫であり、 最終兵器だった。 ※画像出典 https://blog.oracle-ninja.com/2011/06/08/exadata-x2-8-installation-pics/
7 VMの時代 - VM HAのとりこ - 4. • VMへの適応はDBは時間を要した。 •
理由はパフォーマンス。仮想化のオーバーヘッドを避ける傾向が強かった。 • vSphere 4以降、流れが変わってきた印象。HW性能が上がってきたことに 加え、仮想化による運用上のメリットを無視できなくなる。 • Active-Standbyだけでなく、Primary-Secondaryなどの構成も可能に。 P S S 【PostgreSQLのReplication】 【共有Diskを用いたVM HA】
8 そしてコンテナへ - 変化を求められるDBMS - 5. • コンテナ、Kubernetesへの対応もVM時代と同様、DBは遅れている印象。 • 太い帯域、低いレイテンシがDBサーバの足回りには必要?
• やっぱりDBは急に落ちては困るし、勝手に落とされても困る? • コンテナ、Kubernetesのコンセプトと合わないのでは? operator -0 -1 -2 postgres snapshot 【NewSQL with Kubernetes】 【Kubernetes Operatorパターン】
9 まとめ ベアメタル->VMと技術の進歩にDBは確実に追随してきた。 今はクラウドのManaged Serviceを使うのが便利な時代。 しかし、DBのプラットフォームはコンテナ、そして Kubernetes
へ移っていくことは確実。 DBMSの進化もそれを後押しする。 DB with Kubernetes、やっていきましょう。
10 Questions? @tzkb @tzkoba