$30 off During Our Annual Pro Sale. View Details »

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. 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. なぜマイクロサービス?

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

    開発サイクルの速度
  9. Q: 4人のチームでアプリを どう作る? • Rails で1アプリ、web/API 兼任、 1DB • ノーマイクロサービス

    • そもそも Firebase とか • インフラ層にかかる手間はほぼ無、そ んなことよりプロダクト開発
  10. Q: 2000人のチームでたくさんのアプリを どう作る? • いくつも事業領域があったり • 毎日5億人が使ってたり • 毎日リリース

  11. A: 例えば水平に組織を分割 • 事業領域や機能毎に一通りのことができる小さな チームを複数作る • それぞれのチームが裁量を持ってプロダクト開発 を進める、チーム同士のコミュニケーションを減 らす •

    それぞれのチームは最低限の境界上の約束を作っ て連携する • それぞれのチームは小さく頻繁なリリースを行う
  12. モノリシックアーキテクチャの限界 • 組織を水平に分割しても、モノリシックアーキ テクチャでは結局デプロイの調整とかコミュニ ケーション問題が復活してつらい • 小さなリリースがやりづらくなる、アプリを壊 すリスクがある大胆な意思決定がしづらくなる • オーナーシップに影響が出てきて自律的プロダ

    クト開発がしにくくなる、イノベーションを阻 害する
  13. Service Oriented Architecture へ • ソフトウェアのアーキテクチャも変えて1 チームで1つ以上のアプリを担えるように したらオーナーシップの問題解決しそう • その上で、アプリ境界上の最低限の約束事

    だけ決めたらチーム内で好きにできるから コミュニケーションコストも減りそう • Agility 復活じゃん
  14. マイクロサービスとは • このように組織が大きくなっても、小さな 組織のような素早いプロダクト開発をなる べく維持するための方法がマイクロサービ ス • そのような方法のために設計されたアーキ テクチャをマイクロサービスアーキテクチャ と呼んだりすることがある

    (そういう文脈を 抜きにすれば SOA と言ってもいいと思う)
  15. Pros of マイクロサービス • 小さなチームへの責任と権限の委譲 • 頻繁なトライアンドエラー • 高速かつ高精度な意思決定のサポート

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

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

  18. • クックパッドも昔は必要なかったが、大きくなる につれ自然とマイクロサービスへと進んでいった • マイクロサービスと名前がつく前から同じことを していた組織は多い • マイクロサービスはもちろん not 銀の弾丸、デ

    メリットもある • 技術的課題をやっつけてなるべくメリットを享受 するぞ!
  19. Service Mesh とは

  20. 技術的課題と Service Mesh • 分散アーキテクチャの難しさ→倒してメリットを享受 するぞ! ‣ 技術的課題の変遷を簡単に紹介 • Service

    mesh とは ‣ 特に中核の Envoy proxy について ‣ もしかしたら Istio について聞いたことがあるかも? そこ ら辺の話 • 将来マネージドサービスが出た時に役に立つ話かも?
  21. Service Mesh という言葉 • ちょくちょく周りでも聞くようになっ た気がする • もちろん聞いたことなくて全然OK、 これから話します

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

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

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

  25. Service Mesh、 • Kubernetes と関係ありそう • Istio ってやつと関係ありそう • Envoy

    というものと関係ありそう
  26. マイクロサービスの技術的課題の変遷

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

  28. コンテナアーキテクチャの台頭と進化 • Docker によるコンテナ技術のパッ ケージング • リソーススケジューラー・オーケスト レーションソフトウェアの成熟: k8s •

    マネージドサービスの進化: GKE, Amazon EKS/AWS Fargate
  29. マイクロサービス初期の課題2 • サービス同士を繋げるのが大変 (service discovery の問題) • Internal ELB, Airbnb

    SmartStack, consul-template 等
  30. サービス同士を繋げるのは難しい • 素朴な時代: 2013年頃、掲示板サービスの情報をレシ ピサービスへ出してたら巻き込み落ち • サービス境界は慎重に区切っているが新しい事業の進展 とともにどうしてもサービスは増加する ‣ 障害発生時のトラブルシューティングの難しさ

    ‣ TV 放映時等のスパイク向けのキャパシティプランニング の難しさ • クックパッドではエスパーでまだなんとかなってるけど 10xの規模とかを見据えると厳しい
  31. http://techlife.cookpad.com/entry/2017/09/06/115710

  32. 技術的課題の変遷 • 1つ1つのアプリケーションはシンプルになる が、システム全体としての複雑性は上がる: 運 用の複雑性の増加 ‣ たくさんのアプリケーションを動かすのは技術 的に解決されつつある ‣

    たくさんのアプリケーションをうまく繋げるこ とに課題がシフトしつつある • どうやったらもっとうまく運用できるだろうか
  33. Observability • Twitter 社のエンジニア発の概念。Dapper 等、Google 内部での知見が発端っぽい • 分散システムをうまく運用するためにシス テムの繋がりの部分の挙動に注目して可視 化・監視する

    • 取得すべき値や集約・ストレージの設計等 がスコープ
  34. • システム全体はどんな姿で、どのように動いているのか ‣サービス境界でなにが起こっているか: RPS, status, リト ライ・タイムアウト・サーキットブレーカの発動 ‣あるリクエストを処理したサービスがどれで、その処理結 果がどうだったのか: 分散トレーシング

    • また効率的にシステム障害を解決したり、キャパシティ プランニングするのに必要 • 新規に入ってきた開発者が全体を把握できることに価値 がある: 組織の急速な成長に必要
  35. オーナーシップ問題再び • プロダクト開発者は基本的には自分たちのプロ ダクト・サービスに責任を持っている: 責任の 分離 • しかしシステム全体は協調して動作させる必要 があるので組織横断的なチームが必要: SRE

    等 • 横断的なチームがアプリケーションの細部を把 握しなくてもシステム全体の動作を理解できる 必要がある → 中央で管理する必要性
  36. どこで実現するか • ライブラリで提供する? • Polyglot との相性が悪い、実装毎の一貫性の問 題 • ライブラリのメンテナンスのためにアプリケー ションのデプロイが必要:

    横断的チームがやる のはしんどい • このような関心事をアプリケーションから分離 できると良いのでは→ Out Of Process モデル
  37. Service Mesh To The Rescue

  38. Service Mesh とは • アプリケーションに代わりネットワーク層の仕事 をする ‣ メトリクス取得/送信、リトライ等の実行、分散ト レーシング用のログの送信、service discovery,

    load balancing 等も行う • 2つのコンポーネントで構成される ‣ data-plane: proxy として上記タスクを行う ‣ control-plane: 各 proxy の挙動を管理する
  39. ライブラリモデル • アプリケーショ ンに埋め込み • 設定値はアプリ ケーションプロ セスの中に http://blog.christianposta.com/istio-workshop/slides

  40. Service Mesh モデル • proxy として別 プロセスに • proxy を管理す

    る control- plane http://blog.christianposta.com/istio-workshop/slides
  41. Service Mesh の新規性 • よくできた proxy はすでにある: HAProxy, NGINX •

    サービスのつなぎ目の要所になる proxy を中央の control-plane から管理できるようにしたところに新規 性がある ‣ コンテナオーケストレーションと相性が良かった • Observability を強く意識していて metrics に重点を 置いた ‣ クックパッドでも昔 Observability のために HAProxy2 作 ろうかみたいな話をしていた
  42. どんな組織が使っている? • Lyft, Google, IBM, ebay, Apple, Microsoft, stripe, Netflix,

    Pinterest, Meduim, Salesforce, Square, Paypal, Expedia, AOL... • クックパッドも!
  43. Service Mesh の実装の1つ • Istio ‣ control-plane: Pilot, Mixer, Istio-Auth

    ‣ data-plane: Envoy ‣ k8s 以外でも使えるようになったっぽい
  44. • 今回は data-plane について深掘り (後述するように control-plane は 自作したので)

  45. data-planes • Linkerd: Feb, 2016 from Buoyant • Envoy: Sep,

    2016 from Lyft • Conduit proxy: Dec, 2017 from Buoyant
  46. data-planes • Linkerd: Scala, Netty/Finagle • Envoy: C++14, using nghttp2

    • Conduit proxy: Rust, early stage • クックパッドは Envoy proxy を選択
  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. C++? • 実は modern C++ は言うほど読みにくくない、syntax 的にむしろ読みやすい方 • 実は modern

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

  50. What’s Envoy • Service mesh 用 data-plane proxy • Edge

    proxy: TLS termination, routing, load balancing • gRPC サポート • 受付システムの Envoy と名前被りして るので ”Envoy proxy” でググる
  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. 余談: Envoy v1.6.0 release https://twitter.com/taiki45/status/976317282870689792

  53. Getting started • main code: https://github.com/ envoyproxy/envoy • doc/API spec:

    https://github.com/ envoyproxy/data-plane-api • 公式 Docker image あり • ビルドツールに bazel を使っている
  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. 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. コンポーネントの概観

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

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

  59. stats の送信/保存 • statsd sink -> relay -> DB •

    dog_statsd sink -> statsd_exporter <- Prometheus • admin /stats <- Envoy listener/filter <- Prometheus • クックパッドは2個目のやつ採用(というか 自分たちで使うから作った)
  60. gRPC support • gRPC health checking • HTTP/1.1 bridge •

    gRPC-JSON transcoding • gRPC-Web support
  61. go-control-plane • Istio チームが開発中 • Envoy data-plane-api に沿った control-plane を

    go で書くためのラ イブラリ • Java 版もある
  62. • まだまだ Envoy のおもしろいところ はあるけど、そろそろクックパッド での事例へ…

  63. クックパッドでの事例

  64. Service Mesh の未来(予測) • コンテナ管理のサービスに付随して、たぶんマ ネージドサービスが各 Cloud Vendor から出て くると思う

    • コンテナの設定と一緒にサービスを繋ぐ設定を 書いておいたらいい感じにコンテナ内からルー ティングされて、コンソールとかで可視化でき るやつ • 便利そう、しかしまだ無い(し、出て来る確証は ない)、意外と簡単だし作るぞ!
  65. 現状

  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. 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. Our Service Mesh

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

    GitHub が適任
  70. • これで service discovery, retry/ timeout/circuit breaking が実現

  71. Envoy stats on Grafana • サービス毎、特定のサービス×サービス ‣ 各 upstream 毎の

    RPS/status/latency などなど ‣ retry/timeout/circuit-breaker の発動 状況 • 各 Envoy の状況
  72. None
  73. Service Mesh の現状 • retry/timeout/circuit-breaking をアプリケーショ ンの外で実現できている ‣ その設定値が GHE

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

  75. さらなる可視化 • 収集・表示するメトリクスを増やす ‣ gRPC サービスの手前に Envoy を置いてアク セスログ収集等も ‣

    運用していく過程でほしくなったメトリクス • promviz を使った可視化 • 社内のコンソールソフトウェアとの統合
  76. https://github.com/Netflix/vizceral

  77. さらなる自動化 • サービス繋がり部分での各種異常やイベ ントのアラート発火 ‣ まずは SRE へ ‣ プロダクト開発チームへも届けたい(権限と

    責任の委譲) • retry 等の設定値調整用のツール整備・自 動化
  78. Out of Process の進展 • 分散トレーシングを service mesh 層で実現 する

    ‣ AWS X-Ray 用の Tracer 実装 • 認証・認可処理やデッドラインの実現・伝播 • Service identification (or authentication) • Failure Injection をして設定値のテスト
  79. • 余談: config は v2 だけど xDS API は v1

    のものを使ってるので v2 に置 きかえてく ‣せっかくなので Amazon ECS のまま control-plane に Istio のコンポーネ ントを使えないか検証もする予定
  80. まとめ

  81. Service Mesh 便利

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

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

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