DBREをやめてみてわかる、DBREとは何だったのか
この記事は、DBRE Advent Calendar 2024 1日目の記事です(꜆꜄•ω•)꜆꜄꜆
遂に！遂にDBREのAdvent Calendarを作ることができました！！
憧れは止められないんだぜ、というセリフは有名ですが、憧れはいつか実現できるんですね…感無量でございます。
このAdvent Calendarの管理者をさせていただいています、tomoです。
初日、オープニングの記事としてはなかなか異色なタイトルを書かせていただきます。
「DBREをやめてみてわかる、DBREとは何だったのか」
どうかこの記事が、DBREをやってみたい、目指したいと思っている方に届きますように。
はじめに
自己紹介
こんな感じの人です。
そもそもReliaverity Engineeringとは何か？
先日 オープンセミナー2024@広島 でお話させていただいた、イントロダクション的資料がこちら。
気になる方だけ読んでください。ご存知のかたはスルーして、続きをお読みいただけると。
speakerdeck.com
Reliaverity Engineering と名乗ることの敷居の高さ
なんとかRE（これをXREと呼ばれている場合もありますが）に関する書籍は、最近どんどん増えてきましたね。
これがまた、採用している技術はCloudNativeなの当たり前だよね？ですし、分量も多いのなんの。
イベントやSNSではカッコいいSREの取り組み事例が次々あるものですから余計、「うちではそんなの無理」「こんな取り組みは会社単位で取り組まないと。でもそんなことは…」なんて言う感想や、お話を聞くことがあります。
分かる。
特にユニコーン企業（最近言わないですね）みたいなキラキラ企業は、最初からそれありきで組織を作っていたりするので比較的容易に出来ますが、老舗みたいな企業ではなかなか出来ない。
出来ない理由は数多にあれど、大体根本原因に「文化を変えることの難しさ」があって、文化を変えるってとてつもなく難しい。
それまでの考えや手法を変えることを恐れる人、変えることに賛同できない人は山ほどいる。それが企業規模が大きくなればなるほど、多く、難しくなる。
DBREという名前はどうも、敷居が高いようにとらえていらっしゃる方が多いと思います。
DBREをやっていた時に感じたこと
私はSREとDBREを3年ほどさせて頂いていました。
正直↑に書いた劣等感はすごく感じていたし、オライリーを読み返す度にため息をついていました。
何せ使っているメインDBがOracleDBで、事例があまりない。
大体事例に出てくるのはMySQLかPostgreSQLだし、いいなこれと思ったプラグインは、当時はOracleDBだと対応していない、とか。
くらうどねいてぃばない、ShardingとかScalingとか全然しない。（出来るけどライセンス買うお金ない）
ダッシュボードはあるけど、正直AWRかASHごりごり分析するような仕事ばっかりだし。
作業自動化とか多少したけど簡単なLamdaとか使って一部自動化した程度で、Step Functionsとか使って華麗な開発なんてしてないし。
毎日SQLレビューして「ここの実行計画、Range ScanだけどUnique Scanの方がよくない？」とか唸ってる程度だし。
他社さんの事例を見る度にまぶしすぎて、DBREとか名乗るのほんとやめよう…名ばかりだよ…なんて思ったことは多々ありました。
ありましたよ、山ほど。
DBREを辞めて振り返ったこと
そんな私ですが、DBREを辞めました。正確には転職してPdMになりました。理由は劣等感ではなく別の理由ですが、それはまた別の機会に。
そうしてふと、振り返ってみると…DBREをやっていた当時の劣等感に、疑問を覚えました。
そもそも、SREやDBREって何のためにやっていたんだっけ？
離れてみて初めて、俯瞰的に考えられた瞬間でした。
恐らくSREやDBREを現在進行形でやっていた人は多くいれど、あえて意図的に離れた人はそこまで多くないと思います。
そんな私だからこそできる、気付きがあったのかもしれません。
という内容をまとめてみたのが、第34回 中国地方DB勉強会でお話させていただいた、こちら↓
この勉強会は、DBREを離れてから初めて、登壇した際の話です。
そちらに記載させていただいた内容の一部が、このブログで深堀りしたいお話です。
DBREについて
Reliaverity Engineeringの存在意義を深堀りしてみる
SREの文脈でも言われていますが、Reliaverity Engineeringは「文化」だと捉えています。
Observabilityを実現するダッシュボードを作成し
批判なきpostmortemを実現し
SLA/SLOの実現に取り組み
Agility向上の為のリリースエンジニアリングを実現し
よくあるこのあたりは、ただの手段です。
そもそもこのことを考える前に、Reliaverity Engineeringを実現するために大切な事がありませんか。
あなたが属する組織や企業が、成し遂げたいことは、何ですか？
そもそも上記の手段というのはすべて、これの為に必要な手段です。
SREを生み出したGoogleは、顧客からの信頼性を上げたかった。信頼性を得た上で成し遂げたいことがあった。
だからSREという定量的な目標責任を実現する文化を生み出したのではないか。
もちろん「顧客からの信頼性を得る」というのは、どの企業にとっても大切なことです。
それは社会で価値を生み出す企業や組織によって軸であり基本であり、それ故にSREという文化が広がったのでしょう。
仮にこれが正しいとして、改めて確認したい。
あなたが属する組織や企業が、成し遂げたいことは、何ですか？
Agility向上？
Observabilityによるシステムのボトルネックを見つけたい？
それをして、誰が嬉しいの？それをすることで、どんな価値を生み出すの？
それはお客様にとって、組織や企業にとって、どんな嬉しいことがあるの？？
その目的に「信頼性」を用いて実現するのが、Reliaverity Engineeringではないかと思うのです。
そこに、Cloud Nativeは極論必須ではないですし、クラウドでなくてもいいのです。
EOSL目前のオンプレのサーバでも、所謂「化石みたいなシステム」であってもいいのです。
DBはモダンなNewSQLでもなく、一体いつの時代のバージョンのSQL Server？であってもいいのです。
端的に言うと、言いたいことはこれです。
手段は目的ではない。目的を見誤らないように。
DBREという組織やチームは必要か？
個人的に組織単位は必須ではないと思います。
繰り返しになりますが、DBREは文化です。
SREのメンバーが実現していれば、それで十分ではないかと思いますし。
DBAチーム、インフラチーム、何なら個人がやっていてもいいんです。
形にこだわる必要はありません。
大事なことは、目的とそれに対し価値を生み出しているか、です。
DBREが実現することの代表例
さてそんな前提を伝えたところで、本題のDBREについてです。
DBが生み出す価値は年々上がっているように思います。
もはやAI時代において、DBはなくてはならない存在です。
何せ彼らAIが学習するのに必要なデータの大抵は、DBに存在しています。
またRDBMSから始まったDBは、KVS、NoSQL、NewSQLと様々な進化を遂げ、今後更に進化を続けていくでしょう。
そんなDBに対する信頼性向上を実現するDBREが抑えなければいけない点は、大まかに言うと以下点かなと思います。
ここはDBRE本に書いてある内容と、少し違う観点も書きます。なるべく端的に、3つ。
- データの正しさを守る
- データの価値を上げる
- データをDBREだけのものにしない
データの正しさを守る
これは詳細な説明不要ですよね。
企業内やお客様に「正しいデータに基づいてサービスを提供する」ということです。
DBに格納されているデータの正しさを守るのは、信頼性を守るために、DBREの基本中の基本です。
その中にはデータの内容という論理的な意味であったり、データブロック的な（つまりアクセス可能にする、壊れていないデータ）という物理的な意味の両面がある認識です。
またセキュリティ的な側面もあると思います。改ざんに対する防御、監査ログと監視、暗号化と復号化…あぁ、バージョンアップも。
たった一言で言いましたが、やること沢山ありますね。
データの価値を上げる
DBにあるデータは大抵、利用価値が高いことが多いです。
ただそれが、一部だけでしか利用されていなければ、勿体ないですよね。
DBREがすることは「DBのデータで更に企業や顧客に価値を提供すること」ではないかと思います。
例えば顧客情報DBはアプリケーションがメインに使っています。
でも、データ分析基盤にデータ同期すれば、マーケティングや経営分析に有用な情報かもしれません。
でもただデータ同期をすればいいわけじゃない。顧客情報は個人情報を含まれる。
さぁどうすれば、そのデータを価値あるものにできる？それを考えるのも、DBREの仕事ではないかと思います。
データをDBREだけのものにしない
仮にDBREという組織、またはDBエンジニアという肩書を持っていた人がいれば。
DBを、DBエンジニアだけが管理するようにしないことです。
そこには様々な理由がありますが、私は「DBエンジニアがより技術力を高めること、経営面を意識する時間を得るために必要なこと」と考えています。
DBエンジニアしか管理できないDBのことを、DBRE本では「ペット」と呼んでいます。
ペット(DB)の世話につきっきりになっている飼い主(DBエンジニア)という、比喩です。
もちろん alter system 〜や drop、truncateなんてコマンドは、DBの知識がない人が実行すると大障害を引き起こす可能性もあります。
だからといって完全に分業化すると、ナレッジの偏りや属人化を生み出します。
この目的本質は、DBエンジニアが実現する全てを他のエンジニアが出来るようにする、ではないです。
簡単な日々の実行しているクエリで、そこまでリスクが高くないもの、定型化できるものはありませんか？
どれだけリスク低く、DBエンジニア以外がDBに対するオペレーションを出来るようにするか、ということです。
そこには自動化やリスク低減化に対する様々な実現方法があるでしょう。
そうして、DBエンジニアはDBから離れて、他の技術や経営面を考える時間を生み出しましょう。
そこでCloudNativeの技術を学ぶ、経営状況からDBを用いて出来る利益向上や価値創出を考える。その時間が必要です。
自動化という点において、CloudNativeな技術を採用していると実現しやすいという話は、確かにあります。
とは言え、全てができないと諦めることはもったいないです。
そもそもpostmortemは技術云々ではなく文化ですし、Observerbilityは案外、監視サーバが前からやっていることに近い場合もありますよ、ほら。
DBREが体現する「信頼性から生み出す価値」
さてここまで「DBREがよくやるであろうこと」です。
これらの内容もすべて「手段」にしか過ぎないことを、お気づきになられましたか？
もしかしたら私が劣等感を感じていた「SQL実行計画のレビュー」は、この中に当てはまっていたのかもしれません。
そのレビューをしなければ、該当機能の処理は著しく低下していたのかもしれない。
ECサイトであればお客様が欲しい商品を買えなかったかもしれないですし、動画配信サービスであれば映画の配信スピードの低下に顧客体験の悪化から顧客離れを招いていたかもしれない。
それらは全て、企業や組織が顧客に提供したいこと、実現したいことに反することだったのかもしれません。
やっていることは泥臭いことでしたが、生み出していた価値はその企業にとって大切なものだったのかもしれないんですよね。
振り返ってみると、カッコよさはなかったかもしれないけれど、DBREっぽいことは出来ていたんじゃないかなと、今になってそう思えるようになりました。
繰り返しになりますが、手段が何であることに囚われる必要は無いと考えています。
大切なことは、信頼性から何を成し遂げたいのか。どのような価値を提供したいのか。
そしてその先にある、目的です。
おしまいに
DBREって、そんなにハードル高くないでしょ？
なんてことでしょう、SQLの実行計画レビューもDBREの一つらしいですよ、皆様。
ハードルを低くしすぎることも良くないかもしれませんが、逆に高過ぎることはまた、阻害要因にもなります。
実は皆さんが暗黙の了解で、当たり前にしていること。
DBREもそれに名前をつけたものなのかも、しれませんね。
この考えが正しいというわけではありません。
そんなの名ばかりのDBREだよと、笑われちゃうかもしれません。
それでも、笑われても。
Reliaverity Engineeringを、信頼性を得ることで生み出す価値を届けること。
その軸があれば、立派な「DBRE」なのではないでしょうか。
過去の私と同じように、DBREにハードルを感じている方へ
使っている技術が古い。
手段は何でもいいんです、目的が大事です。
使っているDBエンジンがあまり事例がない。
まだ使っている人が少ないなら、ぜひ布教活動をしてみましょう。
OracleDB、SQL Server、DB2…決して古いとか、モダンじゃないとかじゃないですよ。
そのDBエンジンを使っているのには大抵、理由があって。その理由を変えていけるのであれば、変えるのも一つかもしれない。
世の中に事例として出せない、守秘義務がある、立場的に公表できない…いろんな理由があるんですよね。
それらのDBエンジンは、DBという技術を長く支えてきた素晴らしい製品です。
そしてそれらの大抵は、社会基盤を支えている重要なサービスに使われているんですよね。
社会基盤という最も信頼性が必要となる、当たり前に動くサービスを支えているんです。
誰かが笑っても、立派なDBREじゃないかって私は拍手喝采しますよ。
明日の記事のご紹介
さて！明日は RmcHoshiさんによる「見えないエラーの原因とは？ Amazon Aurora MySQL 2で発生したDatabase Collationによるmysqldumpコマンドのエラーメッセージなしで処理が終了する現象について」です。
いやーmysqldumpは長年お世話になってきたdump機能ではあるのですが…Collationによるエラーがあるのに、メッセージが出ない？？！
えええそんな罠ってあるの？！
今からワクワクですね(◍•ᗜ•́)✧
