Bytebaseで実現するデータベース管理の効率化

noteのSREチームのショウゴです。noteではデータベースの管理ツールとしてBytebaseを導入しました。

従来は複数のツールを組み合わせてデータベースに接続していたため、接続設定や管理に手間がかかっていました。Bytebaseの導入により、ツールを一元化し、データベースの接続・管理作業を効率化することができました

本noteでは、Bytebase導入までの過程と活用事例について紹介します。

Bytebaseとは

Bytebaseは、データベースの開発・運用におけるGithubのような位置付けとして構想されたミドルウェアツールです。

Bytebase

接続できるデータベースは、MySQLやPostgreSQLをはじめ、多くのデータベースがサポートされています。
https://www.bytebase.com/docs/introduction/supported-databases/

次に、Bytebaseの主な機能について説明します。

1. WebベースのSQLエディター

Bytebaseは、ブラウザ上のSQLエディターでアクセス権限のあるデータベースに対してクエリを実行、クエリ結果をCSVなどの形式で出力することができます。

SQLエディター (データはデモ用)

クエリだけではなく、スキーマの確認やワークシートという形式でSQLを保存・共有できます。

スキーマ情報 (テーブルはデモ用)

2. 動的データマスキング

Bytebaseでは動的データマスキングを行うことができ、テーブル名やカラム名などの条件を組み合わせて、全マスク・部分マスク・マスク無しを設定できます。

マスキングの設定 (設定はデモ用)

マスキングが設定されている場合、下図のようにクエリ時に値がマスクされた状態でクエリ結果が返ります。

クエリ時のマスキング状態 (データはデモ用)

3. ロールベースのデータアクセス制御

Bytebaseは、各データベースへのアクセス権限をAWSのIAMのようなポリシーとロールの概念で付与することができ、ユーザーやグループ単位でクエリ・CSV出力・アンマスクの権限を制御することができます。

ロールの作成画面

導入の背景

従来のデータベース接続は、複数のツールを組み合わせた以下の仕組みで運用していました。

1. GitHub Actionsで動作する社内ツールでユーザー発行申請を実施

2. 有効期限付きのMySQLユーザーのIDとパスワードを払い出し

3. ローカルのGUIツールもしくはCLIから、踏み台用のECSタスクを経由してデータベースに接続

既存の仕組み

申請者は、有効期限が切れるごとにユーザー発行を申請したり、GUIツールやCLIでのID/パスワードの設定などが都度発生していました。また、管理者はユーザー発行の社内ツールや踏み台サーバーの管理やトラブルシュート対応が発生していました。

Bytebase導入後

Bytebaseを使うことで、複数のツールを一元化することができ、よりセキュアにデータベースに接続することができ、下記のメリットなどがあったため、導入を進めることになりました。

• セルフホストすることができるため、自社の環境で運用できる。

• SSOによるログイン認証ができるため、ユーザーの登録・削除が省略できる。

• 権限申請・承認のワークフロー機能があるため、既存の仕組みを代替できる。

• 細かなアクセス制御ができるため、社員や業務委託などの様々な属性分けに対応できる。

• AWS Marketplace で契約ができるため、請求処理をAWSの費用と一元化できる。

• 監査ログに対応しているため、有事の際にログの参照が可能である。

導入プロセス

導入前の検証

Enterpriseプランのトライアル期間を使って、エンジニアメンバーにステージング環境のデータベースへ接続した環境を実際に触ってもらい、既存で使っていたGUIツールとの比較やBytebaseの使用感を確認してもらいました。
また、Slackとの連携、ワークフロー、SSO、監査ログの取得などの機能の検証も合わせて行いました。

環境準備

Bytebaseはセルフホストすることができるため、AWSのECSにホスティングしています。

構成図

Bytebaseは、一部リソースがTerraformに対応しています。また、APIも用意されており、ロールやマスキングの設定をコード化し、APIを使って環境を設定していくことも可能で、Githubにサンプルリポジトリが用意されています。

権限設計と運用方法の検討

導入が決定し、まずは一番コアな部分である権限の設計を行いました。
デフォルトで用意されているロールはいくつかありますが、ちょうど良いものが無いケースもあったため、各ポリシーの内容を確認し、カスタムロールを作成が必要でした。まずは、デフォルトの各ロールがどのパーミションを付与されているかを横断的に確認できる方法がなかったため、星取り表を作りました。そこから過不足を考慮しながら、カスタムロールの設計を行いました。

Bytebaseのデフォルトロールとポリシーの星取表(2024年10月8日時点).xlsx

101 KB

ファイルダウンロードについて

ダウンロード

11/29更新
v3.1.0で、「Project Querier」ロールが「SQL Editor User」という名称に変更されています。

次に、通常権限を付与していないデータベースに一時的に接続したい場合の権限の申請と承認フローについてです。Bytebaseは、Slack連携ができるため、Slack連携も活用した下記のフローを利用しています。

• SQLエディターからクエリ権限を申請する

クエリ権限をリクエスト

クエリしたいデータベース・テーブルを選択

• 申請が完了するとIssueが発行される

Issueが自動起票

• SlackにIssue作成の通知が届く

Slackの通知例

• 承認者はBytebaseのGUI上でIssueを承認する

Issueの承認

承認時のコメント入力

• Issueが承認されると権限が付与される

Issue承認完了の通知

• 有効期限を迎えると自動破棄される

Slackワークフローによる運用の効率化

現状の機能では対応できない部分があり、運用に関して以下の2点の課題がありました。

1. ユーザーをグループに所属させる作業が初回利用時に必要
   SSO認証によるBytebase上のユーザーは自動でアクティベーションできますが、属性分けのためのグループの所属設定が初回のみ必要となり、新規ユーザーが使い始めるタイミングの認知、グループの設定、設定完了のお知らせする必要がありました。

2. マスキングを一時解除するアンマスクの権限の付与申請がBytebase上でできない
   アンマスクの権限申請は、現状Issueベースのワークフローに対応していないため、権限申請の仕組み化が必要でした。

11/29更新
noteではSSO認証にOneLoginを使用しており、BytebaseではOneLoginのSCIMはサポートされていないため、以下のSlackのワークフローによるグループ設定の仕組みを構築しました。
なお、Entra ID (Azure AD)のSCIMはサポートされています。
https://www.bytebase.com/docs/administration/scim/overview/

両者を解決するためにSlackのワークフローを活用しました。グループの所属設定申請を例にフローを紹介します。

ワークフロー開始画面でグループを選択して申請

Bytebase管理用チャンネルに申請者を自動招待し、初回ログインを依頼

申請者が「ログイン済みです」を押下するとSREチームへ通知

担当者が「対応します」を押下するとチームメンバーに対応中であることを通知

対応者が「対応完了しました」を押下すると申請に完了通知

ステップのボタンを特に有効活用するように意識していて、リンクのボタンとステップを進めるボタンを設置し、今年9月のアップデートで追加されたボタンを押せるユーザーを制限する機能なども活用しています。

ステップの設定例

運用開始

環境準備と運用フローの整備が整ったため、先日社内展開を行いました 🎉
さっそく多くの方に使ってもらえています。

今後について

現状BytebaseのGUI上でしか承認が行えないため、External Approval という機能があるため、Slack上で承認が行えるようにしたいと考えています。

また、他にもDMLやDDLをIssueベースで実行できるDatabase CI/CDの機能や、Githubと連携したGitOpsの機能があるため、機会を見つけて活用を検討していきたいです。

まとめ

以上がBytebase導入までの過程と活用事例の紹介となります。同じような課題に直面している方、Bytebaseを導入検討している方の参考になれば嬉しいです。

▼ noteエンジニアの記事が読みたい方はこちらをご覧ください

noteエンジニアチームの技術記事