[Cloud OnAir] Google Cloud で実践するマイクロサービスアーキテクチャ 2019年2月21日 放送
•
5 likes•6,529 views
近年注目を集める「マイクロサービスアーキテクチャ」を GKE や Isito など Google Cloud のサービスを使ってどのように作るのか、実践的な方法をご紹介します。
Recommended
Recommended
More Related Content
What's hot
What's hot (20)
Similar to [Cloud OnAir] Google Cloud で実践するマイクロサービスアーキテクチャ 2019年2月21日 放送
Similar to [Cloud OnAir] Google Cloud で実践するマイクロサービスアーキテクチャ 2019年2月21日 放送 (20)
More from Google Cloud Platform - Japan
More from Google Cloud Platform - Japan (20)
Recently uploaded
Recently uploaded (8)
[Cloud OnAir] Google Cloud で実践するマイクロサービスアーキテクチャ 2019年2月21日 放送
- 1. Cloud Onr Cloud OnAir Cloud OnAir 2019 年 2 月 21 日 放送 Google Cloud で実践する マイクロサービス アーキテクチャ
- 4. Cloud OnAir アプリケーションの 3 層アーキテクチャ フロントエンド (User Interface) バックエンド (Business Logic) データベース 実装パターン 1：フロントエンドとバックエンドが 1 つのコードベース 実装パターン 2：3 層がそれぞれ別のコードベース / 実行可能ユニット 実装パターン 3：3 層が全て同じコードベース / 実行可能ユニット リクエスト
- 5. Cloud OnAir モノリシックなアプリケーション例 ● 複数の機能が全て 1 つのプロセスとして動作 ● 大きなコードベース host Database app html service A service B mvcjs
- 6. Cloud OnAir モノリシックなアプリケーションへの機能追加が続くと 1. 運用作業負担増 2. コードベースの複雑さ増（開発者のラーニングコスト増） 3. ビルド、テストにかかる時間増 4. スケーリングに限界 変更容易性が低くなり、 新機能をタイムリーにリリースできない（時間がかかる） 事業の成長に合わせたシステムがスケール出来ずボトルネックに
- 7. Cloud OnAir スケーリングの限界 ホストリソース (CPU / RAM) の増強 垂直スケーリング 水平スケーリング ホストの台数を増やす app html service A service B mvcjs app html service A service B mvcjsapp html service A service B mvcjsapp html service A service B mvcjs
- 8. Cloud OnAir app app app マイクロサービスとは Thoughtworks 社の James Lewis 氏と Martin Fowler 氏が 2014 年に提唱 ● 機能毎に独立したアプリケーション （サービス）に分割 ● 各サービスは単一の目的をもつ ● 分散システム、サービス間は疎結合、 軽量な API などでやり取り service A service B service C app UI app UI
- 9. Cloud OnAir マイクロサービス化により得るもの 1. 機能追加が容易に 2. 可用性・耐障害性向上 3. スケールアウトが容易に 4. 新技術の導入がしやすい 5. DevOps / Agile との親和性 新機能をタイムリーに高速にリリースすることが可能に 事業の成長に合わせシステムも柔軟にスケール
- 10. Cloud OnAir マイクロサービス化の課題 (システム面） 1. サービスディスカバリー 2. オートスケーリング 3. トラフィックコントロール 4. Fault Isolation (障害の分離） 5. Observability (可観測性) 6. サービス間の認証・認可 マイクロサービスを実現するためには、 上記を解決するインフラストラクチャが必要となる
- 13. Cloud OnAir GCP でアプリケーションを動かす場合の選択肢 Compute Engine App Engine (Standard) Kubernetes Engine IaaS PaaS 仮想マシンを 提供 Web アプリ基盤を 提供 Kubernetes 環境を 提供 既存のシステムや 既存の運用を踏襲 コンテナ化された アプリケーション向け ランタイム制約なし Web アプリや API 向け ランタイム制約あり CaaS
- 15. Cloud OnAir Kubernetes OSS のコンテナオーケストレーションシステム Google 内部で使われている Borg を参考に開発された オンプレでもクラウドでも運用可能 主な特徴 ● 複数のコンテナに対する管理機構 ● manifest による宣言的な定義/管理 ● コンテナのオートスケーリング ● ローリングアップデート・自己修復
- 16. Cloud OnAir Google Kubernetes Engine (a.k.a GKE) ● Kubernetes のマネージドサービス ● マスターノードの管理は全て Google が行う ● GCP の各種サービスとのインテグレーション ○ Network services (HTTP(S) LB, NW LB) ○ CI / CD (Cloud Build) ○ Logging / Monitoring (Stackdriver)
- 17. Cloud OnAir GKE のアーキテクチャ Master SLA 付きのフルマネージド Google 管理のプロジェクトで動作 課金対象外 Auto-Everything 任意で選択可能 $gcloud $kubectl Node pool Nodes Node pool Nodes Node pool Nodes
- 18. Cloud OnAir Node の OS は Container-Optimized OS (COS) もしくは Ubuntu が選択可能 Node Pool は 1 つのクラスタ内で同じ 構成を持ったノードのサブセット よくある構成 ● ステートフルなアプリ向けの Node pool ● バッチジョブはプリエンプティブルVM の Node pool で Node と Node Pool Master 1 CPU 3.75 GB RAM 1 Nvidia V100 GPU 16 CPU 64 GB RAM Preemptible VM Node pool Nodes Node pool Nodes
- 19. Cloud OnAir Cloud OnAir GKE の主な特徴
- 20. Cloud OnAir ● Auto-repair ○ パフォーマンスに問題があったり故障した Nodes を 自動的にリプレイス ● Auto-upgrade ○ Nodes の Kubernetes / GKE バージョンを常に最新版に 自動的に更新 ● Auto-scale (Cluster Autoscaler) ○ 需要に応じて Node pool 内の Nodes 数を自動的に増減 ● Auto-provision beta ○ Cluster Autoscaler の一部として動作し、リソースに最適な Node pool を作成・削除 Auto-everything
- 21. Cloud OnAir ● Kubernetes のマスターを 同一 リージョン内の 3 つのゾーンで持つ ● Kubernetes API に対する 99.95% の SLA ● デフォルトで 3 つのゾーンで Node を配置、1 から 4 まで 選択可能 ● マスター側のメンテナンスが あってもサービス断なし Regional Clusters Zone BZone A Zone C Regional Control Plane Nodes Nodes Nodes
- 22. Cloud OnAir ● セカンダリのゾーンの Disk に対してデータを ミラーリング ● ゾーン障害があった場合、 GKE はコンテナを 問題のないゾーンに マイグレーション、強制的に ミラーリングしてある Disk を アタッチ Regional Persistent Disks Beta Zone BZone A Zone C Regional Control Plane Nodes Nodes Nodes
- 23. Cloud OnAir 従来の GKE のスケーリング機能 - HPA : Pod の水平スケーリング - VPA : Pod の垂直スケーリング - CA : Node の水平スケーリング Node Auto-Provisioning (NAP) は 上記と一緒に動作し、workload に 最適なインスタンスを使って新しい Node Pool を作成する。 Node Auto-Provisioning Beta Master 1. Deploy new large workload 2. Scheduler determines existing node pool’s instance types are too small for the new workload 3. Provisions new node pool with bigger instances 4. Over time, HPA, CA, and NAP will work together to optimize the cluster Node pool A Nodes Node pool B Nodes
- 24. Cloud OnAir Public IP を持たない Nodes を 利用可能。 Master は Public IP を持つ必要が あるが、Firewall で許可された ネットワークからのみアクセス 可能。 Private Cluster Master Nodes
- 25. Cloud OnAir HTTP(S) ロードバランサーから 直接 Pod の IP を参照 “double-hop” 問題を解決 Latency とルーティング性能を改善 VPC-native clusters かつ kubernetes version 1.10+ で 利用可能 Container Native Loadbalancing Beta Master CC Nodes C Nodes
- 26. Cloud OnAir https://cloud.google.com/blog/products/containers-kubernetes/introducing-container-nati ve-load-balancing-on-google-kubernetes-engine Container Native Loadbalancing Beta
- 27. Cloud OnAir Kubernetes / GKE で解決する課題 1. サービスディスカバリー 2. オートスケーリング 3. トラフィックコントロール 4. Fault Isolation (障害の分離） 5. Observability (可観測性) 6. サービス間の認証・認可
- 29. Cloud OnAir サービスメッシュとは？ マイクロサービス環境において、 サービスディスカバリ、 トラフィックコントロール、 認証・認可、メトリックス収集 などの機能を担うソフトウェア アプリケーション自体に手を入れるのでは なく、 サイドカーと呼ばれるネットワーク プロキシを使うことで機能を提供 Service container Service proxy container Service container Service proxy container Kubernetes cluster Pod Pod Pods/Containers Control plane Data plane
- 30. Cloud OnAir Istio とは？ ● Google と IBM を中心開発している サービスメッシュを提供するための オープンソースソフトウェア ● プロキシとして Envoy を利用 ● GCP では ” Istio on GKE “ (beta) として利用可能
- 31. Cloud OnAir Isito on GKE Beta ● GKE 上の Add-on として、簡単に Isito によるサービスメッシュを構築可能 ● 新規だけでなく既存の GKE Cluster にも追加可能 ● 自動で Control Plane をアップグレード ● Stackdriver をネイティブにサポート
- 34. Cloud OnAir これまで… 10% canaries Load Balancing Canary Default Default Default Default Default Default Default Default Default トラフィックコントロールは インフラストラクチャと結びついていた
- 35. Cloud OnAir Isito を使うと… Canary Default 10% canaries Istio Load Balancing 90% of traffic 10% of traffic インフラストラクチャから分離された トラフィックマネジメント
- 36. Cloud OnAir トラフィック スプリッティング pictures hosts: - pictures http: - route: - destination: host: pictures subset: v1 weight: 90 - destination: host: pictures subset: v2.0-alpha weight: 10 90% 10% Proxy Frontend Pictures Proxy Pictures Proxy
- 37. Cloud OnAir トラフィック ステアリング hosts: - pictures http: - match: - headers: user-agent: regex: ^(.*?;)?(android)(;.*)?$ route: - destination: host: pictures subset: v2.0-alpha - route: - destination: host: pictures subset: v1 pictures Proxy Frontend Pictures Proxy Pictures Proxy
- 38. Cloud OnAir サーキットブレーカー (障害の分離) apiVersion: networking.istio.io/v1alpha3 kind: DestinationRule metadata: name: reviews-cb-policy spec: host: reviews.prod.svc.cluster.local trafficPolicy: connectionPool: tcp: maxConnections: 100 http: http2MaxRequests: 1000 maxRequestsPerConnection: 10 outlierDetection: consecutiveErrors: 7 interval: 5m baseEjectionTime: 15m pictures Proxy Frontend Pictures Proxy Pictures Proxy
- 41. Cloud OnAir サービス間のセキュリティを強化 Citadel Istio Control Plane Proxy Frontend Proxy Payments
- 42. Cloud OnAir Role Based Access Control CaseTool PII proxy proxy mTLS BI Tool proxy Joe authorized user listAll() listAll()mTLS 認証されたユーザーが、正しいクライアント サービスを経由した上で センシティブなデータを扱うサービスに アクセスすることを担保 spec: subjects: - user: “spiffe://case-ns/case-tool” properties: request.auth.claims[role]: “reader” roleRef: kind: ServiceRole name: "book-reader"
- 44. Cloud OnAir Stackdriver Service Monitoring EAP Istio Mixer と連携し、 サービスグラフを表示 サービス間通信のトラフィック量や レイテンシーなどの確認が可能
- 45. Cloud OnAir Stackdriver Trace ユーザーからのリクエストが どのようにサービス間で ルーティングされるのかを可視化 レイテンシーの計測、システム のボトルネックを特定
- 46. Cloud OnAir Cloud OnAir Isito のアーキテクチャ
- 47. Cloud OnAir Istio のアーキテクチャ Pilot: Envoy と連携しサービス間の 通信を制御 Envoy: ネットワークプロキシ Mixer: ポリシー管理、 テレメトリーサービスとの連携 Citadel: 相互 TLS、証明書発行 Control Plane API Mixer Service A Service B proxy proxy HTTP/1.1, HTTP/2, gRPC or TCP -- with or without mTLS Pilot Citadel Config data to Envoys TLS certs to Envoys Policy checks, telemetry
- 48. Cloud OnAir サービスディスカバリーやトラフィック コントロールの構成情報を管理 Envoy と連携しサービス間の通信を 制御する Istio - Pilot proxy proxy Routing and load balancing config to Envoys Pilot Service A Service B
- 49. Cloud OnAir Envoy と連携して、 ● リクエスト送信前のポリシー確認 ● リクエスト送信後に、アクセス制御や、 ログ、トレース、メトリクスの収集を実行 Istio - Mixer Mixer frontend pictures proxy proxy API: /pictures Latency: 10ms Status Code: 503 src: 10.0.0.1 dst: 10.0.0.2 InfluxDB Prometheus Stackdriver
- 50. Cloud OnAir CA(Certificate Authority) として 相互 TLSで使われる鍵の管理や 証明書の発行を行う Istio - Citadel Service A Service B proxy proxy Issuing certs per workload to allow service-based authentication and authorization Citadel
- 51. Cloud OnAir Cloud OnAir Isito によるリクエスト処理の流れ
- 52. Cloud OnAir リクエスト処理の流れ 1 サービス A のサイドカーとしてデプロイされた Envoy がサービスの情報、ルーティングや 構成ポリシーを Pilot から取得。 Citadel が使われる場合は、 TLS 証明書も 配布される。 Mixer Service A Service B proxy proxy Pilot Citadel Routing and load balancing config to Envoys TLS certs to Envoys
- 53. Cloud OnAir リクエスト処理の流れ 2 サービス A からサービス B にリクエストが発生。 クライアント側 (サービス A 側) の Envoy が リクエストをインターセプト。 Envoy はどのように、どこへサービス B 宛の リクエストをルーティングするか構成情報を 参照する。 Mixer Service A Service B proxy proxy Pilot Citadel
- 54. Cloud OnAir リクエスト処理の流れ 3 Envoy はリクエストを適切なサービスの インスタンスへ転送する。 サーバー側 (サービス B 側) の Envoy が 当該リクエストをインターセプトする。 Mixer Service A Service B proxy proxy Pilot Citadel HTTP/1.1, HTTP/2, gRPC or TCP -- with or without mTLS
- 55. Cloud OnAir リクエスト処理の流れ 4 サーバー側 (サービス B 側) の Envoy は 届いた リクエストが許可されたものか Mixer に 問い合わせ確認する。 (ACL, Quota etc.) Mixer Service A Service B proxy proxy Pilot Citadel Policy checks, telemetry
- 56. Cloud OnAir リクエスト処理の流れ 5 Mixer は適切なアダプター ( Policy Engine, Quota Adapter) に当該リクエストを サービス B に転送してよいか true / false で Envoy に返す。 Mixer Service A Service B proxy proxy Pilot Citadel Policy checks, telemetry PolicyEngine Quota Adaptor
- 57. Cloud OnAir リクエスト処理の流れ 6 サーバー側 (サービス B 側) の Envoy はサービス B にリクエストを転送し、レスポンスを受け取る。 Mixer Service A Service B proxy proxy Pilot Citadel
- 58. Cloud OnAir リクエスト処理の流れ 7 Envoy はレスポンスをサービス A へ転送する。 クライアント側 (サービス A 側) の Envoy が インターセプトする。 Mixer Service A Service B proxy proxy Pilot Citadel
- 59. Cloud OnAir リクエスト処理の流れ 8 Mixer Service A Service B proxy proxy Pilot Citadel Logging plugin Monitoring plugin サーバー側 (サービス B 側) の Envoy はテレメトリを Mixer に報告する。
- 60. Cloud OnAir リクエスト処理の流れ 9 クライアント側 (サービス A 側) の Envoy が レスポンスを サービス A に転送する。 Mixer Service A Service B proxy proxy Pilot Citadel
- 61. Cloud OnAir リクエスト処理の流れ 10 Mixer Service A Service B proxy proxy Pilot Citadel Logging plugin Monitoring plugin クライアント側 (サービス A 側) の Envoy が テレメトリ (認知したレイテンシを含む ) を Mixer に 報告する。
- 62. Cloud OnAir Isito で解決する課題 1. サービスディスカバリー 2. オートスケーリング 3. トラフィックコントロール 4. Fault Isolation (障害の分離） 5. Observability (可観測性) 6. サービス間の認証・認可
- 63. Cloud OnAir Cloud OnAir Isito トラフィックコントロール・デモ
- 64. Cloud OnAir デモ構成
- 66. Cloud OnAir まとめ マイクロサービス化することで以下のようなメリットがあります 1. 機能追加が容易に 2. 可用性・耐障害性向上 3. スケールアウトが容易に 4. 新技術の導入がしやすい 5. DevOps / Agile との親和性
- 67. Cloud OnAir まとめ マイクロサービス化することで新たな課題も生まれます それらの課題は GKE と Isito を使うことで解消可能です 1. サービスディスカバリー 2. オートスケーリング 3. トラフィックコントロール 4. Fault Isolation (障害の分離） 5. Observability (可観測性) 6. サービス間の認証・認可