Successfully reported this slideshow.
We use your LinkedIn profile and activity data to personalize ads and to show you more relevant ads. You can change your ad preferences anytime.

Draft: Observability, Service Mesh and Microservices

50 views

Published on

Draft version.

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

Published in: Engineering
  • Be the first to comment

  • Be the first to like this

Draft: Observability, Service Mesh and Microservices

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

×