私的データマートの障害白書2020

データマートの開発をして1年半ぐらい経ったので、私が遭遇した障害をまとめてみようと思います。
アサインされた当時はまだ数テーブルしかなく、ユーザーも目に届く範囲にいました。1年半経った今、気付いたらテーブルの数も中間テーブル含めて100を越え、ユーザーもどこにいるのか見えなくなってきたぐらいに増えてきたので、ちょうど開拓期から成熟期にさしかかろうとしているところです。

私が遭遇したデータマートの障害要因一覧

1年半データマートの開発と運用に関わって、色んな障害を踏みましたが原因をまとめてみるとこんなところです。

• 外部要因
  • 基幹システムのデータ連携が遅れた
  • 基幹システム内のデータに不整合が起こった
  • 外部連携サービスが障害発生した
  • インフラ基盤で障害が発生した
  • 他チームがデータマイニングをしてリソースが逼迫した
• 内部要因
  • 新機能にバグが混在してバッチ処理が異常処理していた
  • データベースの誤操作でリソースを食い潰していた

体感的には新機能のリリース後がやっぱり多かったような気がしますが、その次に多かったのは、他のチームによってテーブルロックがかかってバッチ処理が異常終了したのが多かったような気がします。（統計とっておけばよかった・・・）

データマート特有の障害事象

これらの障害を振り返ってみると、Webサービスの障害とは事情が違った面が見えてきました。

依存関係が多く、予算が限られているのでダウンタイムが長くなりがち

今私が関わっている会社の中では、マート作成をするバッチ処理が異常終了して再実行してユーザーが使えるようになるまで最低でも5時間ぐらいはかかるところもあります。そのため、朝から障害が発生すると夕方までは使えなくなってしまいます。

これはデータベースの性能も関わってきますが、バッチ処理に依存関係が多かったり、並列処理をするのにハードウェアの限界があったり、他部署と同じサーバーを共用しているため、それなりの時間がかかってしまいます。

Webサービスであれば、サーバーを再起動したりコードを直してデプロイすれば復旧することが多いのですが、データマートは部分対応するにしてもその依存しているテーブルの再作成も行うため時間がかかりやすくなります。

データマートの開発チームだけでは回避できない障害もある

データマートの障害で起こりがちなのが、データマートを作るにあたって必要なテーブルが連携が遅れてたり、ユーザーが直接データマートを触って無茶なクエリを叩いてストレージやCPUなどのリソース限界に近づけたりと開発チームだけでは対処しにくい障害が多くあります。

これはシステム的にエラーを出して防ぐにも難しいところなので、検知を早くして早めに関係部署やユーザーに連携状況を確認したり、リソースを使いまくっているユーザーに声をかけて障害にならないように気を張っています。

データの「整合性」も障害になる

バッチ処理が正常終了するだけでは、データマートができたと安心してはいけません。データの整合性が保てていないと、それは事業判断すらも歪めてしまう可能性があるため恐れるべきことだと思っています。

「整合性」とは、本来一意であるはずのテーブル内のキーが重複していたり、全期間のトランザクションが連携されるテーブルでレコードが減っていたのを確認したことがありました。いずれもデータマートの新機能にバグが混在してたり、基幹システムでの改修がデータマートの開発チームに伝わってこなかったり、レコードの物理削除を行ったりといった部分が原因です。

キー重複や増えるべきレコード数が減っていたというのはSQLを叩けば、自動的に検知しやすいので今ではバッチ処理にチェックするSQLを埋め込んで毎日自動的にレコード数の遷移を追いかけています。

まとめ

以上、データマートを運用することで気付いたことを挙げてみました。作ったテーブルが増えるということはメンテナンスするテーブルも増えてくるので、必然的に運用に使う時間が増えてくるとは思いますが、なるべく障害は自動的に回避できるようにしておきたいですね。