Tweet
Tweet

Slide 1

Slide 1 text

1 データ基盤の信頼性エンジニアリング 超実践編 Platform EngineeringによってSRE業はなくなるのか、 と⼈類が議論している傍らで今⽇も基盤システムは壊れ続ける GMOペパボ 技術部データ基盤チーム 染⽮健⼈ 2025-02-07 @ Road to SRE NEXT@京都

Slide 2

Slide 2 text

2 京都

Slide 3

Slide 3 text

3 ⾃⼰紹介 技術部 データ基盤チーム 2022年 新卒⼊社 染⽮ 健⼈ Someya Kento GMOペパボでSREingをやっています。 ３年前まで京都に住んでいました。⻄陣のあたり。 ● GitHub: @kesompochy ● Twitter : @kesompochy ● 書いた記事: https://tech.pepabo.com/authors/pochy/

Slide 4

Slide 4 text

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が動かない

Slide 5

Slide 5 text

GMOペパボ 5

Slide 6

Slide 6 text

企業理念 もっとおもしろくできる 6

Slide 7

Slide 7 text

⾃⼰紹介 7 「⼈類のアウトプットを増やす」サービスを複数運営 GMOペパボの事業

Slide 8

Slide 8 text

データ基盤 8

Slide 9

Slide 9 text

データを蓄積/加⼯/分析するための 基盤システム 9

Slide 10

Slide 10 text

ペパボのデータ基盤 “Bigfoot” 10 マスコットキャラクター「 Bigfootくん」

Slide 11

Slide 11 text

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

Slide 12

Slide 12 text

データ基盤の信頼性 12

Slide 13

Slide 13 text

データ基盤の信頼性とは 13 ● 完全性 → ⽋損がない ● 正確性 → 事象を正しく表現している（正しさとは？） ● 適時性 → ほしいときにアクセスできる ● etc... データの信頼性

Slide 14

Slide 14 text

データ基盤の信頼性とは 14 ● ELTジョブの成功率 → データ完全性、適時性 ● パイプラインの⽣存率 → データ完全性、適時性 ● 加⼯クエリの正しさ → データ正確性 ● クエリが返ってくるまでの速さ → データ適時性 データ基盤の信頼性

Slide 15

Slide 15 text

超実践編 15

Slide 16

Slide 16 text

①なぜかたまに 失敗するDAG 16

Slide 17

Slide 17 text

なぜかたまに失敗するDAG 17 ● Directed Acyclic Graph ● 有向⾮巡回グラフ DAG start end

Slide 18

Slide 18 text

なぜかたまに失敗するDAG 18 ● ワークフローオーケストレーションエンジン ● DAGを定義すると実⾏される ● ペパボではCloud Composerでホストしている ● ELTジョブなどの実⾏環境として利⽤している Airflow

Slide 19

Slide 19 text

「なんか分かんないけど たまに失敗する」 19

Slide 20

Slide 20 text

「祈って再実⾏すると うまくいきがち」 20

Slide 21

Slide 21 text

なぜかたまに失敗するDAG 21 ● その「ガチャ」は将来にわたって⼈間の時間資産と集 中⼒資産を奪い続ける ● その資産で⽣産できるはずだった価値で家が建つ ● ガチャ事象はトイルと⾒做して早期解決しよう 詳解 お祈りre-runを忌避するべき理由

Slide 22

Slide 22 text

なぜかたまに失敗する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. 調査① ログ

Slide 23

Slide 23 text

なぜかたまに失敗するDAG 23 podのephemeral storageが30分で5GBに到達して 爆死している様子 調査② メトリクス

Slide 24

Slide 24 text

なぜかたまに失敗する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*ディレクトリが存在した

Slide 25

Slide 25 text

なぜかたまに失敗するDAG 25 ● ディレクトリ名からフレームワークのCosmosを被疑 として調査した ● https://github.com/astronomer/astronomer-cosmos/issues/958 ● 同様の現象を⽰すIssueが⽴っているのを 発⾒したためそこで調査した 調査④ コードリーディング

Slide 26

Slide 26 text

なぜかたまに失敗するDAG 26 ● Pythonのshallow copyに由来す るCosmosのバグだったので修正 して解決 ○ （1回⽬のPRでバグを仕込みましたごめんなさい） ● 詳細は→ https://tech.pepabo.com/2024/12/11/airflow- trouble-shoot/ 解消

Slide 27

Slide 27 text

②ひっそりと壊れる データパイプライン 27

Slide 28

Slide 28 text

ひっそりと壊れるデータパイプライン 28 Webアプリが出⼒するログを、StatefulSetのfluentdが メッセージングサービスに送る Webアプリのログパイプライン

Slide 29

Slide 29 text

ひっそりと壊れるデータパイプライン 29 ● ログ流量監視だけでは⽋損に気づきにくい場合がある ○ ⼀部経路だけ⽌まっていたり ○ Greenのパイプラインが⽌まっているのにBlue→Greenを徐々に切り替えたり ● パイプライン⾃体の死活を観測できたい ログパイプラインの課題 ❌

Slide 30

Slide 30 text

ひっそりと壊れるデータパイプライン 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”} メトリクスとして エクスポート

Slide 31

Slide 31 text

ひっそりと壊れるデータパイプライン 31 ● https://github.com/kesompochy/beametrics ● キューイングされた構造化ログの内容をメトリクスにして投げ続け るくん ● うまくログを出せばビジネス指標の即時可視化や監視にも使えるは ず ● Let your logs be metrics with Apache Beam. kesompochy/beametrics

Slide 32

Slide 32 text

ひっそりと壊れるデータパイプライン 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に投げる」

Slide 33

Slide 33 text

③20000件のクエリ を書き換えろ 33

Slide 34

Slide 34 text

20000件のRedashクエリを書き換えろ 34 ● 多機能なBIツール ○ 複数データソース対応 ○ クエリ保存 ○ ダッシュボード作成 ● ペパボではk8sでホストしている ● ログや事業データをアドホックに分析するのに使う Redash

Slide 35

Slide 35 text

20000件のRedashクエリを書き換えろ 35 ● データ基盤からBIツールを把握/制御できない問題 ○ いまどれだけのクエリがデータソースを参照しているの？ ○ 意図してない使われ⽅してない？ ○ 分析⽤テーブルの名前を変えたいけど、参照クエリを全部書き換えないと使⽤者が困るよね ● 「では今から、20000件のRedashクエリから条件に合うも のを探して、その全てに対してテーブル名書き換え操作を してください」 BIツールの課題

Slide 36

Slide 36 text

20000件のRedashクエリを書き換えろ 36 ● https://github.com/kesompochy/biops ● BIツールに対する操作をするくん ○ 操作例 ■ 特定条件を満たすクエリ⼀覧を取得 ■ クエリの⽂字列を置換して更新 ■ 更新作業のdry-run, recovery ○ 現状はRedashのみ対応 ■ （Metabaseなどにも対応したい気持ちでBI Opsと名付けた） kesompochy/biops

Slide 37

Slide 37 text

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コマンドが表⽰される

Slide 38

Slide 38 text

④沈黙する データ抽出 ジョブ 38

Slide 39

Slide 39 text

沈黙するデータ抽出ジョブ 39 ● ETLツール ● ペパボではk8sでホストしている ● ZendeskやDatadogからのデータ抽出に使っている Airbyte

Slide 40

Slide 40 text

沈黙するデータ抽出ジョブ 40 ● いつからか、Airbyteジョブが実⾏されていなかった ○ （実はArgo CD Applicationごと消えていた） ■ （⼿動のオペミスが原因と判断したため、その後にApplicationを消せる権限を⼈間から剥奪した） ● ジョブの失敗通知は⾶ばせるが、ジョブ⾃体がないと きに検知できる仕組みがなかった 突然の沈黙 < good bye

Slide 41

Slide 41 text

沈黙するデータ抽出ジョブ 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

Slide 42

Slide 42 text

⑤Terraform apply したらテーブルが 消えた 42

Slide 43

Slide 43 text

テーブル消失事故 43 ● 意図せず消えた ● てんやわんや ● 幸いにもBigQueryのタイムトラベル機能でデータロス にはならなかった ● ﾋﾔﾘﾊｯﾄ事例なので早めに事故の芽を摘みたい applyしたらBQテーブルが消えた

Slide 44

Slide 44 text

テーブル消失事故 44 ● https://github.com/hashicorp/terraform-provider-google/issues/19485 調査

Slide 45

Slide 45 text

テーブル消失事故 45 ● terraform plan後に⼿動実⾏されたbqコマンドの影響 だったと思われる ● policyTagsの扱いとbqコマンドとの⾷い合わせが悪かっ たようだが真相は掴めず ● provider側で不要なAPIリクエストをなくす⽅針でメン テナと合意した 緩和

Slide 46

Slide 46 text

⑥「神ビュー」 46

Slide 47

Slide 47 text

「神ビュー」 47 ● ⼈間には到底読み解けないクエリで書かれたビュー ● 複雑なデータ処理をしようとすると神ビューになる ○ 例: DBにあるデータのミラーをニアリアルタイムにBigQueryで提供するビュー ■ 次の⼆つのデータをマージするビューにして実現 ● 定期で取得するRDBのスナップショットデータ ● RDBのCDCログ ■ https://tech.pepabo.com/2023/04/20/cdc-for-realtime-analysis/ 神ビュー

Slide 48

Slide 48 text

「神ビュー」 48 WITH operation_priorities AS ( SELECT _record.* FROM ( SELECT ARRAY>[ ("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でパラメータを条件 分岐するための三項演算⼦が地獄の ように続く ● ⻑いコードってスライドに載せられなくない？

Slide 49

Slide 49 text

「神ビュー」 49 ● 「時間おかしいです」 ○ タイムゾーン、時刻の精度がデータソースによって異なるため条件分岐が必要 ● 「ぜんぶfalseになってます」 ○ MySQLではbooleanはtinyintだが、PostgreSQLでは’true’, ʻno’ など様々なリテラルがある ため条件分岐が必要 ○ https://www.postgresql.jp/docs/9.4/datatype-boolean.html 神ビューの信頼性課題

Slide 50

Slide 50 text

「神ビュー」 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 = <

Slide 51

Slide 51 text

⑦BigQueryが 動かない 51

Slide 52

Slide 52 text

BigQueryが動かない 52 ● https://cloud.google.com/bigquery/pricing?hl=ja ● slotという単位でコンピュートリソースを使⽤する ● 料⾦プランごとに同時に使⽤できるslotの上限がある BigQueryのコンピュートリソース上限

Slide 53

Slide 53 text

BigQueryが動かない 53 ● slot使⽤が重なるタイミングがある ○ 分析者がクエリを投げてもなかなか返って来なくなったり ○ データ操作ジョブのタイムアウトに繋がったり slot

Slide 54

Slide 54 text

BigQueryが動かない 54 ● 重いクエリを流すジョブ群を特定して実⾏時間を分散さ せることで解消 ● ⾃動で最適化したい（今後の展望） ○ AirflowのDAG実⾏履歴とBQのジョブ履歴を分析したら、slotの制約を満たしながらコスト 最適なDAG実⾏時刻が決定できるのでは？ 解消

Slide 55

Slide 55 text

まとめ 55

Slide 56

Slide 56 text

まとめ 56 ● データ基盤の運⽤にもSREプラクティスを使う ○ 信頼性指標を定めて改善 ○ 監視 ○ 可観測性 ○ ⾃動テスト ○ ⾮難なきポストモーテムによる再発防⽌ ○ ソフトウェアによる⾃動化 まとめ

Slide 57

Slide 57 text

57 おわり