Successfully reported this slideshow.
We use your LinkedIn profile and activity data to personalize ads and to show you more relevant ads. You can change your ad preferences anytime.

Light and shadow of microservices

1,716 views

Published on

JTF2017 session presentation for "Light and shadow of microservices"

Published in: Technology
  • Be the first to comment

Light and shadow of microservices

  1. 1. [C50_3] マイクロサービスは甘くない! 運用してみて分かった「闇」と「対策」 2017年 8月 27日 レッドハット株式会社 テクニカルセールス本部 シニアソリューションアーキテクト 須江 信洋 (nosue@redhat.com)
  2. 2. 自己紹介 • 須江 信洋(すえ のぶひろ) – Mail: nosue@redhat.com – Twitter: @nobusue • 約14年JavaEE関連に携わる(1999〜2013) • Enterprise Mobile製品担当(2012〜2013) • IoTサービス関連ベンチャー 開発から運用まで (2014〜2017) – ストリーミングデータ処理 – マイクロサービス化 – コンテナプラットフォーム構築/運用 2
  3. 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. 4. サービスが小さく、自律 的であるため、素早く開 発してデリバリーできる サービスが小さいため、 デリバリーの自動化やモ ニタリングが容易 細かい粒度でスケーラビ リティを制御でき、リソー スの利用を最適化しやす い SCALABILITY マイクロサービスのいいところ FAST TIME TO MARKET EFFICIENCY 4
  5. 5. 例えばスケーラビリティ モノリシックなシステム Microservices アプリケーション単位でしか スケールアウトできない サービス単位で細かくリソース 調整可能 5
  6. 6. 参考までに・・・”What is Cloud Native?” 1. コンテナ化 – アプリケーションやプロセスなどがコンテナにパッケージングされていること。 これにより再現性、透過性、リソース分離が実現される。 2. 動的なオーケストレーション – コンテナはリソース利用効率が最適になるように、積極的に(再)配置される。 3. マイクロサービス指向 – アプリケーションはマイクロサービスに分割される。これによりアプリケーショ ン全体のアジリティとメンテナンス性が著しく向上する https://www.cncf.io/about/faq/ クラウドネィティブコンピューティングで利用するOSSスタックの前提 (Cloud Native Computing FoundationのFAQより) 6
  7. 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. 8. 問題 • システム構成が複雑 ü サービス追加やスケールアウトの手順が複雑 • スローダウンや停止などサービス障害への対応が困難 ü タイムアウトの発生頻度がどれくらいなら障害? ü 1サービス停止が連鎖的にシステム全体に波及 ü サービス障害原因の特定に時間がかかる • サービスレベル確保の難しさ ü リソースの利用状況の一元的な把握が困難 ü 複数サービスを経由したリクエスト・レスポンスの内訳を解析すること が困難 ü 流量制御とエラーハンドリングを見通しよく実装することが困難 8
  9. 9. マイクロサービスの課題 MyService Resilience Discovery Load Balancing Scaling / Elasticity Logging Monitoring Build, Deployment Pipeline Tracing Invocation Messaging / IPC API Authentication 9
  10. 10. マイクロサービスの課題 l 構築 Ø サービスの境界 / 粒度 Ø ビルド / デプロイの効率化 Ø サービス間連携 (サービスディスカバリ、オーケストレーション、コレオグラフィー) Ø テスト (サービス単位 / エンドツーエンド) Ø 自律的な回復 l 運用 Ø サービスの健全性の管理 / 監視 Ø サービス障害対応 (ログ集中管理、トレーサビリティ ) Ø サービス間の依存関係の管理 (バージョニング、データマイグレーション) Ø パフォーマンス管理 / リソース管理 Ø API管理 (特に外部公開用) l セキュリティ Ø 分散環境での認証 / 認可 Ø 暗号化 Ø 監査 10
  11. 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. 12. Circuit Breaker (eg: Hysterix) l サービス障害の連鎖を阻止するための仕組み Ø タイムアウト発生回数がしきい値を超えたら切断 Ø 同時リクエスト回数制限/キューイングやモニタリングも 12 https://martinfowler.com/bliki/CircuitBreaker.html 可視化
  13. 13. Distributed Trace (eg: Zipkin) l サービス横断でレスポンスの内訳(レイテンシ等)を追跡可能に Ø リクエストにIDを付与してサービス呼び出しの履歴を記録 13
  14. 14. マイクロサービス課題への対応: サービスメッシュ l マイクロサービス間の連携を透過的に扱うためのレイヤーを提供 Ø HTTPやgRPCなどの低レイヤーの通信を隠蔽(タイムアウト、リトライ等) Ø サービスディスカバリとルーティング、トラフィック制御 Ø サービス障害の影響を最小化 (例: circuit breaker) Ø サービス間認証/認可、暗号化 Ø サービス全体のモニタリングとレポーティング l Kubernetes(コンテナ基盤)上の新たな「ミドルウェア」 Ø Istio (https://istio.io/) Ø linkerd (https://linkerd.io/) 14
  15. 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. 16. Istioの適用イメージ on Kubernetes 16 マイクロサービスで構成された アプリケーション マイクロサービスをサービスメッシュで 連携したアプリケーション(Istioの例) source: https://istio.io/docs/samples/bookinfo.html
  17. 17. CNCF(Cloud Native Computing Foundation) 17 https://www.cncf.io/
  18. 18. まとめ • マイクロサービス化の流れは止められない ü Cloud Native時代にはコンテナとマイクロサービスが当たり前 ü Polyglot対応など技術的リスク分散の側面もあり • マイクロサービスの運用管理は簡単ではない ü 本質的には「超分散システム」 ü 順調に動いていればよいが、問題が起こったときの対応や、問題の防止、 問題の兆候を把握する仕組みを考えておくべき • サービスメッシュ: マイクロサービスに対応した新たなミドルウェア ü 運用管理の課題の大部分を解決できる可能性あり ü コンテナ界隈での最重要プロダクト ü CNCFの動向は要チェック 18
  19. 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. 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. 21. Thank you

×