Upgrade to Pro
— share decks privately, control downloads, hide ads and more …
Speaker Deck
Speaker Deck
PRO
Sign in
Sign up
for free
builderscon Tokyo 2019: Intro Service Mesh
taiki45
August 31, 2019
Technology
6
1.6k
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
taiki45
0
240
taiki45
4
1.3k
taiki45
3
2.4k
taiki45
2
260
taiki45
4
3.9k
taiki45
1
1.6k
taiki45
3
1.7k
taiki45
24
5.2k
taiki45
1
360
Other Decks in Technology
See All in Technology
hmatsu47
2
140
yashi8484
0
130
ihcomega56
2
820
kaga
0
230
kawanamiyuu
4
730
legalforce
PRO
0
160
charity
9
12k
nnstt1
2
120
hmatsu47
1
170
kema1015
0
560
am7cinnamon
1
300
ishiayaya
PRO
0
830
Featured
See All Featured
iamctodd
22
2.2k
jonyablonski
21
1.3k
marcelosomers
221
15k
paulrobertlloyd
73
1.5k
paulrobertlloyd
71
3.7k
malarkey
193
8.7k
smashingmag
283
47k
tenderlove
54
3.5k
jakevdp
776
200k
holman
288
130k
brad_frost
157
6.5k
skipperchong
8
780
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