マルチクラスタで gke を最大限株式会社コロプラ …...ci/cd の実践 - colopl...

Google Cloud

Anthos Day

マルチクラスタで GKE を最大限活用するドラゴンクエストウォーク事例株式会社コロプラインフラエンジニア磯賢大

2020/01/30

ドラゴンクエストウォーク

● 1,000 万 DL 突破

● GCP 上で稼働

● GKE● Cloud Spanner

© 2019, 2020 ARMOR PROJECT/BIRD STUDIO/SQUARE ENIX All Rights Reserved.『ドラゴンクエストウォーク』は、Google Maps Platform gaming solution を使用しています

ドラゴンクエストウォーク

● 1,000 万 DL 突破

● GCP 上で稼働

● GKE● Cloud Spanner● Multiple GKE● 10,000+ Pod

© 2019, 2020 ARMOR PROJECT/BIRD STUDIO/SQUARE ENIX All Rights Reserved.『ドラゴンクエストウォーク』は、Google Maps Platform gaming solution を使用しています

これまで発表されたもの

● 第 9 回 Google Cloud INSIDE Games & Apps○ GKE と Cloud Spanner が躍動するドラゴンクエストウォーク

● GCP 導入事例

ドラゴンクエストウォークを支える

GKE と Cloud Spanner

https://www.slideshare.net/GoogleCloudPlatformJP/gke-cloud-spanner-9-google-cloud-inside-game-apps

https://cloud.google.com/blog/ja/topics/customers/gcp-dragonquest-walk-gke-cloudspanner

https://www.slideshare.net/GoogleCloudPlatformJP/gke-cloud-spanner-9-google-cloud-inside-game-apps

https://cloud.google.com/blog/ja/topics/customers/gcp-dragonquest-walk-gke-cloudspanner

自己紹介

● 磯賢大

● 株式会社コロプラインフラグループ所属

● Cloud Native Days Kansai 2019 Best Speaker○ Certified Kubernetes Administorator○ Certified Kubernetes Application Developer

● 好きなもの: Cloud Native, OSS Contribution

Agenda

1. Architecture

2. CI/CD

3. Manifest Management

4. Observability

5. Container LifeCycle

6. Multiple Clusters Mechanism

7. Scale and Spike

8. Multiple Players Game

01Architecture

Game Application Architecture

クライアントサイド

スマートフォン端末

※ Storage 上

ゲームアプリケーション動画・音声・キャラデータなどの

リソース(アセット)

サーバーアプリケーション・ミドルウェア

サーバーサイド

Google Kubernetes Engine

Architecture Overview

GKE Multiple Kubernetes clusters

BackendKubernetes

CloudSpanner

CloudMemorystore

BigQuery

Logging

Cloud Load Balancing

Container Registry

CDN SpinnakerKubernetes

APIGatewayKubernetes

AppKubernetes

AppKubernetes

AppKubernetes

PVPKubernetes

Multiple Kubernetes Clusters Overview


InternalLB



AppKubernetes

AppKubernetes

AppKubernetes

ExperimentKubernetes

SpinnakerKubernetes

PVPKubernetes

BackendKubernetes

02CI/CD

CI/CD の実践 - Colopl での実践

● 宣言的な CI/CD 設定(IaC)● マニフェスト(IaC)を元にした宣言的なデプロイ

○ デイリーデプロイ, リリース

● デプロイ戦略の選択: Canary, Blue/Green● 新規環境提供の容易性

○ ゲームイベントや新規機能デバッグのための新規環境を、手動

ではなく CI/CD で自動で提供する

CI/CD - GitLab + Spinnaker

● CI に GitLab Runner, CD をSpinnakerで実施

● Spinnaker○ Continuous Delivery OSS○ 宣言的なデプロイ(K8s Manifest Base)が可能

○ Pipelineという単位で Trigger(イベント) と Stage(タスク) を設定

することで、オペレーションを定義できる

○ Canary, Blue/Green などのデプロイ戦略を実現

https://www.spinnaker.io/

https://www.spinnaker.io/

Colopl CI/CD Deploy Flow

Container Registry

Developer

GitLabComputeEngine

GitLab CIComputeEngine

1. git push

2. docker image build

3. docker image push

6. canary deploy

4. automated trigger

ManifestsCloud Storage

5. manifests


AppKubernetes

AppKubernetes

AppKubernetes

SpinnakerKubernetes



Container Registry

Developer

GitLabComputeEngine


1. git push



・Docker Image Build

BuildKit による Multi Stage Build を活用

FROM … as base...

FROM … as local...

FROM … as k8s...

FROM … as test

ビルド時間短縮↓依存関係の明確化6. canary deploy


5. manifests


AppKubernetes

AppKubernetes

AppKubernetes

SpinnakerKubernetes




Container Registry

Developer

GitLabComputeEngine


1. git push


・Docker Image Tag

環境名 + 日時 + Commit hash e.g.) dev1-2020.01.30_xxxxx

Image Tag の GC を定期実施 → Tag が増えすぎないように

2. docker image build 6. canary deploy


5. manifests


AppKubernetes

AppKubernetes

AppKubernetes

SpinnakerKubernetes




Container Registry

Developer

GitLabComputeEngine


1. git push

・Automated Trigger

Container Registry に Image Push されると Spinnakerが検知

・Manifests

Helm Template で生成した Manifests を Storage 上に配置し、Spinnaker から参照



6. canary deploy


5. manifests


AppKubernetes

AppKubernetes

AppKubernetes

SpinnakerKubernetes




Container Registry

Developer

GitLabComputeEngine


1. git push

・Canary Deploy

本番環境では、Canary 戦略で Deploy

これによって、問題が発生してもすぐに切り戻すことが可能

実験用のクラスタを用意し、クラスタレベルで事前検証も可能

(= Multiple Clusters Benefit)



6. canary deploy


5. manifests


AppKubernetes

AppKubernetes

AppKubernetes

SpinnakerKubernetes




Container Registry

Developer

GitLabComputeEngine


1. git push

・Canary Deploy

仮に 10,000 Pod がある場合 1 Cluster だと一度に 10,000 Pod を Rolling Update する

Multiple Clusters だと、 Workload を 3 分割できる (10,000 Pod / 3 Cluster)



6. canary deploy


5. manifests


AppKubernetes

AppKubernetes

AppKubernetes

SpinnakerKubernetes


1/3

1/3

1/3


Build Environment with CI/CD Pipeline

Build Environment with CI/CD Pipeline

Container Registry

Developer

GitLabComputeEngine


1. git branch作成

6. create environment




5. manifests

Dev/StgKubernetes

dev1

dev2

dev3

dev4

new

CloudSpanner

dev1 dev3

dev2 dev4

・Build Environment

Develop/Staging 環境では新規イベント・新機能の検証のために、複数の環境を提供する必要がある

人手を介さずに環境を即時作成することで、開発に集中 Developer Experience を高める

SpinnakerKubernetes



03Manifest Management

マニフェスト管理の実践

● ゲームタイトルは毎年増えていく

● 個別に YAML を作成していくのは、手間かつ無駄

● Helm Chart を活用して、プロジェクト共通で管理

● テンプレートエンジンに、独自ロジックを組み込める

(= シェルを書かなくてよくなる)

● value.yaml をゲームタイトルごとに変えるだけでよい

What is Helm

● Helm は Kubernetes のパッケージマネージャ○ Chart という単位でマニフェスト群を管理

○ テンプレートエンジンとして、YAMLに変数やロジックを組み込み可能

https://helm.sh/

apiVersion: apps/v1kind: Deploymentmetadata: name: {{ template “name” . }}spec:... spec: containers: - name: {{ template “name” . }} image: {{ .Values.nginx.image }}

nginx: image: nginx:1.17

values.yaml

https://helm.sh/

Colopl でのマニフェスト管理構造

root/┣ fluentd/┃ ┗ fluentd/┣ grafana/┃ ┗ grafana/┣ prometheus/┃ ┗ prometheus/┣ redis/┃ ┣ redis/┃ ┣ value.dev.yaml┃ ┣ value.stg.yaml┃ ┣ value.prd.yaml...

ゲームタイトルA ゲームタイトルB


共通Chart

共通ChartをGit Submoduleで管理

Colopl でのマニフェスト管理構造


ゲームタイトルA ゲームタイトルB


このvalue.yamlをプロジェクトごとに管理

04Observability

Observability の実践

● Multi Cluster 構成を取っているため、Cluster 間を横断し

た Monitoring 基盤が必要

● 既存タイトルは Prometheus + Grafana ベースで構築

● Prometheus は単体ではスケールアウトできない

● Remote Write Storage の Victoria Metrics を活用

Promethues + Victoria Metrics + Grafana

Multiple Kubernetes Clusters Overview


AppKubernetes

AppKubernetes

AppKubernetes

BackendKubernetes

PVPKubernetes


Multiple Kubernetes Clusters Prometheus


AppKubernetes

AppKubernetes

AppKubernetes

BackendKubernetes

PVPKubernetes


What is Victoria Metrics

● Prometheus 用の長期期間保存用 Remote Storage● 本番運用中だが、非常に高い信頼性で稼働中

● Victoria Metrics は三つのコンポーネントで構成○ vm-select○ vm-insert○ vm-storage

● それぞれのコンポーネントのスケールアウトも容易

※ただし、storage をスケールインすると Data Loss

Multiple Kubernetes Clusters Prometheus


AppKubernetes

AppKubernetes

AppKubernetes

BackendKubernetes

PVPKubernetes


Federation with Victoria Metrics


AppKubernetes

AppKubernetes

AppKubernetes

BackendKubernetes

PVPKubernetes

GKE Multiple Kubernetes clustersVictoriaMetrics

Prometheus & Victoria Metrics Role

scrape

scrape

scrape

Remote Write

VictoriaMetrics

Prometheus: Scrape に集中

Victoria Metrics: データ集約

⇨ 役割を分担することで、 Prometheusの負担を軽減

05Container LifeCycle

Container LifeCycle

entrypoint preStop SIGTERM SIGKILL

Running terminationGracePeriodSeconds(default: 30s)Terminating Terminated

initContainerpostStart

PodInitialize

ContainersStart

任意の初期化

Running

entrypoint

Liveness/Readiness Probe

Pod 起動時の LifeCycle

Pod 終了時の LifeCycle

任意のスクリプトやhttpGetなどを実行

Container LifeCycle (起動時)の工夫

initContainerpostStart

PodInitialize

ContainersStart

任意の初期化

(PodReady)Running

entrypoint

Liveness/Readiness Probe

Pod 起動時の LifeCycle

1. Docker Entrypoint / InitContainer で初期処理を事前実施a. 一時的なディレクトリやログファイルなどの事前作成

b. コストのかかる Warmup や Caching を事前実施

2. Liveness/Readiness Probe で適切な LifeCycle 管理

1. Entrypoint による起動時の初期処理

#!/bin/bash

artisan config:cacheartisan route:cacheartisan db:warmup

echo 1 > /app/.health

startup.sh

entrypoint.sh

Warmup

Caching

HealthCheckステータス更新

CloudSpanner

Application

Session Pool

生成コストが数秒かかることも

コストのかかる Warm Up をEntrypoint で事前に実施

2. Liveness/Readiness Probe

● LivenessProbe○ コンテナが生きているかどうかのヘルスチェック

● ReadinessProbe○ コンテナが正常な応答可能かどうかのチェック

● ReadinessGate○ ReadinessProbeの機能を拡張したチェック ※ NEG で利用

ReadinessGate Official Link: https://kubernetes.io/docs/concepts/workloads/pods/pod-lifecycle/#pod-readiness-gate

https://kubernetes.io/docs/concepts/workloads/pods/pod-lifecycle/#pod-readiness-gate

2. Liveness/Readiness ProbeLivenessProbe: Failed

APP

Running

APP

Terminate

APP

Running

ReadinessProbe: Failed

APP

Running

APP

Running

APP

Running

Service Out(Out of Endpoints)

NEG と ReadinessGates

● Ingress で NEG を有効化すると HealthCheck が追加される

● その HealthCheck で Ready になる

と、Pod の ReadinessGates が True になる

GCE - HealthCheck

Pod is ready == containers are ready AND conditions in ReadinessGates are True

Readiness

https://cloud.google.com/kubernetes-engine/docs/how-to/container-native-load-balancing#pod_readiness



2. Liveness/Readiness Probe

<?php// このファイルが時間内に実行されなかったら// サーバーが再起動される

LivenessProbe: heartbeat.php

ReadinessProbe: healthcheck.php

<?php

const HEALTHCHECK = '../app.health';

/** .health ファイルをチェックして状態を確認する * 1: 正常動作 */ 0: LBから外す

if (intval(@file_get_contents(HEALTHCHECK)) === 0) { header('HTTP/1.1 404 Not Found'); return;}

livenessProbe: httpGet: path: /heartbeat.php port: 80 initialDelaySeconds: 60 periodSeconds: 5 timeoutSeconds: 20readinessProbe: httpGet: path: /healthcheck.php port: 80 initialDelaySeconds: 60 periodSeconds: 3 timeoutSeconds: 2

Container LifeCycle (終了時)の工夫

1. Entrypoint 内でのシグナルハンドリング

2. preStop を活用して Graceful Shutdown

entrypoint preStop SIGTERM SIGKILL

Running terminationGracePeriodSeconds(default: 30s)Terminating

任意のスクリプトやhttpGetなどを実行

Terminated

Pod 終了時の LifeCycle

Graceful Shutdown

#!/bin/bash

echo 0 > /app/.health

sleep 28

PID=$(cat /run/nginx.pid)nginx -s quit

while [ -d /proc/$PID ]; do sleep 0.1done...

shutdown.sh

プロセス停止確認

HealthCheckステータス更新

リクエスト受付停止(Endpoint 削除 & LB Service Out)

Nginxプロセス停止

preStop を活用し、

安全にリクエスト受付

停止し、プロセスを

終了させる

06Multiple ClustersMechanism

Multiple Kubernetes Cluster Overview


AppKubernetes

AppKubernetes

AppKubernetes

BackendKubernetes

PVPKubernetes


Multiple Cluster Communication




AppKubernetes

AppKubernetes

AppKubernetes


PVPKubernetes

BackendKubernetes

1. How communicate from APIGateway to App?

Multiple Cluster Communication (Frontend)



HAProxyKubernetes

AppKubernetes

AppKubernetes

AppKubernetes


PVPKubernetes

BackendKubernetes33%

33%

33%

1%HAPROXY

・Traffic Control・Weight Control・Canary Release

Multiple Cluster Communication




AppKubernetes

AppKubernetes

AppKubernetes


PVPKubernetes

BackendKubernetes

2. How communicate from App to Backend?

Multiple Cluster Communication (Backend)

https://github.com/colopl/k8s-local-dnshttps://github.com/colopl/expose-kubedns




AppKubernetes

AppKubernetes

AppKubernetes


PVPKubernetes

BackendCoreDNS

Caching

Caching

Caching

Caching

InternalLB

CoreDNS

・NameResolve between Clusters・Node Local DNS

https://github.com/axot/k8s-local-dns

https://github.com/axot/expose-kubedns

Communication in Single Cluster

Application Kubernetes cluster

AppKubernetes

ClusterIPKubernetes

StatefulSetKubernetes

Single Cluster 内での Cluster 内通信は Service ClusterIP 経由で行われる。 Multiple Clusters ではどう行う？

Communication between Clusters(1/2)

Application Kubernetes cluster Backend Kubernetes cluster

Node

InternalLB

kube-system namespace

Node LocalDNS Cache

AppKubernetes

CoreDNSKubernetes

HeadlessService




Node

InternalLB


1. NameResolve

2. NameResolve

Node LocalDNS Cache

AppKubernetes

CoreDNSKubernetes

HeadlessService


name.ns.svc.cluster.local.

name.ns.svc.cluster.local.


Node

InternalLB


Access to Pod IP

Node LocalDNS Cache

AppKubernetes

CoreDNSKubernetes

HeadlessService


※同じ VPC 内の VPC Native Cluster は、Cluster間でも Pod to Pod で通信可能


07Scale and Spike

Scale

● Kubernetes の魅力の一つが Auto Scale● Kubernetes の Horizontal Pod AutoScaler で Pod 増減

● GKE では Node の増減を行う Cluster AutoScaler も搭載

ClusterAutoScaler

Horizontal Pod Autoscaler

Spike

● ゲームでは、リリースやイベントで Spike しやすい

● Kubernetes の Scale 機能では追いつかない

● イベント前に事前に Scale させるゲームイベントによるスパイク

大規模 Cluster での工夫

大規模 Cluster での工夫 - カーネルパラメータ

● initContainer と DaemonSet によって、Pod・Node のカーネルパラメータを修正し、性能を Up○ net.ipv4.tcp_syncookies○ net.core.netdev_max_backlog○ net.ipv4.tcp_tw_reuse○ etc...

Kernel Parameter Tuning による性能 Up

大規模 Cluster での工夫 - conntrack table

nf_conntrack: table full, dropping packet

● Podへのルーティングの実態は iptables の書き換え

● Kernel モジュールである conntrack table のエントリとしてト

ラッキングされる

● ノードあたりの Workload(Pod) が多いと、conntrack table が枯渇して、パケットが Kernel によってドロップされることが

ある

大規模 Cluster での工夫 - conntrack table

● クラスタのサイズを大きくする○ (Node あたりの Workload を減らす)

● conntrack tableを調整するパラメータ○ - net.netfilter.nf_conntrack_max○ - /sys/module/nf_conntrack/parameters/hashsize

https://cloud.google.com/kubernetes-engine/docs/troubleshooting#intermittent_failed_connections

https://www.weave.works/blog/racy-conntrack-and-dns-lookup-timeouts

参考:

https://cloud.google.com/kubernetes-engine/docs/troubleshooting#intermittent_failed_connections

https://www.weave.works/blog/racy-conntrack-and-dns-lookup-timeouts

大規模 Cluster での工夫 - DNS(kube-dns)

Kubernetes のデフォルトの dnsPolicy 設定は ClusterFirst

5つの local search domains と ndots: 5 が設定される

※ 問い合わせ名がドット数 < ndots(5) だと、

local search domain に問い合わせが行く

nameserver 10.228.0.10search prd0.svc.cluster.local svc.cluster.local cluster.local c.projectid.internal google.internaloptions ndots:5

Pod’s /etc/resolv.conf ※デフォルト設定

参考:https://pracucci.com/kubernetes-dns-resolution-ndots-options-and-why-it-may-affect-application-performances.html

https://pracucci.com/kubernetes-dns-resolution-ndots-options-and-why-it-may-affect-application-performances.html


大規模 Cluster での工夫 - DNS(kube-dns)

ドットが 5 未満だったり、FQDNでなかったりすると、

DNS Query が最大 10 回余分に発生

※ 5 個のsearch domain × 2区分(ipv4, ipv6) = 10 DNS Query

search prd0.svc.cluster.local svc.cluster.local cluster.local c.projectid.internal google.internaloptions ndots:5

walk-prd0-redis.prd0.svc.cluster.local

Pod’s /etc/resolv.conf ※デフォルト設定

NOT Fully Qualified Domain Name(without last .) Fully Qualified Domain Name(with last .)

walk-prd0-redis.prd0.svc.cluster.local.

参考:https://pracucci.com/kubernetes-dns-resolution-ndots-options-and-why-it-may-affect-application-performances.html



大規模 Cluster での工夫 - Node Local DNS

● Kubernetes の名前解決はすべて kube-dns に問い合わせ

が殺到

● Spike が発生すると、kube-dns にもリクエストが多発

● kube-dns に負担がいかないように対策が必要

● 対策として、Node ごとにキャッシュ用の DNS を配置○ Node Local DNS Cache

Node Local DNS Cache

Kubernetes cluster

Node


Node LocalDNS Cache

AppKubernetes

Node

Node LocalDNS Cache

AppKubernetes

Node

Node LocalDNS Cache

AppKubernetes

kube-dnsKubernetes

大規模 Cluster での工夫 - kube-dns patch

● kube-dns で TCP Connection Leak と Memory Leak でOOMKilled - Node Local DNS を有効にすると発生しやす

いため、最新パッチを個別適応

https://github.com/kubernetes/dns/issues/334

https://kubernetes.io/docs/tasks/administer-cluster/dns-horizontal-autoscaling/

$ kubectl scale deployment --replicas 0 kube-dns-autoscaler -n kube-system $ kubectl scale deployment --replicas 0 kube-dns -n kube-system

$ kubectl apply -f kube-dns-latest.yaml $ kubectl apply -f kube-dns-autoscaler-latest.yaml

最新版kube-dnsを適応

既存のkube-dnsを 0 までスケールイン

https://github.com/kubernetes/dns/issues/334

https://kubernetes.io/docs/tasks/administer-cluster/dns-horizontal-autoscaling/

08Multiple Players Game

Multiple Players Game

● ゲーム中に、対戦機能や協力対戦機能があるため、

その機能も Kubernetes 上で実現

● マルチプレイ機能を実現するには、Room や User の状態

を持つ(ステートフル)・クライアントからの直接接続、 Room Discovery、Matching などの機能を実装する必要がある

Multiple Players GameServer on Kubernetes

Node

Application Kubernetes cluster Real Time Multiple Player(PVP) Kubernetes cluster

AppKubernetes

AppKubernetes

AppKubernetes

AppKubernetes

InternalLB

Node

AuthKubernetes


RPC ServerKubernetes

RPC ServerKubernetes1. API Call

2. Get Server Info (Host & Port)

3. Direct Connect to Game Server


Node


AppKubernetes

AppKubernetes

AppKubernetes

AppKubernetes

InternalLB

Node

AuthKubernetes


UDP ServerKubernetes


Real Time Multiple Player(PVP) Kubernetes cluster


Node


AppKubernetes

AppKubernetes

AppKubernetes

AppKubernetes

InternalLB

Node

AuthKubernetes







Node


AppKubernetes

AppKubernetes

AppKubernetes

AppKubernetes

InternalLB

Node

AuthKubernetes





3. Direct Connect to Game Server


09Summary

まとめ

● マルチクラスタ構成によって、クラスタレベルでの検証やワー

クロードの分割などのメリットを享受

● 宣言的なデプロイで、Kubernetes Native な CD を実現

● Container LifeCycle の工夫で zero-downtime のデプロイ

● マルチクラスタ間通信を CoreDNS で解決

● Multiple GameServer といったゲームならではの工夫

● 大規模ワークロードやスパイク対策に、様々な工夫

● コロプラでは Kubernetes エンジニアを積極採用中です!!○ GKE, Cloud Spanner を使ったゲームや基盤の開発

○ Kubernetes のエコシステムを含めた Cloud Nativeへの取り組み

コロプラ　採用検索

▼詳しくは

https://be-ars.colopl.co.jp/recruit/career/engineer/corporate-business-support/kubernetes.html

We are Hiring!

https://be-ars.colopl.co.jp/recruit/career/engineer/corporate-business-support/kubernetes.html

Thank you

Trademarks● Kubernetes は、The Linux Fundation の

米国またはその他の国における登録商標

または商標です。

● Spinnaker は、The Linux Fundation の米

国またはその他の国における登録商標ま

たは商標です。

● Helm は、The Linux Fundation の米国ま

たはその他の国における登録商標または

商標です。

● Prometheus は、The Linux Fundation の米国またはその他の国における登録商標

または商標です。

● CoreDNS は、The Linux Fundation の米

国またはその他の国における登録商標ま

たは商標です。

● Grafana は、Grafana Labs の米国または

その他の国における登録商標または商標

です。

● その他記載の会社名、製品名、サービス

名、その他固有名詞は、それぞれの会社

の商標または登録商標です。

● 本文中では©、®、™マークなどは明記して

おりません。

マルチクラスタで gke を最大限 株式会社コロプラ …...ci/cd の実践 - colopl...

Documents

マルチクラスタで gke を最大限株式会社コロプラ …...ci/cd の実践 - colopl...