DBプラットフォームの変遷 - ベアメタル、VM、そしてコンテナへ

DBプラットフォームの変遷 - ベアメタル、VM、そしてコンテナへ

2020/5/20、Infra Study Meetup#2のLT資料です。

Cd891a89dfec6ca7bd278b5f5bd87c90?s=128

tzkoba

May 20, 2020
Tweet

Transcript

  1. 2.

    2 最近やっていること • July Tech Festa 2019 “Cloud Native開発者のための Database

    with Kubernetes” • NewSQL関連のブログ投稿 “2020年現在のNewSQLについて” “NewSQLコンポーネント詳解” + =∞
  2. 3.

    3 1. 時は流れて - 2000年以降のDBプラットフォーム - 2. ベアメタルの時代 - 物理サーバ,

    UNIX - 3. Exadataの衝撃 - 専用サーバという浪漫 - 4. VMの時代 - VM HAのとりこ - 5. そしてコンテナへ - 変化を求められるDBMS - アジェンダ
  3. 4.

    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
  4. 5.

    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/
  5. 6.

    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/
  6. 7.

    7 VMの時代 - VM HAのとりこ - 4. • VMへの適応はDBは時間を要した。 •

    理由はパフォーマンス。仮想化のオーバーヘッドを避ける傾向が強かった。 • vSphere 4以降、流れが変わってきた印象。HW性能が上がってきたことに 加え、仮想化による運用上のメリットを無視できなくなる。 • Active-Standbyだけでなく、Primary-Secondaryなどの構成も可能に。 P S S 【PostgreSQLのReplication】 【共有Diskを用いたVM HA】
  7. 8.

    8 そしてコンテナへ - 変化を求められるDBMS - 5. • コンテナ、Kubernetesへの対応もVM時代と同様、DBは遅れている印象。 • 太い帯域、低いレイテンシがDBサーバの足回りには必要?

    • やっぱりDBは急に落ちては困るし、勝手に落とされても困る? • コンテナ、Kubernetesのコンセプトと合わないのでは? operator -0 -1 -2 postgres snapshot 【NewSQL with Kubernetes】 【Kubernetes Operatorパターン】