データ基盤の信頼性エンジニアリング 超実践編 〜Platform EngineeringによってSRE業はなくなるのか、と人類が議論している傍らで今日も基盤システムは壊れ続ける〜

2025/02/07 Road to SRE NEXT@京都の登壇資料です。

Transcript

1. 1 データ基盤の信頼性エンジニアリング 超実践編 Platform EngineeringによってSRE業はなくなるのか、 と⼈類が議論している傍らで今⽇も基盤システムは壊れ続ける GMOペパボ 技術部データ基盤チーム 染⽮健⼈ 2025-02-07 @ Road to SRE NEXT@京都
2. 2 京都
3. 3 ⾃⼰紹介 技術部 データ基盤チーム 2022年 新卒⼊社 染⽮ 健⼈ Someya Kento GMOペパボでSREingをやっています。 ３年前まで京都に住んでいました。⻄陣のあたり。 • GitHub: @kesompochy • Twitter : @kesompochy • 書いた記事: https://tech.pepabo.com/authors/pochy/
4. 4 アジェンダ 1. 京都 2. ⾃⼰紹介を10秒で 3. データ基盤とその信頼性とは 4. データ基盤の信頼性エンジニアリング 超実践編 4.1. なぜかたまに失敗するDAG 4.2. ひっそりと壊れるデータパイプライン 4.3. 20000件のクエリを書き換えろ 4.4. 沈黙するデータ抽出ジョブ 4.5. Terraform applyしたらテーブルが消えた 4.6. 「神ビュー」の信頼性担保 4.7. BigQueryが動かない
5. GMOペパボ 5
6. 企業理念 もっとおもしろくできる 6
7. ⾃⼰紹介 7 「⼈類のアウトプットを増やす」サービスを複数運営 GMOペパボの事業
8. データ基盤 8
9. データを蓄積/加⼯/分析するための 基盤システム 9
10. ペパボのデータ基盤 “Bigfoot” 10 マスコットキャラクター「 Bigfootくん」
11. 11 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
12. データ基盤の信頼性 12
13. データ基盤の信頼性とは 13 • 完全性 → ⽋損がない • 正確性 → 事象を正しく表現している（正しさとは？） • 適時性 → ほしいときにアクセスできる • etc... データの信頼性
14. データ基盤の信頼性とは 14 • ELTジョブの成功率 → データ完全性、適時性 • パイプラインの⽣存率 → データ完全性、適時性 • 加⼯クエリの正しさ → データ正確性 • クエリが返ってくるまでの速さ → データ適時性 データ基盤の信頼性
15. 超実践編 15
16. ①なぜかたまに 失敗するDAG 16
17. なぜかたまに失敗するDAG 17 • Directed Acyclic Graph • 有向⾮巡回グラフ DAG start end
18. なぜかたまに失敗するDAG 18 • ワークフローオーケストレーションエンジン • DAGを定義すると実⾏される • ペパボではCloud Composerでホストしている • ELTジョブなどの実⾏環境として利⽤している Airflow
19. 「なんか分かんないけど たまに失敗する」 19
20. 「祈って再実⾏すると うまくいきがち」 20
21. なぜかたまに失敗するDAG 21 • その「ガチャ」は将来にわたって⼈間の時間資産と集 中⼒資産を奪い続ける • その資産で⽣産できるはずだった価値で家が建つ • ガチャ事象はトイルと⾒做して早期解決しよう 詳解 お祈りre-runを忌避するべき理由
22. なぜかたまに失敗するDAG 22 A worker pod was evicted at 2024-08-27T23:56:15Z with message: Pod ephemeral local storage usage exceeds the total limit of containers 5119Mi. 調査① ログ
23. なぜかたまに失敗するDAG 23 podのephemeral storageが30分で5GBに到達して 爆死している様子 調査② メトリクス
24. なぜかたまに失敗するDAG 24 調査③ コンテナのファイルシステム $ kubectl exec -it airflow-worker-hogefuga -- du -sh /tmp/* 7.6M /tmp/cosmos 406M /tmp/cosmos-venv0k4rdj03 406M /tmp/cosmos-venv3h0tgrmm 406M /tmp/cosmos-venv4i4noepm 406M /tmp/cosmos-venv5f9d2t4e 406M /tmp/cosmos-venv6ic6dauo 408M /tmp/cosmos-venv7jae8s7h 406M /tmp/cosmos-venv8_3_0sjh 406M /tmp/cosmos-venv93rohh8e 406M /tmp/cosmos-venvao9p5wmo … # 10個以上/tmp/cosmos-venv*ディレクトリが存在した
25. なぜかたまに失敗するDAG 25 • ディレクトリ名からフレームワークのCosmosを被疑 として調査した • https://github.com/astronomer/astronomer-cosmos/issues/958 • 同様の現象を⽰すIssueが⽴っているのを 発⾒したためそこで調査した 調査④ コードリーディング
26. なぜかたまに失敗するDAG 26 • Pythonのshallow copyに由来す るCosmosのバグだったので修正 して解決 ◦ （1回⽬のPRでバグを仕込みましたごめんなさい） • 詳細は→ https://tech.pepabo.com/2024/12/11/airflow- trouble-shoot/ 解消
27. ②ひっそりと壊れる データパイプライン 27
28. ひっそりと壊れるデータパイプライン 28 Webアプリが出⼒するログを、StatefulSetのfluentdが メッセージングサービスに送る Webアプリのログパイプライン
29. ひっそりと壊れるデータパイプライン 29 • ログ流量監視だけでは⽋損に気づきにくい場合がある ◦ ⼀部経路だけ⽌まっていたり ◦ Greenのパイプラインが⽌まっているのにBlue→Greenを徐々に切り替えたり • パイプライン⾃体の死活を観測できたい ログパイプラインの課題 ❌
30. ひっそりと壊れるデータパイプライン 30 • fluentdのdummyプラグインでダミーデータを流し続ける • ダミーデータを元に「パイプライン死活」を表すメトリクスとしてエク スポートしつづける パイプラインの死活をメトリクス化 { “pipeline-id”: “0”, “pipeline-env”: “blue” , “time”: “2025-02-07 15:12:43 UTC”} { “pipeline-id”: “1”, “pipeline-env”: “blue” , “time”: “2025-02-07 15:12:43 UTC”} { “pipeline-id”: “2”, “pipeline-env”: “blue” , “time”: “2025-02-07 15:12:43 UTC”} メトリクスとして エクスポート
31. ひっそりと壊れるデータパイプライン 31 • https://github.com/kesompochy/beametrics • キューイングされた構造化ログの内容をメトリクスにして投げ続け るくん • うまくログを出せばビジネス指標の即時可視化や監視にも使えるは ず • Let your logs be metrics with Apache Beam. kesompochy/beametrics
32. ひっそりと壊れるデータパイプライン 32 $ cat YOUR_CONFIG_FILE.yaml metrics: - name: beametrics-test-1 labels: LABEL: HOGE1 dynamic_labels: label_key: some_key filter-conditions: - field: user value: dummy operator: equals type: count export_type: google-cloud-monitoring type: count export_type: google-cloud-monitoring beametricsの使い⽅ • Dataflowのflex templateとして 使⽤可能 • →のようにyamlでメトリクス設 定を宣⾔できる ◦ 「userがdummyなものの数を集計、 some_keyの値をラベルとしてつける、 メトリクスはcloud monitoringに投げる」
33. ③20000件のクエリ を書き換えろ 33
34. 20000件のRedashクエリを書き換えろ 34 • 多機能なBIツール ◦ 複数データソース対応 ◦ クエリ保存 ◦ ダッシュボード作成 • ペパボではk8sでホストしている • ログや事業データをアドホックに分析するのに使う Redash
35. 20000件のRedashクエリを書き換えろ 35 • データ基盤からBIツールを把握/制御できない問題 ◦ いまどれだけのクエリがデータソースを参照しているの？ ◦ 意図してない使われ⽅してない？ ◦ 分析⽤テーブルの名前を変えたいけど、参照クエリを全部書き換えないと使⽤者が困るよね • 「では今から、20000件のRedashクエリから条件に合うも のを探して、その全てに対してテーブル名書き換え操作を してください」 BIツールの課題
36. 20000件のRedashクエリを書き換えろ 36 • https://github.com/kesompochy/biops • BIツールに対する操作をするくん ◦ 操作例 ▪ 特定条件を満たすクエリ⼀覧を取得 ▪ クエリの⽂字列を置換して更新 ▪ 更新作業のdry-run, recovery ◦ 現状はRedashのみ対応 ▪ （Metabaseなどにも対応したい気持ちでBI Opsと名付けた） kesompochy/biops
37. 20000件のRedashクエリを書き換えろ 37 $ biops query list --query-regexp "mytable" 19563 19449 $ biops query update 19563 --query-replace "mytable" "mynewtable" --apply Updating query 19563... Updated query 19563! Diff: --- sql +++ sql select * from - dataset.mytable + dataset.mynewtable Recovery command: biops query update 18140 --query "select * from dataset.mytable” biops • RedashのAPIキーを渡せば準備完 了 • →のように更新の際はdiffと recoveryコマンドが表⽰される
38. ④沈黙する データ抽出 ジョブ 38
39. 沈黙するデータ抽出ジョブ 39 • ETLツール • ペパボではk8sでホストしている • ZendeskやDatadogからのデータ抽出に使っている Airbyte
40. 沈黙するデータ抽出ジョブ 40 • いつからか、Airbyteジョブが実⾏されていなかった ◦ （実はArgo CD Applicationごと消えていた） ▪ （⼿動のオペミスが原因と判断したため、その後にApplicationを消せる権限を⼈間から剥奪した） • ジョブの失敗通知は⾶ばせるが、ジョブ⾃体がないと きに検知できる仕組みがなかった 突然の沈黙 < good bye
41. 沈黙するデータ抽出ジョブ 41 • Airbyteのジョブはk8sのリソースである • Alertmanagerでジョブの存在を監視可能 監視 - alert: Airbyte Jobs expr: count(kube_pod_completion_time{namespace="prod", pod=~"source-.*|destination-.*"} > (time() - 3600)) < 1 for: 1m labels: severity: critical namespace: prod annotations: description: 'Airbyteのジョブが1時間以上実行されていない、あるいはすべて失敗しています。 ' summary: 'Airbyte jobs are not running' namespace: prod
42. ⑤Terraform apply したらテーブルが 消えた 42
43. テーブル消失事故 43 • 意図せず消えた • てんやわんや • 幸いにもBigQueryのタイムトラベル機能でデータロス にはならなかった • ﾋﾔﾘﾊｯﾄ事例なので早めに事故の芽を摘みたい applyしたらBQテーブルが消えた
44. テーブル消失事故 44 • https://github.com/hashicorp/terraform-provider-google/issues/19485 調査
45. テーブル消失事故 45 • terraform plan後に⼿動実⾏されたbqコマンドの影響 だったと思われる • policyTagsの扱いとbqコマンドとの⾷い合わせが悪かっ たようだが真相は掴めず • provider側で不要なAPIリクエストをなくす⽅針でメン テナと合意した 緩和
46. ⑥「神ビュー」 46
47. 「神ビュー」 47 • ⼈間には到底読み解けないクエリで書かれたビュー • 複雑なデータ処理をしようとすると神ビューになる ◦ 例: DBにあるデータのミラーをニアリアルタイムにBigQueryで提供するビュー ▪ 次の⼆つのデータをマージするビューにして実現 • 定期で取得するRDBのスナップショットデータ • RDBのCDCログ ▪ https://tech.pepabo.com/2023/04/20/cdc-for-realtime-analysis/ 神ビュー
48. 「神ビュー」 48 WITH operation_priorities AS ( SELECT _record.* FROM ( SELECT ARRAY<STRUCT<op STRING, priority INT64>>[ ("d", 1), ("u", 2), ("c", 3) ] AS _array ), UNNEST(_array) AS _record ), cdc AS ( SELECT JSON_VALUE(data, "$.payload.ts_ms") AS ts_ms, JSON_VALUE(data, "$.payload.op") AS op, STRUCT( ${parsed_before_primary_key_columns}, ${parsed_before_data_columns} ) AS before, STRUCT( ${parsed_after_primary_key_columns}, ${parsed_after_data_columns} ) AS after, FROM ${dataset}.${cdc_table} WHERE …… # あと5倍くらいある 神ビュー例 • →のようなSQLがterraformの templatefileとして存在する • それとは別にhclでパラメータを条件 分岐するための三項演算⼦が地獄の ように続く • ⻑いコードってスライドに載せられなくない？
49. 「神ビュー」 49 • 「時間おかしいです」 ◦ タイムゾーン、時刻の精度がデータソースによって異なるため条件分岐が必要 • 「ぜんぶfalseになってます」 ◦ MySQLではbooleanはtinyintだが、PostgreSQLでは’true’, ʻno’ など様々なリテラルがある ため条件分岐が必要 ◦ https://www.postgresql.jp/docs/9.4/datatype-boolean.html 神ビューの信頼性課題
50. 「神ビュー」 50 • terraform test + null resource + bqコマンドで実現 • また、localsの値もterraform testでテストできる • null resourceは最後の⼿段なのでもっと良い⼿がありそう ビュークエリの⾃動テスト SELECT -- 未来時刻がないこと COUNTIF(${column} > CURRENT_DATETIME()) = 0 -- 1時間以内のデータがあること AND COUNTIF(${column} > DATETIME_SUB(CURRENT_DATETIME(), INTERVAL 1 HOUR)) > 0 FROM view_query WHERE ${column} IS NOT NULL resource "null_resource" "validation_tests" { for_each = local.test_queries provisioner "local-exec" { command = <<EOT ASSERT( ${each.value.query} ) AS '${each.value.error}' EOT interpreter = ["bq", "query", "--use_legacy_sql=false"] } } run "check_bigquery_query" { command = apply plan_options { target = [ null_resource.validation_tests, ] refresh = true } expect_failures = [] }
51. ⑦BigQueryが 動かない 51
52. BigQueryが動かない 52 • https://cloud.google.com/bigquery/pricing?hl=ja • slotという単位でコンピュートリソースを使⽤する • 料⾦プランごとに同時に使⽤できるslotの上限がある BigQueryのコンピュートリソース上限
53. BigQueryが動かない 53 • slot使⽤が重なるタイミングがある ◦ 分析者がクエリを投げてもなかなか返って来なくなったり ◦ データ操作ジョブのタイムアウトに繋がったり slot
54. BigQueryが動かない 54 • 重いクエリを流すジョブ群を特定して実⾏時間を分散さ せることで解消 • ⾃動で最適化したい（今後の展望） ◦ AirflowのDAG実⾏履歴とBQのジョブ履歴を分析したら、slotの制約を満たしながらコスト 最適なDAG実⾏時刻が決定できるのでは？ 解消
55. まとめ 55
56. まとめ 56 • データ基盤の運⽤にもSREプラクティスを使う ◦ 信頼性指標を定めて改善 ◦ 監視 ◦ 可観測性 ◦ ⾃動テスト ◦ ⾮難なきポストモーテムによる再発防⽌ ◦ ソフトウェアによる⾃動化 まとめ
57. 57 おわり