KINTO Tech Blog
DBRE

イベントレポート DBRE Summit 2023

hoshino
hoshino
Cover Image for イベントレポート DBRE Summit 2023

こんにちは。 KINTO テクノロジーズの DBRE チーム所属のhoshinoです。

前職ではWeb制作会社でインフラ、バックエンドエンジニアとして働いていましたが、DBに興味がありその中でも DBRE の活動に魅力を感じたため2023年8月からKINTOテクノロジーズ DBRE にジョインさせていただくことになりました。

DBRE(Database Reliability Engineering)チームでは、横断組織としてデータベースに関する課題解決や、組織のアジリティとガバナンスのバランスを取るためのプラットフォーム開発などを行なっております。DBRE は比較的新しい概念で、DBRE という組織がある会社も少なく、あったとしても取り組んでいる内容や考え方が異なるような、発展途上の非常に面白い領域です。

弊社における DBRE の取り組み例としては、あわっち(@_awache)による DBRE ガードレール構想の実現に向けた取り組みについてというテックブログや今年の AWS Summit の登壇内容、p2sk(@_p2sk_)によるDBRE Summit 2023の登壇内容を是非ご覧ください。

今回の記事は、2023年8月24日に開催した DBRE Summit 2023をレポートしたいと思います!

DBRE Summit 2023 とは

DBRE の最新のトピックとプラクティスを学び、また DBRE ネットワーキングを目的としたイベントです。
connpass による事前申し込みではオンラインとオフライン合計で186名の方々が申し込みをしてくださり、当日も多くの方々にご参加いただけました。

登壇者の皆様、参加者の皆様、お忙しい中 DBRE Summit を一緒に盛り上げていただきありがとうございました!

DBREを役割ではなく、文化にしたリンケージの取り組み

合同会社 Have Fun Tech 代表社員、株式会社 Linkage CTO、DBRE ユーザー会 DBREJP 共同運営 曽根 壮大(そね たけとも) / そーだい @soudai1025 さん

DBRE は役割ではなくデータベースを中心とした運用の哲学であり普段のプロダクト開発の営みの中でデータベースをメンテナンスする文化です。

データベースを管理できる英雄が現れてしまうと、逆にその人に依存することになってしまう懸念点も出てきます。

そうならないよう安定したサービス運用のために英雄がいらない平和な世界を目指す必要があり、そのために、会社として風土を作っていく必要があります。

個人の適性や熱意は必要だけどそれだけでは文化にならないため、まずは風土を整えていくことが重要です。

また、設計はデータベースの安全や運用に直結しているため、開発者が DBRE を実践していく文化が必要です。

Database Reliability Engineering は哲学であり、運用のスタイルで職人芸ではなく仕組みで問題を解決していくために、対処ではなく予防をする先に DBRE があります。

始めるに遅いことはない今から始めましょう!

<感想>
DBRE を実践していく上で自分たちでどうにかしようとするのではなく、周りを巻き込んで行くことがとても重要なことだと実感しました。
DBRE = 哲学であり文化!会社そのものの風土を作っていくために、積極的に横断的なコミュニケーションを取っていきたいです!

メルカリのDBREの今とクエリリプレイツールの比較

株式会社メルカリ DBRE 三谷智史 @mita2 さん

メルカリの DBRE は設立して1年程、それまではSREがデータベースを担当していました。

メルカリのデータベースの概要としては、元々はMonolith APIとDBだけでしたが現在はMonolith + MicroServiceに分離されました。

DBRE の主な業務としては各マイクロサービ所有のDB支援としてDeveloperのお悩み解決としてDBの各相談を受けたり、生産性を高めるツールの調査を行っています。

MicroService DB支援を始めるに当たって、プロアクティブに活動したいが課題が見えづらい、DBRE チームの認知がされていない等の課題が存在していました。

対応策として

  • Developer Surveyを実施、DBRE にどんなことを期待するかを選択方式でアンケートを実施
  • DBRE News Letterを半年に一回発行、DBRE チームからの積極的な発信

効果として徐々に会社内で認知されており、依頼が多くなってきています。

その他の DBRE 業務としては、Monolith DBの運用業務としてDBA業務やモダン化への挑戦を行っています。

本番のクエリをミラーするリプレイツールの選定を目的として、調査観点を設定し、調査を行いました。

リプレイツールとは

  • 本番のクエリやトラフィックを別の環境に対して再現するツールで、移行やバージョンアップ時の影響調査に利用します。

比較したツール

  • Percona query Playback
    • ログベースで使用できてシンプルに使いやすいツール
  • MySQL-query-replayer (MQR)
    • MQRは大規模なリプレイにフォーカスされていてツールを作成したtomboさんのロマンを感じるツール

<感想>
組織にどのような課題があるかをDeveloper Surveyでの調査や DBRE News Letterなど積極的に DBRE からの発信をしているという印象でした。
また、リプレイツールに関して調査観点やどのように調査を行っているかを聞けてとても参考になりました。

KINTO テクノロジーズでの DBRE 活動のご紹介

KINTO テクノロジーズ DBRE 廣瀬 真輝 @_p2sk_ さん。

会社全体を横断する組織(プラットフォームG)の中に DBRE が所属しています。

DBRE のRoleとしましては、2つに分類を行っています。

  • Database Business Office
    • 開発組織や各ステークホルダーからの要求に基づいて課題解決を行ったり、DBRE が提供するplatformの活用を推進する役割
  • Cloud Platform Engineering
    • ガバナンスに準拠しながらクラウドの効果的な利活用を促進するために、DBに関連する標準やplatformを提供する役割

DBRE の活動内容の決め方としましては4本柱を定義し組織の現状を踏まえ具体的な活動を決定しています。

実際の活動

  • DBクラスタの情報を収集する仕組み
  • DBシークレットローテーション
  • 検証:Aurora zero-ETL integrations with Redshift (preview)

KINTOテクノロジーズの DBRE ではDatabaseのReliabilityを向上をさせるためにプラットフォーム構築を行っています。

その手段としてEngineeringで解決する道を選択しました。

  • Cloudを適切に活用しAgilityを確保しつつDatabaseのSecurityとGovernanceを守る
  • platformへの昇華させ企業全体に展開することでビジネスにいい影響を与え続ける

Database Reliability Engineering というアプローチで進めています。

<感想>
DBRE の役割を明確に示し、それを元に組織としての仕組みづくりを行うことで、データベースの信頼性向上とビジネスへの貢献を同時に追求していてとても素晴らしいと感じました。
今後 DBRE として定義された4本柱を元により良い仕組みづくりに貢献していきたいと思います!

OracleDBを用いたDBREの実現 〜 オイシックス・ラ・大地でやってみた〜

オイシックス・ラ・大地株式会社 DBRE / DBRE ユーザー会 DBREJP 共同運営 原 智子 @tomomo1015 さん

SRE/DBRE が実現する可視化の中でもコストの可視化があまり触れられていなかったため、会社のインフラ全体のコスト管理を行っています。

アプローチとしては請求書リストからシステムの実態と課題を把握することを行っています。

また、費用対効果を評価することで事業の利益率向上に貢献しています。

全体のインフラ費用のなかでもDBのコスト割合は高い、DBはコストをかけてまでシステムにとって重要なものではあるが、あぐらをかいて放置してはいけません。

DBのコストダウンのために、開発環境等のDBを利用していない日は基本停止や一番コスト対効果があるアプローチを考案しています。

商用DBを利用する上でライセンス形態とその金額を知っていることは DBRE を体現する上でとても重要です。

ライセンスの棚卸しを行い会社が契約しているライセンスの妥当性を把握しましょう。

今と未来をどうすれば信頼性向上ができるか、成長できるか、楽しくできるか、それを考えていくために時間を使いましょう。

コストを可視化することによって色々見えてくるものあるため、是非コストを可視化するところから事業貢献や信頼性向上へのアプローチをしてみてください。

<感想>
普段聞けないコスト面での可視化のお話を聞けてとても面白かったです。
お話にもありましたが、DBはインフラ費用の中でも割合が高くシステムの中でも重要な部分なので可視化し費用対効果を評価するのがとても重要と感じました。
コスト面も含め今後 DBRE として課題解決をしていけたらなと参考になりました。

ANDPADでのテーブル定義変更のレビュー自動化とガイドライン作成の取り組み

株式会社アンドパッド DBRE 福間 雄基 @fkm_y さん

プロダクトチームがテーブル定義を変更する場合、DBRE がレビューする運用になっており、そのなかでいくつかの課題が発生しました。そのため、スケール可能なレビュー効率化の仕組みを作ることが必要と感じました。

調査として DBRE から開発者へのレビューコメントの分類を行い、対応できそうなものから小さく段階的にリリースしていくことにしました。早期に成果を得ながら進めていくためにこのアプローチを採用しました。

  • 導線作成の自動化
    • データベース利用規約は既に作成されていましたが、必要になるまであまり読まれていないなかったと仮説を立て必要なタイミングで表示される導線を作成、利用規約への導線を作るコストのみで閲覧数が増加し、レビュー時の指摘頻度が減少しました。
  • テーブル定義レビューの自動化
    • 機械的にチェックできる項目は自動でレビューしてくれる仕組みを作成、DBRE のレビューコストが削減されました。

仕組みをつくることによってレビュー効率化だけでなくレビューできていなかったプロダクトにも横展開できたため、 DBRE としてテーブル定義レビューの自動化ができました。

<感想>
導線作成やテーブル定義レビューの自動化を行うことで、適切なタイミングで使用することができ、とても効率化されていて素晴らしいと感じました。
このような仕組みを僕自身も今後作っていけたらなと、とても参考になりました。

株式会社アンドパッド DBRE 久保 路 @amamanamam さん

あらゆるチームのテーブル定義変更の本番実施が一律的でより質が高くなるような行動方針を作った話

課題としてテーブル定義変更時の検証の質がチームで異なるため検証が不十分のままマイグレーション実施されてしまいサービス影響や障害の恐れがあります。

そのためヒアリングを行い原因を分析。検証の質を担保するための明確なガイドラインを作成しました。

作成したガイドラインの概要

  • 本番実行までにやること一覧を作成
  • PRに載せてほしいことを作成
  • リリースタイミング検討フローを作成

導入した結果、検証結果の内容が網羅的かつ統一的なものになりました。

<感想>
課題を明確に洗い出し、課題を元に品質向上のためのガイドライン、プロセスを整理することで、 チーム全体の認識が高まり信頼性を高められていて素晴らしいと感じました。
DBRE としてチーム全体がその課題に共感し、協力して対処する動機づけになるようにガイドラインを整理していきたいです。

パネルディスカッション 「DBRE のこれから」

曽根 壮大(そね たけとも) / そーだい @soudai1025 さん

三谷智史 @mita2 さん

原 智子 @tomomo1015 さん

  • DBRE をはじめるにあたってなにから始めたら良いか?

    • ゴール設定を先に決めそれを元に何をすればよいかを決めていくことが良いかもしれないです。
    • なにが課題なのかを洗い出して、文化をつくっていくことが大事です。
    • データベースの標準化などが最初にやるテーマとしては良いかもしれないです。
  • DBRE を実践していくにあたって DBRE ならではのスキルって何がありますか?

    • 組織を横断して活動を行っていくためコミュニケーションスキルが重要です。
    • プレッシャーがかかるときに前向きに対応できるパーソナリティーが必要です。
    • 信頼を築ける能力が必要です。
  • キャリアとしての DBRE の魅力はなんですか?

    • DBの専門性を高められます。
    • DBは移り変わりが激しくないため、一度身につけた知識や経験を長く活用できます。
    • DBだけではなくアプリケーション等の視野が広がります。
  • 今後みなさんが取り組んでいきたいこと

    • DBRE としてコミュニティー活動を行っていきたいです。
    • DBRE としての成功体験を増やしていきたいです。
    • DBRE がなりたい職種になるように願っています。

<感想>
DBRE を実践していくうえで必要なスキルがDBの知識だけではないことに少し驚きました。
DBRE としてDBの知識はもちろん必要ですが、組織を横断した文化を作っていくにはコミュニーケーションスキルや前向きに対応できるパーソナリティー文化を作っていくことがとても重要だと実感しました。
僕自身もDBRE がなりたい職種になるよう願っています!

まとめ

いかがでしたでしょうか?

DBRE 自体まだまだ発展途上で導入している企業が少ない取り組みのひとつです。
その中でさまざまな企業の DBRE 活動をDBRE Summitを通して知ることができとても有意義な時間になりました。
僕自身バックエンドエンジニアから DBRE にジョインして間もない為、DBスペシャリストというわけではありませんが、DBへの改善タスクや横断した文化を作っていくエンジニアリングも重要な DBRE 活動であると、DBRE Summitを通して認識することができました。

https://youtube.com/live/C2b93fgn05c

Facebook

関連記事 | Related Posts

We are hiring!

【DBRE】プラットフォームG/東京・名古屋・大阪

プラットフォームグループについてAWS を中心とするインフラ設計、構築、運用などを担当しています。

【データエンジニア】分析G/東京・名古屋・大阪

分析グループについてKINTOにおいて開発系部門発足時から設置されているチームであり、それほど経営としても注力しているポジションです。決まっていること、分かっていることの方が少ないぐらいですので、常に「なぜ」を考えながら、未知を楽しめるメンバーが集まっております。