light and shadow of microservices
TRANSCRIPT
[C50_3]
マイクロサービスは甘くない!運用してみて分かった「闇」と「対策」
2017年 8月 27日
レッドハット株式会社 テクニカルセールス本部
シニアソリューションアーキテクト
須江 信洋 ([email protected])
自己紹介• 須江 信洋(すえ のぶひろ)
– Mail:[email protected]– Twitter:@nobusue
• 約14年JavaEE関連に携わる(1999〜2013)• EnterpriseMobile製品担当(2012〜2013)• IoTサービス関連ベンチャー 開発から運用まで
(2014〜2017)– ストリーミングデータ処理
– マイクロサービス化
– コンテナプラットフォーム構築/運用
2
3
My Career
Apr‘99
Dec‘02
HP JapanIT Consultant
Future SystemConsultant
Apr‘04
BEA SystemsPresales
Jan‘07
IBM JapanPresales
Aug‘13
freelanceArchitect
Jul‘14
Venture(IoT PF)Chief Architect
Apr‘17
Red HatSol. Architect
JavaEE
JavaEE
JavaEE
JavaEE Mobile
JavaEE
IoT
BigData
DevOps
Container
ML
DevOps
Delivery Presales DevOps Presales
DevOpsContainer
サービスが小さく、自律的であるため、素早く開発してデリバリーできる
サービスが小さいため、デリバリーの自動化やモ
ニタリングが容易
細かい粒度でスケーラビリティを制御でき、リソースの利用を最適化しやす
い
SCALABILITY
マイクロサービスのいいところ
FAST TIME TO MARKET EFFICIENCY
4
例えばスケーラビリティ
モノリシックなシステム
Microservicesアプリケーション単位でしか
スケールアウトできない
サービス単位で細かくリソース調整可能
5
参考までに・・・”What is Cloud Native?”
1. コンテナ化
– アプリケーションやプロセスなどがコンテナにパッケージングされていること。これにより再現性、透過性、リソース分離が実現される。
2. 動的なオーケストレーション
– コンテナはリソース利用効率が最適になるように、積極的に(再)配置される。
3. マイクロサービス指向
– アプリケーションはマイクロサービスに分割される。これによりアプリケーション全体のアジリティとメンテナンス性が著しく向上する
https://www.cncf.io/about/faq/
クラウドネィティブコンピューティングで利用するOSSスタックの前提
(Cloud Native Computing FoundationのFAQより)
6
実際にやってみた
7
Proxy(Nginx)
LBInternet
Proxy(Nginx)
認証Svc
認証Svc
QueryAPI
CacheSvc
MongoSvc
CassandraSvc
Mongo
Cassandra
QueryAPI
CacheSvc
MongoSvc
CassandraSvc
MongoMongo
CassandraCassandra
外部Svc
問題• システム構成が複雑
ü サービス追加やスケールアウトの手順が複雑
• スローダウンや停止などサービス障害への対応が困難
ü タイムアウトの発生頻度がどれくらいなら障害?ü 1サービス停止が連鎖的にシステム全体に波及
ü サービス障害原因の特定に時間がかかる
• サービスレベル確保の難しさ
ü リソースの利用状況の一元的な把握が困難
ü 複数サービスを経由したリクエスト・レスポンスの内訳を解析することが困難
ü 流量制御とエラーハンドリングを見通しよく実装することが困難
8
マイクロサービスの課題
MyService
Resilience
Discovery
Load BalancingScaling / Elasticity
Logging
Monitoring
Build,Deployment
PipelineTracing
InvocationMessaging /
IPC
API Authentication
9
マイクロサービスの課題
l 構築
Ø サービスの境界 / 粒度Ø ビルド / デプロイの効率化Ø サービス間連携 (サービスディスカバリ、オーケストレーション、コレオグラフィー)Ø テスト (サービス単位 / エンドツーエンド)Ø 自律的な回復
l 運用
Ø サービスの健全性の管理 / 監視Ø サービス障害対応 (ログ集中管理、トレーサビリティ )Ø サービス間の依存関係の管理 (バージョニング、データマイグレーション)Ø パフォーマンス管理 / リソース管理Ø API管理 (特に外部公開用)
l セキュリティ
Ø 分散環境での認証 / 認可Ø 暗号化Ø 監査
10
マイクロサービスの課題: 解決策の変遷
11
Netflix世代 コンテナ勃興期 CNCF(*1)世代
ルーティング Zulu Finangle linkerd / Istio
サービスディスカバリ Eureka ZooKeeper / Consul linkerd / Istio
ロードバランス Ribbon Finangle / gRPC linkerd / Istio
流量制御/リトライ/サーキットブレーキング
Hysterix Hysterix linkerd / Istio
認証認可/暗号化 - - linkerd / Istio
トレース - Zipkin OpenTracing
メトリクス JMX(Jolokia) cAdvisor Prometeus / Haukular
ロギング - Fluentd Fluentd
備考 JVM主体 多言語化 Docker/Kubernetes主体
(*1)CloudNativeComputingFoundationhttps://www.cncf.io/
Circuit Breaker (eg: Hysterix)l サービス障害の連鎖を阻止するための仕組み
Ø タイムアウト発生回数がしきい値を超えたら切断Ø 同時リクエスト回数制限/キューイングやモニタリングも
12 https://martinfowler.com/bliki/CircuitBreaker.html
可視化
Distributed Trace (eg: Zipkin)l サービス横断でレスポンスの内訳(レイテンシ等)を追跡可能に
Ø リクエストにIDを付与してサービス呼び出しの履歴を記録
13
マイクロサービス課題への対応: サービスメッシュ
l マイクロサービス間の連携を透過的に扱うためのレイヤーを提供Ø HTTPやgRPCなどの低レイヤーの通信を隠蔽(タイムアウト、リトライ等)Ø サービスディスカバリとルーティング、トラフィック制御Ø サービス障害の影響を最小化 (例: circuit breaker)Ø サービス間認証/認可、暗号化Ø サービス全体のモニタリングとレポーティング
l Kubernetes(コンテナ基盤)上の新たな「ミドルウェア」Ø Istio (https://istio.io/)Ø linkerd (https://linkerd.io/)
14
Istio / linkerdに至る歴史
15
Finangle linkerd
Envoy Istio
2010〜 byTwitterLibraryforJVM
2016〜 byBuoyant=>CNCFServiceMesh(JVMbasedStandaloneProxy)
2016〜 byLyftStandaloneProxy(C++based)
2017〜 byLyft/Google/IBMServiceMesh(Envoycore)
https://linkerd.io/
https://lyft.github.io/envoy/ https://istio.io/
https://twitter.github.io/finagle/
Istioの適用イメージ on Kubernetes
16
マイクロサービスで構成されたアプリケーション
マイクロサービスをサービスメッシュで連携したアプリケーション(Istioの例)
source:https://istio.io/docs/samples/bookinfo.html
CNCF(Cloud Native Computing Foundation)
17
https://www.cncf.io/
まとめ• マイクロサービス化の流れは止められない
ü Cloud Native時代にはコンテナとマイクロサービスが当たり前
ü Polyglot対応など技術的リスク分散の側面もあり
• マイクロサービスの運用管理は簡単ではない
ü 本質的には「超分散システム」
ü 順調に動いていればよいが、問題が起こったときの対応や、問題の防止、問題の兆候を把握する仕組みを考えておくべき
• サービスメッシュ: マイクロサービスに対応した新たなミドルウェア
ü 運用管理の課題の大部分を解決できる可能性あり
ü コンテナ界隈での最重要プロダクト
ü CNCFの動向は要チェック
18
参考) Envoy(Istio)によるマイクロサービスパターン
l Kubernetes(OpenShift)の"Sidecar Proxy"を利用したマイクロサービスデザインパターンの紹介Ø "Microservices Patterns with Envoy Sidecar Proxy, Part I: Circuit
Breaking"https://blog.openshift.com/microservices-patterns-envoy-part-i/
Ø "Microservices Patterns with Envoy Proxy, Part II: Timeouts and Retries"https://blog.openshift.com/microservices-patterns-envoy-proxy-part-ii-timeouts-retries/
Ø "Microservices Patterns With Envoy Proxy, Part III: Distributed Tracing"https://blog.openshift.com/microservices-patterns-envoy-proxy-part-iii/
19
参考) SpringBootマイクロサービス on OpenShiftのリファレンスアーキテクチャ
l OpenShift(Kubernetes)上でSpringBootベースのマイクロサービスを実装するためのリファレンスアーキテクチャとサンプルコードを提供Ø Netflix OSSを中心とした、比較的な保守的なテクノロジスタックを採
用しており、今すぐ使いたいという用途には最適Ø 最新動向については比較検討のための情報のみ提供
l "Spring Boot Microservices on Red Hat OpenShift Container Platform 3"Ø https://access.redhat.com/articles/3155471
20
Thank you