Upgrade to Pro — share decks privately, control downloads, hide ads and more …

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

Ryo Okubo
January 18, 2019

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

データとML周辺エンジニアリングを考える会 #1 2019 / 01 / 18 の資料です
https://data-engineering.connpass.com/event/111658/

Ryo Okubo

January 18, 2019
Tweet

More Decks by Ryo Okubo

Other Decks in Programming

Transcript

  1. 2 • @syu_cream • Data Engineer @ merpay, Inc. •

    いちおうこのイベントの主催の1人 • 仕事で使ってる言語: Go, Scala • 学びたい言語: Rust whoami Copyright © Merpay, Inc. All Rights Reserved.
  2. 6 • バックエンドの API やバッチサーバのローカルファイルにログを蓄積 • fluentd でログを逐次送信 ◦ 負荷分散や転送効率化の都合、中継用

    fluentd も存在 • hourly batch で BigQuery や GCS にログを送信 • それとは別にストリーム処理のため Norikra にも送信 メルカリにおけるログ収集 Copyright © Merpay, Inc. All Rights Reserved.
  3. 7 • モノリシックなサービスを支えるのに特化していると言える ◦ 幾つかの限られた種類の App サーバからログを収集する前提 ◦ 出力されるログのスキーマも限られている ◦

    App サーバや周辺インフラ含めて SRE チームが管理 • マイクロサービスにするとどうなってしまうのか...? メルカリにおけるログ収集とマイクロサービス Copyright © Merpay, Inc. All Rights Reserved.
  4. 10 • モノリスを避けて、機能を多数のマイクロサービスに分割 ◦ DB もマイクロサービスごとに持つ ◦ 実装言語や DB の種類はマイクロサービス毎に選択可能にする

    ▪ とはいえ、 Go + MySQL or Cloud Spanner が大多数 ◦ マイクロサービスのコンテナは Kubernetes (GKE) 上で動作 • チームもマイクロサービスに従って分割 ◦ なるべく各マイクロサービスチームが独自に意思決定可能にする メルカリにおけるマイクロサービス Copyright © Merpay, Inc. All Rights Reserved.
  5. 11 • マイクロサービスにするとどうなってしまうのか...? ◦ ログ送信元が 10+, 100+, … 種類に増えることは考慮されていない ▪

    さらに言うと Kubernetes に乗ることも考慮されていない ◦ ログのスキーマを限定するのは難しくなる ▪ 各マイクロサービスが担う機能が異なれば、出力するログも異なるはず ◦ SRE チームがインフラを支え続けるのが難しくなる ◦ ログの利用者の多様化も進むかも? ▪ 送信されたログを活用するマイクロサービスが登場したり ▪ BigQuery, GCS にだけ転送すればいい時代が終わるかも Re: メルカリにおけるログ収集とマイクロサービス Copyright © Merpay, Inc. All Rights Reserved. マイクロサービスになるなら それに特化したログ収集基盤が必要!
  6. 14 • 多数のマイクロサービスからログを受け付けるインタフェースを提供 ◦ 現在は Cloud Pub/Sub を想定 • ログを集約して

    GCS に保存するパスと、パースして BigQuery, GCS に保存するパスを用意 ◦ パースに失敗した際でも GCS にはログが保持される ◦ スキーマは Protocol Buffer で事前定義する ◦ ETL 処理は Cloud Dataflow で行う マイクロサービスのためのログ収集パイプライン Copyright © Merpay, Inc. All Rights Reserved.
  7. 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.
  8. 16 • 現在は「アプリケーションから直接ログ収集のバックエンドにログを送信する」を選択 ◦ Go のロガーライブラリを実装して配布している ◦ Pub/Sub Topic や

    IAM の管理は別途設定する ◦ マイクロサービスの実装言語毎にライブラリ開発が必要なリスクは存在 ... • 秋頃までは「ノードの Logging Agent を使う」を選択していた ◦ GKE なら Stackdriver Logging へ送信する Agent がデフォルトで動作する! ▪ 実態は Google 提供の fluentd コンテナが動作する DaemonSet ◦ 文字列しか扱えない、障害点が増える、コスト大 ...の理由から上記を選択し直した Kubernetes 上のサービスからのログ収集 Copyright © Merpay, Inc. All Rights Reserved.
  9. 18 • スキーマハンドリング ◦ 現在は Protocol Buffer の定義から事前にスキーマを生成してリリース ◦ 柔軟かつスピーディーにスキーマ更新するために

    Schema Registory が必要? ◦ しかし送信されるログのパターンが見えない今は過剰な投資かも ◦ 皆さんがどうやっているか知りたい! • Kubernetes 上のサービスからのログ収集、もっと良いソリューションが欲しい! ◦ Pub/Sub にログを送信する Logging Agent があると良い? ◦ Logging Agent のチューニングや運用コストが生じるデメリットは発生するが ◦ 皆さんがどうやっているか知り(ry 今後の課題 Copyright © Merpay, Inc. All Rights Reserved.
  10. 19 • データガバナンスどうにかする(?) ◦ データを蓄積してもその意味が分からなければ活用は進まない ◦ Apache Atlas とか WhereHows

    とか AWS Glue の Catalog とかはあるが... ◦ 統制の取れたメタデータ管理なんて幻想な気がする • アクセス制御どうにかする ◦ 現状は GCP の IAM で whitelist 的に管理 ◦ どんな粒度で誰がどう管理するかは中長期的にも課題 今後の課題 Copyright © Merpay, Inc. All Rights Reserved.