DBRE のタスクの起源を言語化してみる

この記事は、DBRE Advent Calendar 2024 13日目の記事です。(間がものすごく空いているので書いていただける方はぜひ埋めてくださいませｍｍ)

そしてさらに懺悔です、本当は先週の金曜日に公開しなければならなかったのですがこんなに遅くなってしまいました。。。

1日目の ＠tomomo1015 さんの記事「DBREをやめてみてわかる、DBREとは何だったのか」、とても良かったですね、なるほどなぁと思いながら読ませていただきました。

さて、僕自身も DBRE をやらせていただいる中で、DBRE ってなんなのか？Platform Engineering と何が違うのか？と言うところを言語化できずに、結構モヤモヤしています。

なぜなら、僕たちが日々仕事の中で提供している何か、は Platform Engineering と被ってない？と言うのが拭えなかったからです。

要は DBRE って結局なんなんだっけ？ということがふわっとしていて全く言語化できていなかったのです。

そんな中、最近それを言語化する最適な言葉が見つかったので自分に読み聞かせるようにテイストを変えて、ちょっとエモい感じで描いてみました。

ChatGPT の要約

自分で書いておきながらですが、気持ちだけで書いてしまったのでかなり周りくどく途中でわからなくなってしまいましたｗｗｗ

なので書いたものを ChatGPT に要約してもらいました。このセクションだけ読んでいただければいいのかなと思います。

DBRE の本質を捉えるための視点の違い

DBRE (Database Reliability Engineering) の役割やタスクの起源を言語化し、その本質を捉え直す試みを述べています。特に、Platform Engineering や SRE (Site Reliability Engineering) との違いに注目し、それぞれの注力する方向性や課題の捉え方の違いが解説されています。

Platform Engineering の注力点

• 開発者がラップトップ上で書いたコードを本番環境に届ける「生産ライン」の整備。
• CI/CD パイプラインや開発環境の最適化を通じて、開発者体験の向上に焦点を当てる。
• 本番環境へ進む「流れ」を安全・高速にする「足場」の構築。

SRE の注力点

• 本番環境の信頼性と安定性にフォーカス。
• 本番からラップトップへ「逆向き」に視線を遡り、問題を解決する。
• 信頼性を構築するための問いかけを繰り返す。

DBRE の注力点

• データを中心に据えた視点で、本番環境の「信頼性」「可用性」「継続的成長性」を確保。
• データフローの歪みやリスクを分析・改善し、データの滞りなく活用できる状態を維持。
• Platform Engineering や SRE のツールチェーンを活用しつつも、データベース特有の課題（スケーラビリティ、整合性、セキュリティなど）に取り組む。

DBRE の位置づけと意義

DBRE は、Platform Engineering と SRE の間に位置する存在ではなく、それらと補完的に交差する領域に立ち、特異点としての「データ」を中心に信頼性を築く役割を果たします。この視点を持つことで、エンジニアリングの実践を再定義し、信頼性の本質を探る新たな発見の契機となります。

結論

DBRE は、データベースに焦点を当てたエンジニアリング文化の一形態であり、サービスやプロダクトに宿る情報を尊重し、最大限に活かすための思考法でもあります。Platform Engineering や SRE の知識を活用しつつも、データの信頼性を守る独自の責務を果たし、新たな地平線を切り開いていく役割を担っています。

では本編です。

Platform Engineering と DBRE はタスクの注力の方向が違う

最近読んだ本の一つである「SRE をはじめよう」の割と最初の方に僕が求めていた答えが書かれていました。

1. DevOps のストーリーは、開発者がラップトップにコードを打ち込むところから始まります。DevOps は(とりわけ)、顧客がそのコードから最大の価値を享受できるように、そのコードを本番環境に提供するためには何が必要かを考えます。注目の方向は、ラップトップから本番稼働に向かっています。継続的インテグレーションと継続的デリバリー(CI/CD) システムが、DevOps の道具箱、スキルセット、そして採用広告でこれほど重要な位置を占めている理由の一つは、ここにあると推測できるかもしれません。

2. SRE は異なる場所から始まります。SRE は本番環境から始まります(実際、SRE の意識は本番環境にあります)。信頼できる本番環境を構築するために、SRE は何をしなければならないのでしょうか。この問いに答えるには、本番環境から「後方」に目を向け、開発者のノートパソコンに辿り着くまで、この問いを一歩一歩問いかける視線が必要です。

3. 注目する方向が異なります。同じツール(例えば CI/CD パイプライン) を使うかもしれませんが、その理由は異なります。DevOps と SRE はどちらも監視システムの構築に大きく関与するかもしれませんが、異なる理由で監視を行なっている可能性があります。*

これを読んだとき、僕は目の前のモヤモヤが一気に晴れた気がしました。同時に今まで僕がやっていたことはそれこそ Platform Engineering の領域だったのかもしれないなと、そんな風にも感じました。(だからと言って何かが変わるわけではありませんがｗ)

Platform Engineering は、開発者が手元で書き上げるコードが、どのようにして本番へたどり着くのか、そのプロセスや基盤を磨き上げることで、サービス開発という“ものづくり”を円滑にし、価値を届けるための「足場」を作っていくことが大きなタスクの方向性です。

そこには、開発環境(ローカル含む) PC から本番環境へと続く、ある種「生産ライン」のような流れが存在しています。その流れをいかに整え、いかに安全・高速・簡便なものにするか。Platform Engineer は高度な生産工場のエンジニアリングチームのように、最適化・整流化を繰り返しながら、開発者たちを前へ前へと後押しすることが重要となります。

一方で、DBRE はどうでしょうか？ もし SRE が「本番環境」にフォーカスを置き、その信頼性を高めるために、本番から逆向きにコードの源泉である開発者のラップトップまで視線を遡り、必要な改善を探し求めるのだとしたら、DBRE はそこに「データ」という特異なレンズをはめ込む存在のように思えます。DBRE は本番環境に根を下ろす、サービスのデータベースやデータストアの側からプロダクトを見つめます。データが滞りなく保存され、読み出され、更新され、そのトランザクションが繊細な秩序を保つために、どのような取り組みが必要なのかを、一つひとつ解きほぐしていく必要があるのです。

その際、DBRE が注目するのは、単にパイプラインの効率化や抽象化ではありません。DBRE が抱く問題意識は、データという資源に宿る「信頼性」と「継続的成長性」です。データベースは往々にして、システム全体の病巣やボトルネックになりやすい部分でもあります。スケーラビリティに欠ければ、ビジネスが加速したときに悲鳴を上げるのはデータベースです。整合性管理がずさんであれば、顧客体験に深刻な亀裂を生み出し、信頼を損ねます。セキュリティが甘ければ、我々が築き上げた城壁の内側がまるごと崩れ落ちるリスクさえあります。

DBRE のタスクの起源は、そうした「本番環境」という戦場に張り巡らされた無数のデータの動脈を観察し、信頼性・可用性・セキュリティといった観点から、データフローのどこに歪みがあり、どのような補強が必要なのかを、精緻な外科手術のように分析・改善することにあります。

また、DBRE が行う施策は、一見 Platform Engineering や SRE のツールチェーンと重なる部分があるかもしれません。CI/CD、インフラストラクチャ・オートメーション、監視・ロギング・トレーシングツールなど、その手段は似ています。だが、その用い方やアプローチの原点は異なります。Platform Engineering がいかにしてデプロイを高速化し、開発者体験を向上するかに注力するのに対して、DBRE は「このデータベースが、本番環境において何かしらのリスク、高負荷やセキュリティ的な問題などにさらされても、しなやかに耐え抜くためにはどうするべきか？」を根底の問いとします。それは、ただ手早くコードを届けるための舞台装置を作るのではなく、コードが生み出す膨大なデータが、決して堆積物にならず、流動的で活力ある状態を保てるように整えることに重きを置くことなのかもしれません。

こうした世界観の違いに気づくと、「DBRE って何なんだろう？」というモヤモヤは、むしろ新たな着想へと変わっていきます。

DBRE は、Platform Engineering や SRE という広大なエンジニアリング領域の中で、データという特異点に焦点を当て、そこから信頼性を築き上げようとする試みなのではないでしょうか。

もちろん、だからといってこれまで僕たちがやってきたことが揺らぐわけではありません。僕たちが日々行ってきた Platform Engineering 的な思考や行動は、より広い文脈で見れば、DBRE の実践を豊かにする基盤になっていたと捉えることもできるでしょう。「ラップトップから本番環境へ」の流れと、「本番環境からラップトップへ」の視線を交差させることで、僕たちは新たな発見や革新のチャンスを得る、と信じることこそ大切です。

知識を深めていく過程は常に、対象に新たな光を当て、その意味を組み替え、拡張することの連続です。DBRE という概念は、その光の当て方を変えることで、僕たちが日々対峙している問題や課題を、より立体的に、そして本質的に理解させてくれます。

DBRE が示す視点は、僕たちの責務を再定義するきっかけを与えてくれる。それは「DBRE って何？」という問いに答えるだけでなく、「プラットフォームを構築し、運用し、維持することの意味は何か？」や、「そもそも信頼性とはなんなのか？」という、より根源的な疑問に踏み込まなければなりません。

DBRE の実践は、単なる役割分担や職能の定義を超え、エンジニアリング・カルチャーの新たな地平線を指し示しているように思えます。DBRE は、開発者・プラットフォームエンジニア・SRE・オペレーター、そして組織全体が共有するべき「データへの畏敬と責任感」を促す一つの文化的契機です。その文化を育てることは、単にテクノロジーを磨くだけでなく、サービスに宿る情報を、尊重し、生かしきるための新たな境地を開くことでもあるのかもしれませんね。