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

by Shota Suzuki

Slide 1

Slide 1 text

[B4] 冗長性と生産性を高めるハイブリッドクラウド環境の実現株式会社ユーザベース鈴木祥太

Slide 2

Slide 2 text

紹介 Why ハイブリッドクラウド今後について 3 min 5 min 8 min 2 min 冗長性 / 生産性を高めるには？アジェンダ

Slide 3

Slide 3 text

01 紹介

Slide 4

Slide 4 text

鈴木祥太株式会社ユーザベース仕事：SPEEDA の SRE を担当好き：Kubernetes / Network 趣味：映画 Twitter：@sshota0809 自己紹介

Slide 5

Slide 5 text

z 社名：株式会社ユーザベース / Uzabase, Inc. 創業：2008年4月1日本社所在地：東京都港区六本木 7-7-7 TRI-SEVEN ROPPONGI 13F 事業内容：企業活動の意思決定を支える情報インフラの提供上場市場：東証マザーズ（ 3966） COMPANY OVERVIEW 提供サービス：経済情報プラットフォームソーシャル経済メディアスタートアップ情報プラットフォーム B2Bマーケティングプラットフォーム米クオリティ経済メディアサブスクリプションビジネスに特化したテーマ型ファンド -7-

Slide 6

Slide 6 text

-7- 多様なニーズを持った多様な顧客多くのデータサプライヤー 700 万社を超える超巨大な企業 DB

Slide 7

Slide 7 text

02 Why ハイブリッドクラウド

Slide 8

Slide 8 text

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 を利用した仮想化環境

Slide 9

Slide 9 text

Problems of Previous オンプレミス基盤モノリスアプリケーション機能機能機能機能機能機能

Slide 10

Slide 10 text

Problems of Previous オンプレミス基盤モノリスアプリケーション機能機能機能機能機能機能 z オンプレミス基盤

Slide 11

Slide 11 text

Problems of On-Premise 増設したい提供リードタイム ○ 物理的なサーバを購入する必要 ■ 稟議 - 発注 - 納品 - 設置ランニングコスト ○ 運用の面 ■ 物理レイヤーの運用が必要

Slide 12

Slide 12 text

Problems of Previous オンプレミス基盤モノリスアプリケーション機能機能機能機能機能機能モノリスアプリケーション機能機能機能機能機能機能

Slide 13

Slide 13 text

Problems of Monolith 密結合 ○ 意図しない依存関係の発生 ■ A の部分を修正したら B の部分に影響が出てしまった ○ 開発やリリースが機能毎にやりにくい ■ ある機能をリリースするのにアプリ全体を停止する必要がある機能 A 機能 C 機能 E 機能 B 機能 D 機能 F リリース / 起動 / 停止

Slide 14

Slide 14 text

Problems of Monolith 様々なリードタイムが長く事業の進化のスピードに開発のスピードがついていけなくなってしまった

Slide 15

Slide 15 text

２つの課題の解決に乗り出す Approach for Resolving Problems

Slide 16

Slide 16 text

オンプレミス基盤ハイブリッドクラウド基盤 Approach for Resolving Problems

Slide 17

Slide 17 text

to Hybrid Cloud パブリッククラウドを新たに利用 ○ 物理層をスキップした素早いリードタイムあえてオンプレミスを無くさない ○ 多様な選択肢を提供 ■ アプリのワークロード等によってオンプレミスとパブリッククラウドを使い分ける ○ オンプレミス / パブリッククラウドの長所 / 短所を理解 ■ 両方を運用することでそれぞれの利点を享受できる

Slide 18

Slide 18 text

Approach for resolving Problems オンプレミス基盤マイクロサービス化モノリスアプリケーション機能機能機能機能機能機能

Slide 19

Slide 19 text

to MicroServices 機能が疎結合になる数多くの恩恵 ○ 機能毎に完全に独立した形で開発やリリースやオペレーションができる ■ 事業の進化をしっかりと追従できる開発のスピード ○ 障害影響範囲の局所化 ■ アプリケーション全体が停止してしまうリスクを防ぐ

Slide 20

Slide 20 text

03 冗長性 / 生産性を高めるには？

Slide 21

Slide 21 text

What to Consider about Hybrid Cloud ハイブリッドクラウドの管理冗長化 DNS 設計開発者への提供方法？

Slide 22

Slide 22 text

What to Consider about Hybrid Cloud ハイブリッドクラウドの管理冗長化 DNS 設計開発者への提供方法？ハイブリッドクラウドの管理

Slide 23

Slide 23 text

Management to Hybrid Cloud subnet subnet 専用線商用プロジェクト開発プロジェクト subnet subnet VPC VPC 専用線は 1 つの VPC ( = プロジェクト) にしか紐付けられない権限 / 課金管理はプロジェクト単位に紐づく GCPの仕様が相反・専用線を利用するためにはプロジェクトを 1つに・権限 / 課金を分けるためにはプロジェクトを複数に

Slide 24

Slide 24 text

Management to Hybrid Cloud GCP の Shared VPC という機能を利用 ○ VPC を複数のプロジェクトにシェアできる ■ 共通の VPC を利用しつつ権限や課金等はプロジェクト毎に管理が可能 ○ インフラ部分を統合管理 / 権限等は個別で管理したいといった場合に便利自前で課金整理する仕組み等を作るといった無駄を排除し生産性アップ subnet subnet 専用線 VPC 商用プロジェクト開発プロジェクト

Slide 25

Slide 25 text

What to Consider about Hybrid Cloud ハイブリッドクラウドの管理冗長化 DNS 設計開発者への提供方法？冗長化冗長化

Slide 26

Slide 26 text

Redundancy for Service 専用線オンプレミスと GCP 間の専用線に着目 ○ クラウド間をやり取りする通信がすべて通過するため絶対に止まってはいけない部分 ■ 専用線は 2 重冗長化を実施 ○ GCP の専用線は 99.9 % の SLA を担保 ■ 99.9 % に収まる範囲のメンテナンス等は実施される可能性あり

Slide 27

Slide 27 text

Redundancy for Service 専用線さらなる冗長化を対応 ○ オンプレミスと GCP 間にインターネット経由で VPNを張ることでバックアップ経路を用意 ○ オンプレミス基盤内で BGP によってダイナミックルーティングを実施 VPN 専用線 VPN eBGP  iBGP  クラウド事業者と自社サービスの SLA をしっかり確認し冗長化方針を決定することが大事オンプレルータ Cloud Router

Slide 28

Slide 28 text

What to Consider about Hybrid Cloud ハイブリッドクラウドの管理冗長化 DNS などの非機能系インフラ開発者への提供方法？ DNS 設計

Slide 29

Slide 29 text

Architecture of DNS Dnsmasq CloudDNS Route53 ● オンプレミスのみの状態から拡張をしていったため様々なコンポーネントが存在内向け  [*.gcp]    内向け  [*.k8s.gcp]    内向け  [*.ub-speeda.lan]  [*.uzabase.lan]  etc.    外向け  [*.ub-speeda.com]    Forwarder  CloudDNS CloudDNS CloudDNS

Slide 30

Slide 30 text

Dnsmasq Architecture of DNS CloudDNS Route53 ● 名前解決の導線内向け  [*.gcp]    内向け  [*.k8s.gcp]    内向け  [*.ub-speeda.lan]  [*.uzabase.lan]  etc.    外向け  [*.ub-speeda.com]    Forwarder  VM CloudDNS CloudDNS CloudDNS フォワードフォワードフォワードフォワードフォワードフォワード

Slide 31

Slide 31 text

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 リソースのため参照可能

Slide 32

Slide 32 text

What to Consider about Hybrid Cloud ハイブリッドクラウドの管理冗長化 DNS 設計開発者への提供方法？開発者への提供方法？

Slide 33

Slide 33 text

Integration of The Way to Provide for Developer オンプレ GCP Kubernetes 開発者 Pods A Kubernetes Pods B Kubernetes オンプレミスと Cloud で Kubernetes を利用 ○ 開発者は Kubernetes のレイヤーのみ意識すれば良い ○ 容易にオンプレ / GCP を横断したアプリケーションのデプロイが可能 ■ コンテナのためポータビリティ性が高い開発者はオンプレミス or GCP なのかを気にせず各々の開発に集中することができ生産性を担保

Slide 34

Slide 34 text

The Way to Blue / Green Deployment Kubernetes Blue Green 機能 B 機能 B 機能 A 機能B Service Kubernetes だけではトラフィック制御に課題がある ○ Blue / Green Deployment ■ トラフィックを動的にコントロールしにくい ■ トラフィックがどう流れているか可視化できない ?

Slide 35

Slide 35 text

The Way to Blue / Green Deployment Kubernetes Istio Blue Green 機能 B 機能 B 機能 A 機能B Service Istio で Blue / Green Deployment の実現 ○ Istio により柔軟なトラフィック制御が可能 ■ Blue / Green デプロイ ■ カナリアデプロイ ○ マイクロサービス間のトラフィックを可視化可能 ■ 障害時等にも素早い原因調査が可能

Slide 36

Slide 36 text

The Way to Blue / Green Deployment Blue / Green の切り替え方 ○ Jenkins 等によって Istio を操作することで Blue / Green デプロイが可能マイクロサービス間のトラフィックを可視化可能 ○ Kiali を参照することで ServiceMesh 全体が可視化され視覚的に状態をチェックすることができる blue ⇔ green シンプルなオペレーションと状態の可視化を実現しデプロイコストや運用コストを削減し生産性向上 Kubernetes Istio

Slide 37

Slide 37 text

What to Consider about Hybrid Cloud ハイブリッドクラウドの管理冗長化 DNS 設計開発者への提供方法？

Slide 38

Slide 38 text

04 今後について

Slide 39

Slide 39 text

Integration of Kubernetes Clusters クラスター管理 Anthos 有用性の検証 ○ Anthos によりオンプレミスやパブリッククラウド上のクラスタやポリシーを統合管理することが可能 ■ その有用性等について検証していく予定

Slide 40

Slide 40 text

Thank You

Slide 41

Slide 41 text

Appendix

Slide 42

Slide 42 text

Dynamic な DNS

Slide 43

Slide 43 text

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 を解決させる必要がある ○ 手運用で静的に名前解決の設定をするのでは生産性が落ちてしまう

Slide 44

Slide 44 text

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

Slide 45

Slide 45 text

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

Slide 46

Slide 46 text

Architecture of DNS Kubernetes NameSpace Service

Slide 47

Slide 47 text

Istio

Slide 48

Slide 48 text

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 によってトラフィック制御が可能になる

Slide 49

Slide 49 text

Slide 50

Slide 50 text

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 に通信

Slide 51

Slide 51 text

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 に通信