はじめに
こんにちは、estieでQAエンジニアをしている macho です。
この記事はestie QAメンバー3名によるブログリレー 1日目としてお届けしています。
各メンバーのブログを通してestieのQA楽しそう！と少しでも興味を持っていただけたら嬉しいです！
さて、今回は私の所属している賃貸DaaS(Data as a Service)ユニットでデータ品質に向き合った取り組みをご紹介します。
アプリは正常でも、データが異常なら障害になる
私たちのユニットが開発しているプロダクトは、建物情報・募集データ・テナント情報など大量のデータを提供する データ分析サービス です。
私のユニットではその中のアプリケーションをメインに開発しており、プロダクトDBに流れてくるデータのパイプラインはデータチームが担当し、連携をとりながらプロダクト開発をしています。
アプリケーションの品質は当然大切ですが、同等もしくはそれ以上に データ品質 がサービスの根幹を支えています。
そのため、いくらアプリケーションが不具合なく完璧に稼働していても、プロダクトまでデータを運んでくれるデータパイプラインやデータ自身に異常が発生すると、内容によってはユーザーにとってサービス断と同等レベルの大きな障害となる可能性もあります。
例えば、buildings テーブルに deleted という Boolean 型カラムがあり、
false→ サービス上に表示true→ サービス上に非表示
というロジックでデータを絞り込んでいるとします。
もしこの deleted カラムが誤って全レコードで true になった場合どうなるでしょう？
すべてのビル情報が表示されなくなり、ユーザーはサービスを利用できず、大規模な障害につながります。
上記は少し極端な例ですが、実際昨年末ごろから担当プロダクト内でデータ起因のインシデントが数件発生し顧客影響が出たことで、アプリケーションのテストだけでは守り切れない領域がある と認識したことが今回の活動を始めるきっかけとなりました。
まずは現状把握から
データ品質に取り組む第一歩として、直近のインシデントを振り返り、以下をプロダクトメンバーやデータエンジニアと議論しました。
- 直近のインシデント原因は何か？
- どうすれば防げたか？
- 再発防止のために何が必要か？
結果として「プロダクトにとって重要なデータの異常変化を自動で検知する仕組み」を整備する方針を決めました。
※ こちらのテストはデータ分野では 異常検知(Anomaly Detection) と呼ばれる手法を活用しており、それに倣って本ブログ内でも異常検知と呼びます。
幸い異常検知ができる自動テスト基盤は既にデータチームが構築してくれており、スムーズにテスト整備を始められそうなことも議論の中でわかりました。
異常検知はdbtとElementary というOSSを使って実装されています。
詳しくは公式ドキュメントを見ていただきたいのですが、「dbt Elementary データ品質」などのキーワードで検索をしていただいてもさまざまな記事がヒットするかと思います。
データの重要度を定義し優先順位をつける
現状把握により既に異常検知の基盤が整っており一部のテストが運用されていることがわかりました。
テスト整備を進めるにあたり、データチームにヒアリングをしていく中で「テストをむやみに増やすと誤検知対応が大変」になりそうという問題が見えてきました。
そのため、まずは プロダクトにとって特に重要なデータ を明確化しました。
主要なテーブルとカラムを洗い出し、以下のような データのTier表 をユニットメンバーと協力して作成しました。
| Tier | プロダクトでの使われ方 | 該当カラム |
|---|---|---|
| 1 | ・主要検索機能で使われている | hoges.hoge |
| 2 | ・主要出力機能で使われている | fugas.fuga |
| 3 | ・UI表示に使われている | piyos.piyo |
異常レベル というもう一本の軸
Tier表が完成しデータの重要度が整理できました。
しかしそれらのデータにどんなテストを書くのか、そのテストが失敗した場合どのような対応を取るのかは決まっていませんでした。
そこで異常レベルを三段階でCRITICAL / ERROR / WARNING のように定義し、Tier × Level のマトリクスを作成しました。
- CRITICAL / ERROR：メンション付きでSlack通知
- WARNING：ログのみ
例：「Tier 1データ ✖️ CRITICAL = テストが失敗した場合プロダクトへのデータ移送を停止する」
このマトリクスにより、事前に “止める／止めない” の合意形成をし運用ルールを明確にしました。
サーキットブレーカーの導入
データの重要度と異常時の対応方針が決まりましたが、この時点では異常時にテストの結果をもとにデータ移送を停止する仕組みはありませんでした。
そのため、データエンジニアと協力しDesign Docを起こしました。
レビューを重ねた結果、サーキットブレーカー を導入することが決まりました。
サーキットブレーカーとは：電気回路の「ブレーカー」と同じイメージで、異常が発生した際に、自動で回路を遮断して被害を防ぐ仕組みをデータパイプラインに応用したものです。
ブレーカーを落とす条件はテストの実行結果で自動判定し、前述した異常レベルでいうCRITICALに該当するテストが失敗した場合はサーキットブレーカーが作動し、プロダクトへデータ移送はされずインシデントを未然に防げるようになります。
コラボレーションが大切
サーキットブレーカーについてさも自分が考案したかのように説明しましたが、これらの考案から実装までは一貫してスタッフエンジニアのLinさんが担当してくれました。
私はというと、データチームとのコラボレーションを持ちかけ、必要なテストをチームで考え、テストを実装する部分を担当しました。
一人では解決できない課題でも、このようにチーム外のメンバーとも積極的にコラボレーションをすることで前に進めることができました。
コラボレーションによって業務が進んでいくのはestieのよいカルチャーだなと改めて実感しました。
現状とこれからについて
ついに6月下旬からサーキットブレーカーの本稼働が始まりました。
稼働から間もないためまだ作動例はありませんが、データ起因のインシデントを未然に防ぐ第一歩を踏み出すことができたと考えています。
とはいえ今回整備したテストは、データ品質の6次元(正確性・完全性・一貫性・適時性・妥当性・一意性)のうち「完全性」や「一貫性」が中心で、まだまだQAとしてアプローチしきれていない次元があるのも事実です。
引き続きQAとしてプロダクトにとって重要なデータ品質について向き合っていきたいと考えています。
最後に
今回は直近私が取り組んだデータ品質施策について書きました。
estieのQAチームでは、「高速な価値提供サイクルの支えになる」をミッションとして、日々主体性を持って業務に取り組んでおり、他QAメンバーの記事もestieQAチームの特徴が伝わる内容になっていますので2日目、3日目のブログもお読み頂けると嬉しいです。
また、estieでは一緒に働いてくださる仲間を探しています。
estieやQAチームの活動に少しでも興味を持っていただけましたら、以下のリンクからカジュアル面談もしくは選考のご応募をお待ちしております！
QAエンジニアという職種に閉じず、たくさんの方とお話しできる機会を楽しみにしております。
👇 面談希望はこちらからどうぞ！
