Draft: Observability, Service Mesh and Microservices

44e6e0e9bcc3d8279020aad563f16f34?s=47 taiki45
March 24, 2018

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

44e6e0e9bcc3d8279020aad563f16f34?s=128

taiki45

March 24, 2018
Tweet

Transcript

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

    Inc.
  2. Service Mesh 便利

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

  4. None
  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 の状況
  73. None
  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

  84. None
  85. 今回のお話 • なぜマイクロサービスに挑戦しているのか ‣ 時間の都合上カット、資料に掲載 • 「service mesh とは」について背景やメ リットなど普遍的な話

    • クックパッドでの事例紹介: Envoy + 自作 control-plane