Draft: Observability, Service Mesh and Microservices

Draft version.

Talk at Rails Developers Meetup 2018: Day 2 https://techplay.jp/event/655769

Clikcable link version: https://www.slideshare.net/TaikiOno/draft-observability-service-mesh-and-microservices-91693080

1. Observability, Service Mesh and Microservices Taiki Ono Software Engineer Cookpad Inc.
2. Service Mesh 便利
3. 採用目的™ https://info.cookpad.com/careers
5. 今回のお話 • なぜマイクロサービスに挑戦しているのか ‣ 時間の都合上カット、資料に掲載 • 「service mesh とは」について背景やメ リットなど普遍的な話 • クックパッドでの事例紹介: Envoy + 自作 control-plane
6. • 組織のステージは色々ありそれぞれのステージで必 要なものは変わる • こういう事例もあるのか〜の場 • 資料にリンクをいっぱい貼ったので知らないことは 後で調べてもらえれば OK、この発表は新しいことを 楽しんでくれるとうれしい • 卒 Rails の場 (個人的に Ruby も Rails も好きだけ ど、 Rails の話をしないトークも歓迎とのことなの で…！)
7. 語り手 • Taiki Ono, Cookpad Inc. • 開発基盤: 開発生産性上げていく • @taiki45 at GitHub • 大規模プロダクト開発, network proxy • 地域研究をやっていたのでペルシア語対応人材 ‣ 膝に矢を受けてしまってな…
8. なぜマイクロサービス？
9. なぜマイクロサービス？ • スケーラビリティの問題: 4人の組織 から2000人の組織へ ‣ オーナーシップの問題: 意思決定の速度 ‣ Agility: 開発サイクルの速度
10. Q: 4人のチームでアプリを どう作る？ • Rails で1アプリ、web/API 兼任、 1DB • ノーマイクロサービス • そもそも Firebase とか • インフラ層にかかる手間はほぼ無、そ んなことよりプロダクト開発
11. Q: 2000人のチームでたくさんのアプリを どう作る？ • いくつも事業領域があったり • 毎日5億人が使ってたり • 毎日リリース
12. A: 例えば水平に組織を分割 • 事業領域や機能毎に一通りのことができる小さな チームを複数作る • それぞれのチームが裁量を持ってプロダクト開発 を進める、チーム同士のコミュニケーションを減 らす • それぞれのチームは最低限の境界上の約束を作っ て連携する • それぞれのチームは小さく頻繁なリリースを行う
13. モノリシックアーキテクチャの限界 • 組織を水平に分割しても、モノリシックアーキ テクチャでは結局デプロイの調整とかコミュニ ケーション問題が復活してつらい • 小さなリリースがやりづらくなる、アプリを壊 すリスクがある大胆な意思決定がしづらくなる • オーナーシップに影響が出てきて自律的プロダ クト開発がしにくくなる、イノベーションを阻 害する
14. Service Oriented Architecture へ • ソフトウェアのアーキテクチャも変えて1 チームで1つ以上のアプリを担えるように したらオーナーシップの問題解決しそう • その上で、アプリ境界上の最低限の約束事 だけ決めたらチーム内で好きにできるから コミュニケーションコストも減りそう • Agility 復活じゃん
15. マイクロサービスとは • このように組織が大きくなっても、小さな 組織のような素早いプロダクト開発をなる べく維持するための方法がマイクロサービ ス • そのような方法のために設計されたアーキ テクチャをマイクロサービスアーキテクチャ と呼んだりすることがある (そういう文脈を 抜きにすれば SOA と言ってもいいと思う)
16. Pros of マイクロサービス • 小さなチームへの責任と権限の委譲 • 頻繁なトライアンドエラー • 高速かつ高精度な意思決定のサポート
17. Cons of マイクロサービス • アプリケーションはシンプルになるが システム全体として複雑になる • 個々のアプリケーションの開発は楽に なるがシステム全体の運用がめっちゃ 難しくなる
18. マイクロサービスと言ったら 「小さいチームで意思決定バーン、 アプリ数もそれに合わせてドーン」
19. • クックパッドも昔は必要なかったが、大きくなる につれ自然とマイクロサービスへと進んでいった • マイクロサービスと名前がつく前から同じことを していた組織は多い • マイクロサービスはもちろん not 銀の弾丸、デ メリットもある • 技術的課題をやっつけてなるべくメリットを享受 するぞ！
20. Service Mesh とは
21. 技術的課題と Service Mesh • 分散アーキテクチャの難しさ→倒してメリットを享受 するぞ！ ‣ 技術的課題の変遷を簡単に紹介 • Service mesh とは ‣ 特に中核の Envoy proxy について ‣ もしかしたら Istio について聞いたことがあるかも？ そこ ら辺の話 • 将来マネージドサービスが出た時に役に立つ話かも？
22. Service Mesh という言葉 • ちょくちょく周りでも聞くようになっ た気がする • もちろん聞いたことなくて全然OK、 これから話します
23. 全世界: 5年スパン https://trends.google.com/trends/explore?date=today%205-y&q=service%20mesh
24. 日本: 5年スパン https://trends.google.com/trends/explore?date=today%205- y&geo=JP&q=service%20mesh
25. 一体何者なんだ… https://trends.google.com/trends/explore?date=today%205-y&q=service%20mesh
26. Service Mesh、 • Kubernetes と関係ありそう • Istio ってやつと関係ありそう • Envoy というものと関係ありそう
27. マイクロサービスの技術的課題の変遷
28. マイクロサービス初期の課題1 • アプリケーションの動作環境の整備が 大変 • A: Puppet 等によるサーバー構築の自 動化
29. コンテナアーキテクチャの台頭と進化 • Docker によるコンテナ技術のパッ ケージング • リソーススケジューラー・オーケスト レーションソフトウェアの成熟: k8s • マネージドサービスの進化: GKE, Amazon EKS/AWS Fargate
30. マイクロサービス初期の課題2 • サービス同士を繋げるのが大変 (service discovery の問題) • Internal ELB, Airbnb SmartStack, consul-template 等
31. サービス同士を繋げるのは難しい • 素朴な時代: 2013年頃、掲示板サービスの情報をレシ ピサービスへ出してたら巻き込み落ち • サービス境界は慎重に区切っているが新しい事業の進展 とともにどうしてもサービスは増加する ‣ 障害発生時のトラブルシューティングの難しさ ‣ TV 放映時等のスパイク向けのキャパシティプランニング の難しさ • クックパッドではエスパーでまだなんとかなってるけど 10xの規模とかを見据えると厳しい
32. http://techlife.cookpad.com/entry/2017/09/06/115710
33. 技術的課題の変遷 • 1つ1つのアプリケーションはシンプルになる が、システム全体としての複雑性は上がる: 運 用の複雑性の増加 ‣ たくさんのアプリケーションを動かすのは技術 的に解決されつつある ‣ たくさんのアプリケーションをうまく繋げるこ とに課題がシフトしつつある • どうやったらもっとうまく運用できるだろうか
34. Observability Engineering • Twitter 社のエンジニア発の概念。Dapper 等、Google 内部での知見が発端っぽい • 分散システムをうまく運用するためにシス テムの繋がりの部分の挙動に注目して可視 化・監視する • 取得すべき値や集約・ストレージの設計等 がスコープ
35. • システム全体はどんな姿で、どのように動いているのか ‣サービス境界でなにが起こっているか: RPS, status, リト ライ・タイムアウト・サーキットブレーカの発動 ‣あるリクエストを処理したサービスがどれで、その処理結 果がどうだったのか: 分散トレーシング • これらを加入したての開発者でも素早く把握できること に価値がある • また効率的にシステム障害の解決したり、キャパシティ プランニングするのに必要
36. オーナーシップ問題再び • プロダクト開発者は基本的には自分たちのプロ ダクト・サービスに責任を持っている: 責任の 分離 • しかしシステム全体は協調して動作させる必要 があるので組織横断的なチームが必要: SRE 等 • 横断的なチームがアプリケーションの細部を把 握しなくてもシステム全体の動作を理解できる 必要がある → 中央で管理する必要性
37. どこで実現するか • それぞれアプリケーション内で実装するのは厳し い。ではライブラリで提供する？ • Polyglot との相性が悪い、実装毎の一貫性の問題 • ライブラリのメンテナンスのためにアプリケーショ ンのデプロイが必要: 横断的チームがやるのはし んどい • このような関心事をアプリケーションから分離で きると良いのでは→ Out Of Process モデル
38. Service Mesh To The Rescue
39. Service Mesh とは • アプリケーションに代わりネットワーク層の仕事 をする ‣ メトリクス取得/送信、リトライ等の実行、分散ト レーシング用のログの送信、service discovery, load balancing 等も行う • 2つのコンポーネントで構成される ‣ data-plane: proxy として上記タスクを行う ‣ control-plane: 各 proxy の挙動を管理する
40. ライブラリモデル • アプリケーショ ンに埋め込み • 設定値はアプリ ケーションプロ セスの中に http://blog.christianposta.com/istio-workshop/slides
41. Service Mesh モデル • proxy として別 プロセスに • proxy を管理す る control- plane http://blog.christianposta.com/istio-workshop/slides
42. Service Mesh の新規性 • よくできた proxy はすでにある: HAProxy, NGINX • サービスのつなぎ目の要所になる proxy を中央の control-plane から管理できるようにしたところに新規 性がある ‣ コンテナオーケストレーションと相性が良かった • Observability を強く意識していて metrics に重点を 置いた ‣ クックパッドでも昔 Observability のために HAProxy2 作 ろうかみたいな話をしていた
43. どんな組織が使っている？ • Lyft, Google, IBM, ebay, Apple, Microsoft, stripe, Netflix, Pinterest, Meduim, Salesforce, Square, Paypal, Expedia, AOL... • クックパッドも！
44. Service Mesh の実装の1つ • Istio ‣ control-plane: Pilot, Mixer, Istio-Auth ‣ data-plane: Envoy ‣ k8s 以外でも使えるようになったっぽい
45. • 今回は data-plane について深掘り (後述するように control-plane は 自作したので)
46. data-planes • Linkerd: Feb, 2016 from Buoyant • Envoy: Sep, 2016 from Lyft • Conduit proxy: Dec, 2017 from Buoyant
47. data-planes • Linkerd: Scala, Netty/Finagle • Envoy: C++14, using nghttp2 • Conduit proxy: Rust, early stage • クックパッドは Envoy proxy を選択
48. Envoy vs Linkerd at Cookpad • no VM vs JVM ‣ less resource usage ‣ hot restart • 豊富な設定、xDS API による更新 • h2, gRPC support が not experimental • Istio での採用状況: community の厚さ
49. C++? • 実は modern C++ は言うほど読みにくくない、syntax 的にむしろ読みやすい方 • 実は modern C++ は言うほど書きにくくない、覚えるこ とはわりとあるが step by step でパッチを書ける • 各種ツールが優秀: clang-tidy, AddressSanitizer, ThreadSanitizer... • あくまでアプリケーションを読み書きする上では。ライ ブラリはわからない • Envoy コミュニティのレビュー層が厚い
50. 詳解 Envoy
51. What’s Envoy • Service mesh 用 data-plane proxy • Edge proxy: TLS termination, routing, load balancing • gRPC サポート • 受付システムの Envoy と名前被りして るので ”Envoy proxy” でググる
52. • 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 の発行・ログの送 信
53. 余談: Envoy v1.6.0 release https://twitter.com/taiki45/status/976317282870689792
54. Getting started • main code: https://github.com/ envoyproxy/envoy • doc/API spec: https://github.com/ envoyproxy/data-plane-api • 公式 Docker image あり • ビルドツールに bazel を使っている
55. 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: 自身の設定を更新 →
56. xDS API • data-plane API とも呼ばれている • Envoy 内の情報を更新するための API spec ‣ LDS: Listener Discovery Service ‣ CDS: Cluster Discovery Service ‣ EDS: Endpoint Discovery Service ‣ RDS: Route Discovery Service ‣ その他…
57. コンポーネントの概観
58. Thread model https://blog.envoyproxy.io/envoy-threading-model-a8d44b922310
59. Hot Restart https://blog.envoyproxy.io/envoy-hot-restart-1d16b14555b5
60. stats の送信/保存 • statsd sink -> relay -> DB • dog_statsd sink -> statsd_exporter <- Prometheus • admin /stats <- Envoy listener/filter <- Prometheus • クックパッドは2個目のやつ採用(というか 自分たちで使うから作った)
61. gRPC support • gRPC health checking • HTTP/1.1 bridge • gRPC-JSON transcoding • gRPC-Web support
62. go-control-plane • Istio チームが開発中 • Envoy data-plane-api に沿った control-plane を go で書くためのラ イブラリ • Java 版もある
63. • まだまだ Envoy のおもしろいところ はあるけど、そろそろクックパッド での事例へ…
64. クックパッドでの事例
65. Service Mesh の未来(予測) • コンテナ管理のサービスに付随して、たぶんマ ネージドサービスが各 Cloud Vendor から出て くると思う • コンテナの設定と一緒にサービスを繋ぐ設定を 書いておいたらいい感じにコンテナ内からルー ティングされて、コンソールとかで可視化でき るやつ • 便利そう、しかしまだ無い(し、出て来る確証は ない)、意外と簡単だし作るぞ！
66. 現状
67. クックパッドでの 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
68. 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 の設定を更新
69. Our Service Mesh
70. 中央のリポジトリで管理する理由 • 変更履歴を理由付きで管理しておきた い: Git が適任 • サービスを繋ぐ設定変更を横断的な チームがレビューできるようにした い: GitHub が適任
71. • これで service discovery, retry/ timeout/circuit breaking が実現
72. Envoy stats on Grafana • サービス毎、特定のサービス×サービス ‣ 各 upstream 毎の RPS/status/latency などなど ‣ retry/timeout/circuit-breaker の発動 状況 • 各 Envoy の状況
74. Service Mesh の現状 • メトリクスの可視化ができている • retry/timeout/circuit-breaker をアプリケーショ ンの外で実現できている ‣ その設定値が GHE 上で管理されていて変更履歴が追え る ‣ その設定値をアプリケーションとは別にレビューできる • 余談: gRPC 用の client-side load balancing on ECS も service mesh があったのでサクッとできた
75. 今後
76. さらなる可視化 • 収集・表示するメトリクスを増やす ‣ gRPC サービスの手前に Envoy を置いてアク セスログ収集等も ‣ 運用していく過程でほしくなったメトリクス • promviz を使った可視化 • 社内のコンソールソフトウェアとの統合
77. https://github.com/Netflix/vizceral
78. さらなる自動化 • サービス繋がり部分での各種異常やイベ ントのアラート発火 ‣ まずは SRE へ ‣ プロダクト開発チームへも届けたい(権限と 責任の委譲) • retry 等の設定値調整用のツール整備・自 動化
79. Out of Process の進展 • 分散トレーシングを service mesh 層で 実現する ‣ AWS X-Ray 用の Tracer 実装 • 認証・認可処理やデッドラインの実現・ 伝播 • Failure Injection をして設定値のテスト
80. • 余談: config は v2 だけど xDS API は v1 のものを使ってるので v2 に置 きかえてく ‣せっかくなので Amazon ECS のまま control-plane に Istio のコンポーネ ントを使えないか検証もする予定
81. まとめ
82. Service Mesh 便利
83. 採用目的™ https://info.cookpad.com/careers
85. 今回のお話 • なぜマイクロサービスに挑戦しているのか ‣ 時間の都合上カット、資料に掲載 • 「service mesh とは」について背景やメ リットなど普遍的な話 • クックパッドでの事例紹介: Envoy + 自作 control-plane