View
16
Download
0
Category
Preview:
Citation preview
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
自己紹介
● 磯 賢大
● 株式会社コロプラ インフラグループ所属
● 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
Cloud Load Balancing
InternalLB
GKE Multiple Kubernetes clusters
APIGatewayKubernetes
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/
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
ExperimentKubernetes
AppKubernetes
AppKubernetes
AppKubernetes
SpinnakerKubernetes
GKE Multiple Kubernetes clusters
Colopl CI/CD Deploy Flow
Container Registry
Developer
GitLabComputeEngine
GitLab CIComputeEngine
1. git push
2. docker image build
3. docker image push
・Docker Image Build
BuildKit による Multi Stage Build を活用
FROM … as base...
FROM … as local...
FROM … as k8s...
FROM … as test
ビルド時間短縮↓依存関係の明確化6. canary deploy
ManifestsCloud Storage
5. manifests
ExperimentKubernetes
AppKubernetes
AppKubernetes
AppKubernetes
SpinnakerKubernetes
GKE Multiple Kubernetes clusters
4. automated trigger
Colopl CI/CD Deploy Flow
Container Registry
Developer
GitLabComputeEngine
GitLab CIComputeEngine
1. git push
3. docker image push
・Docker Image Tag
環境名 + 日時 + Commit hash e.g.) dev1-2020.01.30_xxxxx
Image Tag の GC を定期実施 → Tag が増えすぎないように
2. docker image build 6. canary deploy
ManifestsCloud Storage
5. manifests
ExperimentKubernetes
AppKubernetes
AppKubernetes
AppKubernetes
SpinnakerKubernetes
GKE Multiple Kubernetes clusters
4. automated trigger
Colopl CI/CD Deploy Flow
Container Registry
Developer
GitLabComputeEngine
GitLab CIComputeEngine
1. git push
・Automated Trigger
Container Registry に Image Push されると Spinnakerが 検知
・Manifests
Helm Template で生成した Manifests を Storage 上に 配置し、Spinnaker から参照
2. docker image build
3. docker image push
6. canary deploy
ManifestsCloud Storage
5. manifests
ExperimentKubernetes
AppKubernetes
AppKubernetes
AppKubernetes
SpinnakerKubernetes
GKE Multiple Kubernetes clusters
4. automated trigger
Colopl CI/CD Deploy Flow
Container Registry
Developer
GitLabComputeEngine
GitLab CIComputeEngine
1. git push
・Canary Deploy
本番環境では、Canary 戦略 で Deploy
これによって、問題が発生 してもすぐに切り戻すこと が可能
実験用のクラスタを用意し、 クラスタレベルで事前検証 も可能
(= Multiple Clusters Benefit)
2. docker image build
3. docker image push
6. canary deploy
ManifestsCloud Storage
5. manifests
ExperimentKubernetes
AppKubernetes
AppKubernetes
AppKubernetes
SpinnakerKubernetes
GKE Multiple Kubernetes clusters
4. automated trigger
Colopl CI/CD Deploy Flow
Container Registry
Developer
GitLabComputeEngine
GitLab CIComputeEngine
1. git push
・Canary Deploy
仮に 10,000 Pod がある場合 1 Cluster だと一度に 10,000 Pod を Rolling Update する
Multiple Clusters だと、 Workload を 3 分割できる (10,000 Pod / 3 Cluster)
2. docker image build
3. docker image push
6. canary deploy
ManifestsCloud Storage
5. manifests
ExperimentKubernetes
AppKubernetes
AppKubernetes
AppKubernetes
SpinnakerKubernetes
GKE Multiple Kubernetes clusters
1/3
1/3
1/3
4. automated trigger
Build Environment with CI/CD Pipeline
Build Environment with CI/CD Pipeline
Container Registry
Developer
GitLabComputeEngine
GitLab CIComputeEngine
1. git branch作成
6. create environment
ManifestsCloud Storage
2. docker image build
3. docker image push
5. manifests
Dev/StgKubernetes
dev1
dev2
dev3
dev4
new
CloudSpanner
dev1 dev3
dev2 dev4
・Build Environment
Develop/Staging 環境では 新規イベント・新機能の検証 のために、複数の環境を提供 する必要がある
人手を介さずに環境を即時 作成することで、開発に集中 Developer Experience を高める
SpinnakerKubernetes
GKE Multiple Kubernetes clusters
4. automated trigger
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
Colopl でのマニフェスト管理構造
root/┣ fluentd/┃ ┗ fluentd/┣ grafana/┃ ┗ grafana/┣ prometheus/┃ ┗ prometheus/┣ redis/┃ ┣ redis/┃ ┣ value.dev.yaml┃ ┣ value.stg.yaml┃ ┣ value.prd.yaml...
ゲームタイトルA ゲームタイトルB
root/┣ fluentd/┃ ┗ fluentd/┣ grafana/┃ ┗ grafana/┣ prometheus/┃ ┗ prometheus/┣ redis/┃ ┣ redis/┃ ┣ value.dev.yaml┃ ┣ value.stg.yaml┃ ┣ value.prd.yaml...
共通Chart
共通ChartをGit Submoduleで管理
Colopl でのマニフェスト管理構造
root/┣ fluentd/┃ ┗ fluentd/┣ grafana/┃ ┗ grafana/┣ prometheus/┃ ┗ prometheus/┣ redis/┃ ┣ redis/┃ ┣ value.dev.yaml┃ ┣ value.stg.yaml┃ ┣ value.prd.yaml...
ゲームタイトルA ゲームタイトルB
root/┣ fluentd/┃ ┗ fluentd/┣ grafana/┃ ┗ grafana/┣ prometheus/┃ ┗ prometheus/┣ redis/┃ ┣ redis/┃ ┣ value.dev.yaml┃ ┣ value.stg.yaml┃ ┣ value.prd.yaml...
このvalue.yamlをプロジェクトごとに管理
04Observability
Observability の実践
● Multi Cluster 構成を取っているため、Cluster 間を横断し
た Monitoring 基盤が必要
● 既存タイトルは Prometheus + Grafana ベースで構築
● Prometheus は単体ではスケールアウトできない
● Remote Write Storage の Victoria Metrics を活用
Promethues + Victoria Metrics + Grafana
Multiple Kubernetes Clusters Overview
APIGatewayKubernetes
AppKubernetes
AppKubernetes
AppKubernetes
BackendKubernetes
PVPKubernetes
GKE Multiple Kubernetes clusters
Multiple Kubernetes Clusters Prometheus
APIGatewayKubernetes
AppKubernetes
AppKubernetes
AppKubernetes
BackendKubernetes
PVPKubernetes
GKE Multiple Kubernetes clusters
What is Victoria Metrics
● Prometheus 用の長期期間保存用 Remote Storage● 本番運用中だが、非常に高い信頼性で稼働中
● Victoria Metrics は三つのコンポーネントで構成○ vm-select○ vm-insert○ vm-storage
● それぞれのコンポーネントのスケールアウトも容易
※ただし、storage をスケールインすると Data Loss
Multiple Kubernetes Clusters Prometheus
APIGatewayKubernetes
AppKubernetes
AppKubernetes
AppKubernetes
BackendKubernetes
PVPKubernetes
GKE Multiple Kubernetes clusters
Federation with Victoria Metrics
APIGatewayKubernetes
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
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
APIGatewayKubernetes
AppKubernetes
AppKubernetes
AppKubernetes
BackendKubernetes
PVPKubernetes
GKE Multiple Kubernetes clusters
Multiple Cluster Communication
Cloud Load Balancing
GKE Multiple Kubernetes clusters
APIGatewayKubernetes
AppKubernetes
AppKubernetes
AppKubernetes
ExperimentKubernetes
PVPKubernetes
BackendKubernetes
1. How communicate from APIGateway to App?
Multiple Cluster Communication (Frontend)
Cloud Load Balancing
GKE Multiple Kubernetes clusters
HAProxyKubernetes
AppKubernetes
AppKubernetes
AppKubernetes
ExperimentKubernetes
PVPKubernetes
BackendKubernetes33%
33%
33%
1%HAPROXY
・Traffic Control・Weight Control・Canary Release
Multiple Cluster Communication
Cloud Load Balancing
GKE Multiple Kubernetes clusters
APIGatewayKubernetes
AppKubernetes
AppKubernetes
AppKubernetes
ExperimentKubernetes
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
Cloud Load Balancing
GKE Multiple Kubernetes clusters
APIGatewayKubernetes
AppKubernetes
AppKubernetes
AppKubernetes
ExperimentKubernetes
PVPKubernetes
BackendCoreDNS
Caching
Caching
Caching
Caching
InternalLB
CoreDNS
・NameResolve between Clusters・Node Local DNS
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
StatefulSetKubernetes
Communication between Clusters(1/2)
Application Kubernetes cluster Backend Kubernetes cluster
Node
InternalLB
kube-system namespace
1. NameResolve
2. NameResolve
Node LocalDNS Cache
AppKubernetes
CoreDNSKubernetes
HeadlessService
StatefulSetKubernetes
name.ns.svc.cluster.local.
name.ns.svc.cluster.local.
Communication between Clusters(2/2)
Node
InternalLB
kube-system namespace
Access to Pod IP
Node LocalDNS Cache
AppKubernetes
CoreDNSKubernetes
HeadlessService
StatefulSetKubernetes
※同じ VPC 内の VPC Native Cluster は、Cluster間でも Pod to Pod で通信可能
Application Kubernetes cluster Backend Kubernetes cluster
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
参考:
大規模 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
大規模 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
kube-system namespace
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 までスケールイン
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
Cloud Load Balancing
RPC ServerKubernetes
RPC ServerKubernetes1. API Call
2. Get Server Info (Host & Port)
3. Direct Connect to Game Server
Multiple Players GameServer on Kubernetes
Node
Application Kubernetes cluster
AppKubernetes
AppKubernetes
AppKubernetes
AppKubernetes
InternalLB
Node
AuthKubernetes
Cloud Load Balancing
UDP ServerKubernetes
RPC ServerKubernetes1. API Call
Real Time Multiple Player(PVP) Kubernetes cluster
Multiple Players GameServer on Kubernetes
Node
Application Kubernetes cluster
AppKubernetes
AppKubernetes
AppKubernetes
AppKubernetes
InternalLB
Node
AuthKubernetes
Cloud Load Balancing
RPC ServerKubernetes
RPC ServerKubernetes1. API Call
2. Get Server Info (Host & Port)
Real Time Multiple Player(PVP) Kubernetes cluster
Multiple Players GameServer on Kubernetes
Node
Application Kubernetes cluster
AppKubernetes
AppKubernetes
AppKubernetes
AppKubernetes
InternalLB
Node
AuthKubernetes
Cloud Load Balancing
RPC ServerKubernetes
RPC ServerKubernetes1. API Call
2. Get Server Info (Host & Port)
3. Direct Connect to Game Server
Real Time Multiple Player(PVP) Kubernetes cluster
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!
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 の米国または
その他の国における登録商標または商標
です。
● その他記載の会社名、製品名、サービス
名、その他固有名詞は、それぞれの会社
の商標または登録商標です。
● 本文中では©、®、™マークなどは明記して
おりません。
Recommended