マイクロサービスにおけるログ収集の課題と取り組み

Slide 1

Slide 1 text

データとML周辺エンジニアリングを考える会 #1 2019 / 01 / 18 @syu_cream マイクロサービスにおけるログ収集の課題と取り組み

Slide 2

Slide 2 text

Slide 3

Slide 3 text

Slide 4

Slide 4 text

メルカリログ収集前史 © Merpay, Inc. 4

Slide 5

Slide 5 text

Slide 6

Slide 6 text

6 ● バックエンドの API やバッチサーバのローカルファイルにログを蓄積 ● fluentd でログを逐次送信 ○ 負荷分散や転送効率化の都合、中継用 fluentd も存在 ● hourly batch で BigQuery や GCS にログを送信 ● それとは別にストリーム処理のため Norikra にも送信メルカリにおけるログ収集 Copyright © Merpay, Inc. All Rights Reserved.

Slide 7

Slide 7 text

7 ● モノリシックなサービスを支えるのに特化していると言える ○ 幾つかの限られた種類の App サーバからログを収集する前提 ○ 出力されるログのスキーマも限られている ○ App サーバや周辺インフラ含めて SRE チームが管理 ● マイクロサービスにするとどうなってしまうのか...？メルカリにおけるログ収集とマイクロサービス Copyright © Merpay, Inc. All Rights Reserved.

Slide 8

Slide 8 text

マイクロサービスにおけるログ収集 © Merpay, Inc. 8

Slide 9

Slide 9 text

Slide 10

Slide 10 text

10 ● モノリスを避けて、機能を多数のマイクロサービスに分割 ○ DB もマイクロサービスごとに持つ ○ 実装言語や DB の種類はマイクロサービス毎に選択可能にする ■ とはいえ、 Go + MySQL or Cloud Spanner が大多数 ○ マイクロサービスのコンテナは Kubernetes (GKE) 上で動作 ● チームもマイクロサービスに従って分割 ○ なるべく各マイクロサービスチームが独自に意思決定可能にするメルカリにおけるマイクロサービス Copyright © Merpay, Inc. All Rights Reserved.

Slide 11

Slide 11 text

11 ● マイクロサービスにするとどうなってしまうのか...？ ○ ログ送信元が 10+, 100+, … 種類に増えることは考慮されていない ■ さらに言うと Kubernetes に乗ることも考慮されていない ○ ログのスキーマを限定するのは難しくなる ■ 各マイクロサービスが担う機能が異なれば、出力するログも異なるはず ○ SRE チームがインフラを支え続けるのが難しくなる ○ ログの利用者の多様化も進むかも？ ■ 送信されたログを活用するマイクロサービスが登場したり ■ BigQuery, GCS にだけ転送すればいい時代が終わるかも Re: メルカリにおけるログ収集とマイクロサービス Copyright © Merpay, Inc. All Rights Reserved. マイクロサービスになるならそれに特化したログ収集基盤が必要！

Slide 12

Slide 12 text

メルペイのデータパイプライン構成 © Merpay, Inc. 12

Slide 13

Slide 13 text

Slide 14

Slide 14 text

14 ● 多数のマイクロサービスからログを受け付けるインタフェースを提供 ○ 現在は Cloud Pub/Sub を想定 ● ログを集約して GCS に保存するパスと、パースして BigQuery, GCS に保存するパスを用意 ○ パースに失敗した際でも GCS にはログが保持される ○ スキーマは Protocol Buffer で事前定義する ○ ETL 処理は Cloud Dataflow で行うマイクロサービスのためのログ収集パイプライン Copyright © Merpay, Inc. All Rights Reserved.

Slide 15

Slide 15 text

15 ● ログ収集パイプラインの Pub/Sub に送信する方法が欲しい ● いくつかのオプションが Kubernetes の Doc で提示されている ○ ノードの Logging Agent を使う ○ Logging Agent を持った Sidecar Container をアプリケーション Pod に含める ○ ログ出力する Sidecar Container をアプリケーション Pod に含める ■ ログ送信は別 Pod で行う ○ アプリケーションから直接ログ収集のバックエンドにログを送信する ○ ref. https://kubernetes.io/docs/concepts/cluster-administration/logging/ Kubernetes 上のサービスからのログ収集 Copyright © Merpay, Inc. All Rights Reserved.

Slide 16

Slide 16 text

16 ● 現在は「アプリケーションから直接ログ収集のバックエンドにログを送信する」を選択 ○ Go のロガーライブラリを実装して配布している ○ Pub/Sub Topic や IAM の管理は別途設定する ○ マイクロサービスの実装言語毎にライブラリ開発が必要なリスクは存在 ... ● 秋頃までは「ノードの Logging Agent を使う」を選択していた ○ GKE なら Stackdriver Logging へ送信する Agent がデフォルトで動作する！ ■ 実態は Google 提供の fluentd コンテナが動作する DaemonSet ○ 文字列しか扱えない、障害点が増える、コスト大 ...の理由から上記を選択し直した Kubernetes 上のサービスからのログ収集 Copyright © Merpay, Inc. All Rights Reserved.

Slide 17

Slide 17 text

Slide 18

Slide 18 text

18 ● スキーマハンドリング ○ 現在は Protocol Buffer の定義から事前にスキーマを生成してリリース ○ 柔軟かつスピーディーにスキーマ更新するために Schema Registory が必要？ ○ しかし送信されるログのパターンが見えない今は過剰な投資かも ○ 皆さんがどうやっているか知りたい！ ● Kubernetes 上のサービスからのログ収集、もっと良いソリューションが欲しい！ ○ Pub/Sub にログを送信する Logging Agent があると良い？ ○ Logging Agent のチューニングや運用コストが生じるデメリットは発生するが ○ 皆さんがどうやっているか知り（ｒｙ今後の課題 Copyright © Merpay, Inc. All Rights Reserved.

Slide 19

Slide 19 text

19 ● データガバナンスどうにかする（？） ○ データを蓄積してもその意味が分からなければ活用は進まない ○ Apache Atlas とか WhereHows とか AWS Glue の Catalog とかはあるが... ○ 統制の取れたメタデータ管理なんて幻想な気がする ● アクセス制御どうにかする ○ 現状は GCP の IAM で whitelist 的に管理 ○ どんな粒度で誰がどう管理するかは中長期的にも課題今後の課題 Copyright © Merpay, Inc. All Rights Reserved.