【SRE NEXT 2020】冗長性と生産性を高めるハイブリッドクラウド環境の実現

Transcript

1. [B4] 冗長性と生産性を高める ハイブリッドクラウド環境の実現 株式会社ユーザベース 鈴木 祥太
2. 紹介 Why ハイブリッド クラウド 今後について 3 min 5 min 8 min 2 min 冗長性 / 生産性 を高めるには？ アジェンダ
3. 01 紹介
4. 鈴木 祥太 株式会社ユーザベース 仕事：SPEEDA の SRE を担当 好き：Kubernetes / Network 趣味：映画 Twitter：@sshota0809 自己紹介
5. z 社名：株式会社ユーザベース / Uzabase, Inc. 創業：2008年4月1日 本社所在地：東京都港区六本木 7-7-7 TRI-SEVEN ROPPONGI 13F 事業内容：企業活動の意思決定を支える情報インフラの提供 上場市場：東証マザーズ（ 3966） COMPANY OVERVIEW 提供サービス： 経済情報 プラットフォーム ソーシャル経済 メディア スタートアップ情報 プラットフォーム B2Bマーケティング プラットフォーム 米クオリティ 経済メディア サブスクリプションビ ジネスに特化した テーマ型ファンド -7-
6. -7- 多様なニーズを持った 多様な顧客 多くの データサプライヤー 700 万社を超える 超巨大な企業 DB
7. 02 Why ハイブリッド クラウド
8. Previous Architecture of SPEEDA CDN CDN CDN Load Balancer CDN CDN Web Apache CDN CDN AP tomcat CDN CDN RDB MySQL Batch Data ES オンプレミス Web - AP - DB の 3 層構造 ◦ AP 層が Service の機能を担う オンプレミスデータセンターを利用 ◦ Xen を利用した仮想化環境
9. Problems of Previous オンプレミス基盤 モノリスアプリケーション 機能 機能 機能 機能 機能 機能
10. Problems of Previous オンプレミス基盤 モノリスアプリケーション 機能 機能 機能 機能 機能 機能 z オンプレミス基盤
11. Problems of On-Premise 増設したい 提供リードタイム ◦ 物理的なサーバを購入する必要 ▪ 稟議 - 発注 - 納品 - 設置 ランニングコスト ◦ 運用の面 ▪ 物理レイヤーの運用が必要
12. Problems of Previous オンプレミス基盤 モノリスアプリケーション 機能 機能 機能 機能 機能 機能 モノリスアプリケーション 機能 機能 機能 機能 機能 機能
13. Problems of Monolith 密結合 ◦ 意図しない依存関係の発生 ▪ A の部分を修正したら B の部分に 影響が出てしまった ◦ 開発やリリースが機能毎にやりにくい ▪ ある機能をリリースするのにアプリ全体 を停止する必要がある 機能 A 機能 C 機能 E 機能 B 機能 D 機能 F リリース / 起動 / 停止
14. Problems of Monolith 様々なリードタイムが長く 事業の進化のスピードに 開発のスピードがついていけなくなってしまった
15. ２つの課題の解決に乗り出す Approach for Resolving Problems
16. オンプレミス基盤 ハイブリッドクラウド基盤 Approach for Resolving Problems
17. to Hybrid Cloud パブリッククラウドを新たに利用 ◦ 物理層をスキップした素早いリードタイム あえてオンプレミスを無くさない ◦ 多様な選択肢を提供 ▪ アプリのワークロード等によってオンプレミスとパブリッククラウドを使い分ける ◦ オンプレミス / パブリッククラウドの 長所 / 短所 を理解 ▪ 両方を運用することでそれぞれの利点を享受できる
18. Approach for resolving Problems オンプレミス基盤 マイクロサービス化 モノリスアプリケーション 機能 機能 機能 機能 機能 機能
19. to MicroServices 機能が疎結合になる数多くの恩恵 ◦ 機能毎に完全に独立した形で開発やリリースやオペレーションができる ▪ 事業の進化をしっかりと追従できる開発のスピード ◦ 障害影響範囲の局所化 ▪ アプリケーション全体が停止してしまうリスクを防ぐ
20. 03 冗長性 / 生産性 を高めるには？
21. What to Consider about Hybrid Cloud ハイブリッドクラウドの管理 冗長化 DNS 設計 開発者への提供方法 ？
22. What to Consider about Hybrid Cloud ハイブリッドクラウドの管理 冗長化 DNS 設計 開発者への提供方法 ？ ハイブリッドクラウドの管理
23. Management to Hybrid Cloud subnet subnet 専用線 商用 プロジェクト 開発 プロジェクト subnet subnet VPC VPC 専用線は 1 つの VPC ( = プロジェクト) にしか紐付けられない 権限 / 課金管理はプロジェクト単位に紐づく GCPの仕様が相反 ・専用線を利用するためにはプロジェクトを 1つに ・権限 / 課金を分けるためにはプロジェクトを複数に
24. Management to Hybrid Cloud GCP の Shared VPC という機能を利用 ◦ VPC を複数のプロジェクトにシェアできる ▪ 共通の VPC を利用しつつ権限や課金等は プロジェクト毎に管理が可能 ◦ インフラ部分を統合管理 / 権限等は個別で管理 したいといった場合に便利 自前で課金整理する仕組み等を作るといった無駄を排除し 生産性アップ subnet subnet 専用線 VPC 商用 プロジェクト 開発 プロジェクト
25. What to Consider about Hybrid Cloud ハイブリッドクラウドの管理 冗長化 DNS 設計 開発者への提供方法 ？ 冗長化 冗長化
26. Redundancy for Service 専用線 オンプレミスと GCP 間の専用線に着目 ◦ クラウド間をやり取りする通信がすべて通過するた め絶対に止まってはいけない部分 ▪ 専用線は 2 重冗長化を実施 ◦ GCP の専用線は 99.9 % の SLA を担保 ▪ 99.9 % に収まる範囲のメンテナンス等は 実施される可能性あり
27. Redundancy for Service 専用線 さらなる冗長化を対応 ◦ オンプレミスと GCP 間にインターネット経由で VPNを 張ることでバックアップ経路を用意 ◦ オンプレミス基盤内で BGP によってダイナミック ルーティングを実施 VPN 専用線 VPN eBGP
 iBGP
 クラウド事業者と自社サービスの SLA をしっかり確認し 冗長化方針を決定することが大事 オンプレルータ Cloud Router
28. What to Consider about Hybrid Cloud ハイブリッドクラウドの管理 冗長化 DNS などの非機能系インフラ 開発者への提供方法 ？ DNS 設計
29. Architecture of DNS Dnsmasq CloudDNS Route53 • オンプレミスのみの状態から拡張をしていったため様々なコンポーネントが存在 内向け
 [*.gcp]
 
 内向け
 [*.k8s.gcp]
 
 内向け
 [*.ub-speeda.lan]
 [*.uzabase.lan]
 etc.
 
 外向け
 [*.ub-speeda.com]
 
 Forwarder
 CloudDNS CloudDNS CloudDNS
30. Dnsmasq Architecture of DNS CloudDNS Route53 • 名前解決の導線 内向け
 [*.gcp]
 
 内向け
 [*.k8s.gcp]
 
 内向け
 [*.ub-speeda.lan]
 [*.uzabase.lan]
 etc.
 
 外向け
 [*.ub-speeda.com]
 
 Forwarder
 VM CloudDNS CloudDNS CloudDNS フォワード フォワード フォワード フォワード フォワード フォワード
31. Architecture of DNS Dnsmasq CloudDNS 内向け
 [*.gcp]
 
 内向け
 [*.ub-speeda.lan]
 [*.uzabase.lan]
 etc.
 
 Forwarder
 Dnsmasq による Forwarder の必要性 ◦ Cloud DNS の zone を内向けに設定すると NS レコードがメタデータサーバ (169.254.169.254) と なるためオンプレミス側のリソースから参照不可 ◦ GCP のリソースとして Dnsmasq を構築することで Dnsmasq からメタデータサーバは参照可能 ▪ Dnsmasq を経由することで名前解決が可能 オンプレDNS から CloudDNSに疎通性がない フォワード フォワード フォワード Dnsmasq は GCP リソースのため参照可能
32. What to Consider about Hybrid Cloud ハイブリッドクラウドの管理 冗長化 DNS 設計 開発者への提供方法 ？ 開発者への提供方法 ？
33. Integration of The Way to Provide for Developer オンプレ GCP Kubernetes 開発者 Pods A Kubernetes Pods B Kubernetes オンプレミスと Cloud で Kubernetes を利用 ◦ 開発者は Kubernetes のレイヤーのみ意識すれば良い ◦ 容易にオンプレ / GCP を横断したアプリケーションの デプロイが可能 ▪ コンテナのためポータビリティ性が高い 開発者はオンプレミス or GCP なのかを気にせず 各々の開発に集中することができ生産性を担保
34. The Way to Blue / Green Deployment Kubernetes Blue Green 機能 B 機能 B 機能 A 機能B Service Kubernetes だけではトラフィック制御に課題がある ◦ Blue / Green Deployment ▪ トラフィックを動的にコントロールしにくい ▪ トラフィックがどう流れているか可視化できない ?
35. The Way to Blue / Green Deployment Kubernetes Istio Blue Green 機能 B 機能 B 機能 A 機能B Service Istio で Blue / Green Deployment の実現 ◦ Istio により柔軟なトラフィック制御が可能 ▪ Blue / Green デプロイ ▪ カナリアデプロイ ◦ マイクロサービス間のトラフィックを可視化可能 ▪ 障害時等にも素早い原因調査が可能
36. The Way to Blue / Green Deployment Blue / Green の切り替え方 ◦ Jenkins 等によって Istio を操作することで Blue / Green デプロイが可能 マイクロサービス間のトラフィックを可視化可能 ◦ Kiali を参照することで ServiceMesh 全体が可視化され 視覚的に状態をチェックすることができる blue ⇔ green シンプルなオペレーションと状態の可視化を実現し デプロイコストや運用コストを削減し生産性向上 Kubernetes Istio
37. What to Consider about Hybrid Cloud ハイブリッドクラウドの管理 冗長化 DNS 設計 開発者への提供方法 ？
38. 04 今後について
39. Integration of Kubernetes Clusters クラスター管理 Anthos 有用性の検証 ◦ Anthos によりオンプレミスやパブリッククラウド上の クラスタやポリシーを統合管理することが可能 ▪ その有用性等について検証していく予定
40. Thank You
41. Appendix
42. Dynamic な DNS
43. Architecture of DNS Kubernetes POD POD POD POD POD POD POD POD POD POD POD POD POD POD POD Service A Service B Service C Service D Service E Load Balancer Load Balancer Load Balancer Load Balancer Load Balancer IP A IP B IP C IP D IP E External IP (type: LoadBalancer) hoge.uzabase.com fuga.uzabase.com ・・・ • Kubernetes の Service リソースに対して FQDN を解決させる必要がある ◦ 手運用で静的に名前解決の設定をするのでは生産性が落ちてしまう
44. Architecture of DNS • 各 k8s クラスタの中にクラスタ外向けの CoreDNS を用意することで解決 ◦ 各クラスタにドメインを与えてそれぞれの CoreDNS にフォワード Service Service Service Kubernetes POD POD Service Load Balancer Service Service Service Kubernetes POD POD Service Load Balancer Service Service Service Kubernetes POD POD Service Load Balancer cluster-a.uzabase.com hoge.uzabase.com Dnsmasq
45. Architecture of DNS Kubernetes https://github.com/coredns/coredns/tree/master/plugin/k8s_external • CoreDNS の k8s_external プラグインを利用 ◦ External-IP を Dynamic に解決することができる DNSの手運用を減らすことで生産性を担保 開発者が日々デプロイをする Service リソースを 自動で追従して名前解決が可能になる Kubernetes NameSpace Service
46. Architecture of DNS Kubernetes NameSpace Service
47. Istio
48. Architecture of Istio Kubernetes Service A Service B Istio Ingress Gateway *.fuga.lan *.hoge.lan b.svc.cluster.local 機能 A Pod A 機能 B Pod B • Istio によって各 POD にサイドカー Proxy がデプロイ ◦ POD に関する In / Out トラフィックが Proxy を経由 ▪ これによって Istio によってトラフィック制御が可能になる
49. Architecture of Istio • Istio のトラフィック処理フロー Kubernetes Service: 機能 A Blue Green Istio Ingress Gateway 機能 A Kubernetes 機能 A Kubernetes VirtualService Resource DestinationRule Resource 論理的な経路 実際の経路 POD Inside Cluster
50. Architecture of Istio • Istio のトラフィック処理フロー Kubernetes Service: 機能 A Blue Green Istio Ingress Gateway 機能 A Kubernetes 機能 A Kubernetes VirtualService Resource DestinationRule Resource 論理的な経路 実際の経路 POD Inside Cluster Istio Ingress Gateway VirtualService Resource POD Inside Cluster • Host header が hoge.com に対してルールが適用 ◦ path が /* であれば ▪ 指定した host(service) の subset: blue に通信
51. Architecture of Istio • Istio のトラフィック処理フロー Kubernetes Service: 機能 A Blue Green Istio Ingress Gateway 機能 A Kubernetes 機能 A Kubernetes VirtualService Resource DestinationRule Resource 論理的な経路 実際の経路 POD Inside Cluster Istio Ingress Gateway VirtualService Resource DestinationRule Resource POD Inside Cluster • subnet: blue であれば ◦ version: blue ラベルがついた POD に通信
52. Architecture of Istio • Istio のトラフィック処理フロー Kubernetes Service: 機能 A Blue Green Istio Ingress Gateway 機能 A Kubernetes 機能 A Kubernetes VirtualService Resource DestinationRule Resource 論理的な経路 実際の経路 POD Inside Cluster VirtualService Resource