Observability, Service Mesh and Microservices

by taiki45

Slide 1

Slide 1 text

Observability, Service Mesh and Microservices Taiki Ono Software Engineer Cookpad Inc.

Slide 2

Slide 2 text

Service Mesh 便利

Slide 3

Slide 3 text

採用目的™ https://info.cookpad.com/careers

Slide 4

Slide 4 text

No content

Slide 5

Slide 5 text

今回のお話 • なぜマイクロサービスに挑戦しているのか ‣ 時間の都合上カット、資料に掲載 • 「service mesh とは」について背景やメリットなど普遍的な話 • クックパッドでの事例紹介: Envoy + 自作 control-plane

Slide 6

Slide 6 text

• 組織のステージは色々ありそれぞれのステージで必要なものは変わる • こういう事例もあるのか〜の場 • 資料にリンクをいっぱい貼ったので知らないことは後で調べてもらえれば OK、この発表は新しいことを楽しんでくれるとうれしい • 卒 Rails の場 (個人的に Ruby も Rails も好きだけど、 Rails の話をしないトークを歓迎とのことなので…！)

Slide 7

Slide 7 text

なぜマイクロサービス？

Slide 8

Slide 8 text

なぜマイクロサービス？ • スケーラビリティの問題: 4人の組織から2000人の組織へ ‣ オーナーシップの問題: 意思決定の速度 ‣ Agility: 開発サイクルの速度

Slide 9

Slide 9 text

Q: 4人のチームでアプリをどう作る？ • Rails で1アプリ、web/API 兼任、 1DB • ノーマイクロサービス • そもそも Firebase とか • インフラ層にかかる手間はほぼ無、そんなことよりプロダクト開発

Slide 10

Slide 10 text

Q: 2000人のチームでたくさんのアプリをどう作る？ • いくつも事業領域があったり • 毎日5億人が使ってたり • 毎日リリース

Slide 11

Slide 11 text

A: 例えば水平に組織を分割 • 事業領域や機能毎に一通りのことができる小さなチームを複数作る • それぞれのチームが裁量を持ってプロダクト開発を進める、チーム同士のコミュニケーションを減らす • それぞれのチームは最低限の境界上の約束を作って連携する • それぞれのチームは小さく頻繁なリリースを行う

Slide 12

Slide 12 text

モノリシックアーキテクチャの限界 • 組織を水平に分割しても、モノリシックアーキテクチャでは結局デプロイの調整とかコミュニケーション問題が復活してつらい • 小さなリリースがやりづらくなる、アプリを壊すリスクがある大胆な意思決定がしづらくなる • オーナーシップに影響が出てきて自律的プロダクト開発がしにくくなる、イノベーションを阻害する

Slide 13

Slide 13 text

Service Oriented Architecture へ • ソフトウェアのアーキテクチャも変えて1 チームで1つ以上のアプリを担えるようにしたらオーナーシップの問題解決しそう • その上で、アプリ境界上の最低限の約束事だけ決めたらチーム内で好きにできるからコミュニケーションコストも減りそう • Agility 復活じゃん

Slide 14

Slide 14 text

マイクロサービスとは • このように組織が大きくなっても、小さな組織のような素早いプロダクト開発をなるべく維持するための方法がマイクロサービス • そのような方法のために設計されたアーキテクチャをマイクロサービスアーキテクチャと呼んだりすることがある (そういう文脈を抜きにすれば SOA と言ってもいいと思う)

Slide 15

Slide 15 text

Pros of マイクロサービス • 小さなチームへの責任と権限の委譲 • 頻繁なトライアンドエラー • 高速かつ高精度な意思決定のサポート

Slide 16

Slide 16 text

Cons of マイクロサービス • アプリケーションはシンプルになるがシステム全体として複雑になる • 個々のアプリケーションの開発は楽になるがシステム全体の運用がめっちゃ難しくなる

Slide 17

Slide 17 text

マイクロサービスと言ったら「小さいチームで意思決定バーン、アプリ数もそれに合わせてドーン」

Slide 18

Slide 18 text

• クックパッドも昔は必要なかったが、大きくなるにつれ自然とマイクロサービスへと進んでいった • マイクロサービスと名前がつく前から同じことをしていた組織は多い • マイクロサービスはもちろん not 銀の弾丸、デメリットもある • 技術的課題をやっつけてなるべくメリットを享受するぞ！

Slide 19

Slide 19 text

Service Mesh とは

Slide 20

Slide 20 text

技術的課題と Service Mesh • 分散アーキテクチャの難しさ→倒してメリットを享受するぞ！ ‣ 技術的課題の変遷を簡単に紹介 • Service mesh とは ‣ 特に中核の Envoy proxy について ‣ もしかしたら Istio について聞いたことがあるかも？そこら辺の話 • 将来マネージドサービスが出た時に役に立つ話かも？

Slide 21

Slide 21 text

Service Mesh という言葉 • ちょくちょく周りでも聞くようになった気がする • もちろん聞いたことなくて全然OK、これから話します

Slide 22

Slide 22 text

全世界: 5年スパン https://trends.google.com/trends/explore?date=today%205-y&q=service%20mesh

Slide 23

Slide 23 text

日本: 5年スパン https://trends.google.com/trends/explore?date=today%205- y&geo=JP&q=service%20mesh

Slide 24

Slide 24 text

一体何者なんだ… https://trends.google.com/trends/explore?date=today%205-y&q=service%20mesh

Slide 25

Slide 25 text

Service Mesh、 • Kubernetes と関係ありそう • Istio ってやつと関係ありそう • Envoy というものと関係ありそう

Slide 26

Slide 26 text

マイクロサービスの技術的課題の変遷

Slide 27

Slide 27 text

マイクロサービス初期の課題1 • アプリケーションの動作環境の整備が大変 • A: Puppet 等によるサーバー構築の自動化

Slide 28

Slide 28 text

コンテナアーキテクチャの台頭と進化 • Docker によるコンテナ技術のパッケージング • リソーススケジューラー・オーケストレーションソフトウェアの成熟: k8s • マネージドサービスの進化: GKE, Amazon EKS/AWS Fargate

Slide 29

Slide 29 text

マイクロサービス初期の課題2 • サービス同士を繋げるのが大変 (service discovery の問題) • Internal ELB, Airbnb SmartStack, consul-template 等

Slide 30

Slide 30 text

サービス同士を繋げるのは難しい • 素朴な時代: 2013年頃、掲示板サービスの情報をレシピサービスへ出してたら巻き込み落ち • サービス境界は慎重に区切っているが新しい事業の進展とともにどうしてもサービスは増加する ‣ 障害発生時のトラブルシューティングの難しさ ‣ TV 放映時等のスパイク向けのキャパシティプランニングの難しさ • クックパッドではエスパーでまだなんとかなってるけど 10xの規模とかを見据えると厳しい

Slide 31

Slide 31 text

http://techlife.cookpad.com/entry/2017/09/06/115710

Slide 32

Slide 32 text

技術的課題の変遷 • 1つ1つのアプリケーションはシンプルになるが、システム全体としての複雑性は上がる: 運用の複雑性の増加 ‣ たくさんのアプリケーションを動かすのは技術的に解決されつつある ‣ たくさんのアプリケーションをうまく繋げることに課題がシフトしつつある • どうやったらもっとうまく運用できるだろうか

Slide 33

Slide 33 text

Observability • Twitter 社のエンジニア発の概念。Dapper 等、Google 内部での知見が発端っぽい • 分散システムをうまく運用するためにシステムの繋がりの部分の挙動に注目して可視化・監視する • 取得すべき値や集約・ストレージの設計等がスコープ

Slide 34

Slide 34 text

• システム全体はどんな姿で、どのように動いているのか ‣サービス境界でなにが起こっているか: RPS, status, リトライ・タイムアウト・サーキットブレーカの発動 ‣あるリクエストを処理したサービスがどれで、その処理結果がどうだったのか: 分散トレーシング • また効率的にシステム障害を解決したり、キャパシティプランニングするのに必要 • 新規に入ってきた開発者が全体を把握できることに価値がある: 組織の急速な成長に必要

Slide 35

Slide 35 text

オーナーシップ問題再び • プロダクト開発者は基本的には自分たちのプロダクト・サービスに責任を持っている: 責任の分離 • しかしシステム全体は協調して動作させる必要があるので組織横断的なチームが必要: SRE 等 • 横断的なチームがアプリケーションの細部を把握しなくてもシステム全体の動作を理解できる必要がある → 中央で管理する必要性

Slide 36

Slide 36 text

どこで実現するか • ライブラリで提供する？ • Polyglot との相性が悪い、実装毎の一貫性の問題 • ライブラリのメンテナンスのためにアプリケーションのデプロイが必要: 横断的チームがやるのはしんどい • このような関心事をアプリケーションから分離できると良いのでは→ Out Of Process モデル

Slide 37

Slide 37 text

Service Mesh To The Rescue

Slide 38

Slide 38 text

Service Mesh とは • アプリケーションに代わりネットワーク層の仕事をする ‣ メトリクス取得/送信、リトライ等の実行、分散トレーシング用のログの送信、service discovery, load balancing 等も行う • 2つのコンポーネントで構成される ‣ data-plane: proxy として上記タスクを行う ‣ control-plane: 各 proxy の挙動を管理する

Slide 39

Slide 39 text

ライブラリモデル • アプリケーションに埋め込み • 設定値はアプリケーションプロセスの中に http://blog.christianposta.com/istio-workshop/slides

Slide 40

Slide 40 text

Service Mesh モデル • proxy として別プロセスに • proxy を管理する control- plane http://blog.christianposta.com/istio-workshop/slides

Slide 41

Slide 41 text

Service Mesh の新規性 • よくできた proxy はすでにある: HAProxy, NGINX • サービスのつなぎ目の要所になる proxy を中央の control-plane から管理できるようにしたところに新規性がある ‣ コンテナオーケストレーションと相性が良かった • Observability を強く意識していて metrics に重点を置いた ‣ クックパッドでも昔 Observability のために HAProxy2 作ろうかみたいな話をしていた

Slide 42

Slide 42 text

どんな組織が使っている？ • Lyft, Google, IBM, ebay, Apple, Microsoft, stripe, Netﬂix, Pinterest, Meduim, Salesforce, Square, Paypal, Expedia, AOL... • クックパッドも！

Slide 43

Slide 43 text

Service Mesh の実装の1つ • Istio ‣ control-plane: Pilot, Mixer, Istio-Auth ‣ data-plane: Envoy ‣ k8s 以外でも使えるようになったっぽい

Slide 44

Slide 44 text

• 今回は data-plane について深掘り (後述するように control-plane は自作したので)

Slide 45

Slide 45 text

data-planes • Linkerd: Feb, 2016 from Buoyant • Envoy: Sep, 2016 from Lyft • Conduit proxy: Dec, 2017 from Buoyant

Slide 46

Slide 46 text

data-planes • Linkerd: Scala, Netty/Finagle • Envoy: C++14, using nghttp2 • Conduit proxy: Rust, early stage • クックパッドは Envoy proxy を選択

Slide 47

Slide 47 text

Envoy vs Linkerd at Cookpad • no VM vs JVM ‣ less resource usage ‣ hot restart • 豊富な設定、xDS API による更新 • h2, gRPC support が not experimental • Istio での採用状況: community の厚さ

Slide 48

Slide 48 text

C++? • 実は modern C++ は言うほど読みにくくない、syntax 的にむしろ読みやすい方 • 実は modern C++ は言うほど書きにくくない、覚えることはわりとあるが step by step でパッチを書ける • 各種ツールが優秀: clang-tidy, AddressSanitizer, ThreadSanitizer... • あくまでアプリケーションを読み書きする上では。ライブラリはわからない • Envoy コミュニティのレビュー層が厚い

Slide 49

Slide 49 text

詳解 Envoy

Slide 50

Slide 50 text

What’s Envoy • Service mesh 用 data-plane proxy • Edge proxy: TLS termination, routing, load balancing • gRPC サポート • 受付システムの Envoy と名前被りしてるので ”Envoy proxy” でググる

Slide 51

Slide 51 text

• 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 の発行・ログの送信

Slide 52

Slide 52 text

余談: Envoy v1.6.0 release https://twitter.com/taiki45/status/976317282870689792

Slide 53

Slide 53 text

Getting started • main code: https://github.com/ envoyproxy/envoy • doc/API spec: https://github.com/ envoyproxy/data-plane-api • 公式 Docker image あり • ビルドツールに bazel を使っている

Slide 54

Slide 54 text

Envoy のコンポーネント • Listener: TCP connection をハンドル • Cluster: upstream host 群(endpoints)の情報を持ってる • Filter: data を受け取り処理をして流す ‣ Network ﬁlters: Client TLS Authn, Redis, Mongo... ‣ HTTP ﬁlters: Router, gzip, Lua... • Stats sink: statistics を送る口 • xDS API: 自身の設定を更新 →

Slide 55

Slide 55 text

xDS API • data-plane API とも呼ばれている • Envoy 内の情報を更新するための API spec ‣ LDS: Listener Discovery Service ‣ CDS: Cluster Discovery Service ‣ EDS: Endpoint Discovery Service ‣ RDS: Route Discovery Service ‣ その他…

Slide 56

Slide 56 text

コンポーネントの概観

Slide 57

Slide 57 text

Thread model https://blog.envoyproxy.io/envoy-threading-model-a8d44b922310

Slide 58

Slide 58 text

Hot Restart https://blog.envoyproxy.io/envoy-hot-restart-1d16b14555b5

Slide 59

Slide 59 text

stats の送信/保存 • statsd sink -> relay -> DB • dog_statsd sink -> statsd_exporter <- Prometheus • admin /stats <- Envoy listener/ﬁlter <- Prometheus • クックパッドは2個目のやつ採用(というか自分たちで使うから作った)

Slide 60

Slide 60 text

gRPC support • gRPC health checking • HTTP/1.1 bridge • gRPC-JSON transcoding • gRPC-Web support

Slide 61

Slide 61 text

go-control-plane • Istio チームが開発中 • Envoy data-plane-api に沿った control-plane を go で書くためのライブラリ • Java 版もある

Slide 62

Slide 62 text

• まだまだ Envoy のおもしろいところはあるけど、そろそろクックパッドでの事例へ…

Slide 63

Slide 63 text

クックパッドでの事例

Slide 64

Slide 64 text

Service Mesh の未来(予測) • コンテナ管理のサービスに付随して、たぶんマネージドサービスが各 Cloud Vendor から出てくると思う • コンテナの設定と一緒にサービスを繋ぐ設定を書いておいたらいい感じにコンテナ内からルーティングされて、コンソールとかで可視化できるやつ • 便利そう、しかしまだ無い(し、出て来る確証はない)、意外と簡単だし作るぞ！

Slide 65

Slide 65 text

現状

Slide 66

Slide 66 text

クックパッドでの 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

Slide 67

Slide 67 text

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 の設定を更新

Slide 68

Slide 68 text

Our Service Mesh

Slide 69

Slide 69 text

中央のリポジトリで管理する理由 • 変更履歴を理由付きで管理しておきたい: Git が適任 • サービスを繋ぐ設定変更を横断的なチームがレビューできるようにしたい: GitHub が適任

Slide 70

Slide 70 text

• これで service discovery, retry/ timeout/circuit breaking が実現

Slide 71

Slide 71 text

Envoy stats on Grafana • サービス毎、特定のサービス×サービス ‣ 各 upstream 毎の RPS/status/latency などなど ‣ retry/timeout/circuit-breaker の発動状況 • 各 Envoy の状況

Slide 72

Slide 72 text

No content

Slide 73

Slide 73 text

Service Mesh の現状 • retry/timeout/circuit-breaking をアプリケーションの外で実現できている ‣ その設定値が GHE 上で管理されていて変更履歴が追える ‣ その設定値をアプリケーションとは別にレビューできる • メトリクスの可視化ができている • 余談: gRPC 用の client-side load balancing on ECS も service mesh があったのでサクッとできた

Slide 74

Slide 74 text

今後

Slide 75

Slide 75 text

さらなる可視化 • 収集・表示するメトリクスを増やす ‣ gRPC サービスの手前に Envoy を置いてアクセスログ収集等も ‣ 運用していく過程でほしくなったメトリクス • promviz を使った可視化 • 社内のコンソールソフトウェアとの統合

Slide 76

Slide 76 text

https://github.com/Netﬂix/vizceral

Slide 77

Slide 77 text

さらなる自動化 • サービス繋がり部分での各種異常やイベントのアラート発火 ‣ まずは SRE へ ‣ プロダクト開発チームへも届けたい(権限と責任の委譲) • retry 等の設定値調整用のツール整備・自動化

Slide 78

Slide 78 text

Out of Process の進展 • 分散トレーシングを service mesh 層で実現する ‣ AWS X-Ray 用の Tracer 実装 • 認証・認可処理やデッドラインの実現・伝播 • Service identiﬁcation (or authentication) • Failure Injection をして設定値のテスト

Slide 79

Slide 79 text

• 余談: conﬁg は v2 だけど xDS API は v1 のものを使ってるので v2 に置きかえてく ‣せっかくなので Amazon ECS のまま control-plane に Istio のコンポーネントを使えないか検証もする予定