Slide 1
Slide 1 text
データ分析基盤における
オブザーバビリティの取り組み
Observability Conference 2022
2022-03-11
1
Slide 2
Slide 2 text
自己紹介
松本 浩二 / Koji Matsumoto
@koji_mats
GMOペパボ株式会社 データエンジニア
2
Slide 3
Slide 3 text
概要
現在のペパボのデータ分析基盤を題材にして、データ分析基盤に求められる可用性や、小規模なチームに
おけるオブザーバビリティへの取り組みについて紹介します。
<ターゲット>
主に、Observabilityについてまだ実践できていないデータエンジニアやデータサイエンティスト。
3
Slide 4
Slide 4 text
アジェンダ
1. Observabilityとは
2. ペパボのデータ分析基盤 Bigfootの構成
3. BigfootのObservabilityの現状
4. Observabilityについて今後取り組んでいきたい課題
4
Slide 5
Slide 5 text
Observability(可観測性)とは
Observabilityとはシステムを構成するインフラやアプリケーションの状態を把握できるという性質
Observabilityがあると...
- 効率的にシステムの状態を把握できる
- システムのパフォーマンスや品質の向上などの改善活動に繋げられる
5
Slide 6
Slide 6 text
Observabilityが必要な背景
- 複雑な多数のコンポーネントの組み合わせによって構成されているシステムではサービスの問題の
原因がどこにあるかをすぐに把握するのは難しい
- 個別にモニタリングするだけでは、個々のモニタリングデータの関連を把握するのも困難
→ 個々のモニタリングデータに繋がりを持たせ、サービスの状態を効率的に把握できる状態にしてお
く
6
Slide 7
Slide 7 text
Observabilityが必要な背景 ~データ分析基盤~
- データ活用のニーズに対応すべく、スケーラブルな設計が求められる
- クラウドサービスやコンテナの組み合わせで構成することが多い
→ 問題発生時の原因切り分けに時間を要する
- データパイプラインの上で起きるデータに関する問題も効率的に把握できるようにしたい
- 少人数でも効率よく運用したい
- データ分析基盤は組織の重要な判断で使われる基盤
7
Slide 8
Slide 8 text
Observabilityに必要なプロセス
「システムの状態に関するデータ」の ...
- 収集
- 分析
- 可視化
「システムの状態に関するデータ」をテレメトリーデータという
8
Slide 9
Slide 9 text
テレメトリーデータ
- Metrics
- 特定期間のシステムに関する集計データ
- Log
- システムのイベントや状態を表すテキストデータ
- Trace
- トランザクションなどの単位で複数のコンポーネント間で連携する状態を表すデータ
9
Slide 10
Slide 10 text
Observabilityに関するまとめ
- Observabilityがあると...
- サービスで問題が発生したときに効率的にシステムの状態を把握できる
- システムのパフォーマンスや品質の向上などの改善活動を推し進めることができる
- データ分析基盤でも Observabilityは重要
- 多数のコンポーネントによる複雑なシステム構成
- 組織の重要な判断に使用されるシステム基盤
- Observabilityを実現するプロセス
- テレメトリデータの収集・分析・可視化
- テレメトリデータ
- Metrics・Log・Trace
10
Slide 11
Slide 11 text
アジェンダ
1. Observabilityとは
2. ペパボのデータ分析基盤 Bigfootの構成
3. BigfootのObservabilityの現状
4. Observabilityについて今後取り組んでいきたい課題
11
Slide 12
Slide 12 text
データ分析基盤とは
事業において重要な判断をするために必要なデータを継続的に収集・蓄積・意味付けをするシステム基盤
データ分析基盤が行う基本プロセス
- 収集
- 分析
- 可視化
自社サービス
のDB
外部システム
のAPI
社内システム
のAPI
データ分析基盤
抽出 加工 可視化
蓄積 ダッシュボード
レポート
機械学習
12
Slide 13
Slide 13 text
Google Spreadsheet
Redash
Google Data Studio
ペパボのデータ分析基盤 Bigfoot
Cloud Composer (Workflow Engine)
Embulk
docker-compose
on GCE
k8s POD
on GKE
BigQuery (DWH) Cloud Run
extract1 load1 transform1
extract2 load2 transform2
Data Load Data Fetch
execute
execute
execute
Google CloudでBigQueryを中心に構成
13
Slide 14
Slide 14 text
Google Spreadsheet
Redash
Google Data Studio
ペパボのデータ分析基盤 Bigfoot
Cloud Composer (Workflow Engine)
Embulk
docker-compose
on GCE
k8s POD
on GKE
BigQuery (DWH) Cloud Run
extract1 load1 transform1
extract2 load2 transform2
Data Load Data Fetch
execute
execute
execute
- サーバレスのクエリエンジンとストレージからなるサービス
- あらゆるデータをBigQueryに蓄積
- 事業部のユーザが分析したりデータを可視化
- データ変換処理もBigQuery上で実行
- SQLでクエリを実行する
14
Slide 15
Slide 15 text
Google Spreadsheet
Redash
Google Data Studio
ペパボのデータ分析基盤 Bigfoot
Cloud Composer (Workflow Engine)
Embulk
docker-compose
on GCE
k8s POD
on GKE
BigQuery (DWH) Cloud Run
extract1 load1 transform1
extract2 load2 transform2
Data Load Data Fetch
execute
execute
execute
- 様々なデータソースからBigQueryにデータをロードする
- Embulk(CLIツール)、Airbyte(サーバタイプ)、Stitch(SaaS)といっ
たETLツールを使う
- ETLとはExtract / Transform / Loadという一連の処理のこと
15
Slide 16
Slide 16 text
Google Spreadsheet
Redash
Google Data Studio
ペパボのデータ分析基盤 Bigfoot
Cloud Composer (Workflow Engine)
Embulk
docker-compose
on GCE
k8s POD
on GKE
BigQuery (DWH) Cloud Run
extract1 load1 transform1
extract2 load2 transform2
Data Load Data Fetch
execute
execute
execute
- データの抽出・ロード・変換処理というタスクを
Workflow Engineで
スケジュール実行する
- Apache Airflowのマネージド・サービス Cloud Composerを使用し
ている
- ワークフローはPythonで記述する
16
Slide 17
Slide 17 text
Google Spreadsheet
Redash
Google Data Studio
ペパボのデータ分析基盤 Bigfoot
Cloud Composer (Workflow Engine)
Embulk
docker-compose
on GCE
k8s POD
on GKE
BigQuery (DWH) Cloud Run
extract1 load1 transform1
extract2 load2 transform2
Data Load Data Fetch
execute
execute
execute
- 可視化ツールは部署によって使いやすいものを使っている
- データチームはStreamlit(データ分析向けWeb Application
Framework)によるダッシュボードシステムを提供している
- StreamlitはPythonによってダッシュボードを記述する
(Dashboard
as Code)
17
Slide 18
Slide 18 text
ペパボのデータ基盤チーム
データ分析基盤を少人数で開発・運用している
- リードエンジニア1名
- データエンジニア３名
- データサイエンティスト２名
18
Slide 19
Slide 19 text
アジェンダ
1. Observabilityとは
2. ペパボのデータ分析基盤 Bigfootの構成
3. BigfootのObservabilityの現状
4. Observabilityについて今後取り組んでいきたい課題
19
Slide 20
Slide 20 text
データ分析基盤のObservability
データ分析基盤における Observabilityのスコープは...
「サーバインフラ 〜 アプリ ＋ データ」
- システムのObservability
- 世間一般で言われる Observabilityのスコープ
- データのObservability
- データマネジメントの文脈で良く言われる Data Qualityなどのスコープ
データのObservabilityについても紹介していきます
20
Slide 21
Slide 21 text
Observability成熟モデル
引用: https://speakerdeck.com/katzchang/obizababiriteicheng-shou-moderu?slide=8
21
Slide 22
Slide 22 text
BigfootにおけるObservabilityの現状
Google Spreadsheet
Redash
Google Data Studio
Cloud Composer (Workflow Engine)
Embulk
docker-compose
on GCE
k8s POD
on GKE
BigQuery (DWH) Cloud Run
extract1 load1 transform1
extract2 load2 transform2
Data Load Data Fetch
execute
execute
execute
Lv.2
Lv.1
Lv.1
Lv.1
22
Slide 23
Slide 23 text
BigQueryの計算リソースの利用量可視化 ~Lv.2~
23
Slide 24
Slide 24 text
BigQueryのジョブ実行時間可視化 ~Lv.2~
24
Slide 25
Slide 25 text
BigQueryの状態可視化に取り組んだ経緯
- BigQueryの契約には、従量課金と月額固定がある
- 従量課金
- 使用計算リソース量はベストエフォート
- クエリ時のデータスキャン量によって課金される
- 月額固定
- 使用計算リソース量の上限を設ける
- クエリ時のデータスキャン量に関係なく定額料金
- 月額固定は費用が予測しやすくなるが、クエリが集中した場合は計算リソース不足で実行時間が伸
びる可能性がある
- 月額固定の契約期間は月・年単位だが、秒単位で契約できる Flex Slotもある
25
Slide 26
Slide 26 text
BigQueryの状態可視化に取り組んだ経緯
- ペパボでは月額固定を年単位で契約している
- 料金を気にせずクエリを実行できるようになったが、計算リソースの利用状況に注意を払う必要があ
るため、利用状況を可視化した
- BigQueryのINFORMATION_SCHEMAから利用状況のデータを取得している
26
Slide 27
Slide 27 text
BigQueryの状態可視化によって取れるアクション
次のアクションに繋げられることを想定
- 一時的にクエリ実行時間が伸びるような場合は、 Flex Slotを即契約・解除
- 慢性的にSlot利用量が上昇してクエリ実行時間も伸びている場合、追加の Slot契約
- Slot利用量やクエリ実行時間が目立って多いユーザには実行内容の確認やクエリの改善提案など
のサポート
27
Slide 28
Slide 28 text
Airflowのワークフローのジョブの実行結果の通知や蓄積の仕組みを実装し、蓄積した
データをダッシュボードで可視化している
ジョブ実行の失敗時はSlackにメンション付きで通知している
Cloud Composerのモニタリングと状態可視化 ~Lv.1~
28
Slide 29
Slide 29 text
Cloud Composerのモニタリングと状態可視化 ~Lv.1~
29
Slide 30
Slide 30 text
Cloud Composerの現在のObservability
- ユーザ目線での高レイヤでのチェックによる異常検知とサービス状態可視化ができている
- システムに係る低レイヤのチェックについては効率的にできていない状況
- 低レイヤのMetricsの収集や、Traceを活用をしてObservabilityを高めていきたい
- Cloud Composerをver.1からver.2にバージョンアップするとワーカーのオートスケーリング機能が使
えるようになるため、動的に変化する環境に対応できるよう Observability向上は必須
30
Slide 31
Slide 31 text
Streamlitにより実装した実際のダッシュボード画面
参考: 「エンジニアの活動情報からFour Keysを集計、可視化した話」
https://tech.pepabo.com/2022/01/06/four-keys-dashboard/
ダッシュボード基盤のモニタリングと状態可視化 ~Lv.1~
31
Slide 32
Slide 32 text
ダッシュボード基盤のモニタリングと状態可視化 ~Lv.1~
ダッシュボードのエラー検知は Sentryを使っており、SentryからSlackにエラーを通知している。
ダッシュボードシステムの WAFであるStreamlitはPythonでダッシュボードを記述するため、その中に
Sentryへの通知を仕込んでいる。
32
Slide 33
Slide 33 text
ダッシュボードのアクセス数とエラー数を基にエラー率を可視化している
ダッシュボード基盤のモニタリングと状態可視化 ~Lv.1~
33
Slide 34
Slide 34 text
ダッシュボード基盤のモニタリングと状態可視化 ~Lv.1~
ダッシュボードごとのアクセス数も可視化している
34
Slide 35
Slide 35 text
ダッシュボード基盤のObservabilityの課題
ダッシュボードではBigQueryにクエリを投げて返ってきたデータに基づいてグラフを表示するため、通常の
Webアプリケーションと違って表示までに時間が掛かる。
グラフ表示にいつもより時間が掛かっているというような場合、 StreamlitとBigQueryの処理時間の内訳が
わかるようになると問題への対応速度が上がる。
OpenTelemetryを使ってCloud Traceにデータを収集できると解決しそう。
※現状はTraceがうまく取れていない
35
Slide 36
Slide 36 text
Airbyteの稼働状況モニタリング ~Lv.1~
Airbyteが「ジョブを実行可能な状態か」という観点でモニタリング
30分間隔で空ジョブを実行して失敗した場合は Sentryに通知する
36
Slide 37
Slide 37 text
ジョブの実行結果のログをFluent Bit経由転送している。
全てのログはBigQueryに蓄積し、失敗ログについてはSlackにも通知している。
参考: 「ペパボのデータ基盤『Bigfoot』におけるAirbyteの本番運用」
https://tech.pepabo.com/2021/12/11/airbyte-in-bigfoot/
Airbyteのジョブ実行結果のロギングとエラー通知 ~Lv.1~
37
Slide 38
Slide 38 text
Airbyteのジョブエラー率
BigQueryに蓄積したデータを可視化している。
38
Slide 39
Slide 39 text
AirbyteのObservabilityの状況
Airbyteもサービスとジョブの監視のみ
docker-compose on GCE環境からAirbyte Cloud(SaaS)への移行を視野に入れているので Observability
向上への取り組みは優先度低
39
Slide 40
Slide 40 text
データのObservability
データパイプラインに関するモニタリングでは、サーバインフラやアプリケーションだけでなくその上を流れる
データの正常性もチェックする必要がある。
システム的には正常にデータ同期処理が完了してもデータが異常な状態になっている可能性がある。
ペパボでは、定期的にデータをチェックして結果を通知する仕組みを用意している。
40
Slide 41
Slide 41 text
BigQuery上のデータに対して想定する値になっているかをクエリを投げてチェックして、検査結果のレポートを
Webで閲覧できるシステム。
検査内容はRSpecのDSLで記述し、結果はHTMLで出力される。
Shoegazerのコアコンポーネントの QuerygazerはOSSとして公開されています。
(https://github.com/udzura/querygazer)
)
https://github.com/udzura/querygazer
Shoegazer
41
Slide 42
Slide 42 text
Shoegazer
検査の定期実行はCloud SchedulerとCloud Runの組み合わせで実行している。
データの異常を監視するというものなので Lv.1、ここからLv.2に向けて、データのカラムごとの統計値や分
布、外れ値などをプロファイリングしてレポートしてくれるデータクオリティツールにも取り組んでいきたい。
OSSのデータクオリティツール great_expectations
nullの占める割合や想定外の値が入っていないか等プ
ロファイリングしてくれる。
42
Slide 43
Slide 43 text
アジェンダ
1. Observabilityとは
2. ペパボのデータ分析基盤 Bigfootの構成
3. BigfootのObservabilityの現状
4. Observabilityについて今後取り組んでいきたい課題
43
Slide 44
Slide 44 text
BigfootにおけるObservabilityの課題
- Cloud Composerのジョブ失敗時の原因が不明のままとりあえず復旧して様子見として終わりとして
いることが多い
- Cloud Composerとそのworkflow上で実行されるk8sなどの様々なワークロードを辿って問題
を追跡していくのは時間が掛かる
- Cloud Logging、Metrics、Traceを活用してLv.2を目指す
- データパイプラインで生成されるテーブル間の依存関係を辿るのに時間が掛かる
- 依存関係を辿る作業を効率化する仕組みとしてデータリネージがある
- チームメンバーがOSSのデータリネージツール Stairlight
(https://github.com/tosh2230/stairlight)を開発中
- データリネージツールとデータクオリティツールを活用してデータの Observabilityも向上させた
い
44
Slide 45
Slide 45 text
BigfootにおけるObservabilityの課題への対応
- Cloud Logging、Cloud Metrics、Cloud Traceを使いこなすことでシステムの Observabilityを向上さ
せる
- 引き続き、Observabilityに関するデータをBigQueryに蓄積し、分析・可視化をやっていく
- データのObservabilityへの取り組みを優先度上げてやっていく
45
Slide 46
Slide 46 text
BigfootにおけるObservabilityの今後
- BigfootはGoogle CloudからAWSに基盤を拡張している
- ペパボのサービスが稼働している AWSやその他のプラットフォームからデータを収集するため
に、Google CloudからAWSに跨って機能拡張を進めている
- Cloud ComposerからEmbulk on AWS BatchでサービスのRDSからデータを抽出して
BigQueryに同期するというもの
- マルチクラウド環境での Observabilityに取り組んでいく必要がある
- MLOpsへの取り組みも始まった
- ペパボのサービス→データ分析基盤→機械学習システム→ペパボのサービス というサイクル
が生まれる
- よりリアルタイム性も求められるようになるので問題への効率的な対応が求められる
46
Slide 47
Slide 47 text
まとめ
- Observability成熟モデルに基づいて現在のペパボのデータ分析基盤の Observabilityについてアセ
スメントした
- 殆どLv.1
- データ駆動が進めば基盤の重要性が増し、更なる品質とスピードも求められてくるので少しず
つでもレベルアップを図っていきたい
- データのObservabilityについても取り組みを紹介した
- データの正常性を定期的にチェックする仕組みとして Shoegazerを紹介した
- 今後、機械学習が組み込まれてヒトが介在しないサイクルへ発展することが予想される
- データパイプラインの状態を効率的に把握できるようにデータの Observability向上にも力を入
れていきたい
47