こんにちは！バクラク事業部 Platform Engineering 部 DevOps チームの id:sadayoshi_tadaです。

7月はエンジニアブログがたくさん出る #ベッテク月間です。今後も記事が出ますので、どんな記事がでるのかこちらのカレンダーからよければチェックしてみてください！7/2にSRE Lounge#17にて開発者が安心して実行可能なSQL実行基盤の取り組みという発表させていただきました。この記事では当該発表で時間の関係で触れきれなかった内容や補足を行っていきます。

従来のデータベースのデータ変更における課題

システムを運用する中で本番DBのデータ変更を行う場面があるかと思いますが、皆さんの会社ではどのように行っているでしょうか？バクラクでは、踏み台サーバのポートフォワード経由で本番DBに接続し、開発者のツーマンオペレーションにてSQLクライアントでデータ変更を行っていました。

上記のオペレーションで以下の課題を感じておりました。

事前に開発者同士で相互レビューを行っているが、当該オペレーションだとデータ変更時の承認や承認した記録がなくデータ変更を実行できること
SQLクライアントでデータ変更する際にダブルチェックがしづらいこと

これらの課題からお客様の重要なデータをより安全に扱うため、安全かつ確実な作業ができる基盤を導入していくことに決めました。

課題に対する解決策の検討

課題に対する解決策の検討を行い、要件として以下のものを設けました。

SQLのレビューと実行を1つのシステム上で完結できる
- 実行するSQLにはお客様の情報が含まれておりGitHubに置けないため、GitHubを使わなくても利用できること
データベースのデータの変更が可能な権限を直接作業者に渡すことなく作業ができる

これらの要件に対して複数のツールや自作することも検討したのですが、検証した結果を踏まえメリット/デメリットを整理した結果、Bytebaseというツールを導入していくことが良いという結論に至りました。Bytebaseの採用理由は以下になります。

データ変更のSQLをレビュアーが承認しないと、本番DBにSQLの実行ができないように設定できること
データベースの書き込みはBytebaseが行うため、エンジニアに権限を付与しないで済むこと
BytebaseはSQLのレビューと実行まで一気通貫で行えること

Bytebaseの利用にかかるコスト

また、補足としてBytebaseのコスト感もまとめておきます。Bytebaseの利用形態は3つタイプがあります。Communityは無償のプランで、ProとEnterpriseが有償プランになります。

Community
Pro
Enterprise

Pricingのページにプランごとに利用できる機能の詳細が記載されていますが、データ変更の承認機能を使うとなるとPro以上の有料プランを契約する必要があります。主に価格に影響するのはinstanceという概念です。これはBytebaseから接続するDBサーバを指しています。例えば、AWSのRDSインスタンスやAuroraクラスターのエンドポイントにBytebaseから1つ接続すると1インスタンスという扱いになります。

Proプランですと、1つのDBにつき$100/月の費用で契約することになります。Bytebaseで管理するDBサーバの数が20個以内であればProプランで、それ以上のDBの数を管理するもしくはProプランでサポートされてない機能を使いたい場合はEnterpriseプランを検討することになります。

Bytebaseの導入及びデータ変更のフロー整備

Bytebaseの利用方法はSaaSかセルフホストするかの2択をとることができます。私達は以下の理由でセルフホストで利用し、ECS Fargateで稼働させています。

データ変更のSQLにはお客様の情報が含まれており、私達が管理するシステムの外に出したくないこと
SaaS版ではデータベースにインターネット経由で接続できるようにする必要があるが、それをせず管理しているネットワーク内で完結させたいこと

正常に起動すると、以下の画像のログイン画面が表示されます。

データ変更のフロー整備

Bytebaseの稼働ができたので、次にデータ変更のフロー整備を行っていきました。このフローで重要になるのがデータ変更の承認設定とクエリのテストを行うための複製DBで、この2つに焦点をあてつつオペレーションフローを紹介します。

まず、データ変更の承認設定です(オペレーションフローの4の工程)。Custom Approvalという設定ページで設定ができるのですが、私達は専用の承認権限を持つロール(ここでいうとProject Approverがそれにあたります)を作り、その権限を持つメンバーが承認する設定にしています。

この設定により必ず承認プロセスを経ないと、データ変更のSQLを実行できなくなりました。

データ変更者がissueを登録し、レビュアーから承認をもらってSQL実行するまでのイメージ図

次に、クエリのテストを行うための複製DBについてです(オペレーションフローの3の工程)。ここでいう複製DBというのは本番DBから複製したものを指し、AWSのAuroraのクローン機能を使っています。クエリのテストでは、本番DBに対してデータ変更を行う前に意図した変更が行えるかや変更にどれくらいの時間を要するか等を確認するのですが、クローン機能によって本番相当のデータベースでテストを実現しています。これにより、開発者が本番データベースへの変更を行う際に一定の担保が取れた状態で実施できます。

Bytebase導入後の変化

Bytebaseを導入して整備したデータベースのオペレーションフローを2ヶ月ほど運用した結果、従来のオペレーションで感じた課題を解消しつつ、開発者からも安心してオペレーションができるようになったとポジティブなフィードバックをもらえています。

発表では触れられなかったのですが、複製DBを使えることになってクエリの改善を本番データで試すことが容易になりました。これによりパフォーマンス改善につながった事例があるなど、当初想定してなかった嬉しい効果もありました。

データ変更オペレーション上の課題

とはいえ、Bytebaseや整備したデータ変更オペレーションの運用上の課題があります。それは運用の過程での特権ユーザーしか実行できない手動オペレーションが残っていることにあります。

手動オペレーションが残っているというのは具体例でいうと、開発者への権限設定や有料プランにある、登録したDBへライセンスを割当てや剥奪等を始めとする特権ユーザーしか行えないオペレーションがあり、現状DevOpsチームがそれを担っています。BytebaseにはAPIによる操作がサポートされているため、人間が作業することのないよう自動化を進めています

まとめ

開発者にとって安心して本番DBに対してSQLを実行する基盤を導入し、運用に関わるお話をSRE Lounge#17の発表で触れきれなかった内容や補足を交えてご紹介しました。多くのポジティブなフィードバックをいただいたものの、まだオペレーション上の課題も残っており、引き続き安全にお客様のデータを扱える環境づくりを進めていきます。

最後に

今回の取り組みは1つの例ですが、インフラやCI/CD基盤、セキュリティ等プラットフォーム機能の開発や運用に興味・関心ある方をDevOpsチームでは募集しています。 open.talentio.com まずは話だけでも、という方は是非カジュアル面談や、LayerX Casual Nightといったイベントにぜひ応募ください。