Upgrade to PRO for Only $50/Year—Limited-Time Offer! 🔥

Observability, Service Mesh and Microservices

taiki45
March 25, 2018

Observability, Service Mesh and Microservices

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 はすでにある: HAProxy, NGINX •

    サヌビスの぀なぎ目の芁所になる proxy を䞭倮の control-plane から管理できるようにしたずころに新芏 性がある ‣ コンテナオヌケストレヌションず盞性が良かった • Observability を匷く意識しおいお metrics に重点を 眮いた ‣ クックパッドでも昔 Observability のために HAProxy2 䜜 ろうかみたいな話をしおいた
  7. どんな組織が䜿っおいる • Lyft, Google, IBM, ebay, Apple, Microsoft, stripe, Netflix,

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

    ‣ data-plane: Envoy ‣ k8s 以倖でも䜿えるようになったっぜい
  9. data-planes • Linkerd: Feb, 2016 from Buoyant • Envoy: Sep,

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

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

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

    C++ は蚀うほど曞きにくくない、芚えるこ ずはわりずあるが step by step でパッチを曞ける • 各皮ツヌルが優秀: clang-tidy, AddressSanitizer, ThreadSanitizer... • あくたでアプリケヌションを読み曞きする䞊では。ラむ ブラリはわからない • Envoy コミュニティのレビュヌ局が厚い
  13. What’s Envoy • Service mesh 甹 data-plane proxy • Edge

    proxy: TLS termination, routing, load balancing • gRPC サポヌト • 受付システムの Envoy ず名前被りしお るので ”Envoy proxy” でググる
  14. • 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 の発行・ログの送 ä¿¡
  15. Getting started • main code: https://github.com/ envoyproxy/envoy • doc/API spec:

    https://github.com/ envoyproxy/data-plane-api • 公匏 Docker image あり • ビルドツヌルに bazel を䜿っおいる
  16. 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: 自身の蚭定を曎新 →
  17. xDS API • data-plane API ずも呌ばれおいる • Envoy 内の情報を曎新するための API

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

    dog_statsd sink -> statsd_exporter <- Prometheus • admin /stats <- Envoy listener/filter <- Prometheus • クックパッドは2個目のや぀採甚(ずいうか 自分たちで䜿うから䜜った)
  19. gRPC support • gRPC health checking • HTTP/1.1 bridge •

    gRPC-JSON transcoding • gRPC-Web support
  20. go-control-plane • Istio チヌムが開発䞭 • Envoy data-plane-api に沿った control-plane を

    go で曞くためのラ むブラリ • Java 版もある
  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 のコンポヌネ ントを䜿えないか怜蚌もする予定