これからのZOZOを支える
 ログ収集基盤を設計した話
 株式会社ZOZOテクノロジーズ
 EC基盤本部 SRE部 データ基盤チーム
 リーダー
 塩崎 健弘 Copyright © ZOZO Technologies, Inc.

© ZOZO Technologies, Inc. 株式会社ZOZOテクノロジーズ
 EC基盤本部 SRE部 データ基盤チーム
 リーダー 塩崎 健弘
 データ基盤の開発運用を担当。
 好きなGCPサービスはCloud Identity-Aware ProxyとCloud Asset Inventory
 2

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

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

© 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

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

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

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

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

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

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

© 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

© 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 メッセージブローカー サーバーからの ログ収集 ブラウザ・アプリからの ログ収集

© 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 メッセージブローカー サーバーからの ログ収集 ブラウザ・アプリからの ログ収集

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

© 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 メッセージブローカー サーバーからの ログ収集 ブラウザ・アプリからの ログ収集

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

© 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 メッセージブローカー サーバーからの ログ収集 ブラウザ・アプリからの ログ収集

© 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

© 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 メッセージブローカー サーバーからの ログ収集 ブラウザ・アプリからの ログ収集

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

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

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

© 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

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