Upgrade to Pro — share decks privately, control downloads, hide ads and more …

データ基盤の信頼性エンジニアリング 超実践編 〜Platform Engineeringによっ...

kesompochy
February 07, 2025
350

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

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

kesompochy

February 07, 2025
Tweet

Transcript

  1. 3 ⾃⼰紹介 技術部 データ基盤チーム 2022年 新卒⼊社 染⽮ 健⼈ Someya Kento

    GMOペパボでSREingをやっています。 3年前まで京都に住んでいました。⻄陣のあたり。 • GitHub: @kesompochy • Twitter : @kesompochy • 書いた記事: https://tech.pepabo.com/authors/pochy/
  2. 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が動かない
  3. 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
  4. データ基盤の信頼性とは 14 • ELTジョブの成功率 → データ完全性、適時性 • パイプラインの⽣存率 → データ完全性、適時性

    • 加⼯クエリの正しさ → データ正確性 • クエリが返ってくるまでの速さ → データ適時性 データ基盤の信頼性
  5. なぜかたまに失敗する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. 調査① ログ
  6. なぜかたまに失敗する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*ディレクトリが存在した
  7. ひっそりと壊れるデータパイプライン 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”} メトリクスとして エクスポート
  8. ひっそりと壊れるデータパイプライン 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に投げる」
  9. 20000件のRedashクエリを書き換えろ 34 • 多機能なBIツール ◦ 複数データソース対応 ◦ クエリ保存 ◦ ダッシュボード作成

    • ペパボではk8sでホストしている • ログや事業データをアドホックに分析するのに使う Redash
  10. 20000件のRedashクエリを書き換えろ 36 • https://github.com/kesompochy/biops • BIツールに対する操作をするくん ◦ 操作例 ▪ 特定条件を満たすクエリ⼀覧を取得

    ▪ クエリの⽂字列を置換して更新 ▪ 更新作業のdry-run, recovery ◦ 現状はRedashのみ対応 ▪ (Metabaseなどにも対応したい気持ちでBI Opsと名付けた) kesompochy/biops
  11. 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コマンドが表⽰される
  12. 沈黙するデータ抽出ジョブ 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
  13. 「神ビュー」 47 • ⼈間には到底読み解けないクエリで書かれたビュー • 複雑なデータ処理をしようとすると神ビューになる ◦ 例: DBにあるデータのミラーをニアリアルタイムにBigQueryで提供するビュー ▪

    次の⼆つのデータをマージするビューにして実現 • 定期で取得するRDBのスナップショットデータ • RDBのCDCログ ▪ https://tech.pepabo.com/2023/04/20/cdc-for-realtime-analysis/ 神ビュー
  14. 「神ビュー」 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でパラメータを条件 分岐するための三項演算⼦が地獄の ように続く • ⻑いコードってスライドに載せられなくない?
  15. 「神ビュー」 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 = [] }
  16. まとめ 56 • データ基盤の運⽤にもSREプラクティスを使う ◦ 信頼性指標を定めて改善 ◦ 監視 ◦ 可観測性

    ◦ ⾃動テスト ◦ ⾮難なきポストモーテムによる再発防⽌ ◦ ソフトウェアによる⾃動化 まとめ