Observability, Service Mesh and Microservices

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

Clikcable link version: https://www.slideshare.net/TaikiOno/observability-service-mesh-and-microservices

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