LoginSignup
TrendQuestionOfficial EventOfficial ColumnOpportunitiesOrganization
14
8

More than 3 years have passed since last update.

@tzkoba

posted at

【#CNDT2019 登壇記録】Cloud Native Stoageが拓くDatabase on Kubernetesの未来

PostgreSQL,kubernetes,Rook

登壇資料

CloudNativeDays Tokyo 2019で私が発表した資料は、SpeackeDeckにあげています。
普段のLTより少し硬いイメージの発表資料に仕上げてみました（途中おふざけはありますが）。

当日の様子

7/22（月）の15時40分から40分間、RoomBで発表を行いました。
同じ時間帯にMySQL Operatorのセッションがあったり、注目のKnativeの話もあったりと裏番組が強力で、集客の自信は全くなかったのですが、多くの方にお越し頂きました。
本当にありがとうございました。

（会場の様子）
IMG_0504.jpg
※来ているオレンジのTシャツはPGConf.Asia 2018で登壇者向けに頂いたものです。ポスグレ勢の立場表明のつもりで着用しました。

当日は、

  • イントロダクション(Cloud Nativeなデータベース/ストレージ）で8分
  • K8sでデータベースを動かす際の課題で10分
  • DB on K8sの実装例紹介で15分
  • DBプラットフォームとしてのK8sで7分

と時間配分をしていましたが、実装例で一部飛んでしまった部分があったのか、最後は時間が少し余りました。その分、最終章に思いを込められたかなとは思います。

セッションに関する感想

いくつか感想のツイートを見つけることも出来ました。


Kubernetesガチ勢の中で古参のDBエンジニアとしての色を出すために、DBクラスタリングの説明にも時間を割きましたが、思いが伝わっていれば大変嬉しいです。


Operatorにつながる流れについてもコメント頂き、こちらも感謝です。

セッション後の質問と私なりの回答

数人の方とはセッション後に直接お話して、議論を交わすことが出来ました。
備忘録のために自身で呟いたものを紹介しておきます。

これはDB on K8sと聞いて多くの方が抱く疑問ではないかと思います。RDSやAuroraなどManagedなサービスがあるんだから、それを使えば良いのでは？ということですね。

こうした質問への私の回答は一貫していて、

「その通りです。RDSもAuroraもサービス提供を強力に手助けしてくれる強力なプラットフォームです。どんどん使っていきましょう。」

ということです。ただ、一エンジニアとしての思いは別にあるのでそれは後ほど。


Cloud Native StorageとDBを組み合わせるという考えを、深く理解して頂いた上でのご質問でした。

私の回答としては後に書く経緯でも触れるのですが、マイクロサービスにおける共有DBアンチパターンを意識しています。

「機能や顧客単位などで分割されたマイクロサービスではバックエンドに巨大なデータベースは不要となり、分割されたサービス毎のDBが沢山生まれてくる。その際にはPostgreSQL+DRBDの構成もシンプルさと効率の良さから採用される可能性が出てくる。」

と、お答えしています。

話しきれなかったこと

DB on K8sの現在と未来（予想）について私なりの考えを述べることができた一方で、このテーマで登壇した背景・思いなどに触れる時間はありませんでした。CNDTでの発表は私の中でも大きな区切りになるものですので、一度それらを整理しておきたいと思います。

なぜDatabase on Kubernetesの話をし続けるのか

どなたかがセッションで仰っていたと思うのですが、こんな意見がありました。

新技術探求のモチベーションは日常業務への飽き、退屈から来ている。

これには私も深く頷いてしまいました。
既存ビジネスを守ることが優先となり、インフラエンジニアがチャレンジできる機会はそう多くはありません。データベースともなれば、安定性が最優先でリスクは犯せないのは当然のことです。

ただ、現在当たり前に使われている下記構成も安定運用に至るまでに沢山のチャレンジが繰り返されてきました。

  • 仮想マシン上のデータベース
  • パブリッククラウド上のマネージドなデータベース・サービス

過去には（といっても20年程度前ですが）、「データベースOSはUNIX、ストレージもファイルシステムフォーマットはせずにRAWデバイスで。」という時代があったのです。その頃からインフラ技術の変遷を見てきている人間としては、Kubernetesまたはその次に来るオーケストレーター・ツールでDBを管理することが普及したとしても驚きはしません。

Linux-HAやVM上でのレプリケーション、Managedなサービスなど、現状の選択肢から一歩踏み出すことがDBエンジニアとしての成長に必要ではないかと考え続けています。

今回の発表内容になった経緯

まず、セッションタイトルはCFP出した時から変更していません。
しかし、当初考えていたのは

  • PGConf.Asiaで試したPostgreSQL+Rook/Cephは性能悪かったので、DRBDを試そう。
  • DBはこれからOperetor管理になる、KubeDBを試そう。
  • 他にもNetApp TridentやStorageOSなんかも気になるな。

というぐらいで、Kubernetes Nativeなストレージとデータベースを色々紹介しようと思っていました。ですが、スライドの流れを考えていく中で2つの転機がありました。

マイクロサービスにおける共有DBアンチパターン

一つは以下でツイートしたように、マイクロサービスにおけるデータベースの在り方について考えたことです。

Cloud Nativeという文脈ではデータベースは簡単にプロビジョニングできて、かつスケールも容易でないとダメなように思われます。ただ、マイクロサービスの観点でサービスが分割されていくとその後ろにあるデータベースも単一で巨大なものにするのか、サービスと同じ単位で分割するのかということを考える必要があります。

songmuさんやブログ内で紹介された書籍は後者の分割されたDBを支持しており、その構成を前提とすれば、K8sによる宣言的設定やプロビジョニングの容易性などをデータベース管理にも持ち込むことが出来るのではないかと考えました。

残念ながら勉強不足で、この分野での言及はCNDTのセッションでは出来ませんでした。しかし、別途調査を進めているDBRE（Database Reliability Engineering）と繋がる可能性をもつ、重要な方向性になると思っています。

今後、どこかで考えをまとめて発表したいと思います。

分散システム上のデータベースについて

これは下記でツイートしたように、ZooKeeperの本をたまたま読んでいて、フェンシングの概念を説明する箇所を見つけて閃きました。

DB on K8sが難しいと思われる理由って何なんだろう？という疑問に対して、出来る限り背景を示して答えたいと考え、そのヒントを分散システムに関する議論からもらったという感じでしょうか。

今ならこちらでしょうね。発表数日前に出版された新しい本ですが、内容的には直球ど真ん中です。これから頑張って読みます。

類似の発表について

タイミングについては偶然だと思うのですが、JPOUGでも類似の発表がありました。

こちらは私が「Database on Kubernetesの未来」の兆候として示したAWS Aurora、Azure Hyperscaleを、Oracleコミュニティとしての視点で分析して下さった発表だったようです。

私もAuroraとHyperscaleは非常に参考にしており、下記のブログなどを参考にさせて頂きました。

どちらも日本語でこのような解説が読めることに感謝しきりです。

まとめ

CFPの選考結果が発表されたのが4月頃だったでしょうか。
そこから2-3ヶ月かけて準備してきた登壇が一応の成功を収めたことに、まずはホッとしています。CNDTの運営の方々、そして関連コミュニティの方々には大変お世話になりました。

この活動がどこまで進むのか、まだ私にも分かっていないのですが、少なくとも下期に向けてPostgreSQLのコミュニティ向けに同様の内容をぶつけてみたいと思っています。

どこかで私をお見かけの際には気軽に話しかけて頂けると喜びます（表情には出ないかも知れません）。

Register as a new user and use Qiita more conveniently

  1. You get articles that match your needs
  2. You can efficiently read back useful information
What you can do with signing up
Sign upLogin
14
8