Upgrade to Pro — share decks privately, control downloads, hide ads and more …

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.

    View Slide

  2. Service Mesh
    便利

    View Slide

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

    View Slide

  4. View Slide

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

    View Slide

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

    View Slide

  7. なぜマイクロサービス?

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

  14. マイクロサービスとは
    • このように組織が大きくなっても、小さな
    組織のような素早いプロダクト開発をなる
    べく維持するための方法がマイクロサービ

    • そのような方法のために設計されたアーキ
    テクチャをマイクロサービスアーキテクチャ
    と呼んだりすることがある (そういう文脈を
    抜きにすれば SOA と言ってもいいと思う)

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

  19. Service Mesh とは

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

  36. どこで実現するか
    • ライブラリで提供する?
    • Polyglot との相性が悪い、実装毎の一貫性の問

    • ライブラリのメンテナンスのためにアプリケー
    ションのデプロイが必要: 横断的チームがやる
    のはしんどい
    • このような関心事をアプリケーションから分離
    できると良いのでは→ Out Of Process モデル

    View Slide

  37. Service Mesh To The Rescue

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

  42. どんな組織が使っている?
    • Lyft, Google, IBM, ebay, Apple,
    Microsoft, stripe, Netflix,
    Pinterest, Meduim, Salesforce,
    Square, Paypal, Expedia, AOL...
    • クックパッドも!

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

  49. 詳解 Envoy

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

  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: 自身の設定を更新 →

    View Slide

  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
    ‣ その他…

    View Slide

  56. コンポーネントの概観

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

  65. 現状

    View Slide

  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

    View Slide

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

    View Slide

  68. Our Service Mesh

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

  72. View Slide

  73. Service Mesh の現状
    • retry/timeout/circuit-breaking をアプリケーショ
    ンの外で実現できている
    ‣ その設定値が GHE 上で管理されていて変更履歴が追え

    ‣ その設定値をアプリケーションとは別にレビューできる
    • メトリクスの可視化ができている
    • 余談: gRPC 用の client-side load balancing on ECS
    も service mesh があったのでサクッとできた

    View Slide

  74. 今後

    View Slide

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

    View Slide

  76. https://github.com/Netflix/vizceral

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

  80. まとめ

    View Slide

  81. Service Mesh
    便利

    View Slide

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

    View Slide

  83. View Slide

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

    View Slide