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

Draft: Observability, Service Mesh and Microservices

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

taiki45

March 24, 2018
Tweet

More Decks by taiki45

Other Decks in Technology

Transcript

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

    View full-size slide

  2. Service Mesh
    便利

    View full-size slide

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

    View full-size slide

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

    View full-size slide

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

    View full-size slide

  6. 語り手
    • Taiki Ono, Cookpad Inc.
    • 開発基盤: 開発生産性上げていく
    • @taiki45 at GitHub
    • 大規模プロダクト開発, network proxy
    • 地域研究をやっていたのでペルシア語対応人材
    ‣ 膝に矢を受けてしまってな…

    View full-size slide

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

    View full-size slide

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

    View full-size slide

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

    View full-size slide

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

    View full-size slide

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

    View full-size slide

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

    View full-size slide

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

    View full-size slide

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

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

    View full-size slide

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

    View full-size slide

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

    View full-size slide

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

    View full-size slide

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

    View full-size slide

  19. Service Mesh とは

    View full-size slide

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

    View full-size slide

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

    View full-size slide

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

    View full-size slide

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

    View full-size slide

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

    View full-size slide

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

    View full-size slide

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

    View full-size slide

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

    View full-size slide

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

    View full-size slide

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

    View full-size slide

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

    View full-size slide

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

    View full-size slide

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

    View full-size slide

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

    View full-size slide

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

    View full-size slide

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

    View full-size slide

  36. どこで実現するか
    • それぞれアプリケーション内で実装するのは厳し
    い。ではライブラリで提供する?
    • Polyglot との相性が悪い、実装毎の一貫性の問題
    • ライブラリのメンテナンスのためにアプリケーショ
    ンのデプロイが必要: 横断的チームがやるのはし
    んどい
    • このような関心事をアプリケーションから分離で
    きると良いのでは→ Out Of Process モデル

    View full-size slide

  37. Service Mesh To The Rescue

    View full-size slide

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

    View full-size slide

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

    View full-size slide

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

    View full-size slide

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

    View full-size slide

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

    View full-size slide

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

    View full-size slide

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

    View full-size slide

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

    View full-size slide

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

    View full-size 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 full-size slide

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

    View full-size slide

  49. 詳解 Envoy

    View full-size slide

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

    View full-size 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 full-size slide

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

    View full-size 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 full-size 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 full-size 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 full-size slide

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

    View full-size slide

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

    View full-size slide

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

    View full-size slide

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

    View full-size slide

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

    View full-size slide

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

    View full-size slide

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

    View full-size slide

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

    View full-size slide

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

    View full-size slide

  65. クックパッドでの 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 full-size slide

  66. 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 full-size slide

  67. Our Service Mesh

    View full-size slide

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

    View full-size slide

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

    View full-size slide

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

    View full-size slide

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

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

    View full-size slide

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

    View full-size slide

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

    View full-size slide

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

    View full-size slide

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

    View full-size slide

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

    View full-size slide

  77. Service Mesh
    便利

    View full-size slide

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

    View full-size slide

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

    View full-size slide