DBRE ガードレール構想の実現に向けた取り組みについて

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

今回は僕が KTC で実現したい Database のガードレール構想についてお話ししたいと思います。

ガードレールとは

ガードレールとは Cloud Center of Excellence (CCoE) の活動の中でよく表現される言葉です。

一言でガードレールを表現すると「可能な限り利用者の自由を確保しつつ、望ましくない領域のみ制限、または発見するためのソリューション」です。

ガバナンスを重視することを求められる Database 領域を取り扱うという役割の特性上、DB エンジニアは時に「ゲートキーパー」として作用してしまい、企業活動のアジリティを損なってしまうこともあります。

そこで DBRE の活動にこの「ガードレール」の考え方を取り入れてアジリティとガバナンスコントロールを両立させようと考えています。

ガードレールの種類

ガードレールは下記の 3種類に分類できます。

• 予防的ガードレール
  

• 発見的ガードレール
  

• 訂正的ガードレール
  

ガードレール構想

導入当初の段階から予防的ガードレールによって強い制限を適用してしまうとこれまでできていたことや、やりたいことができなくなることで現場のエンジニアの反発や疲弊に繋がる可能性があります。

逆に訂正的ガードレールによって自動修復を行ってしまうと何が不適切だったのか、不適切な設定をどのように直していくのかを考えるというエンジニアのスキル向上の機会を失わせてしまうこともあるかと思います。

だからこそ現在は可能な限り利用者の自由を確保し、ガバナンスコントロールを実現するための地盤固めのフェーズだと思っています。その上で「発見的ガードレール」を取り入れることが望ましいと考えています。

現在 KTC では DEV/STG/PROD の 3ステージ制を導入しているため発見的ガードレールによってリスクを検知の周期を Daily で回したとしても、多くの場合本番に適用される前に気付ける状態にあります。発見的ガードレールで不適切な設定を定期的に検知し、それを受け取った現場のエンジニアが修正して適用する、というサイクルを継続的に回すことでサービスレベルの底上げに繋げられればこの仕組みの価値も上がっていきます。

もちろん発見的ガードレールは提供して終わりではなく、そこで検知されるルールを現場の状況に合わせてアップデートし続けることも大切です。現場のエンジニアと伴走し KTC の実態にあったガードレールを提供することで、この仕組み自体も KTC と一緒に成長していく必要があります。

Executive Sponsor の強力な後ろ盾

「ガードレールで検知されたものはエラーレベルに応じて対応する」ということが浸透しなければ狼アラートを増やすだけです。また個別のサービスの事情に応じてこのルールは対応しない、ということを許容してしまうこともアンチパターンだと考えます。

そこで大切にするべきことは「KTC としてサービスを提供する以上最低限守るべきルールだけを盛り込むこと」です。

細か過ぎるルールは定義せず、ガードレールでアラートが上がったらエラーレベルに応じて対応をする、の一点を KTC 内の全てのエンジニアに対して共通認識化、浸透させることができなければこの仕組みの価値がありません。

そこで最後の後押しをしてくれるのは、活動を後押ししてくれる Executive Sponsor です。Executive Sponsor は経営層、CxO など、企業としての方向性を示してくれる役割の方が望ましいです。

最初はどれだけ気を遣ったとしても現場のエンジニアにルールを強制する、という本質的なことは変わらないので、この活動が Executive Sponsor を通じて経営でコミットされているということは彼らが協力的に動く一つの理由やモチベーションとして作用するはずです。

責任分界点

KTC の DBRE は横断組織でありサービスを直接運用しているわけではありません。そのためどこからどこまでが DBRE の責任でどこからどこまでは現場のエンジニアの責任なのか、を明確にする必要があります。

僕はこれをDMAIC というフレームワークを用いて考えました。DMAIC については 「【DMAICとは：定義、測定、分析、改善、定着】業務フロー改善プロジェクトの必勝パターン（リーンシックスシグマ）」に非常に分かりやすくまとまっていると思いますのでこちらをご覧ください。

この５段階の手順にざっくりと誰が責任を持つのか、そしてそこでやるべきこと、を当てはめると下記のようになります。

この図はそれぞれ役割を明確にしつつも、 全てのステップでお互いに相談や改善、など連携しながら最終的な責任をどこが持つのか、ということを表しています。例えば DBRE は現場の改善や定着に向けた動きを一切手助けしないということではない、ということを補足させていただきます。

どのようにガードレールを構築するのか

ここまで長々とガードレールを構築するまでの考え方を記載させていただきましたがここから具体的な取り組みについて説明させていただきます。

[Define] エラーレベルの定義

最初にエラーレベルを定義することは最も重要です。

エラーレベルとはこのガードレールが KTC に提供する価値そのものです。DBRE としてどれだけ Must でやるべきことと考えたとしても定義されたエラーレベルに合ってなければ Notice もしくは対象外になります。設定したルールを定義に照らし合わせることを僕自身も徹底することで現場のエンジニアに対する説明責任を果たすことや、「何でも Critical」としたい欲求などをコントロールすることができます。

具体的な定義は下記の通り設定しました。

[Define] 具体的な内容整理

続いて定義したルールの中でガイドライン作成を検討することになるのですが、最初から Database 全体を見ようと思うと失敗してしまいます。そのため僕は最初のステップではガードレールの範囲を「おおよそ自力でできる範囲」と置いています。おおよそ自力でできる範囲、とは今動いているサービスに対する深いドメイン知識がなくてもできる範囲、例えば Database クラスター(KTC ではメインの DB は Amazon Aurora MySQL を使用しています) の設定や、DB 接続ユーザーの作成、Schema、Table、Column の定義、がそこにあたります。逆に現段階でガードレールで手を出さないところはスキーマ設計やデータ構造、Query などになります。

特にここでのポイントは 「Slow Query が発生した場合の対処」をガードレールに設定していないこと、です。Slow Query は非常に重要な指標になりうるものですが、サービス単位の深いドメイン知識がなければ対応は困難です。もし現段階で大量に出ていたとしたらどこから手をつけたらいいのか、そしてそれをエラーレベルに応じた期限通りに確実に対処し続けることも難しい状態です。

Slow Query に関してはまずはガードレールではなく、Slow Query を可視化し誰でも状況が確認できるようにする、そしてそれを対処することを SLO として定義し、 DBRE から個別に提案してみる、という動きをもって段階を踏んで考えていきたいと思っています。

• ガードレールで確認する領域イメージ

[Define] ガイドラインの設定/スクリプト化の実施

定義したエラーレベルや、手を出す範囲を決めた上でガイドラインに落とし込みます。そこで合意を得たものに関して自動的に検出できるようにします。
こうして作成したガイドラインを一部紹介します。

これらは AWS の API や Information Schema (一部 mysql Schema や Performance Schema) だけの情報から取得可能な範囲にしています。

これらの情報を取得した上でスクリプト化します。例えば 「Schema、Table、Column の文字コードに utf8(utf8mb3) で構成されたオブジェクトが存在しない」を調べたければ下記のクエリを実行することで取得できます。

SELECT
    SCHEMA_NAME,
    CONCAT('schema''s default character set: ', DEFAULT_CHARACTER_SET_NAME)
FROM
    information_schema.SCHEMATA
WHERE
    SCHEMA_NAME NOT IN ('information_schema', 'mysql', 'performance_schema', 'sys', 'tmp') AND
    DEFAULT_CHARACTER_SET_NAME in ('utf8', 'utf8mb3')
UNION
SELECT
    CONCAT(TABLE_SCHEMA, ".", TABLE_NAME, ".", COLUMN_NAME),
    CONCAT('column''s default character set: ', CHARACTER_SET_NAME) as WARNING
FROM
    information_schema.COLUMNS
WHERE
    TABLE_SCHEMA NOT IN ('information_schema', 'mysql', 'performance_schema', 'sys', 'tmp') AND
    CHARACTER_SET_NAME in ('utf8', 'utf8mb3')
;

その他のステップ（Measure/Analyze/Improve/Control）

上記のようなクエリなどガイドラインを満たすための情報取得をスクリプト化したものを定期的に実行し、その結果が適切でないと判断された場合にはアラートを送る、それをガードレールとして機能させる Platform を構築します。そして取得した結果の可視性を高めるための Dashboard を用意し現場のエンジニアに対応してもらう、このサイクルを回すことが当面の僕の DBRE としての活動軸になると考えています。

このガードレールの仕組みの良い点は、例えば 「1秒以上 Slow Query のうち、フロントエンドからの Query が 1ヶ月の 99パーセンタイルで 0 になること」が KTC 内で必要とされるようになった場合には、そのルールを加えればそれだけで KTC で管理している全てのサービスに適用できることです。逆に不要になったルールを外すことも一括で可能となります。

これが僕の考えるスケールする Database ガードレールの構想です。

まとめ

いかがでしたでしょうか？今回は僕が KTC の DBRE としてスケールし、継続的な価値提供を生み出していくための一つの軸として考えている DBRE ガードレールについて紹介させていただきました。

まだまだ構築段階ですがこれまでのように Database 技術 を用いているわけではなく、その技術をどのように効果的に KTC に適用するのか、そしてビジネス価値に繋げるところまで考えた DBRE 組織を作っているところです。そう言った意味でも今はチャレンジの時期でアプリケーションエンジニアリングからクラウドエンジニアリングまで幅広く行なっています。

こういったことを一歩一歩積み重ねて継続して皆さんにアウトプットしていこうと思っていますので引き続きよろしくお願いします！

またこの活動に少しでも興味を持ったり話を聞いてみたい、と思った方はお気軽に Twitter DM 等でご連絡いただければと思います。