Upgrade to Pro
— share decks privately, control downloads, hide ads and more …
Speaker Deck
Features
Speaker Deck
PRO
Sign in
Sign up for free
Search
Search
データ基盤の信頼性エンジニアリング 超実践編 〜Platform Engineeringによっ...
Search
kesompochy
February 07, 2025
0
350
データ基盤の信頼性エンジニアリング 超実践編 〜Platform EngineeringによってSRE業はなくなるのか、と人類が議論している傍らで今日も基盤システムは壊れ続ける〜
2025/02/07 Road to SRE NEXT@京都の登壇資料です。
kesompochy
February 07, 2025
Tweet
Share
More Decks by kesompochy
See All by kesompochy
もっとSREを広げるための初学者向け技術研修設計
kesompochy
0
3.7k
データ駆動のFinOpsを実現するための社内横断データ基盤
kesompochy
0
140
ペパボのオブザーバビリティ研修2024 説明資料
kesompochy
1
4.1k
こわくないRDS B/Gデプロイ
kesompochy
12
1.9k
Featured
See All Featured
How STYLIGHT went responsive
nonsquared
98
5.4k
RailsConf & Balkan Ruby 2019: The Past, Present, and Future of Rails at GitHub
eileencodes
133
33k
The Illustrated Children's Guide to Kubernetes
chrisshort
48
49k
It's Worth the Effort
3n
184
28k
The World Runs on Bad Software
bkeepers
PRO
67
11k
Put a Button on it: Removing Barriers to Going Fast.
kastner
60
3.7k
Understanding Cognitive Biases in Performance Measurement
bluesmoon
27
1.6k
Designing for Performance
lara
604
68k
4 Signs Your Business is Dying
shpigford
182
22k
Producing Creativity
orderedlist
PRO
344
39k
The Straight Up "How To Draw Better" Workshop
denniskardys
232
140k
GitHub's CSS Performance
jonrohan
1030
460k
Transcript
1 データ基盤の信頼性エンジニアリング 超実践編 Platform EngineeringによってSRE業はなくなるのか、 と⼈類が議論している傍らで今⽇も基盤システムは壊れ続ける GMOペパボ 技術部データ基盤チーム 染⽮健⼈ 2025-02-07
@ Road to SRE NEXT@京都
2 京都
3 ⾃⼰紹介 技術部 データ基盤チーム 2022年 新卒⼊社 染⽮ 健⼈ Someya Kento
GMOペパボでSREingをやっています。 3年前まで京都に住んでいました。⻄陣のあたり。 • GitHub: @kesompochy • Twitter : @kesompochy • 書いた記事: https://tech.pepabo.com/authors/pochy/
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が動かない
GMOペパボ 5
企業理念 もっとおもしろくできる 6
⾃⼰紹介 7 「⼈類のアウトプットを増やす」サービスを複数運営 GMOペパボの事業
データ基盤 8
データを蓄積/加⼯/分析するための 基盤システム 9
ペパボのデータ基盤 “Bigfoot” 10 マスコットキャラクター「 Bigfootくん」
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
データ基盤の信頼性とは 13 • 完全性 → ⽋損がない • 正確性 → 事象を正しく表現している(正しさとは?)
• 適時性 → ほしいときにアクセスできる • etc... データの信頼性
データ基盤の信頼性とは 14 • ELTジョブの成功率 → データ完全性、適時性 • パイプラインの⽣存率 → データ完全性、適時性
• 加⼯クエリの正しさ → データ正確性 • クエリが返ってくるまでの速さ → データ適時性 データ基盤の信頼性
超実践編 15
①なぜかたまに 失敗するDAG 16
なぜかたまに失敗するDAG 17 • Directed Acyclic Graph • 有向⾮巡回グラフ DAG start
end
なぜかたまに失敗するDAG 18 • ワークフローオーケストレーションエンジン • DAGを定義すると実⾏される • ペパボではCloud Composerでホストしている •
ELTジョブなどの実⾏環境として利⽤している Airflow
「なんか分かんないけど たまに失敗する」 19
「祈って再実⾏すると うまくいきがち」 20
なぜかたまに失敗するDAG 21 • その「ガチャ」は将来にわたって⼈間の時間資産と集 中⼒資産を奪い続ける • その資産で⽣産できるはずだった価値で家が建つ • ガチャ事象はトイルと⾒做して早期解決しよう 詳解
お祈りre-runを忌避するべき理由
なぜかたまに失敗する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. 調査① ログ
なぜかたまに失敗するDAG 23 podのephemeral storageが30分で5GBに到達して 爆死している様子 調査② メトリクス
なぜかたまに失敗する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*ディレクトリが存在した
なぜかたまに失敗するDAG 25 • ディレクトリ名からフレームワークのCosmosを被疑 として調査した • https://github.com/astronomer/astronomer-cosmos/issues/958 • 同様の現象を⽰すIssueが⽴っているのを 発⾒したためそこで調査した
調査④ コードリーディング
なぜかたまに失敗するDAG 26 • Pythonのshallow copyに由来す るCosmosのバグだったので修正 して解決 ◦ (1回⽬のPRでバグを仕込みましたごめんなさい) •
詳細は→ https://tech.pepabo.com/2024/12/11/airflow- trouble-shoot/ 解消
②ひっそりと壊れる データパイプライン 27
ひっそりと壊れるデータパイプライン 28 Webアプリが出⼒するログを、StatefulSetのfluentdが メッセージングサービスに送る Webアプリのログパイプライン
ひっそりと壊れるデータパイプライン 29 • ログ流量監視だけでは⽋損に気づきにくい場合がある ◦ ⼀部経路だけ⽌まっていたり ◦ Greenのパイプラインが⽌まっているのにBlue→Greenを徐々に切り替えたり • パイプライン⾃体の死活を観測できたい
ログパイプラインの課題 ❌
ひっそりと壊れるデータパイプライン 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 • https://github.com/kesompochy/beametrics • キューイングされた構造化ログの内容をメトリクスにして投げ続け るくん • うまくログを出せばビジネス指標の即時可視化や監視にも使えるは ず
• Let your logs be metrics with Apache Beam. kesompochy/beametrics
ひっそりと壊れるデータパイプライン 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に投げる」
③20000件のクエリ を書き換えろ 33
20000件のRedashクエリを書き換えろ 34 • 多機能なBIツール ◦ 複数データソース対応 ◦ クエリ保存 ◦ ダッシュボード作成
• ペパボではk8sでホストしている • ログや事業データをアドホックに分析するのに使う Redash
20000件のRedashクエリを書き換えろ 35 • データ基盤からBIツールを把握/制御できない問題 ◦ いまどれだけのクエリがデータソースを参照しているの? ◦ 意図してない使われ⽅してない? ◦ 分析⽤テーブルの名前を変えたいけど、参照クエリを全部書き換えないと使⽤者が困るよね
• 「では今から、20000件のRedashクエリから条件に合うも のを探して、その全てに対してテーブル名書き換え操作を してください」 BIツールの課題
20000件のRedashクエリを書き換えろ 36 • https://github.com/kesompochy/biops • BIツールに対する操作をするくん ◦ 操作例 ▪ 特定条件を満たすクエリ⼀覧を取得
▪ クエリの⽂字列を置換して更新 ▪ 更新作業のdry-run, recovery ◦ 現状はRedashのみ対応 ▪ (Metabaseなどにも対応したい気持ちでBI Opsと名付けた) kesompochy/biops
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
沈黙するデータ抽出ジョブ 39 • ETLツール • ペパボではk8sでホストしている • ZendeskやDatadogからのデータ抽出に使っている Airbyte
沈黙するデータ抽出ジョブ 40 • いつからか、Airbyteジョブが実⾏されていなかった ◦ (実はArgo CD Applicationごと消えていた) ▪ (⼿動のオペミスが原因と判断したため、その後にApplicationを消せる権限を⼈間から剥奪した)
• ジョブの失敗通知は⾶ばせるが、ジョブ⾃体がないと きに検知できる仕組みがなかった 突然の沈黙 < good bye
沈黙するデータ抽出ジョブ 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
⑤Terraform apply したらテーブルが 消えた 42
テーブル消失事故 43 • 意図せず消えた • てんやわんや • 幸いにもBigQueryのタイムトラベル機能でデータロス にはならなかった •
ヒヤリハット事例なので早めに事故の芽を摘みたい applyしたらBQテーブルが消えた
テーブル消失事故 44 • https://github.com/hashicorp/terraform-provider-google/issues/19485 調査
テーブル消失事故 45 • terraform plan後に⼿動実⾏されたbqコマンドの影響 だったと思われる • policyTagsの扱いとbqコマンドとの⾷い合わせが悪かっ たようだが真相は掴めず •
provider側で不要なAPIリクエストをなくす⽅針でメン テナと合意した 緩和
⑥「神ビュー」 46
「神ビュー」 47 • ⼈間には到底読み解けないクエリで書かれたビュー • 複雑なデータ処理をしようとすると神ビューになる ◦ 例: DBにあるデータのミラーをニアリアルタイムにBigQueryで提供するビュー ▪
次の⼆つのデータをマージするビューにして実現 • 定期で取得するRDBのスナップショットデータ • RDBのCDCログ ▪ https://tech.pepabo.com/2023/04/20/cdc-for-realtime-analysis/ 神ビュー
「神ビュー」 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 • 「時間おかしいです」 ◦ タイムゾーン、時刻の精度がデータソースによって異なるため条件分岐が必要 • 「ぜんぶfalseになってます」 ◦ MySQLではbooleanはtinyintだが、PostgreSQLでは’true’,
ʻno’ など様々なリテラルがある ため条件分岐が必要 ◦ https://www.postgresql.jp/docs/9.4/datatype-boolean.html 神ビューの信頼性課題
「神ビュー」 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 = [] }
⑦BigQueryが 動かない 51
BigQueryが動かない 52 • https://cloud.google.com/bigquery/pricing?hl=ja • slotという単位でコンピュートリソースを使⽤する • 料⾦プランごとに同時に使⽤できるslotの上限がある BigQueryのコンピュートリソース上限
BigQueryが動かない 53 • slot使⽤が重なるタイミングがある ◦ 分析者がクエリを投げてもなかなか返って来なくなったり ◦ データ操作ジョブのタイムアウトに繋がったり slot
BigQueryが動かない 54 • 重いクエリを流すジョブ群を特定して実⾏時間を分散さ せることで解消 • ⾃動で最適化したい(今後の展望) ◦ AirflowのDAG実⾏履歴とBQのジョブ履歴を分析したら、slotの制約を満たしながらコスト 最適なDAG実⾏時刻が決定できるのでは?
解消
まとめ 55
まとめ 56 • データ基盤の運⽤にもSREプラクティスを使う ◦ 信頼性指標を定めて改善 ◦ 監視 ◦ 可観測性
◦ ⾃動テスト ◦ ⾮難なきポストモーテムによる再発防⽌ ◦ ソフトウェアによる⾃動化 まとめ
57 おわり