Light and shadow of microservices

[C50_3]

マイクロサービスは甘くない！運用してみて分かった「闇」と「対策」

2017年 8月 27日

レッドハット株式会社 テクニカルセールス本部

シニアソリューションアーキテクト

須江 信洋 (nosue@redhat.com)

自己紹介• 須江 信洋（すえ のぶひろ）

– Mail:nosue@redhat.com– 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