Upgrade to Pro
— share decks privately, control downloads, hide ads and more …
Speaker Deck
Features
Speaker Deck
PRO
Sign in
Sign up for free
Search
Search
builderscon Tokyo 2019: Intro Service Mesh
Search
taiki45
August 31, 2019
Technology
6
3k
builderscon Tokyo 2019: Intro Service Mesh
https://builderscon.io/builderscon/tokyo/2019/session/d6fc1b22-b1ed-490e-bb2d-7c9652d52beb
taiki45
August 31, 2019
Tweet
Share
More Decks by taiki45
See All by taiki45
RustでAWS Lambda functionをいい感じに書く
taiki45
1
250
SPIFFE Meetup Tokyo #2 LT: Envoy SDS
taiki45
0
570
NoOps Meetup Tokyo #7: 入門サービスメッシュ
taiki45
4
1.7k
CloudNative Days Tokyo 2019: Understanding Envoy
taiki45
3
3.2k
Cloud Native Meetup Tokyo #8 ServiceMesh Day Recap
taiki45
2
300
EnvoyCon 2018: Building and operating service mesh at mid-size company
taiki45
4
4.3k
Cookpad Tech Kitchen #20 クックパッドでのサービスメッシュについて
taiki45
1
2.2k
Building and operating service mesh at mid-size company
taiki45
2
2.2k
Observability, Service Mesh and Microservices
taiki45
25
6.2k
Other Decks in Technology
See All in Technology
Oracle Modern Data Platform Reference Architecture (Autonomous Data Warehouse編)
oracle4engineer
PRO
0
530
Cloud Nativeを支える要素技術・プロダクト・プラクティスの歩み / infrastudy-returns-01-amsy810
masayaaoyama
3
400
RAG構築におけるKendraとPineconeの使い分け
sonoda_mj
2
270
Lernen durch Schmerzen! Mit Reinforcement Learning selbstlernende Systeme entwickeln
joergneumann
0
220
Oracle Exadata Database Service:サービス概要のご紹介
oracle4engineer
PRO
0
8k
ビズリーチが目指す「開発生産性」ダッシュボード 〜 データ収集の壁と乗り越え方 〜 / dev-productivity-con2024
visional_engineering_and_design
14
7.4k
[Breizh Camp 2024] L’open-source n’est pas (déjà) mort
abrianceau
0
160
まずはパネル「Table」を使い倒してみよう@GrafanaMeetupJapan#2
rinchoku
1
300
プロダクト開発の落とし穴と改善したいマインド
maidol
2
200
作りすぎない技術 - API時代の開発努力の在り方について考える / Thinking about the state of development efforts in the API era
yokawasa
10
7.1k
新常識! Javascript×AWS Lambdaがアツい!!
watany
3
260
楽ありゃ苦もあるモノレポ化 / Goodness and Difficulties of Monorepo
henryofficial
2
930
Featured
See All Featured
Fontdeck: Realign not Redesign
paulrobertlloyd
78
5k
Designing with Data
zakiwarfel
96
4.9k
We Have a Design System, Now What?
morganepeng
45
6.9k
Robots, Beer and Maslow
schacon
PRO
155
8k
Learning to Love Humans: Emotional Interface Design
aarron
269
39k
RailsConf & Balkan Ruby 2019: The Past, Present, and Future of Rails at GitHub
eileencodes
128
32k
Visualization
eitanlees
137
14k
Unsuck your backbone
ammeep
664
57k
For a Future-Friendly Web
brad_frost
173
9.1k
Distributed Sagas: A Protocol for Coordinating Microservices
caitiem20
324
21k
The Illustrated Children's Guide to Kubernetes
chrisshort
36
47k
ReactJS: Keep Simple. Everything can be a component!
pedronauck
661
120k
Transcript
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 でも対応
None
None
Service Mesh Before Container