データ分析基盤におけるオブザーバビリティの取り組み

GMOペパボ株式会社では主にGoogle Cloud Platformのサービスを利用してデータ分析基盤を構築し運用しています。その中心となるのがデータウェアハウスのBigQueryとワークフローエンジンのCloud Composerです。また、社内向けのデータ可視化(ダッシュボード)システムではCloud Runを利用しています。
データ分析基盤から得られる情報を重要な意思決定に用いるためには、ユーザーに提供しているインフラと同様に、可用性を明らかにし、継続的に可用性を高める Realiability エンジニアリングが必要となります。本講演ではGCPで構築されているデータ分析基盤を題材として、データ分析基盤に求められる可用性や、小規模なチームにおけるオブザーバビリティへの取り組みについてご紹介します。

Transcript

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