Taiki Ono builderscon Tokyo 2019 入門サービスメッシュ

Agenda ● 業界がサービスメッシュに至るまでの変遷 ○ Microservices での課題 ○ ライブラリアプローチの限界 ○ サービスメッシュの登場 ● サービスメッシュのプロダクション事例の紹介 ○ Extending SmartStack ○ Hybrid workloads with containers and VMs ○ Incremental adaptation to Istio ● サービスメッシュ選球眼 2

Service Mesh Before Container

Service Mesh Before Container

Service Mesh Before

Microservices 界での当時の状況 ● 開発のスケーラビリティ向上のために分散化し複雑になるシステム構成 ○ 多数の小さいチームでそれぞれが小さいアプリケーションを開発 -> マイクロサービス ○ クラウド技術を使うことでより動的なデプロイ構成を可能にする -> クラウドネイティブ ● 今までのツールでは対応できない運用課題が増加 ○ 柔軟で性能が良い traffic control, load balancing ○ Observability ○ Failure recovery, fault isolation ○ サービス認証/access control, End-to-End でセキュアな通信 ● Finagle に代表されるライブラリアプローチの興隆 ○ 実装の一貫性の問題 ○ アップグレードが高コスト・要コミュニケーション 6

歴史 ● 2011年8月 Finagle public release ● 2013年10月 SmartStack public release ● 2014年11月 Prana public release ● 2016年2月 Linkerd public release ○ 2017年4月 Linkerd v1.0 public release ○ 2018年9月 Linkerd v2 pubic release ● 2016年9月 Envoy public release ● 2017年5月 Istio public release 7

Upstreams Architecture of SmartStack proxy app Upstreams Nerve Synapse DB Upstreams routing

https://medium.com/netflix-techblog/prana-a-sidecar-for-your-netflix-paas-based-applications-and-services-258a5790a015

Concept of Service Mesh proxy app Control plane Upstreams proxy Upstreams proxy Service Entries TSDB routing, failure recv, en-decryption etc.

世のサービスメッシュ実装 ● Proxy=Envoy ○ Control plane 自作勢 ○ Istio ○ マネージドサービス: Traffic Director, App Mesh, etc. ○ Consul ● Linkerd v2 ● Nginx based ● ...

Use cases 1: Extending SmartStack

EnvoyCon 2018 / How to DDOS yourself with Envoy: https://sched.co/HDbQ

EnvoyCon 2018 / How to DDOS yourself with Envoy: https://sched.co/HDbQ

EnvoyCon 2018 / How to DDOS yourself with Envoy: https://sched.co/HDbQ

Use cases 2: Containers/VMs hybrid workload

EnvoyCon 2018 / Building + Operating Service Mesh: https://sched.co/HDdu

Hybrid workload with VMs ● VM ベースの構成からコンテナベースの構成へマイグレーションする時とか にも利用できる ○ あるいは on-prems から public cloud へのマイグレーション ○ Legacy は少しづつ地道に modern にしていくしかない ● 既存のサービスメッシュ実装のみではまだ難しい分野 ○ 要素技術を組み合わせていく必要がある ○ エンタープライズ向けに製品を開発している会社もでてきている 18

Use cases 3: Incremental adaptation to Istio

Google Cloud Next ’19 in Tokyo / D2-4-S07: https://cloud.withgoogle.com/next/tokyo/sessions?session=D2-4-S07

https://medium.com/@vbanthia/adopting-istio-for-a-multi-tenant-kubernetes-cluster-in-producti on-df1a8260ca24

サービスメッシュ選球眼 ● 自分たちの規模を見据える ○ 大規模になるなら開発・運用の分散化が重要になってくる ○ 高度に分散化した環境では通信層での”仕事”は必須に近い ● 自分たちの環境を分析してソフトウェアを選ぶ ○ Brown field か green field か ● いつかは念じたらビジネスロジックが動く時代が来るかもしれない ○ 念じたらどこかのコンピューター群で自分たちのビジネスロジックが動き、相互にやりとり する、そんなランタイムもサービスメッシュも統合されたようなプラットフォームができそ う -> Serverless ○ それまでの繋ぎ、過渡期かもしれない

まとめ Q&A ● サービスメッシュは Microservices での課題を解決する ○ そもそも解決したい問題がかなり advanced ○ 自分たちの問題に合わせて少しずつ利用する ○ いつかフルマネージドになるのでそれまで待つのも手 ● サービスメッシュはいろんな環境で多様に利用できる ○ “Service Mesh is not for Kubernetes only” ○ ただし VM/コンテナ の共用構成やマルチクラウド・ハイブリッドクラウドな構成では*まだ* 既存の製品は使えないことがほとんどなのと事例も少ないのでがんばりが必要 Q&A: @taiki45 でも対応

No content

No content

Service Mesh Before Container