データ分析基盤の障害を未然に防ぐためのチェックリスト 2020/11/4 Sotaro Tanaka @__sotaron__ Data Engineering Study #4

2 ● Data Management & BI ● Data Reliability ● Site Reliability ● Like : Docker/k8s/Python/Go/小倉唯さん ● Hobby : / / ⚽ / 小倉唯さん 自己紹介 Sotaro Tanaka @__sotaron__ Data Engineer @ Ubie, Inc. DS Team 2

3 今日お話すること データ分析基盤においてよくありがちな障害を、未然に防止するにはどんなことをしたらいいのか？ それらを ● ベースとなるData Reliabilityの概念 ● 事前防止策のチェックリストの例 あたりを交えながら、お話したいと思います。 タイトルに「チェックリスト」とありますが、わかりやすさのための例くらいに思ってください。 3

4 目次 １．はじめに / Data Reliabilityとは？ ２．データ分析基盤のコンポーネントと品質チェックリスト ３．retroactiveからproactiveへ 4

5 Data Reliabilityって何？ はじめに / Data Reliabilityとは？ データ活用を推進する上で、避けては通れないデータに関わる諸々の品質についての話。 ざっくり2つの品質があると思います。 1/ データ品質 　 分析レポートやMLアプリケーションで利用している「データそのもの」の品質。間違ってたら困る。 2/ データ関連システムの品質 　データパイプラインやワークフロー、BIツール、データベースなど、「データを取り扱うシステム」の品質。 5

6 データ品質の指標 代表的なもの 6 完全性 Integrity レコードは欠損していないか？ Requiredなカラムに値があるか？ これがないと…？ - 許容値を超えたら、データは「ス トアするのに金がかかるゴミ」に なる 一貫性 Consistency ある値が… データセット間で一貫しているか？ データセット内で一貫しているか？ これがないと…？ - レポートAとレポートBで同じ指 標値が異なる値になったりする 一意性 Uniqueness 重複してはいけないレコードやインスタ ンスが重複していないか？ 重複排除とほぼ同じ。 これがないと…？ - 極端な話、KPIが不正に二倍に なったりする。 はじめに / Data Reliabilityとは？

7 データ関連システムの品質指標 代表的なもの 7 適時性 Timeliness 更新系システムのデータ変化に分析 /ML側が適切に追従できているか？ レポートは適切に更新されたか？ これがないと…？ - 3日前の速報値で意思決定する PdM - ある日のデータ反映が、顧客側 に表示されるのは3日後 可用性 Availability システムが稼働しているべき時間中、 稼働し続けているか？ これがないと…？ - ダッシュボード見れません！ 冗長性 Redundancy データロストしないか？ オペミスでデータ消した時にどうなる？ これがないと…？ - 事業＼(^o^)／オワタ はじめに / Data Reliabilityとは？

8 目次 １．はじめに / Data Reliabilityとは？ ２．データ分析基盤のコンポーネントと品質チェックリストの例 ３．retroactiveからproactiveへ 8

9 よくあるシステム構成要素で 考えてみる 9

10 ETL(ELT)パイプライン、ワークフローの場合 データ分析基盤のコンポーネントと品質チェックリストの例 1/ パイプライン上のタスクが失敗したときのリトライを考慮できているか？ 　 耳タコだが、タスクが冪等になっているかなどの観点がある。可用性、一貫性、一意性など複数の指標が関係。 　 冪等にできない場合、リトライ手順は複雑化するのでドキュメンテーションできているかなども事前にチェックできると‍♂ 2/ 扱っているデータごとの時間的なボラティリティを理解しているか？ 　社内レポートや顧客に表示する画面へのデータ反映などの問題。適時性の指標が関係。 　 たとえば頻繁な更新が走るデータと、静的なマスタデータを同じパイプラインに載せるのが吉なのか？などを考えられる。 3/ デプロイ時にストリームデータが欠損しないシステムになっているか？ 　たとえば、Blue/Greenなデプロイ戦略をとれているのか？メッセージキューを利用しているならackを正しくハンドリングしているか、 など。可用性、完全性、冗長性などの指標が関係する。ストリーム処理の障害対応はつらい。 10

11 データストアの場合 データ分析基盤のコンポーネントと品質チェックリストの例 1/ 故障してもデータロストしないか？ 　 当たり前だけど、バックアップを取る。そのバックアップがリストアできることを定期的にテストしておく、など。 　 PITRがサポートされているのか？サポートされていないなら、何を許容できるのか把握しているか？冗長性の観点。 2/ failover時の挙動はテストしているか？ 　機能的に提供されているfailoverに安心しきってはいけない。 　 failoverには暗黙的な条件がいくつもあったりするので、それを正しくハンドリングできているのか？をチェックしておく 　 可用性、一貫性(replication失敗とか)などに関わる。 11

12 BIツールの場合 1/ 故障したとき、シートの情報はロストしないか？（自社ホストの場合） 　 BIツールは多くの場合、内部的にシート情報や外部データソースへの接続情報を保持するため、データストア層を持つ。 　 MySQLとかPostgreでバックアップを取るというと当たり前だが、こちらのバックアップ/リストア戦略も当然だいじ。 　 冗長性の指標。 2/ グラフや数表の描画や表示にかかる時間をモニタできているか？ SLOにおさまっているか？ 　「グラフの表示が遅いんですけど〜」と言われることはよくあると思います。 　 ユーザーからの体感値の報告を無視してはいけません。 　 データセットが肥大化していることによって、レスポンスが遅くなっていたら、ある日突然全てのグラフが1日見れなくなるなんてこともあ るかもしれません。 データ分析基盤のコンポーネントと品質チェックリストの例 12

13 小さな失敗や事故は 発生しうる前提で考える 13

14 品質を気にしておかないと どうなりますか？ 14

15 小さな失敗や事故が 放置され積み重なり、 障害が発生しやすくなる 15

16 目次 １．はじめに / Data Reliabilityとは？ ２．データ分析基盤のコンポーネントと品質チェックリスト ３．retroactiveからproactiveへ 16

17 とはいえ、 障害は起きうるので 17

18 retroactiveな障害対応から品質への期待を知る 事後的な障害対応においては、ポストモーテムをやるべき。というのは SREの文脈では当たり前の話。 同様にデータ分析基盤においても、ポストモーテムのプロセスから、顧客 (社内/社外)のデータ品質やデータ関連シ ステムの品質への期待を知るのが吉。（もちろん事前にわかる期待には応えておく） 18 retroactiveからproactiveへ

19 proactiveに品質を追求する ポストモーテムで知った品質期待を先述したようなチェックリストや SLIに落とし込んで、 自身の組織内で継続的な品質向上、維持のサイクルを回す。 求められる品質はプロダクトの性質や顧客が誰なのか、採用技術は何なのかによって異なるので、 完全に標準化されたガイドは世に出てこない。 19 retroactiveからproactiveへ

20 Key Takeaway 20

21 今日のお持ち帰り retroactiveな障害対応から品質期待を知り、 proacitiveなデータ品質維持、向上を目指そう 21

22 Ubieで一緒にData ReliabilityとかBIとかやりませんか？ BIとかData Reliabilityに限らず、様々な職種でも募集中なので、是非！！ 22