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