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

スタディサプリ小中高のオブザーバビリティ / Observability in StudySa...

スタディサプリ小中高のオブザーバビリティ / Observability in StudySapuri

スタディサプリ/Quipper Product Meetup #3 〜SREチームが取り組むマイクロサービス化に向けたDevOps開発事例〜 における発表資料です https://techplay.jp/event/737389

Yuya Takeyama

July 18, 2019
Tweet

More Decks by Yuya Takeyama

Other Decks in Programming

Transcript

  1. @yuya-takeyama ➔ 2015年9月~: Web Developer at Quipper ◆ Rails/Backone.js/React.js/React Native

    などなど ➔ 2018年4月~: SRE at Quipper ◆ Kubernetes をはじめとしたインフラの構築・運用 ◆ マイクロサービス化のために必要なツール等の検証・導入・実装 ◆ その他インフラ周りのあらゆること
  2. 何故マイクロサービス化するのか ➔ スタディサプリ小中高は Global の Quipper とコードベースが共通 ◆ 各国ごとにプロダクトのあり方が多様化しつつあり、ある国での変更が別 の国の機能に影響し得る

    ➔ 各国の各チームがそれぞれ Ownership を持って、スピード感を持って開発の サイクルを回すため ◆ 開発だけでなく、必要なインフラ (データベース、キュー等) も各チームでで きるよう、セルフサービス化の推進 ◆ 自分たちで作ったものを自分たちで運用していく自律分散型の組織に (DevOps)
  3. スタディサプリ小中高・マイクロサービス化の現状 ➔ 2018年12月に Microservices 基盤として Kubernetes での本番運用を開始 ➔ まだまだ Microservices

    と呼べる状況ではない ◆ Heroku や Deis で動かしていたものを Kubernetes に載せ替え ◆ マイクロなサービスはまだ 10 もないぐらい (開発中含む) ◆ モノリシックな Rails が 5 つぐらい • まだほとんどの機能はモノリス内で完結している • ごく一部の機能の裏側でマイクロなサービスが動いている ◆ フロントエンドが 3 つぐらい
  4. スタディサプリ小中高・マイクロサービス化の現状 ➔ Monolith からの Microservice の切り出しは一部で進行中 ◆ 学習データサービスの切り出し (Elixir/Go) ➔

    一部新機能については Microservice を作って Monolith に結合している ◆ データ系プロダクト (講義のレコメンデーション、講義検索) (Python/Flask) ◆ 学校向け機能 (生徒データの名寄せ) (Ruby/gRPC) ◆ 顧客ターゲットが全く異なる新規事業プロダクト (Ruby/Go/gRPC/GraphQL)
  5. Metric ➔ 様々なレイヤに渡る Metrics ◆ AWS ◆ Kubernetes Node (EC2/Linux)

    ◆ Kubernetes Pod ◆ Protocol/Language/Framework/Middleware ➔ スタディサプリ小中高では Datadog を使用 ◆ Metrics の収集、Dashboard の作成、アラートの送信 (Slack)
  6. Protocol/Language/Framework/Middleware のメトリクス ➔ HTTPやgRPC のリクエスト数、レスポンスステータスの内訳、エラー率 ➔ プロセスモデルに応じたメトリクス (pre-fork したプロセスごとのメモリ使用量) ➔

    基本的に Datadog が勝手に拾ってくれる訳ではない ◆ 恐らく Prometheus 等の別ツールにおいても同様のはず ➔ スタディサプリ小中高では Prometheus Exporter と Datadog の Autodiscovery を活用
  7. Prometheus Exporter ➔ Prometheus 向けにメトリクスを主力するための API フォーマット ◆ GitHub 上などを探せば様々な

    Protocol, Language, Framework または Middleware の Exporter が見つかる ➔ Quipper では Ruby のサービスで prometheus_exporter や grpc_prometheus といった gem を利用 ➔ https://prometheus.io/docs/instrumenting/exporters/
  8. Datadog Autodiscovery ➔ Datadog agent が様々な API からメトリクスを自動的に収集するための機能 ➔ Kubernetes

    においては Pod の annotations から API の URL や、収集時の 設定を discover する ◆ サービスが増えていっても、簡単にメトリクスの収集対象に加えられる ➔ Prometheus Exporter からの収集にも対応 ◆ そのほかにも Nginx, Go, gunicorn, Envoy 等様々なものからメトリクスを 収集できる
  9. Datadog Autodiscovery のための annotations の記述 metadata: annotations: ad.datadoghq.com/api.check_names: | ["prometheus"]

    ad.datadoghq.com/api.init_configs: | [{}] ad.datadoghq.com/api.instances: | [ { "prometheus_url": "http://%%host%%:9394/metrics", "namespace": "prometheus_checks", "metrics": ["*"] } ]
  10. ➔ サービスをまたいでログを集約し、検索可能な状態にする ➔ GCP の Stackdriver Logging を利用 ◆ 標準出力・エラー出力に書くだけで勝手に

    fluentd で収集 ➔ ログが JSON だった場合、構造化ログとして記録される ◆ Kubernetes 上のアプリケーションから Stackdriver Logging に構造化ロ グを送る ➔ Request ID を元に関連するログをまとめて検索できる ◆ Sentry 等のエラー集約基盤でも Request ID を記録しておくことで、エ Logging
  11. ➔ ログフォーマットの統一化 ◆ Request ID や User ID のような共通の項目のフィールド名を統一化する ことで、複数サービスをまたいで効率よく検索可能にする

    ◆ JSON を出力すればいいので、言語に関係なく統一化が可能 ◆ Web Developer の @reizist さんがとあるサービスでいい感じのフォー マットを提案してくれたので、あとは他のサービスにも展開するだけ? Logging 今後の展望
  12. Tracing ➔ 複数サービスをまたいだリクエストにおいて、ボトルネックを可視化 ◆ 特に Microservices においては重要な要素 ➔ スタディサプリ小中高においては Jaeger

    を検証したりしたが、運用が大変なの で Stackdriver Trace 等のクラウドサービスを検討中 ◆ 現状はまだほぼできていない
  13. まとめ ➔ Microservices 化し、組織が自律分散型になっても安定してスケールしていけ るよう、統一的に Observability を確保 ➔ Metric は

    Datadog の Autodiscovery 等を活用して、言語やフレームワークご とに統一的に収集 ➔ Logging は Kubernetes クラスタ全体から Stackdriver Logging に集約し、今 後は構造化ログのフォーマットの統一化等を行なっていきたい ➔ Tracing はまだ活用できていないが、Stackdriver Trace 等を検討中 ➔ その他、Envoy/Service Mesh でもこの辺色々やっていきたい... 興味あれば懇親会で