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

Observability, Service Mesh and Microservices

Avatar for taiki45 taiki45
March 25, 2018

Observability, Service Mesh and Microservices

Avatar for taiki45

taiki45

March 25, 2018
Tweet

More Decks by taiki45

Other Decks in Technology

Transcript

  1. Q: 4人のチームでアプリを どう作る? • Rails で1アプリ、web/API 兼任、 1DB • ノーマイクロサービス

    • そもそも Firebase とか • インフラ層にかかる手間はほぼ無、そ んなことよりプロダクト開発
  2. 技術的課題と Service Mesh • 分散アーキテクチャの難しさ→倒してメリットを享受 するぞ! ‣ 技術的課題の変遷を簡単に紹介 • Service

    mesh とは ‣ 特に中核の Envoy proxy について ‣ もしかしたら Istio について聞いたことがあるかも? そこ ら辺の話 • 将来マネージドサービスが出た時に役に立つ話かも?
  3. • システム全体はどんな姿で、どのように動いているのか ‣サービス境界でなにが起こっているか: RPS, status, リト ライ・タイムアウト・サーキットブレーカの発動 ‣あるリクエストを処理したサービスがどれで、その処理結 果がどうだったのか: 分散トレーシング

    • また効率的にシステム障害を解決したり、キャパシティ プランニングするのに必要 • 新規に入ってきた開発者が全体を把握できることに価値 がある: 組織の急速な成長に必要
  4. どこで実現するか • ライブラリで提供する? • Polyglot との相性が悪い、実装毎の一貫性の問 題 • ライブラリのメンテナンスのためにアプリケー ションのデプロイが必要:

    横断的チームがやる のはしんどい • このような関心事をアプリケーションから分離 できると良いのでは→ Out Of Process モデル
  5. Service Mesh とは • アプリケーションに代わりネットワーク層の仕事 をする ‣ メトリクス取得/送信、リトライ等の実行、分散ト レーシング用のログの送信、service discovery,

    load balancing 等も行う • 2つのコンポーネントで構成される ‣ data-plane: proxy として上記タスクを行う ‣ control-plane: 各 proxy の挙動を管理する
  6. Service Mesh モデル • proxy として別 プロセスに • proxy を管理す

    る control- plane http://blog.christianposta.com/istio-workshop/slides
  7. Service Mesh の新規性 • よくできた proxy はすでにある: HAProxy, NGINX •

    サービスのつなぎ目の要所になる proxy を中央の control-plane から管理できるようにしたところに新規 性がある ‣ コンテナオーケストレーションと相性が良かった • Observability を強く意識していて metrics に重点を 置いた ‣ クックパッドでも昔 Observability のために HAProxy2 作 ろうかみたいな話をしていた
  8. どんな組織が使っている? • Lyft, Google, IBM, ebay, Apple, Microsoft, stripe, Netflix,

    Pinterest, Meduim, Salesforce, Square, Paypal, Expedia, AOL... • クックパッドも!
  9. Service Mesh の実装の1つ • Istio ‣ control-plane: Pilot, Mixer, Istio-Auth

    ‣ data-plane: Envoy ‣ k8s 以外でも使えるようになったっぽい
  10. data-planes • Linkerd: Feb, 2016 from Buoyant • Envoy: Sep,

    2016 from Lyft • Conduit proxy: Dec, 2017 from Buoyant
  11. data-planes • Linkerd: Scala, Netty/Finagle • Envoy: C++14, using nghttp2

    • Conduit proxy: Rust, early stage • クックパッドは Envoy proxy を選択
  12. Envoy vs Linkerd at Cookpad • no VM vs JVM

    ‣ less resource usage ‣ hot restart • 豊富な設定、xDS API による更新 • h2, gRPC support が not experimental • Istio での採用状況: community の厚さ
  13. C++? • 実は modern C++ は言うほど読みにくくない、syntax 的にむしろ読みやすい方 • 実は modern

    C++ は言うほど書きにくくない、覚えるこ とはわりとあるが step by step でパッチを書ける • 各種ツールが優秀: clang-tidy, AddressSanitizer, ThreadSanitizer... • あくまでアプリケーションを読み書きする上では。ライ ブラリはわからない • Envoy コミュニティのレビュー層が厚い
  14. What’s Envoy • Service mesh 用 data-plane proxy • Edge

    proxy: TLS termination, routing, load balancing • gRPC サポート • 受付システムの Envoy と名前被りして るので ”Envoy proxy” でググる
  15. • hot reload/hot restart のサポート • nghttp2 for h2, single

    process multi- threaded, libevent for aysnc IO • 豊富な stats: per AZ, per listener, per upstream cluster, per canary... • リトライ・タイムアウト・サーキットブレーカー • 分散トレーシング: request ID の発行・ログの送 信
  16. Getting started • main code: https://github.com/ envoyproxy/envoy • doc/API spec:

    https://github.com/ envoyproxy/data-plane-api • 公式 Docker image あり • ビルドツールに bazel を使っている
  17. Envoy のコンポーネント • Listener: TCP connection をハンドル • Cluster: upstream

    host 群(endpoints)の情報を持って る • Filter: data を受け取り処理をして流す ‣ Network filters: Client TLS Authn, Redis, Mongo... ‣ HTTP filters: Router, gzip, Lua... • Stats sink: statistics を送る口 • xDS API: 自身の設定を更新 →
  18. xDS API • data-plane API とも呼ばれている • Envoy 内の情報を更新するための API

    spec ‣ LDS: Listener Discovery Service ‣ CDS: Cluster Discovery Service ‣ EDS: Endpoint Discovery Service ‣ RDS: Route Discovery Service ‣ その他…
  19. stats の送信/保存 • statsd sink -> relay -> DB •

    dog_statsd sink -> statsd_exporter <- Prometheus • admin /stats <- Envoy listener/filter <- Prometheus • クックパッドは2個目のやつ採用(というか 自分たちで使うから作った)
  20. gRPC support • gRPC health checking • HTTP/1.1 bridge •

    gRPC-JSON transcoding • gRPC-Web support
  21. Service Mesh の未来(予測) • コンテナ管理のサービスに付随して、たぶんマ ネージドサービスが各 Cloud Vendor から出て くると思う

    • コンテナの設定と一緒にサービスを繋ぐ設定を 書いておいたらいい感じにコンテナ内からルー ティングされて、コンソールとかで可視化でき るやつ • 便利そう、しかしまだ無い(し、出て来る確証は ない)、意外と簡単だし作るぞ!
  22. クックパッドでの Service Mesh • AWS ECS with Hako, no k8s

    • data-plane: Envoy proxy ‣ コミットほぼ全部見てるので origin HEAD を使ってる • control-plane: kumonos + Amazon S3 + lyft/ discovery ‣ kumonos は今のところ実装のみの公開 • metrics: dog_statsd sink + statsd_exporter + Prometheus
  23. Our control-plane • 中央のリポジトリで各サービスの依存情報を YAML で管理す る • kumonos gem

    で依存定義を CDS/RDS API 用の JSON に変換 • 生成した JSON を S3 で各 Envoy に配布 • CDS で配布する endpoint は Internal ELB に限定する ‣ 後に ELB 無しに動的なホスト群を扱えるようにもした: for gRPC client-side load balancing • CDS/RDS API 経由で各 Envoy インスタンスのルーティングや retry/timeout/circuit-breaker の設定を更新
  24. Envoy stats on Grafana • サービス毎、特定のサービス×サービス ‣ 各 upstream 毎の

    RPS/status/latency などなど ‣ retry/timeout/circuit-breaker の発動 状況 • 各 Envoy の状況
  25. Service Mesh の現状 • retry/timeout/circuit-breaking をアプリケーショ ンの外で実現できている ‣ その設定値が GHE

    上で管理されていて変更履歴が追え る ‣ その設定値をアプリケーションとは別にレビューできる • メトリクスの可視化ができている • 余談: gRPC 用の client-side load balancing on ECS も service mesh があったのでサクッとできた
  26. さらなる可視化 • 収集・表示するメトリクスを増やす ‣ gRPC サービスの手前に Envoy を置いてアク セスログ収集等も ‣

    運用していく過程でほしくなったメトリクス • promviz を使った可視化 • 社内のコンソールソフトウェアとの統合
  27. Out of Process の進展 • 分散トレーシングを service mesh 層で実現 する

    ‣ AWS X-Ray 用の Tracer 実装 • 認証・認可処理やデッドラインの実現・伝播 • Service identification (or authentication) • Failure Injection をして設定値のテスト
  28. • 余談: config は v2 だけど xDS API は v1

    のものを使ってるので v2 に置 きかえてく ‣せっかくなので Amazon ECS のまま control-plane に Istio のコンポーネ ントを使えないか検証もする予定