ETLサービスの活用を支えるインシデント対応の工夫

primeNumberさんとGMOペパボのデータエンジニアリング勉強会のLT資料です

Transcript

1. 1 ETLサービスの活用を支える インシデント対応の工夫 小松 ももか / GMO PEPABO inc. 2023.06.05　データエンジニアリング合同勉強会
2. GMOペパボ株式会社 技術部データ基盤チーム エンジニア 2020年 新卒入社 2 自己紹介 小松 ももか Momoka Komatsu • データエンジニア • Twitter : @UsaMomokawa • 「ザ・スーパーマリオブラザーズ・ムービー」 よかったです
3. 3 • Cloud Composer は、Airflow をベースとした フルマネージドワークフローオーケストレーションサービス ◦ Apache Airflow は Python でワークフローを構築するオープンソースプロジェクト • Bigfoot 内外のデータ操作をコントロールする役目を負っている 今日は Cloud Composer の話をします
4. • ペパボの全社データ基盤 • ペパボにおけるデータの収集、分析、活用を支えている 4 4 Bigfoot 【Bigfootくん】 データ基盤「Bigfoot」のマスコットキャラクター
5. • インターネットサービスを多数運営している ◦ ホスティング / EC支援 / ハンドメイド 5 5 GMOペパボ
6. • ペパボの全社データ基盤 • ペパボにおけるデータの収集、分析、活用を支えている • BigQuery を中心に構築されている 6 6 Bigfoot 【Bigfootくん】 データ基盤「Bigfoot」のマスコットキャラクター
7. 7 Bigfoot 概略図 logs metrics GitHub issues databases tbls BigQuery bigfoot/platform Cloud Storage Looker Studio bigfoot/cloud-composer Cloud Composer dags/ tbls-build base tbls.yml files patch files ( *.yml, *.json ) patched tbls.yml files tbls-meta tbls data catalog bigfoot/data-catalog Send analysis results Verne Vertex AI Pub/Sub Dataflow
8. 8 Bigfoot 概略図 logs metrics GitHub issues databases tbls BigQuery bigfoot/platform Cloud Storage Looker Studio bigfoot/cloud-composer Cloud Composer dags/ tbls-build base tbls.yml files patch files ( *.yml, *.json ) patched tbls.yml files tbls-meta tbls data catalog bigfoot/data-catalog Send analysis results Verne Vertex AI Pub/Sub Dataflow Cloud Composer
9. ある日突然、 Cloud Composer 本番環境 が壊れた💥💣 ...どうなる？
10. Cloud Composer 10 Cloud Composer の本番環境が壊れたら? データ抽出処理 データ集計処理 データ取込処理 データ集計処理 データ集計処理 データソース BigQuery
11. Cloud Composer 11 Cloud Composer の本番環境が壊れたら? データ抽出処理 データ集計処理 データ取込処理 データ集計処理 データ集計処理 データソース BigQuery
12. Cloud Composer 12 Cloud Composer の本番環境が壊れたら? データ抽出処理 データ集計処理 データ取込処理 データ集計処理 データ集計処理 データソース BigQuery
13. Cloud Composer 13 Cloud Composer の本番環境が壊れたら? データ抽出処理 データ集計処理 データ取込処理 データ集計処理 データ集計処理 データソース BigQuery
14. 14 データ同期処理、集計処理が 全部止まってしまう😥 データの利用者が、正しいデータを参照できなくなる可能性がある (データの利用者 = サービスのユーザー、社内のパートナーなど)
15. 過去のインシデント対応の記録 * ここでは、Cloud Composer の本番環境が停止していた間に生じたデータ欠損について、可能な限り復旧した状態を指す 15 1年前に Cloud Composer の本番環境が壊れた😖 過去のインシデント対応の記録をふりかえる - 影響範囲の調査開始から共有まで 約3時間かかることもあった - データ欠損の完全復旧*まで 2日かかったこともあった 1年前
16. - 影響範囲の調査開始から共有まで 約3時間かかることもあった - データ欠損の完全復旧*まで 2日かかったこともあった 過去のインシデント対応の記録 * ここでは、Cloud Composer の本番環境が停止していた間に生じたデータ欠損について、可能な限り復旧した状態を指す 16 過去のインシデント対応の記録をふりかえる 1年前に Cloud Composer の本番環境が壊れた😖 1年前 - 影響範囲の調査開始から共有まで 30分〜1時間でできるようになった - データ欠損の完全復旧まで 半日で完了できるようになった 最近
17. - 影響範囲の調査開始から共有まで 約3時間かかることもあった - データ欠損の完全復旧*まで 2日かかったこともあった 過去のインシデント対応の記録 * ここでは、Cloud Composer の本番環境が停止していた間に生じたデータ欠損について、可能な限り復旧した状態を指す 17 過去のインシデント対応の記録をふりかえる 1年前に Cloud Composer の本番環境が壊れた😖 1年前 - 影響範囲の調査開始から共有まで 30分〜1時間でできるようになった - データ欠損の完全復旧まで 半日で完了できるようになった 最近 対応がうまくなってきた感覚がある💡
18. とはいえ、すぐにうまくなったわけではない 18 - インシデントが起きたら、ふりかえりをしてポストモーテム(事後分析)を書く - アクションアイテム(再発防止策)を出す - アクションアイテムを達成する ...を地道に繰り返していくうちに、だんだんインシデント対応がうまくなっていったのだと思います
19. とはいえ、すぐにうまくなったわけではない 19 - インシデントが起きたら、ふりかえりをしてポストモーテム(事後分析)を書く - アクションアイテム(再発防止策)を出す - アクションアイテムを達成する ...を地道に繰り返していくうちに、だんだんインシデント対応がうまくなっていったのだと思います 過去のインシデント対応記録をふりかえって、 「再発防止策をやったおかげで、うまくいった 👏」 と思えた工夫をいくつか紹介します 🗒
20. 20 インシデント対応の工夫
21. 21 インシデント対応の工夫 GMOペパボのインシデント対応マニュアルより引用 📝 「インシデント」の定義 機密性の問題 情報資産のうち重要性１、２に属するものについて、アク セス権限がない人が閲覧することができた 完全性の問題 情報資産全てを対象にして、なくなってしまった 完全性の問題 情報資産全てを対象に改ざんされてしまった 可用性の問題 情報資産全てを対象に、一時的に利用できない状態が発 生しお客様に影響が発生した Cloud Composer の本番環境が壊れると、可用性に影響が出る
22. 22 インシデント対応の工夫 事象検知 影響範囲 の特定 チーム間の 役割分担
23. 23 インシデント対応の工夫 事象検知 影響範囲 の特定 チーム間の 役割分担
24. 事象検知 24 過去のインシデント対応で、うまくいかなかったこと - 事象を検知する手段が不足していて、事象に気がつかなかった - 検知していたが通知を見逃した - Slack 通知一度きりだと、時間帯によっては気づかないことがある インシデント対応の工夫 事象が発生したら、早期に検知して対応したい 「気を付ける」のではなく、自然と気がつくような仕組みで解決したい
25. 事象検知 25 過去のインシデント対応で、うまくいかなかったこと - 事象を検知する手段が不足していて、事象に気がつかなかった -> 🔍 事象を検知する手段を増やす - 検知していたが通知を見逃した -> 🔍 通知を見逃さないような仕組みを用意する インシデント対応の工夫 事象が発生したら、早期に検知して対応したい 「気を付ける」のではなく、自然と気がつくような仕組みで解決したい
26. 事象検知：　事象を検知する手段を増やす 26 アラートを適切に設定する 例えば、Cloud Monitoring のアラート ポリシーを設定する - 「Cloud Composer の本番環境が正常に動作しているか？」 - 「Pub/Sub のメッセージは適切に捌けているか？」 問題を検知したら、GitHub Issue を作成する インシデント対応の工夫
27. Cloud Composer DAG が作ったデータに対するチェックを行う DAG (Directed Acyclic Graph) 有向非巡回グラフ 27 b a c 💡 - 向きがある - 循環がない インシデント対応の工夫 事象検知：　事象を検知する手段を増やす Task を繋ぐことで依存関係を定義する
28. Cloud Composer DAG が作ったデータに対するチェックを行う DAG (Directed Acyclic Graph) 有向非巡回グラフ 28 b a c Task を定義する時は、テンプレートとして事前定義された Operator を使う - BigQueryInsertJobOperator: BigQueryへSELECTを実行して、その結果を別テーブルに保存する - GoogleCloudStorageToBigQueryOperator： GCSに保存されているファイルのデータをBigQueryへ登録する 💡 - 向きがある - 循環がない インシデント対応の工夫 事象検知：　事象を検知する手段を増やす Task を繋ぐことで依存関係を定義する
29. 29 Cloud Composer DAG が作ったデータに対するチェックを行う DAG の処理の末尾で、 バリデーションクエリを投げる仕組み*を導入した インシデント対応の工夫 事象検知：　事象を検知する手段を増やす
30. 30 Cloud Composer DAG が作ったデータに対するチェックを行う DAG の処理の末尾で、 バリデーションクエリを投げる仕組み*を導入した validation b a c * 実態は、渡されたSQLを実行する KubernetesPodOperator インシデント対応の工夫 事象検知：　事象を検知する手段を増やす
31. 31 Cloud Composer DAG が作ったデータに対するチェックを行う DAG の処理の末尾で、 バリデーションクエリを投げる仕組み*を導入した #バリデーションクエリの例 ASSERT (( SELECT COUNT(*), FROM table ) > 0) ; validation b a c * 実態は、渡されたSQLを実行する KubernetesPodOperator 1件以上のレコードがあれば成功する インシデント対応の工夫 事象検知：　事象を検知する手段を増やす
32. 32 Cloud Composer DAG が作ったデータに対するチェックを行う DAG の処理の末尾で、 バリデーションクエリを投げる仕組み*を導入した バリデーションに失敗したら、DAG が失敗する DAG が失敗したら、GitHub Issue を作成する #バリデーションクエリの例 ASSERT (( SELECT COUNT(*), FROM table ) > 0) ; validation b a c * 実態は、渡されたSQLを実行する KubernetesPodOperator 1件以上のレコードがあれば成功する インシデント対応の工夫 事象検知：　事象を検知する手段を増やす
33. 事象検知 33 - 「Cloud Monitoring でアラートを検知したら、GitHub Issue を作成する」 - 「DAG が失敗したら、GitHub Issue を作成する」 ... など 基本的な方針として、何かが起きたら、GitHub Issue を作成してストックする そしてGitHub Issue の一覧は定期的に自動通知して、見逃しを防ぐ工夫をしている インシデント対応の工夫 GitHub Issue の通知には、特定ラベルが付いたIssueを特定時間にSlackに通知する仕組み linyows/github-issues-notice を利用しています
34. 事象検知 34 - アラートを適切に設定する - データに対するチェックを行う - 何かが起きたら、GitHub Issue を立てる このような工夫によって、 事象が発生したときに、以前よりも早く検知ができるようになった インシデント対応の工夫
35. 事象を検知したら、みんなに情報共有 35 🔗インシデントレスポンスを自動化で支援する Slack Bot で人機一体なセキュリティ対策を実現する - SEASON2 インシデント対応の工夫
36. 36 - Slackチャンネルの作成 - 初動対応チーム の招集 * * サービス、部門ごとに初動対応チームを編成している。 技術職、カスタマーサポート職、マネージャー職などが含まれたSlack グループ インシデント対応訓練のSlack通知 インシデント対応の工夫 Slack チャンネルを見れば、これまでの調査内容を追うことができる 事象を検知したら、みんなに情報共有
37. 37 インシデント対応の工夫 事象検知 影響範囲 の特定 チーム間の 役割分担
38. 影響範囲の特定 38 人力で頑張るのは、とても時間がかかる... たくさんのファイルを読み解いて、手作業で影響範囲をまとめていた - 処理の依存関係 - 実行周期 - 同期方法 など ... 実行周期 同期方法 必要な情報が 散らばっている 影響範囲のまとめ インシデント対応の工夫
39. 影響範囲の特定 39 データリネージの仕組みで、影響のあるジョブやテーブルを確認する インシデント対応の工夫 🔗データリネージの組織導入事例と今後の戦略
40. 影響範囲の特定 40 データリネージの仕組みで、影響のあるジョブやテーブルを確認する # users テーブルの下流テーブルを抽出する例 $ stairlight down -c config -r -t users [ "hoge", "fuga", ... ] インシデント対応の工夫
41. 影響範囲の特定 41 データリネージの仕組みで、影響のあるジョブやテーブルを確認する # users テーブルの下流テーブルを抽出する例 $ stairlight down -c config -r -t users [ "hoge", "fuga", ... ] インシデント対応時には、他にも ... - xx テーブルに依存する SQLファイル - xx テーブルに依存する Cloud Composer DAG といった情報を抽出している 影響範囲の特定にかかる時間が減少 ↓ インシデント対応の工夫
42. 影響範囲の特定 42 Table　A Table　B Table　C Table　D Table　E DAG 1 DAG ２ 「誰がどのテーブルを見ているか分からない」 ので、 - テーブルが壊れたことを誰に伝えたらよいか - どの処理を優先して復旧させればよいか 見当をつけるのが難しい どちらを優先して復旧させる? インシデント対応の工夫
43. 影響範囲の特定 43 クエリ実行ログを見て、「誰が困っているか」を把握する テーブル名 参照数 Table E 1000 Table D 800 Table A 1 Table B 1 Table C 1 テーブル参照数を抽出する例 INFORMATION _SCHEMA をもとに、 テーブル参照数やテーブルを参照している人を 取得するViewを作りました テーブル名 実行したクエリ クエリを実行した人の メールアドレス Table E ... ... Table E ... ... テーブルを参照している人を抽出する例 インシデント対応の工夫
44. 44 インシデント対応の工夫 事象検知 チーム間の 役割分担 影響範囲 の特定
45. チーム間の役割分担 45 - 影響範囲をスプレッドシートで共有し、ジョブ再実行の判断を分担する - DAGやクエリの実装と見比べて、対応の優先度や再実行の判断を行う - GitHub Issue と Assign 機能を使って、復旧対応を分担する - 失敗したジョブは GitHub Issue で可視化されているので、分担して再実行 - 必要に応じて他のチームメンバーの手を借りる - sssbot が作成した Slack チャンネルに人を呼ぶ - Slack チャンネルを見れば、これまでの調査内容を追うことができる ツールをうまく使って、みんなと協力する インシデント対応の工夫
46. インシデント対応における工夫を紹介しました - 事象検知 - 影響範囲の特定 - チーム間の役割分担 まとめ 46 すぐにできるようになったわけではなく、 ポストモーテム(事後分析)を書いて、アクションアイテム(再発防止策)を出して、地道に対応していった 結果として、発生から復旧までの時間を短縮できるようになりました インシデント対応の工夫
47. これからやっていきたいこと 47 - カラム単位の異常検知 値の傾向が急激に変化した時に検出する(例: NULLの割合が急に増加した*) 検知ルールの管理方法をわかりやすく管理できるような仕組みが作れると良さそう - 職種や部署を超えて、みんなとうまく協力するための仕組みづくり データ基盤チームの力だけでは単純に手数が足りないことがあったり、わからない部分があったりする 専門分野は得意な人に任せて、みんなの力で対応できるようにしたい インシデント対応の工夫 💡最近のトピック: データ欠落を検知できるようになりました。 カラム単位でNULLの割合を見て、割合が急激に変化したら通知するような処理を GitHub Actions で定期実行しています。
48. 48 ETLサービスの活用を支える インシデント対応の工夫 小松 ももか / GMO PEPABO inc. 2023.06.05　データエンジニアリング合同勉強会