JTF2017 session presentation for "Light and shadow of microservices"

1. [C50_3]
マイクロサービスは甘くない！
運用してみて分かった「闇」と「対策」
2017年 8月 27日
レッドハット株式会社 テクニカルセールス本部
シニアソリューションアーキテクト
須江 信洋 (nosue@redhat.com)

2. 自己紹介
• 須江 信洋（すえ のぶひろ）
– Mail: nosue@redhat.com
– Twitter: @nobusue
• 約14年JavaEE関連に携わる(1999〜2013)
• Enterprise Mobile製品担当(2012〜2013)
• IoTサービス関連ベンチャー 開発から運用まで
(2014〜2017)
– ストリーミングデータ処理
– マイクロサービス化
– コンテナプラットフォーム構築/運用
2

3. 3
My Career
Apr
‘99
Dec
‘02
HP Japan
IT Consultant
Future System
Consultant
Apr
‘04
BEA Systems
Presales
Jan
‘07
IBM Japan
Presales
Aug
‘13
freelance
Architect
Jul
‘14
Venture(IoT PF)
Chief Architect
Apr
‘17
Red Hat
Sol. Architect
JavaEE
JavaEE
JavaEE
JavaEE Mobile
JavaEE
IoT
BigData
DevOps
Container
ML
DevOps
Delivery Presales DevOps Presales
DevOpsContainer

4. サービスが小さく、自律
的であるため、素早く開
発してデリバリーできる
サービスが小さいため、
デリバリーの自動化やモ
ニタリングが容易
細かい粒度でスケーラビ
リティを制御でき、リソー
スの利用を最適化しやす
い
SCALABILITY
マイクロサービスのいいところ
FAST TIME TO MARKET EFFICIENCY
4

5. 例えばスケーラビリティ
モノリシックなシステム
Microservices
アプリケーション単位でしか
スケールアウトできない
サービス単位で細かくリソース
調整可能
5

6. 参考までに・・・”What is Cloud Native?”
1. コンテナ化
– アプリケーションやプロセスなどがコンテナにパッケージングされていること。
これにより再現性、透過性、リソース分離が実現される。
2. 動的なオーケストレーション
– コンテナはリソース利用効率が最適になるように、積極的に(再)配置される。
3. マイクロサービス指向
– アプリケーションはマイクロサービスに分割される。これによりアプリケーショ
ン全体のアジリティとメンテナンス性が著しく向上する
https://www.cncf.io/about/faq/
クラウドネィティブコンピューティングで利用するOSSスタックの前提
(Cloud Native Computing FoundationのFAQより)
6

7. 実際にやってみた
7
Proxy
(Nginx)
LB
Internet
Proxy
(Nginx)
認証
Svc
認証
Svc
Query
API
Cache
Svc
Mongo
Svc
Cassandra
Svc
Mongo
Cassandra
Query
API
Cache
Svc
Mongo
Svc
Cassandra
Svc
Mongo
Mongo
Cassandra
Cassandra
外部
Svc

8. 問題
• システム構成が複雑
ü サービス追加やスケールアウトの手順が複雑
• スローダウンや停止などサービス障害への対応が困難
ü タイムアウトの発生頻度がどれくらいなら障害?
ü 1サービス停止が連鎖的にシステム全体に波及
ü サービス障害原因の特定に時間がかかる
• サービスレベル確保の難しさ
ü リソースの利用状況の一元的な把握が困難
ü 複数サービスを経由したリクエスト・レスポンスの内訳を解析すること
が困難
ü 流量制御とエラーハンドリングを見通しよく実装することが困難
8

9. マイクロサービスの課題
MyService
Resilience
Discovery
Load
Balancing
Scaling /
Elasticity
Logging
Monitoring
Build,
Deployment
Pipeline
Tracing
Invocation
Messaging /
IPC
API Authentication
9

10. マイクロサービスの課題
l 構築
Ø サービスの境界 / 粒度
Ø ビルド / デプロイの効率化
Ø サービス間連携 (サービスディスカバリ、オーケストレーション、コレオグラフィー)
Ø テスト (サービス単位 / エンドツーエンド)
Ø 自律的な回復
l 運用
Ø サービスの健全性の管理 / 監視
Ø サービス障害対応 (ログ集中管理、トレーサビリティ )
Ø サービス間の依存関係の管理 (バージョニング、データマイグレーション)
Ø パフォーマンス管理 / リソース管理
Ø API管理 (特に外部公開用)
l セキュリティ
Ø 分散環境での認証 / 認可
Ø 暗号化
Ø 監査
10

11. マイクロサービスの課題: 解決策の変遷
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) Cloud Native Computing Foundation https://www.cncf.io/

12. Circuit Breaker (eg: Hysterix)
l サービス障害の連鎖を阻止するための仕組み
Ø タイムアウト発生回数がしきい値を超えたら切断
Ø 同時リクエスト回数制限/キューイングやモニタリングも
12 https://martinfowler.com/bliki/CircuitBreaker.html
可視化

13. Distributed Trace (eg: Zipkin)
l サービス横断でレスポンスの内訳(レイテンシ等)を追跡可能に
Ø リクエストにIDを付与してサービス呼び出しの履歴を記録
13

14. マイクロサービス課題への対応: サービスメッシュ
l マイクロサービス間の連携を透過的に扱うためのレイヤーを提供
Ø HTTPやgRPCなどの低レイヤーの通信を隠蔽(タイムアウト、リトライ等)
Ø サービスディスカバリとルーティング、トラフィック制御
Ø サービス障害の影響を最小化 (例: circuit breaker)
Ø サービス間認証/認可、暗号化
Ø サービス全体のモニタリングとレポーティング
l Kubernetes(コンテナ基盤)上の新たな「ミドルウェア」
Ø Istio (https://istio.io/)
Ø linkerd (https://linkerd.io/)
14

15. Istio / linkerdに至る歴史
15
Finangle linkerd
Envoy Istio
2010〜 by Twitter
Library for JVM
2016〜 by Buoyant =>CNCF
Service Mesh (JVM based Standalone Proxy)
2016〜 by Lyft
Standalone Proxy (C++ based)
2017〜 by Lyft/Google/IBM
Service Mesh (Envoy core)
https://linkerd.io/
https://lyft.github.io/envoy/ https://istio.io/
https://twitter.github.io/finagle/

16. Istioの適用イメージ on Kubernetes
16
マイクロサービスで構成された
アプリケーション
マイクロサービスをサービスメッシュで
連携したアプリケーション(Istioの例)
source: https://istio.io/docs/samples/bookinfo.html

17. CNCF(Cloud Native Computing Foundation)
17
https://www.cncf.io/

18. まとめ
• マイクロサービス化の流れは止められない
ü Cloud Native時代にはコンテナとマイクロサービスが当たり前
ü Polyglot対応など技術的リスク分散の側面もあり
• マイクロサービスの運用管理は簡単ではない
ü 本質的には「超分散システム」
ü 順調に動いていればよいが、問題が起こったときの対応や、問題の防止、
問題の兆候を把握する仕組みを考えておくべき
• サービスメッシュ: マイクロサービスに対応した新たなミドルウェア
ü 運用管理の課題の大部分を解決できる可能性あり
ü コンテナ界隈での最重要プロダクト
ü CNCFの動向は要チェック
18

19. 参考) 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

20. 参考) 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
2
0

21. Thank you