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

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 として別 プロセスに • 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 のコンポーネ ントを使えないか検証もする予定