KTC における DBRE の必要性

こんにちは、KINTO テクノロジーズ (以下 KTC) で DBRE をやっていますあわっち(@_awache) です。

KTC では、モビリティサービスを提供する基盤として Amazon Web Services (以降 AWS と略します) 上で Amazon Aurora 等の Database を多く運用しており、Database Reliability Engineering (以降 DBRE と略します) を組織として設立し、事業のアジリティとガバナンスを両立するための取り組みを実施しています。

本投稿では KTC はなぜ DBRE を必要としたのか、について記載させていただきたいと思います。

Database Reliability Engineering (DBRE) とは

DBRE とは Database Reliability Engineering の略で「Software Engineering と Database 管理の Best Practice を組み合わせたアプローチ」を行っていく役割です。主なものとして

• SLO/SLI を定義、測定し、それに合わせた開発組織へのアプローチ
• 自動化、自律化推進による生産性の向上
• Backup/Restore などサービス稼働率の向上
• Database Security の担保とガバナンスコントロールの実現
• 他分野のスペシャリストとの分野を超えたコラボレーション

などが挙げられます。

これらの役割を一言で言うと「Database に対する専門知識と判断を用いてサービスの信頼性を担保する」こと、と言えると思います。

DBRE は企業にとって必要なのか？

「DBRE」というキーワードは、ある人にとってはとても魅力的に映るかもしれません。しかし、なぜそれが必要なのかを考えなければ、持続的な DBRE 活動を実現することは困難になります。

なぜなら AWS をはじめとした Public Cloud の爆発的な進展、DevOps/SRE 思想の成熟、AI 技術の進歩など Cloud を活用することによって誰でも一定のレベルで課題を解決できる土壌が揃っており、Database Engineer の専門知識の必要性が小さくなってきているからです。

一方で、過去も現在も実は Database そのものに対する基本的なアプローチはこれまでと変わっていないことも事実です。

• 環境分離
• 構成管理
• パフォーマンス測定
• Backup/Restore
• Security の担保、など

変化しているのは Database を取り巻く周りの環境であると考えることができます。

こういった時代の変化を判断し、その上で DBRE の必要性がある場合には皆様の会社でも DBRE を検討するといいでしょう。

なぜ KTC に DBRE が必要だったのか

ではなぜ KTC が DBRE を実践しているのか、を以下で説明します。

Software Engineer と Database Administrator の関係性の変化

• Software Engineer と Database Administrator の役割が明確に分かれていた時代

まだ企業においてオンプレミスの構成がメインであった時代、一般的には Software Engineer と Database Administrator はそれぞれの役割が明確に分かれており、それぞれの専門領域の分野で活動を行なっていました。

例えば下記のような分類がされていることがあったと思います。

• Software Engineer 領域
  • サービスの稼働率を守り、その成長を促進するための活動
    • ユーザーからのリクエストで必要なデータを抽出する
    • クエリの変更など Database の DDL に対する変更を必要としないチューニング
    • Database Administrator からの要望に対するアプリケーションへの適用
• Database Administrator 領域
  • Database そのものの稼働率を守るための活動

両者の大きな違いはそのリクエストやユーザー要望に対する対応速度と専門性であると言えます。

Software Engineer はサービス提供側に近いところにあるためどちらかというとニーズに合わせて可能な限り素早く応える必要があります。

Database Administrator はサービスというよりも Database そのものに重点を置いているため、多少レスポンス速度は遅くとも専門知識を用いて様々な課題を解決していきます。

図に表すと下記のような形になります。

このような組織では DBA は組織横断的に課題発見と課題解決を行っていました。

• Public Cloud の台頭による DBA の役割の縮小と SWE の領域の拡大

AWS をはじめとする Public Cloud が台頭してきて両者の役割は大きく変化してきました。特に Database そのものの稼働率を守るという点に関しては Public Cloud が担ってくれることから Database Administrator の役割は大きく縮小してきたと言えます。

代わりにこれまで Database Administrator が担ってきた役割のうち Database Administrator と Software Engineer の役割が被っている部分、具体的には

• 環境分離
• 構成管理
• パフォーマンス測定
• Backup/Restore
• Security や Governance Control

などを現場の Software Engineer が自分達で担う必要が出てきました。

その結果どうしても Database にまで注意が行き届かないというケースも存在してしまいます。

KTC ではこの点に課題を持ち始めました。継続的に事業成長を加速させるためには Software Engineer が事業成長に注力できる状態でなくてはいけません。

Cloud 利活用を主軸とした現在において、Software Engineer が事業活動に注力できる状態にするためには DBRE が Public Cloud との間に Hub となって活動する必要があります。
DBRE に求められる主な役割としては

• Database を軸としてサービスの稼働率を守る
• 現場のエンジニアの生産性を高める
• データベースセキュリティへの対応
• 内的要因、外的要因から Database を守る

を通じて企業の継続的成長を促進することが挙げられます。

次の章ではそれぞれの役割について補足します。

Cloud 時代の DBRE の役割

• Database を軸としてサービスの稼働率を守る

一般的にサービスが正常な状態は Database が正常に機能していることが前提となります。つまり Database のダウンタイムはそのままサービスのダウンタイムにつながってしまうのです。サービスの稼働率を維持するためには正しく適切に迅速に Database を復旧しなければなりません。

そこで DBRE に必要とされるのは Cloud 上で稼働するデータベースに対するスキルと言えるでしょう。

• 現場のエンジニアの生産性を高める

Database を運用していく中で、標準化を推進することは企業に対して大きな貢献ができるポイントです。例えば企業のガイドラインを提供した Platform の適用、ER 図をはじめとした Database ドキュメントの自動生成、定常的なオペレーションの自動化などが挙げられます。

また、日々進化する Cloud 技術の新機能検証と企業への適用、スロークエリなどのアプリケーションのボトルネック対応のサポート、そしてトラブル対応などを DBRE としてサポートすることも重要な役割となります。

これらは DBRE だけができてもスケールしません。DBRE は Software Engineer に比べて非常に限られたリソースの中で活動を行う必要があります。

大切なポイントは DBRE によってアウトプットされた物事は Software Engineer に還元され、そして誰でも扱える状態になることです。

• データベースセキュリティへの対応

Database の重要性は事業の成長と共に高まっていきます。そしてその価値が高まった Database は常に狙われる一つのコンポーネントとなります。

万が一データ流出が発生した場合、財務的な損失だけでなくそれに伴う甚大なレピュテーションリスクを抱えることになってしまいます。

企業を継続的に成長させるためにはこういったリスクから Database を守ることが必要不可欠です。そのためにも DBRE は Database に対するセキュリティを企業単位で適用することが重要となるのです。

• 内的要因、外的要因から Database を守る

データはその重要性から外部要因の変化による影響も受けやすい一つの要素です。そのため Database 運用に求められることは年々厳しくなっています。

特に政治・法律・世論の変化など、企業や個人ではコントロールできない要因に適切に対応することは企業に求められるものとなります。例えば個人情報保護法など定期的に改定されており、その度に罰則が厳しくなる傾向にあります。

外部要因による影響を各サービスが独自に適用しているのではコスト的なリスクだけでなく、適用漏れなどによるリスクも発生してしまいます。

DBRE に求められることは外的要因によるリスクを適切に把握し、企業内全ての Database に対して最適なガバナンスコントロールを行うこととなります。

KTC DBRE の目指すべき姿

KTC における DBRE は横断組織です。自分達のアウトプットがビジネスに反映されることによって価値提供されます。横断組織はそこにあるだけでは何に使われるかわからない税金と同じです。ビジネスに対してどのように良い影響を与えることができるか、が重要です。

今の時代、ルールやレビューだけで対応できるほど事業の変化のスピードは遅くありません。DBRE の持っている Database の知識を現場のエンジニアに還元して KTC 全体の Reliability を守ることが重要になります。

そのためにも私たちは Database に対するモノゴトを可能な限り Engineering によって解決しようと試みています。

ルールでがんじがらめにするのではなく、現場のエンジニアと協働して解決する、高いアジリティを保持しつつサービスのガバナンスコントロールを実現することでビジネスへの良い影響を提供していきます。

まとめ

KTC DBRE の役割

• 現場のエンジニアが事業成長に注力できる環境を提供すること

KTC DBRE に求められる主な役割としては

• Database を軸としてサービスの稼働率を守る
• 現場のエンジニアの生産性を高める
• データベースセキュリティへの対応
• 内的要因、外的要因から Database を守る

を通じて KTC の継続的成長を促進することが挙げられます。

この役割を軸として、ルールに縛られるのではなく、現場のエンジニアと協力して問題を解決し、高いアジリティを保ちつつサービスのガバナンスコントロールを実現することで、ビジネスへの良い影響を提供していくことが求められています。

僕たちと DBRE ディスカッションしませんか？

僕たちの DBRE はまだまだ始まったばかりです。なぜ DBRE があり、何を実現するためにどんなことをしていくのか、試行錯誤をしています。
お互いのやっていること、やりたいことなどをざっくばらんにお話しできると僕たちも視野が広がります。
僕たちからも多くをインプットしていただけるように取り組んでいることをお話しさせていただきたいと思います。

興味がある方は Twitter DM でも構いませんのでご連絡ください。

We are Hiring

DBRE の採用に関する課題は非常に大きいなと思っています。僕たちの活動に興味がある方はぜひ 採用ページ からご登録ください。
カジュアルに話を聞きたい、という方も Welcome です。
そのうち DBRE を実践している企業様とコラボレーションして DBRE Meetup 的なイベントもできたら嬉しいと思っていますのでその際はどうぞよろしくお願いします！