Zenn
😸

一人目の DBRE として活動を推進するためにやったこと

2022/04/22に公開
MySQL
#
dbre
tech

一人目の DBRE として KINTO テクノロジーズ株式会社に入社して2ヶ月が経とうとしています。その中で僕がやっていることをアウトプットしてみたいと思います。

DBRE　として活動するための情報収集

当たり前ですが社内ではまだ DBRE って何？ DBRE って何をやってくれるの？ という状態で認知がされていません。認知もされていなければ Database に関してどうなってるのか、を知りたいと思ってもそれを知っているキーパーソンとの接点もないのでこのままだと会社に対して何も価値を提供できない、と思いました。

またもし、Database に関する情報が整備されていない部署があったとして、それがないと DBRE としての価値提供がしづらい、ということから作成をしてもらう、というお願いをするのはとても気が引けました。

逆に Database に関するドキュメントがあったとしても部署毎に違うフォーマットだったり、欲しい情報が欠けていたりした場合に僕がアクションを起こすまでのアジリティが低下してしまうことも懸念としてあります。

更に Database に関するドキュメントは生き物だと思っているので正しく更新され続けないと意味のないものができてしまいます。一度作ることすら時間も人も必要なのにそれを更新させ続ける、というトイルをエンジニアに課すのは変なハレーションを生みかねないと感じます。

なので最初の一手として Schema Document を自動生成するツールを開発しています。

Shenron

KINTO の名前の由来はドラゴンボールの筋斗雲、だそうです(笑) そこからもじって Database に関わるツールを集めたら神龍を呼び出せる、とかそんな願いを込めてこのコマンドを作りました。

僕が作っているコマンドは今のところはまだ6個ですが下記の様な感じです。

Usage:
  shenron [command]

Available Commands:
  help              Help about any command
  mysqldatasize     Outputs the MySQL data size
  mysqlddl          Generates schema DDL in markdown or json or ddl format
  mysqlerd          Outputs the ERD created by schemaspy
  mysqlschemapolicy Outputs columns that are problematic by design
  mysqlusers        Outputs the list of MySQL users
  mysqlvars         Generate configuration files
  1. mysqlvars
    • MySQL の Variables を取得してそれを出力
    • 出力形式は　markdown と conf 形式
    • markdown　はそのまま github に上げることを想定
    • conf ファイルは my.cnf にして docker　を立ち上げる時に使えば稼働している Database　とほぼ同じ設定ファイルを使えることになる
  2. mysqlddl
    • これはもうほぼ　tbls の劣化版です(笑)
      • 最新のスキーマ全体の dump ファイルがいつでも手元に欲しかったのでそれを追加したぐらい
      • この dump ファイルをコピーして docker の initdb.d 以下に配置すれば conf と併用して同じ様な構成を手元で簡単に作れるのでこれから開発サポートをする時にいちいち構成を担当エンジニアに聞かなくてもドライブすることができると思っています
    • 出力形式は markdown と ddl と json 形式
  3. mysqlusers
    • MySQL サーバー内にあるユーザーとその権限、GRANT 文を出力
    • 出力形式は terminal と json 形式
  4. mysqldatasize
    • Database やテーブルのデータサイズ、インデックスサイズ、合計サイズ、行数を出力
    • もし　DB オペレーションをしたいと思った時にどれくらい時間がかかりそうか、どれくらい影響があるのかを想像するのに使います
    • 定期的に実行してそれを Datadog や OpenSearch に入れることでデータサイズの変化をモニタリングするのにも使いたいと考えています
    • 出力形式は terminal と json 形式
  5. mysqlerd
    • これは ScheemaSpy を叩くだけのツールです
    • 対象の Database サーバにあるスキーマリストを動的に引き渡す、ということをしたかったくらいです
  6. mysqlschemapolicy
    • MySQL Shell の機能の一つである upgrade checker を go に置き直しただけです
    • その上で個人的に追加したい要素、PK を持たないテーブルを ERROR にする、などカスタムポリシーを追加しています
      • Aurora 3.0 系へのバージョンアップをそろそろ検討してもいいかなと思ったのでこれを作ってみました

さて、7個目のドラゴンボール(機能)は何にしようか、ネタですがゆっくり考えてみたいと思います（笑）

これから

幸いにも僕が所属する部署は社内のクラウドを管理している部署なので全てのクラウドの状態を知ることができます。なのでまずは最も利用率の高い AWS 環境で全ての Database に対して定期的に実行し、アウトプットをすることでいつでも社内利用中の Database の正しいドキュメントを統一されたフォーマットで確認することができる様にします。

目的を果たせているか

結局これらのツールで何がしたかったのか、価値を見失うとお給料をもらって遊んでいるだけになってしまうのでそこはブレない様にしなければなりません。

僕がこのツールを作った大きな目的は 「Database の今の状態を知ること」 でエンジニアからの問い合わせがあった場合にすぐにアクションを始め、ビジネス貢献をすることです。

僕が今置かれている立場は横断組織の１メンバーであり、横断組織はいるだけではただの税金なので公共事業(今回の様なツール作り)を行って現場のエンジニアが少しでも活動しやすくなり、更にそこから個別のサポートに繋げていく、という動きをすすめることでビジネスへの貢献を肌で感じられるところまで昇華できたら嬉しいですね。

またせっかくなのでこれを社内展開して DB　エンジニアであれば当たり前にできることもアプリケーションエンジニアにはハードルが高い、というオペレーションを横展開して、各エンジニアとの接点を増やし、お互いが伴奏できる様にできたらいいな、という思いもあります。

ここまでが入社2ヶ月でやってきたことです。

たった1日で基本が身に付く！　Go言語　超入門 を片手に試行錯誤しているのが今なのでものすごく汚いソースコードでまともなテストも書けていないので公開できる日がいつになるかわかりませんがどっかで公開するのもありかもしれないとも思っています(笑)

お約束

DBRE は僕一人で活動しているのが現状です。やりたいことはまだまだたくさんあります。
少しでも興味がありましたら是非カジュアルにご連絡ください。

Discussion