Google Cloud Anthos Day Anthos を利用したハイブリッドクラウド環境における Kubernetes 運用の統合株式会社ユーザベース SRE 鈴木祥太

(1)

Google Cloud

Anthos Day

Anthos を利用した

ハイブリッドクラウド環境における

Kubernetes 運用の統合

株式会社ユーザベース

SRE 鈴木祥太

(2)

アジェンダ

00

01

02

03

04 紹介

スピーカー紹介 + 会社紹介

課題

従来のシステム構成とその課題

GKE On-Prem の採用

GKE On-Prem の採用理由・アーキテクチャ

GKE On-Prem の検証

弊社環境における GKE On-Prem の構成・検証内容

05 まとめ

本セッションのまとめ

GKE On-Prem による運用の変化

GKE On-Prem によって運用がどのように変化するか

(3)

00

(4)

スピーカー紹介

鈴木祥太

株式会社ユーザベース

➢ 業務内容

　自社 SaaS の SRE を担当

➢ 好きな技術

　 Kubernetes / Network 全般

➢ 好きな GCP のサービス

　

➢ Twitter

　 @sshota0809

(5)

z

社名：株式会社ユーザベース / Uzabase, Inc. 創業：2008年4月1日 本社所在地：東京都港区六本木 7-7-7 TRI-SEVEN ROPPONGI 13F 事業内容：企業活動の意思決定を支える情報インフラの提供 上場市場：東証マザーズ（ 3966）

COMPANY OVERVIEW

提供サービス：

経済情報プラットフォームソーシャル経済メディアスタートアップ情報プラットフォーム B2Bマーケティング プラットフォーム米クオリティ経済メディアサブスクリプションビジネスに特化したテーマ型ファンド

(6)

-7-多様なニーズを持った

多様な顧客

多くの

データサプライヤー

700 万社を超える

超巨大な企業 DB

(7)

01

課題

(8)

従来のシステム構成（

Before Micro Service）

CDN Load Balancer WEB Application Database

batch Session Elastic Search

● WEB - AP - Database の3層構造

○ サービスの機能は一つのモノリスなアプリに集中

● ビジネススピードに開発スピードが追いつかない

○ 巨大になり過ぎたモノリスアプリケーション

○ モノリスなうえ開発言語も固定されてしまう

● マイクロサービス化へ舵取り

○ 開発単位を細かく分離することで開発高速化

○ 各マイクロサービス毎に言語を選定

■

アプリの特性や技術的チャレンジを意識

(9)

現在のシステム構成（

After Micro Service）

● 新規機能などはすべてマイクロサービスで開発

● コンテナ基盤として Kubernetes を採用

○ ハイブリッドクラウド環境における運用

■

オンプレミス環境のクラスタ（OSS）

■

GCP 環境のクラスタ（GKE）

Kubernetes on-prem Kubernetes GKE

(10)

現在のシステム構成（

Focus on Kubernetes）

● API Gateway として Kong を採用

○ 認証やロギング等集中管理

● Istio による柔軟なデプロイ

○ Blue / Green ルーティングの制御

○ HTTP Header などによるルーティングも実施

● オンプレクラスタでも GKE でも上記は同様

Kubernetes クラスタ Istio IngressGateway ･･･ Kong (blue) Kong (green) MS A (blue) MS A (green) MS B (blue) MS B (green) Istio ControlPlane

(11)

ハイブリッドクラウド運用

● オンプレ / クラウドの選択

○ ユースケースやコスト等で適切に判断

○ オンプレ / クラウド合わせて約 20 台程度の k8s

● オンプレ運用による技術力向上

○ 低レイヤーの技術スタック

○ マネージドでない物からの学び

■

Hypervisor / VM / DB / ES 等も運用

Kubernetes on-prem Kubernetes GKE

(12)

マイクロサービス化

+ Kubernetes の成果

● 開発スピードの向上

○ ビジネススピードに追いつける開発スピード

● Kubernetes + Istio による柔軟なデプロイやルーティング制御

○ Istio によるシンプルな Blue / Green デプロイ

○ HTTP レイヤーの情報に基づくルーティング制御

アプリケーション開発者の目線で見るとそれなりに良い環境を実現できた

しかしインフラ運用はまだ課題が多い

(13)

ハイブリッドクラウドにおける

Kubernetes 運用

● クラスタの信頼性

○ Kubernetes の高い信頼性を享受

■

一方でオンプレミス Kubernetes クラスタでは障害対応に時間を費やすことがある

● 相対的に見ると GKE の方が安定性は高い

● GKE とオンプレミス Kubernetes クラスタの運用差異

○ 構成管理の方法や Cloud Provider とのインテグレーション

Kubernetes オンプレミス Kubernetes GKE

(14)

ハイブリッドクラウドにおける

Kubernetes 運用

● 技術力向上と運用工数削減のバランスの意識

○ 技術力 / 運用工数どちらも大事にしている

■

知識やスキルをつけるためにあえてマネージドで無いものを触る

● 1 からの構築 / トラブルシューティング / etc...

■

マネージドなものを利用し運用工数を下げる

○ Kubernetes はしばらく運用し知識やスキルはある程度溜まった

■

運用効率化を目指すフェーズに移行

オンプレミス Kubernetes クラスタの信頼性向上

オンプレクラスタと GKE で運用の統一を図りたい

(15)

02

GKE On-Prem の

採用

GKE On-Prem の採用理由

(16)

GKE On-Prem とは

● Anthos のコアコンポーネント

GKE On-Prem は、Google Kubernetes Engine（GKE）をオンプレミスの

データセンターに組み込むハイブリッドクラウドソフトウェアです。GKE

On-Prem を使用すると、オンプレミス環境で Kubernetes クラスタを作

成、管理、アップグレードできます。

(

https://cloud.google.com/anthos/gke/docs/on-prem/overview?hl=ja

)

● GKE ライクなクラスタをオンプレミスで実現

○ easy なクラスタ構築 / 運用

○ ロギングとモニタリングの統合

○ 統合されたロードバランサ

○ 認証

etc...

(17)

GKE On-Prem を採用した理由

● 既存環境との親和性の高さ

○ 元々 GCP をメインクラウドとして利用

■

GKE クラスタを 10 セット以上運用

■

専用線でオンプレと接続済み

○ GCP の良さを肌で感じていた

■

GKE の安定感

■

Stackdriver 等の使いやすさ

(18)

GKE On-Prem アーキテクチャ

● Hypervisor として vSphere を利用

○ Anthos のレイヤーから vSphere API と通信することで様々な操作を行う

○ Kubernetes レイヤー + vSphere レイヤーの機能で高い耐障害性を実現

● Kubernetes クラスタを Kubernetes クラスタが管理

○ Admin Cluster：User Cluster を集中管理するクラスタ

○ User Cluster：アプリケーション等が稼働するクラスタ

Physical Server vSphere

Virtual Server (Kubernetes Node) Admin Cluster User Cluster

(19)

Client Machine

GKE On-Prem アーキテクチャ

● Admin Workstation（VM）から Admin / Cluster クラスタの操作

○ gkectl：Anthos の管理コマンド

■

cluster create / update / delete

● User クラスタの Control Plane は Admin クラスタの POD として動作

○ Kubernetes レイヤーで耐障害性を担保

Admin Workstation gkectl kubectl kubectl GKE on-prem 　　 Admin Cluster User Cluster Master Node Worker Node Worker Node Worker Node User Cluster Control Plane Component User Cluster Control Plane Component User Cluster Control Plane Component Worker Node Worker Node Worker Node Admin Cluster LoadBalancer User Cluster LoadBalancer LB (Standby) LB (Active) LB (Standby) LB (Active)

(20)

Client Machine

GKE On-Prem アーキテクチャ

● LoadBalancer はクラスタに統合

○ クラスタと同時にデプロイされる

■

kube-api-server もこの LB 経由で分散される

○ type: loadbalancer のリソース作成時に LB に設定が投入される

○ LB は複数の選択肢が用意されている

■

F5 BIG-IP / Seesaw / Citrix

(21)

Client Machine

GKE On-Prem アーキテクチャ

● ロギングやモニタリングの統合

○ ログやメトリクスが GCP 上に送信され GKE と同じ感覚で各種情報が閲覧可能

● OIDC によるクラスタへの認証

○ Google をプロバイダにすることで GKE と同様 Google アカウント

（gcloud コマンド経由）での認証が可能

(22)

GKE On-Prem アーキテクチャ

● クラスタデプロイが容易

○ クラスタの定義は YAML ファイルで構成管理

■

Node の構成

■

Kubernetes クラスタの構成

■

統合された LoadBalancer の構成

○ gkectl コマンドによる 3 コマンドでクラスタデプロイが完了

gkectl

gkectl check-conﬁg

YAML ファイルの Varidate / GCP の各種サービスアカウントの権限 / ネットワーク疎通性等細かくクラスタ構築に必要な要素を事前チェック

gkectl create loadbalancer

YAML ファイルの定義に従ってクラスタに統合されたロードバランサリソースをvSphere 上のVMとして作成

gkectl create cluster

YAML ファイルの定義に従って Kubernetes クラスタを作成

(23)

03

GKE On-Prem

の検証

弊社環境における

_{GKE On-Prem}

の構成・検証内容

(24)

GKE on-prem の構成（vSphere レイヤー）

● 技術的挑戦として iSCSI ディスク領域として ceph を採用

○ Kubernetes 上のワークロードでは I/O 等に関して高速度は必要ないという判断

○ iSCSI-Gatewayの利用

■

ceph を iSCSI-Gateway でマウント

■

iSCSI-Gateway が iSCSI プロトコルで vSphere のノードと通信

iSCSI Seg User Cluster Seg

Admin Cluster Seg

vSphere & Anthos Mgmt Seg

vCenter Anthos User Cluster Anthos Admin Cluster Anthos Admin WS

Physical Server #1 Physical Server #2 Physical Server #3

Anthos User Cluster LoadBalancer Anthos Admin Cluster LoadBalancer Core SW iSCSI-Gateway

･･･

(25)

GKE on-prem の構成（Anthos レイヤー）

● LoadBalancer は OSS として公開されている Seesaw を採用

○ https://github.com/google/seesaw

○ 検証当時は Seesaw との統合機能がリリースされて 1 ヶ月も経っていなかった

■

Anthos 検証のうえで大きな挑戦の 1 つ

○ OSS 採用による低コスト化も実現

Client Machine Admin Workstation gkectl kubectl kubectl GKE on-prem 　　 Admin Cluster User Cluster Master Node Worker Node Worker Node Worker Node User Cluster Control Plane Component User Cluster Control Plane Component User Cluster Control Plane Component Worker Node Worker Node Worker Node Admin Cluster LoadBalancer User Cluster LoadBalancer LB (Standby) LB (Active) LB (Standby) LB (Active)

(26)

GKE on-prem の構成（監視戦略）

● GKE on-prem のレイヤーは Cloud Monitoring と Prometheus で運用

○ 大量の Anthos Metrics が存在

（

https://cloud.google.com/monitoring/api/metrics_anthos）

○ Grafana のダッシュボードも使いやすく整備しているため併用

ストレージ

ハイパーバイザー

物理サーバ

GKE on-prem Node

Kubernetes

vSphere

プロセス死活：Nagios

メトリクス：Prometheus + Grafana

死活：Nagios

メトリクス：telegraf + inﬂuxdb + grafana

死活 / メトリクス：Cloud Monitoring

(27)

検証内容

● Kubernetes 自体は運用済みなため Anthos 特有の機能等を検証

○ gkectl コマンドを用いた GKE on-prem のオペレーション

○ GitOps やサービスメッシュを提供する機能

項目

中項目

GKE on-prem クラスタ作成 クラスタ削除 クラスタリサイズ 認証 / ロギング / モニタリング等の統合

Anthos Conﬁg Management ACMを利用したGitOps

(28)

検証内容

● 英語版公式ドキュメントベースに検証を実施

○ 大きな問題もなく検証完了

■

途中 NW 構成等でハマったりはした

項目

中項目

GKE on-prem クラスタ作成 クラスタ削除 クラスタリサイズ 認証 / ロギング / モニタリング等の統合

Anthos Conﬁg Management ACMを利用したGitOps

Anthos Service Mesh ASMを利用したサービスメッシュの管理

(29)

04

GKE On-Prem による

運用の変化

GKE On-Prem によって運用がど

(30)

Description

構築方法

（構成管理） Terraform ※. Ansible ベースの Kubernetes クラスタ構築ツールkubespray

マスターノードマネージド自前で運用

Cloud Provider GCP

-ログ収集 StackDriver に送信（デフォルトで収集） Google 公式が公開している StackDriver 用の Fluentd プラグインを改修して StackDriver に送信

クラスタ

アップデート自動 kubespray

クラスタへの認証 gcloud コマンドで Google アカウント経由で認証 Kubernetes の機能としての Service Account / User 等で認証

ハイブリッドクラウドにおける

Kubernetes 運用

Kubernetes オンプレミス Kubernetes

(31)

ハイブリッドクラウドにおける

Kubernetes 運用

Description

構築方法

クラスタ

GKE

(32)

(33)

構築方法（構成管理）

GKE

● Terraform の定義ファイルで Node + Cluster

どちらも 1 ファイルで構成管理可能

● Node と Cluster 別々で構成管理

○ Node: 自作 Ansible playbook

■

Ansible の変数として VM 情報を定義

○ Cluster: kubespray

■

inventory ファイルにVM 情報を記載

自作 playbook の変数 playbook 実行 (VM 構築) kubespray の inventory に記載 kubespray 実行 (Cluster 構築)

(34)

構築方法（構成管理）

● kubespray によるクラスタ構築

○ Ansible を使った Kubernetes クラスタ構築ツール

■

Inventory ファイルを記述して Playbook を流すだけでクラスタ構築等が可能

■

オプション等選択の自由度が高い

■

https://github.com/kubernetes-sigs/kubespray

○ オプション等で色々選択できる一方 Playbook は複雑

■

全体の流れを理解するのにも苦労する

● クラスタ初期構築の Playbook は流すだけで 20 分程度かかる

■

複雑なため Node を追加するといった処理を実行する際も少なからず恐怖心がある

■

エラー等起こった時の debug が大変

(35)

クラスタアップデート

● 自動 / 手動でローリングアップデート

○ マネージドならではの安心感

● kubespray によるアップデート

○ 複雑な Playbook の理解等が必要

■

弊社環境では新しいバージョンのクラスタを

横展開する方針をとっている

(36)

(37)

構築方法（構成管理）

/ クラスタアップデート

GKE on-prem gkectl

gkectl check-conﬁg

YAML ファイルの Varidate / GCP の各種サービスアカウントの権限 / ネットワーク疎通性等細かくクラスタ構築に必要な要素を事前チェック

gkectl create loadbalancer

YAML ファイルの定義に従ってクラスタに統合されたロードバランサリソースをvSphere 上のVMとして作成

gkectl create cluster

YAML ファイルの定義に従って Kubernetes クラスタを作成

● YAML ファイルによる構成管理

○ Terraform による構築ではないがgkectl コマンドによる easy なクラスタ構築 / 運用

○ OS イメージ等もすべて GKE on-prem 用のイメージベースで構築される

■

YAML ファイルが同一であれば何度クラスタを作っても全く同じ環境を再現できる

● 必要な時にすぐクラスタを用意でき不要になったらすぐ破棄できる

gkectl upgrade cluster

YAML ファイルの定義に従って Kubernetes クラスタをアップグレード

(38)

ハイブリッドクラウドにおける

Kubernetes 運用

Description

構築方法

クラスタ

GKE

(39)

(40)

マスターノード

● マネージドなので運用する必要無し

○ マスターノードは隠蔽されている

● マスターノード含めて運用する必要がある

○ クラスタ全体の安定性は GKE の方が高い

○ 過去経験として様々な障害が発生

■

原因調査から解決まで骨の折れる作業

■

あくまで Kubernetes のナレッジを溜める

いい機会だと考えている

(41)

(42)

マスターノード

GKE on-prem Client Machine Admin Workstation gkectl kubectl kubectl GKE on-prem 　　 Admin Cluster User Cluster Master Node Worker Node Worker Node Worker Node User Cluster Control Plane Component User Cluster Control Plane Component User Cluster Control Plane Component Worker Node Worker Node Worker Node Admin Cluster LoadBalancer User Cluster LoadBalancer LB (Standby) LB (Active) LB (Standby) LB (Active)

● GKE と同様 User Cluster から見るとマスターノードが隠蔽された状態

○ Admin Cluster の POD として Control Plane が稼働しているため高い耐障害性

■

仮に POD がダウンしても Kubernetes のレイヤーでオートヒーリング

○ Admin Cluster も vSphere 上で稼働しているため完全にマネージドではない

(43)

ハイブリッドクラウドにおける

Kubernetes 運用

Description

構築方法

クラスタ

GKE

(44)

(45)

Cloud Provider / ログ収集

● GCP の様々なサービスと統合されている

○ ロギング：Cloud Logging

○ 監視：Cloud Monitoring

○ 負荷分散：Google Cloud Load Balancing

etc...

● 各機能等の連携をそれぞれ用意必要がある

○ ロギング：Stackdriver 用の Fluentd Plugin を改修

■

Version Up に沿ってメンテナンスの必要がある

■ https://github.com/GoogleCloudPlatform/ﬂuent-plugin-google-cloud

○ 負荷分散：Metal LB をクラスタにインストール

■ https://github.com/metallb/metallb Kubernetes GKE

･･･

Kubernetes on-prem

(46)

(47)

Cloud Provider / ログ収集

GKE on-prem

Seesaw / BIG-IP / Citrix

● クラスタ管理者が意識せずとも自動で連携

○ GKE と同じインターフェースでログやメトリクスの確認が可能

■

運用の統合を大きく加速

■

公式から Cloud Monitoring のダッシュボードも提供

● 監視設定等もスムーズにスタートできる

(48)

ハイブリッドクラウドにおける

Kubernetes 運用

Description

構築方法

クラスタ

GKE

(49)

(50)

クラスタへの認証

● ユーザーアカウント（ SRE や開発者）

○ gcloud コマンドを使った認証

■

Google アカウントによる認証

● 認証情報は統合的に管理できていない

○ クラスタ毎にバラバラの認証情報

Kubernetes

GKE on-premKubernetes

Kubernetes on-prem Kubernetes

GKE

(51)

(52)

クラスタへの認証

GKE on-prem

● OpenID Connect を利用した認証に対応

○ Google を Provider として認証すれば Google アカウントでクラスタへ認証が可能

■

ドメインによる認証の制限等も可能

● e.g.) @uzabase.com のドメインアカウントのみ承認

GKE on-prem

(53)

Anthos 導入により

様々運用を簡素

/ 統一化

● その他機能も活用

○ Anthos Conﬁg Management による GitOps の実践

○ GKE / Anthos のダッシュボード統合

(54)

Anthos GKE On-Prem Cluster - dev/e2e test

Anthos 導入戦略

monolit

OSS kubernetes Cluster - prod

on-premise

Anthos GKE On-Prem Cluster - dev/e2e test

logging / monitoring

GKE Cluster - prod

monolith AP

OSS kubernetes Cluster - prodOSS Kubernetes Cluster - prod

monolith AP

GKE Cluster - prod

GKE Cluster - prod

Micro Service A prod Micro Service B prod Micro Service C prod ･･･ End User Micro Service E prod Micro Service F prod Micro Service D prod

Dedicated Interconnect

Micro Service A e2e test

GCP

･･･ ･･･ Micro Service A dev ･･･

● Develop / e2e test 環境で Anthos の稼働実績を積む

○ オンプレミス Kubernetes / GKE の Develop / e2e 環境を Anthos クラスタに集約

(55)

05

まとめ

(56)

Google Cloud Anthos Day Anthos を利用した ハイブリッドクラウド環境における Kubernetes 運用の統合 株式会社ユーザベース SRE 鈴木祥太

Google Cloud

Anthos Day

Anthos を利用した

ハイブリッドクラウド環境における

Kubernetes 運用の統合

株式会社ユーザベース

SRE 鈴木祥太

アジェンダ

00

01

02

03

04

紹介

スピーカー紹介 + 会社紹介

課題

従来のシステム構成とその課題

GKE On-Prem の採用

GKE On-Prem の採用理由・アーキテクチャ

GKE On-Prem の検証

弊社環境における GKE On-Prem の構成・検証内容

05

まとめ

本セッションのまとめ

GKE On-Prem による運用の変化

GKE On-Prem によって運用がどのように変化するか

00

スピーカー紹介

鈴木 祥太

➢ 業務内容

自社 SaaS の SRE を担当

➢ 好きな技術

Kubernetes / Network 全般

➢ 好きな GCP のサービス

➢ Twitter

@sshota0809

z

COMPANY OVERVIEW

提供サービス：

-7-多様なニーズを持った

多様な顧客

多くの

データサプライヤー

700 万社を超える

超巨大な企業 DB

01

課題

従来のシステム構成（

Before Micro Service）

●

WEB - AP - Database の3層構造

○

サービスの機能は一つのモノリスなアプリに集中

●

ビジネススピードに開発スピードが追いつかない

○

巨大になり過ぎたモノリスアプリケーション

○

モノリスなうえ開発言語も固定されてしまう

●

マイクロサービス化へ舵取り

○

開発単位を細かく分離することで開発高速化

○

各マイクロサービス毎に言語を選定

■

アプリの特性や技術的チャレンジを意識

現在のシステム構成（

After Micro Service）

●

新規機能などはすべてマイクロサービスで開発

●

コンテナ基盤として Kubernetes を採用

○

ハイブリッドクラウド環境における運用

■

オンプレミス環境のクラスタ（OSS）

■

GCP 環境のクラスタ（GKE）

Google Cloud Anthos Day Anthos を利用したハイブリッドクラウド環境における Kubernetes 運用の統合株式会社ユーザベース SRE 鈴木祥太

鈴木祥太

　自社 SaaS の SRE を担当

　 Kubernetes / Network 全般

　 @sshota0809