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

by Momoka Komatsu

Slide 1

Slide 1 text

1 ETLサービスの活用を支えるインシデント対応の工夫小松ももか / GMO PEPABO inc. 2023.06.05　データエンジニアリング合同勉強会

Slide 2

Slide 2 text

GMOペパボ株式会社技術部データ基盤チームエンジニア 2020年新卒入社 2 自己紹介小松ももか Momoka Komatsu ● データエンジニア ● Twitter : @UsaMomokawa ● 「ザ・スーパーマリオブラザーズ・ムービー」よかったです

Slide 3

Slide 3 text

3 ● Cloud Composer は、Airflow をベースとしたフルマネージドワークフローオーケストレーションサービス ○ Apache Airflow は Python でワークフローを構築するオープンソースプロジェクト ● Bigfoot 内外のデータ操作をコントロールする役目を負っている今日は Cloud Composer の話をします

Slide 4

Slide 4 text

● ペパボの全社データ基盤 ● ペパボにおけるデータの収集、分析、活用を支えている 4 4 Bigfoot 【Bigfootくん】データ基盤「Bigfoot」のマスコットキャラクター

Slide 5

Slide 5 text

● インターネットサービスを多数運営している ○ ホスティング / EC支援 / ハンドメイド 5 5 GMOペパボ

Slide 6

Slide 6 text

● ペパボの全社データ基盤 ● ペパボにおけるデータの収集、分析、活用を支えている ● BigQuery を中心に構築されている 6 6 Bigfoot 【Bigfootくん】データ基盤「Bigfoot」のマスコットキャラクター

Slide 7

Slide 7 text

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

Slide 8

Slide 8 text

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

Slide 9

Slide 9 text

ある日突然、 Cloud Composer 本番環境が壊れた💥💣 ...どうなる？

Slide 10

Slide 10 text

Cloud Composer 10 Cloud Composer の本番環境が壊れたら? データ抽出処理データ集計処理データ取込処理データ集計処理データ集計処理データソース BigQuery

Slide 11

Slide 11 text

Cloud Composer 11 Cloud Composer の本番環境が壊れたら? データ抽出処理データ集計処理データ取込処理データ集計処理データ集計処理データソース BigQuery

Slide 12

Slide 12 text

Cloud Composer 12 Cloud Composer の本番環境が壊れたら? データ抽出処理データ集計処理データ取込処理データ集計処理データ集計処理データソース BigQuery

Slide 13

Slide 13 text

Cloud Composer 13 Cloud Composer の本番環境が壊れたら? データ抽出処理データ集計処理データ取込処理データ集計処理データ集計処理データソース BigQuery

Slide 14

Slide 14 text

14 データ同期処理、集計処理が全部止まってしまう😥 データの利用者が、正しいデータを参照できなくなる可能性がある (データの利用者 = サービスのユーザー、社内のパートナーなど)

Slide 15

Slide 15 text

過去のインシデント対応の記録 * ここでは、Cloud Composer の本番環境が停止していた間に生じたデータ欠損について、可能な限り復旧した状態を指す 15 1年前に Cloud Composer の本番環境が壊れた😖 過去のインシデント対応の記録をふりかえる - 影響範囲の調査開始から共有まで約3時間かかることもあった - データ欠損の完全復旧*まで 2日かかったこともあった 1年前

Slide 16

Slide 16 text

- 影響範囲の調査開始から共有まで約3時間かかることもあった - データ欠損の完全復旧*まで 2日かかったこともあった過去のインシデント対応の記録 * ここでは、Cloud Composer の本番環境が停止していた間に生じたデータ欠損について、可能な限り復旧した状態を指す 16 過去のインシデント対応の記録をふりかえる 1年前に Cloud Composer の本番環境が壊れた😖 1年前 - 影響範囲の調査開始から共有まで 30分〜1時間でできるようになった - データ欠損の完全復旧まで半日で完了できるようになった最近

Slide 17

Slide 17 text

- 影響範囲の調査開始から共有まで約3時間かかることもあった - データ欠損の完全復旧*まで 2日かかったこともあった過去のインシデント対応の記録 * ここでは、Cloud Composer の本番環境が停止していた間に生じたデータ欠損について、可能な限り復旧した状態を指す 17 過去のインシデント対応の記録をふりかえる 1年前に Cloud Composer の本番環境が壊れた😖 1年前 - 影響範囲の調査開始から共有まで 30分〜1時間でできるようになった - データ欠損の完全復旧まで半日で完了できるようになった最近対応がうまくなってきた感覚がある💡

Slide 18

Slide 18 text

とはいえ、すぐにうまくなったわけではない 18 - インシデントが起きたら、ふりかえりをしてポストモーテム(事後分析)を書く - アクションアイテム(再発防止策)を出す - アクションアイテムを達成する ...を地道に繰り返していくうちに、だんだんインシデント対応がうまくなっていったのだと思います

Slide 19

Slide 19 text

とはいえ、すぐにうまくなったわけではない 19 - インシデントが起きたら、ふりかえりをしてポストモーテム(事後分析)を書く - アクションアイテム(再発防止策)を出す - アクションアイテムを達成する ...を地道に繰り返していくうちに、だんだんインシデント対応がうまくなっていったのだと思います過去のインシデント対応記録をふりかえって、「再発防止策をやったおかげで、うまくいった 👏」と思えた工夫をいくつか紹介します 🗒

Slide 20

Slide 20 text

20 インシデント対応の工夫

Slide 21

Slide 21 text

21 インシデント対応の工夫 GMOペパボのインシデント対応マニュアルより引用 📝 「インシデント」の定義機密性の問題情報資産のうち重要性１、２に属するものについて、アクセス権限がない人が閲覧することができた完全性の問題情報資産全てを対象にして、なくなってしまった完全性の問題情報資産全てを対象に改ざんされてしまった可用性の問題情報資産全てを対象に、一時的に利用できない状態が発生しお客様に影響が発生した Cloud Composer の本番環境が壊れると、可用性に影響が出る

Slide 22

Slide 22 text

22 インシデント対応の工夫事象検知影響範囲の特定チーム間の役割分担

Slide 23

Slide 23 text

23 インシデント対応の工夫事象検知影響範囲の特定チーム間の役割分担

Slide 24

Slide 24 text

事象検知 24 過去のインシデント対応で、うまくいかなかったこと - 事象を検知する手段が不足していて、事象に気がつかなかった - 検知していたが通知を見逃した - Slack 通知一度きりだと、時間帯によっては気づかないことがあるインシデント対応の工夫事象が発生したら、早期に検知して対応したい「気を付ける」のではなく、自然と気がつくような仕組みで解決したい

Slide 25

Slide 25 text

事象検知 25 過去のインシデント対応で、うまくいかなかったこと - 事象を検知する手段が不足していて、事象に気がつかなかった -> 🔍 事象を検知する手段を増やす - 検知していたが通知を見逃した -> 🔍 通知を見逃さないような仕組みを用意するインシデント対応の工夫事象が発生したら、早期に検知して対応したい「気を付ける」のではなく、自然と気がつくような仕組みで解決したい

Slide 26

Slide 26 text

事象検知：　事象を検知する手段を増やす 26 アラートを適切に設定する例えば、Cloud Monitoring のアラートポリシーを設定する - 「Cloud Composer の本番環境が正常に動作しているか？」 - 「Pub/Sub のメッセージは適切に捌けているか？」問題を検知したら、GitHub Issue を作成するインシデント対応の工夫

Slide 27

Slide 27 text

Cloud Composer DAG が作ったデータに対するチェックを行う DAG (Directed Acyclic Graph) 有向非巡回グラフ 27 b a c 💡 - 向きがある - 循環がないインシデント対応の工夫事象検知：　事象を検知する手段を増やす Task を繋ぐことで依存関係を定義する

Slide 28

Slide 28 text

Cloud Composer DAG が作ったデータに対するチェックを行う DAG (Directed Acyclic Graph) 有向非巡回グラフ 28 b a c Task を定義する時は、テンプレートとして事前定義された Operator を使う - BigQueryInsertJobOperator: BigQueryへSELECTを実行して、その結果を別テーブルに保存する - GoogleCloudStorageToBigQueryOperator： GCSに保存されているファイルのデータをBigQueryへ登録する 💡 - 向きがある - 循環がないインシデント対応の工夫事象検知：　事象を検知する手段を増やす Task を繋ぐことで依存関係を定義する

Slide 29

Slide 29 text

29 Cloud Composer DAG が作ったデータに対するチェックを行う DAG の処理の末尾で、バリデーションクエリを投げる仕組み*を導入したインシデント対応の工夫事象検知：　事象を検知する手段を増やす

Slide 30

Slide 30 text

30 Cloud Composer DAG が作ったデータに対するチェックを行う DAG の処理の末尾で、バリデーションクエリを投げる仕組み*を導入した validation b a c * 実態は、渡されたSQLを実行する KubernetesPodOperator インシデント対応の工夫事象検知：　事象を検知する手段を増やす

Slide 31

Slide 31 text

31 Cloud Composer DAG が作ったデータに対するチェックを行う DAG の処理の末尾で、バリデーションクエリを投げる仕組み*を導入した #バリデーションクエリの例 ASSERT (( SELECT COUNT(*), FROM table ) > 0) ; validation b a c * 実態は、渡されたSQLを実行する KubernetesPodOperator 1件以上のレコードがあれば成功するインシデント対応の工夫事象検知：　事象を検知する手段を増やす

Slide 32

Slide 32 text

32 Cloud Composer DAG が作ったデータに対するチェックを行う DAG の処理の末尾で、バリデーションクエリを投げる仕組み*を導入したバリデーションに失敗したら、DAG が失敗する DAG が失敗したら、GitHub Issue を作成する #バリデーションクエリの例 ASSERT (( SELECT COUNT(*), FROM table ) > 0) ; validation b a c * 実態は、渡されたSQLを実行する KubernetesPodOperator 1件以上のレコードがあれば成功するインシデント対応の工夫事象検知：　事象を検知する手段を増やす

Slide 33

Slide 33 text

事象検知 33 - 「Cloud Monitoring でアラートを検知したら、GitHub Issue を作成する」 - 「DAG が失敗したら、GitHub Issue を作成する」 ... など基本的な方針として、何かが起きたら、GitHub Issue を作成してストックするそしてGitHub Issue の一覧は定期的に自動通知して、見逃しを防ぐ工夫をしているインシデント対応の工夫 GitHub Issue の通知には、特定ラベルが付いたIssueを特定時間にSlackに通知する仕組み linyows/github-issues-notice を利用しています

Slide 34

Slide 34 text

事象検知 34 - アラートを適切に設定する - データに対するチェックを行う - 何かが起きたら、GitHub Issue を立てるこのような工夫によって、事象が発生したときに、以前よりも早く検知ができるようになったインシデント対応の工夫

Slide 35

Slide 35 text

事象を検知したら、みんなに情報共有 35 🔗インシデントレスポンスを自動化で支援する Slack Bot で人機一体なセキュリティ対策を実現する - SEASON2 インシデント対応の工夫

Slide 36

Slide 36 text

36 - Slackチャンネルの作成 - 初動対応チームの招集 * * サービス、部門ごとに初動対応チームを編成している。技術職、カスタマーサポート職、マネージャー職などが含まれたSlack グループインシデント対応訓練のSlack通知インシデント対応の工夫 Slack チャンネルを見れば、これまでの調査内容を追うことができる事象を検知したら、みんなに情報共有

Slide 37

Slide 37 text

37 インシデント対応の工夫事象検知影響範囲の特定チーム間の役割分担

Slide 38

Slide 38 text

影響範囲の特定 38 人力で頑張るのは、とても時間がかかる... たくさんのファイルを読み解いて、手作業で影響範囲をまとめていた - 処理の依存関係 - 実行周期 - 同期方法など ... 実行周期同期方法必要な情報が散らばっている影響範囲のまとめインシデント対応の工夫

Slide 39

Slide 39 text

影響範囲の特定 39 データリネージの仕組みで、影響のあるジョブやテーブルを確認するインシデント対応の工夫 🔗データリネージの組織導入事例と今後の戦略

Slide 40

Slide 40 text

影響範囲の特定 40 データリネージの仕組みで、影響のあるジョブやテーブルを確認する # users テーブルの下流テーブルを抽出する例 $ stairlight down -c config -r -t users [ "hoge", "fuga", ... ] インシデント対応の工夫

Slide 41

Slide 41 text

影響範囲の特定 41 データリネージの仕組みで、影響のあるジョブやテーブルを確認する # users テーブルの下流テーブルを抽出する例 $ stairlight down -c config -r -t users [ "hoge", "fuga", ... ] インシデント対応時には、他にも ... - xx テーブルに依存する SQLファイル - xx テーブルに依存する Cloud Composer DAG といった情報を抽出している影響範囲の特定にかかる時間が減少 ↓ インシデント対応の工夫

Slide 42

Slide 42 text

影響範囲の特定 42 Table　A Table　B Table　C Table　D Table　E DAG 1 DAG ２「誰がどのテーブルを見ているか分からない」ので、 - テーブルが壊れたことを誰に伝えたらよいか - どの処理を優先して復旧させればよいか見当をつけるのが難しいどちらを優先して復旧させる? インシデント対応の工夫

Slide 43

Slide 43 text

影響範囲の特定 43 クエリ実行ログを見て、「誰が困っているか」を把握するテーブル名参照数 Table E 1000 Table D 800 Table A 1 Table B 1 Table C 1 テーブル参照数を抽出する例 INFORMATION _SCHEMA をもとに、テーブル参照数やテーブルを参照している人を取得するViewを作りましたテーブル名実行したクエリクエリを実行した人のメールアドレス Table E ... ... Table E ... ... テーブルを参照している人を抽出する例インシデント対応の工夫

Slide 44

Slide 44 text

44 インシデント対応の工夫事象検知チーム間の役割分担影響範囲の特定

Slide 45

Slide 45 text

チーム間の役割分担 45 - 影響範囲をスプレッドシートで共有し、ジョブ再実行の判断を分担する - DAGやクエリの実装と見比べて、対応の優先度や再実行の判断を行う - GitHub Issue と Assign 機能を使って、復旧対応を分担する - 失敗したジョブは GitHub Issue で可視化されているので、分担して再実行 - 必要に応じて他のチームメンバーの手を借りる - sssbot が作成した Slack チャンネルに人を呼ぶ - Slack チャンネルを見れば、これまでの調査内容を追うことができるツールをうまく使って、みんなと協力するインシデント対応の工夫

Slide 46

Slide 46 text

インシデント対応における工夫を紹介しました - 事象検知 - 影響範囲の特定 - チーム間の役割分担まとめ 46 すぐにできるようになったわけではなく、ポストモーテム(事後分析)を書いて、アクションアイテム(再発防止策)を出して、地道に対応していった結果として、発生から復旧までの時間を短縮できるようになりましたインシデント対応の工夫

Slide 47

Slide 47 text

これからやっていきたいこと 47 - カラム単位の異常検知値の傾向が急激に変化した時に検出する(例: NULLの割合が急に増加した*) 検知ルールの管理方法をわかりやすく管理できるような仕組みが作れると良さそう - 職種や部署を超えて、みんなとうまく協力するための仕組みづくりデータ基盤チームの力だけでは単純に手数が足りないことがあったり、わからない部分があったりする専門分野は得意な人に任せて、みんなの力で対応できるようにしたいインシデント対応の工夫 💡最近のトピック: データ欠落を検知できるようになりました。カラム単位でNULLの割合を見て、割合が急激に変化したら通知するような処理を GitHub Actions で定期実行しています。

Slide 48

Slide 48 text

48 ETLサービスの活用を支えるインシデント対応の工夫小松ももか / GMO PEPABO inc. 2023.06.05　データエンジニアリング合同勉強会