これからのZOZOを支える ログ収集基盤を設計した話 / Log collection infrastructure to support ZOZO in the future

Transcript

1. これからのZOZOを支える

   ログ収集基盤を設計した話

   株式会社ZOZOテクノロジーズ

   EC基盤本部 SRE部 データ基盤チーム

   リーダー

   塩崎 健弘
   Copyright © ZOZO Technologies, Inc.
   

   View Slide

2. © ZOZO Technologies, Inc.
   株式会社ZOZOテクノロジーズ

   EC基盤本部 SRE部 データ基盤チーム

   リーダー
   塩崎 健弘

   データ基盤の開発運用を担当。

   好きなGCPサービスはCloud Identity-Aware ProxyとCloud
   Asset Inventory

   2
   

   View Slide

3. © ZOZO Technologies, Inc.
   Software Designさんに寄稿しました(宣伝)

   BigQueryによるデータ基盤構築の舞台裏
   失敗から学んだ健全な運用とは
   ● ZOZOにおけるデータ基盤の事例を惜しみなく紹介
   ○ Redshift→BigQueryの移行事例
   ○ BigQueryの活用事例
   ○ BigQueryの失敗事例
   ● 対象読者
   ○ これからデータ基盤を作る予定の方
   ■ BigQueryの活用方法が分かります
   ○ 既にデータ基盤の開発・運用をしている方
   ■ なかなか表に出ないデータエンジニアリングのノウハウ満載です
   3
   

   View Slide

4. © ZOZO Technologies, Inc.
   目次

   ● ログ収集基盤とは
   ● 設計方針
   ○ 少人数のチームでも開発運用できるようにする
   ○ システム全体の冪等性を高める
   ○ ログ収集を非同期的に行う
   ○ 固定費を作らない
   ● インフラ紹介
   ○ メッセージブローカー
   ○ ストリーミングETL
   ○ サーバーからのログ収集
   ○ ブラウザ・ネイティブアプリからのログ収集
   ● 負荷試験
   ○ リージョン間転送料金の節約
   ● まとめ
   4
   

   View Slide

5. © ZOZO Technologies, Inc.
   ZOZOTOWNで発生するログを収集し、データ基盤であるBigQueryにデータ連携する基盤
   Server(OnPrem, Cloud)
   Browser
   iOS
   Android
   ログ収集基盤
   データ基盤
   (BigQuery)
   ログ収集基盤とは

   5
   Icons made by Freepik from www.flaticon.com
   Icons made by Pixel perfect from www.flaticon.com
   

   View Slide

6. © ZOZO Technologies, Inc.
   ログ収集基盤の必要性

   ● 施策の効果測定を効率化することが目的
   ○ 施策の着手前に「このKPIが〇〇を上回っていればOK」と言える状態に
   ● 3rd party計測ツールの課題
   ○ 柔軟性
   ■ 我々の好きなタイミング・構造でログを出力できない
   ○ 複雑性
   ■ ログの構造が複雑なため「計測ツールのプロ」でないと分析クエリを書けない
   ○ データのサイロ化
   ■ いくつもの計測ツールを組み合わせているためデータがサイロ化している
   ○ 価格
   ■ 少なくはない費用が発生している
   ⇒我々の要件に会うログ収集の仕組みを1から設計することに
   6
   

   View Slide

7. © ZOZO Technologies, Inc.
   ログ収集基盤の要件

   ● サーバー・ブラウザ・ネイティブアプリからのログを収集
   ○ ZOZOTOWNを提供している全ての環境が対象
   ● データ基盤にログを連携する
   ○ 全てのログをBigQueryに集める
   ● リアルタイムにログを収集(数分以内)
   ○ 日次・月次のレポーティング用途だけでなく、ログを元にプロダクト側に情報を反映できるように
   ● 最大で数万 Messages / sec
   ○ TV CMなどによるスパイク的なトラフィックにも対応
   ● ログのスキーマの自由度
   ○ JSON形式の非構造化ログを扱いたい
   7
   

   View Slide

8. © ZOZO Technologies, Inc.
   設計方針: 少人数のチームでも開発運用できるようにする

   ● 1人でも運用しきれること
   ○ 開発運用しているのはわずか3人のチーム
   ○ これ以外のシステムの面倒も見ているので、実質的には1人くらい
   ● より抽象度の高いマネージドサービス選択すること
   ○ IaaSよりもPaaS、PaaSよりSaaSを活用
   ● 自動スケーリング・自動復旧がデフォルトで組み込まれていること
   ○ 負荷に応じて自動的にスケーリングする仕組みがデフォルトで備わっている
   ○ デフォルトでマルチゾーン構成になりシングルゾーン障害時には自動的に切り替わる
   ○ 3人では深夜待機シフトは組めないのでシステムが自動的にスケール・復旧する必要あり
   ○ 「デフォルト」というのがポイント
   ■ FaaSなどを組み合わせたピタゴラ装置を後付けで作りたくない
   8
   

   View Slide

9. © ZOZO Technologies, Inc.
   設計方針: システム全体の冪等性を高める

   ● 冪等性
   ○ 同じ操作を何回繰り返しても、同じ結果が得られること
   ● 同一のログが複数回送られてきても問題ないように基盤側で何とかする
   ● クライアント側のリトライロジックを簡素化
   ○ 正常に送信できたか怪しい場合はとりあえずリトライ
   ● ログ基盤にログを投げる時にUUIDを生成する
   ○ リトライ時には前回のUUIDを引き回す
   ● 最終的にBigQueryに格納されたタイミングで重複を排除
   ○ ログ収集基盤ではat least onceのデータ連携のみを保証
   9
   

   View Slide

10. © ZOZO Technologies, Inc.
    設計方針: ログ収集を非同期的に行う

    ● エンドユーザーは商品を買うためにZOZOTOWNを利用している
    ○ ログ収集は裏方の仕事
    ● ログ収集基盤によってユーザー体験を損ねないようにする必要がある
    ○ 画面のローディングが遅くなるなどはダメ
    ● ログ収集基盤がダウンしていてもZOZOTOWNそのものは正常に稼働
    ○ 障害が波及しないようにログの連携を行う
    ● ログ収集を非同期的に行う
    ○ 非同期処理は失敗時の扱いが難しい
    ○ システム全体を冪等にしたのでリトライ戦略が簡素化
    10
    

    View Slide

11. © ZOZO Technologies, Inc.
    設計方針: 固定費を作らない

    ● スケーリングする環境下では費用が固定値ではなくなる
    ● プロビジョンに対する課金 vs 使用量に対する課金
    ○ プロビジョンに対する課金
    ■ 事前に使用量を申告
    ■ 実際に使用したかどうかは関係なく、申告した量に応じて課金
    ■ 例: Compute Engine, Cloud SQL
    ○ 使用量に対する課金
    ■ 事前の使用量の申告は不要
    ■ 使用量した量のみに応じて課金
    ■ Cloud Pub/Sub, BigQuery
    ● 使用量に対して課金されるサービス(後者)を活用
    ● 負荷試験のタイミングで負荷 vs 費用を確認
    11
    

    View Slide

12. © ZOZO Technologies, Inc.
    インフラ図

    12
    Server(OnPrem, Cloud)
    Browser
    iOS
    Android
    BigQuery
    12
    App Engine
    Cloud
    Pub/Sub
    Cloud
    Dataflow
    Icons made by Freepik from www.flaticon.com
    Icons made by Pixel perfect from www.flaticon.com
    

    View Slide

13. © ZOZO Technologies, Inc.
    インフラ図

    13
    Server(OnPrem, Cloud)
    Browser
    iOS
    Android
    BigQuery
    13
    App Engine
    Cloud
    Pub/Sub
    Cloud
    Dataflow
    Icons made by Freepik from www.flaticon.com
    Icons made by Pixel perfect from www.flaticon.com
    ストリーミングETL
    メッセージブローカー
    サーバーからの
    ログ収集
    ブラウザ・アプリからの
    ログ収集
    

    View Slide

14. © ZOZO Technologies, Inc.
    インフラ図

    14
    Server(OnPrem, Cloud)
    Browser
    iOS
    Android
    BigQuery
    14
    App Engine
    Cloud
    Pub/Sub
    Cloud
    Dataflow
    Icons made by Freepik from www.flaticon.com
    Icons made by Pixel perfect from www.flaticon.com
    ストリーミングETL
    メッセージブローカー
    サーバーからの
    ログ収集
    ブラウザ・アプリからの
    ログ収集
    

    View Slide

15. © ZOZO Technologies, Inc.
    Cloud Pub/Sub(メッセージブローカー)

    ● メッセージのバッファリング・複数の宛先への配送を担っている
    ● at least onceの配信のみをサポート
    ○ システム全体で冪等性を担保しているので問題なし
    ● マルチリージョン
    ● 事前のプロビジョニングは不要
    ○ Kinesis Data Streamのシャード数管理のような手間はなし
    ○ 急激なトラフィック増の手間を軽減
    ● リクエスト数に応じた課金体系
    15
    

    View Slide

16. © ZOZO Technologies, Inc.
    インフラ図

    16
    Server(OnPrem, Cloud)
    Browser
    iOS
    Android
    BigQuery
    16
    App Engine
    Cloud
    Pub/Sub
    Cloud
    Dataflow
    Icons made by Freepik from www.flaticon.com
    Icons made by Pixel perfect from www.flaticon.com
    ストリーミングETL
    メッセージブローカー
    サーバーからの
    ログ収集
    ブラウザ・アプリからの
    ログ収集
    

    View Slide

17. © ZOZO Technologies, Inc.
    Cloud Dataflow(ストリーミングETL)

    ● Apache Beamのマネージドサービス
    ● 元々Google社内で使われていたMillWheelがベースになっている
    ● スケーリングの仕組みがデフォルトで備わっている
    ○ Cloud Pub/Subのメトリクスに応じてスケーリング
    ● 複数のプログラミング言語に対応
    ○ Java
    ○ Python
    ○ Go
    ● ログスキーマに柔軟性を持たせるためPython版を選択
    ○ 静的型付け言語でスキーマレスなJSONを扱いたくないため
    17
    

    View Slide

18. © ZOZO Technologies, Inc.
    インフラ図

    18
    Server(OnPrem, Cloud)
    Browser
    iOS
    Android
    BigQuery
    18
    App Engine
    Cloud
    Pub/Sub
    Cloud
    Dataflow
    Icons made by Freepik from www.flaticon.com
    Icons made by Pixel perfect from www.flaticon.com
    ストリーミングETL
    メッセージブローカー
    サーバーからの
    ログ収集
    ブラウザ・アプリからの
    ログ収集
    

    View Slide

19. © ZOZO Technologies, Inc.
    サーバーからのログ受信

    ● Fluentdを利用してログ収集
    ● Cloud Pub/Subがダウンした場合のバッファリングも担当
    ● 多くの環境に対応
    ○ Windows & Linux
    ○ Kubernetes(sidecar) & VM(daemon)
    ● Kubernetes環境でのログ欠損を防ぐために独自のカスタムコントローラーを作成
    ○ Podに対してPersistent Volume Chainを動的にプロビジョニング
    ○ Podが突然死してもログ欠損が発生しないように
    ● outputプラグインとしてfluent-plugin-gcloud-pubsub-customを利用
    ○ https://github.com/mia-0032/fluent-plugin-gcloud-pubsub-custom
    ○ リージョン間転送費用を削減するためのパッチをあてて利用
    ■ https://github.com/mia-0032/fluent-plugin-gcloud-pubsub-custom/pull/70
    19
    

    View Slide

20. © ZOZO Technologies, Inc.
    インフラ図

    20
    Server(OnPrem, Cloud)
    Browser
    iOS
    Android
    BigQuery
    20
    App Engine
    Cloud
    Pub/Sub
    Cloud
    Dataflow
    Icons made by Freepik from www.flaticon.com
    Icons made by Pixel perfect from www.flaticon.com
    ストリーミングETL
    メッセージブローカー
    サーバーからの
    ログ収集
    ブラウザ・アプリからの
    ログ収集
    

    View Slide

21. © ZOZO Technologies, Inc.
    ブラウザ・アプリからのログ受信

    ● App Engineでログ受信のためのエンドポイントを作成
    ● 負荷に応じてスケーリング
    ○ Go言語でログ受信サーバーを作成してスケーリング速度の向上
    ● 認証処理 + ログに追加の情報の埋め込みを行う
    ○ IP Address
    ○ User Agent
    ○ Country
    ● GDPR対応のためにEU圏からの情報は一部フィルタリング
    21
    

    View Slide

22. © ZOZO Technologies, Inc.
    負荷試験

    ● 想定される負荷に耐えることができるか確認……だけではない
    ● 負荷の変動に対するシステムの弾力性も確認
    ○ サーバー台数・費用は
    ■ ❌ 定数
    ■ ⭕ 負荷に応じて変化する関数
    ○ 以下の項目の線形性を確認
    ■ 負荷 vs App Engineのサーバー台数
    ■ 負荷 vs Cloud Dataflowのサーバー台数
    ■ 負荷 vs GCPの費用(AppEngine, Cloud Pub/Sub, Cloud Dataflow)
    ○ 非線形な振る舞いをする場合はボトルネックが隠れている可能性が高い
    ● GKEクラスタの上にLocustを構築して分散環境から負荷をかける
    ○ 数万 Message/secの負荷試験環境をお手軽に構築
    22
    

    View Slide

23. © ZOZO Technologies, Inc.
    負荷試験

    ● App Engine
    ○ ゼロから数万 Message/secに一気に上げると一時的にエラーレート上昇(< 0.1%)
    ○ 数分待つとエラーレートは完全にゼロに
    ○ 暖気申請不要
    ○ ⇒ ログ送信側のリトライ処理で十分にリカバリ可能
    ● Cloud Pub/Sub
    ○ 数百万 Messageまでバッファリングすることを確認 (仕様上は上限なし)
    ○ 事前にキャパシティをプロビジョニングする必要なし
    ● Cloud Dataflow
    ○ Pub/Subが詰まったことをトリガーにしてサーバーがスケールする
    ○ 応答速度は数分程度
    ○ ⇒ 遅延時間の要件は満たせる
    23
    

    View Slide

24. © ZOZO Technologies, Inc.
    リージョン間転送料金の削減

    ● 負荷試験中に請求ダッシュボードを確認していたら
    ○ Pub/Subのネットワーク料金という「謎」項目を発見
    ● 費用が発生する条件
    ○ PublishするEndpointのリージョン != SubscribeするEndpointのリージョン
    ● App Engine・Cloud Dataflowの対応
    ○ us-centralリージョンでホスティング
    ● Fluentdの対応
    ○ Publishするエンドポイントを指定できるようにする
    ○ 詳細は弊社TECH BLOGで
    ○ https://techblog.zozo.com/entry/fluentd-pubsub-oss
    24
    

    View Slide

25. © ZOZO Technologies, Inc.
    まとめ

    ● ログ収集基盤の設計&構築を行いました
    ● 少人数でも運用できるようにGCPのマネージドサービスをフル活用して作りました
    ○ App Engine, Pub/Sub, Dataflow
    ● GCPはBigQueryだけじゃなくて、他のサービスも便利
    ○ 1つの役割に特化したサービス設計になっているため、上手くハマれば凄く便利
    ● これからのZOZOを支える基盤になるように育成していきます
    ● データエンジニアリング面白いよ！！
    25
    

    View Slide