Download as PDF, PPTX
![[Cloud OnAir] Anthos で実現する ハイブリッドクラウド 〜 Cloud Service Mesh 編 〜 2019年9月5日 放送](https://cdn.slidesharecdn.com/ss_thumbnails/2-190905101410-thumbnail.jpg?width=640&height=640&fit=bounds)
Draft: Observability, Service Mesh and Microservices
- 1. Observability, Service Mesh and Microservices TaikiOno Software Engineer Cookpad Inc.
- 2.
- 3.
- 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.
- 16. Pros of マイクロサービス •小さなチームへの責任と権限の委譲 • 頻繁なトライアンドエラー • 高速かつ高精度な意思決定のサポート
- 17. Cons of マイクロサービス •アプリケーションはシンプルになるが システム全体として複雑になる • 個々のアプリケーションの開発は楽に なるがシステム全体の運用がめっちゃ 難しくなる
- 18.
- 19. • クックパッドも昔は必要なかったが、大きくなる につれ自然とマイクロサービスへと進んでいった • マイクロサービスと名前がつく前から同じことを していた組織は多い •マイクロサービスはもちろん not 銀の弾丸、デ メリットもある • 技術的課題をやっつけてなるべくメリットを享受 するぞ！
- 20.
- 21. 技術的課題と Service Mesh •分散アーキテクチャの難しさ→倒してメリットを享受 するぞ！ ‣ 技術的課題の変遷を簡単に紹介 • Service mesh とは ‣ 特に中核の Envoy proxy について ‣ もしかしたら Istio について聞いたことがあるかも？ そこ ら辺の話 • 将来マネージドサービスが出た時に役に立つ話かも？
- 22. Service Mesh という言葉 •ちょくちょく周りでも聞くようになっ た気がする • もちろん聞いたことなくて全然OK、 これから話します
- 23.
- 24.
- 25.
- 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.
- 33. 技術的課題の変遷 • 1つ1つのアプリケーションはシンプルになる が、システム全体としての複雑性は上がる: 運 用の複雑性の増加 ‣たくさんのアプリケーションを動かすのは技術 的に解決されつつある ‣ たくさんのアプリケーションをうまく繋げるこ とに課題がシフトしつつある • どうやったらもっとうまく運用できるだろうか
- 34. Observability Engineering • Twitter社のエンジニア発の概念。Dapper 等、Google 内部での知見が発端っぽい • 分散システムをうまく運用するためにシス テムの繋がりの部分の挙動に注目して可視 化・監視する • 取得すべき値や集約・ストレージの設計等 がスコープ
- 35. • システム全体はどんな姿で、どのように動いているのか ‣サービス境界でなにが起こっているか: RPS,status, リト ライ・タイムアウト・サーキットブレーカの発動 ‣あるリクエストを処理したサービスがどれで、その処理結 果がどうだったのか: 分散トレーシング • これらを加入したての開発者でも素早く把握できること に価値がある • また効率的にシステム障害の解決したり、キャパシティ プランニングするのに必要
- 36. オーナーシップ問題再び • プロダクト開発者は基本的には自分たちのプロ ダクト・サービスに責任を持っている: 責任の 分離 •しかしシステム全体は協調して動作させる必要 があるので組織横断的なチームが必要: SRE 等 • 横断的なチームがアプリケーションの細部を把 握しなくてもシステム全体の動作を理解できる 必要がある → 中央で管理する必要性
- 37. どこで実現するか • それぞれアプリケーション内で実装するのは厳し い。ではライブラリで提供する？ • Polyglotとの相性が悪い、実装毎の一貫性の問題 • ライブラリのメンテナンスのためにアプリケーショ ンのデプロイが必要: 横断的チームがやるのはし んどい • このような関心事をアプリケーションから分離で きると良いのでは→ Out Of Process モデル
- 38. Service Mesh ToThe Rescue
- 39. Service Mesh とは •アプリケーションに代わりネットワーク層の仕事 をする ‣ メトリクス取得/送信、リトライ等の実行、分散ト レーシング用のログの送信、service discovery, load balancing 等も行う • 2つのコンポーネントで構成される ‣ data-plane: proxy として上記タスクを行う ‣ control-plane: 各 proxy の挙動を管理する
- 40.
- 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 Linkerdat Cookpad • no VM vs JVM ‣ less resource usage ‣ hot restart • 豊富な設定、xDS API による更新 • h2, gRPC support が not experimental • Istio での採用状況: community の厚さ
- 49. C++? • 実は modernC++ は言うほど読みにくくない、syntax 的にむしろ読みやすい方 • 実は modern C++ は言うほど書きにくくない、覚えるこ とはわりとあるが step by step でパッチを書ける • 各種ツールが優秀: clang-tidy, AddressSanitizer, ThreadSanitizer... • あくまでアプリケーションを読み書きする上では。ライ ブラリはわからない • Envoy コミュニティのレビュー層が厚い
- 50.
- 51. What’s Envoy • Servicemesh 用 data-plane proxy • Edge proxy: TLS termination, routing, load balancing • gRPC サポート • 受付システムの Envoy と名前被りして るので ”Envoy proxy” でググる
- 52. • hot reload/hotrestart のサポート • 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.0release 🎉 https://twitter.com/taiki45/status/976317282870689792
- 54. Getting started • maincode: 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-planeAPI とも呼ばれている • Envoy 内の情報を更新するための API spec ‣ LDS: Listener Discovery Service ‣ CDS: Cluster Discovery Service ‣ EDS: Endpoint Discovery Service ‣ RDS: Route Discovery Service ‣ その他…
- 57.
- 58.
- 59.
- 60. stats の送信/保存 • statsdsink -> relay -> DB • dog_statsd sink -> statsd_exporter <- Prometheus • admin /stats <- Envoy listener/filter <- Prometheus • クックパッドは2個目のやつ採用(というか 自分たちで使うから作った)
- 61. gRPC support • gRPChealth 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.
- 70. 中央のリポジトリで管理する理由 • 変更履歴を理由付きで管理しておきた い: Gitが適任 • サービスを繋ぐ設定変更を横断的な チームがレビューできるようにした い: GitHub が適任
- 71. • これで servicediscovery, retry/ timeout/circuit breaking が実現
- 72. Envoy stats onGrafana • サービス毎、特定のサービス×サービス ‣ 各 upstream 毎の RPS/status/latency などなど ‣ retry/timeout/circuit-breaker の発動 状況 • 各 Envoy の状況
- 74. Service Mesh の現状 •メトリクスの可視化ができている • retry/timeout/circuit-breaker をアプリケーショ ンの外で実現できている ‣ その設定値が GHE 上で管理されていて変更履歴が追え る ‣ その設定値をアプリケーションとは別にレビューできる • 余談: gRPC 用の client-side load balancing on ECS も service mesh があったのでサクッとできた
- 75.
- 76. さらなる可視化 • 収集・表示するメトリクスを増やす ‣ gRPCサービスの手前に Envoy を置いてアク セスログ収集等も ‣ 運用していく過程でほしくなったメトリクス • promviz を使った可視化 • 社内のコンソールソフトウェアとの統合
- 77.
- 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.
- 83.
- 85. 今回のお話 • なぜマイクロサービスに挑戦しているのか ‣ 時間の都合上カット、資料に掲載 •「service mesh とは」について背景やメ リットなど普遍的な話 • クックパッドでの事例紹介: Envoy + 自作 control-plane