Upgrade to Pro — share decks privately, control downloads, hide ads and more …

Go+GCP+Kubernetesを活用したクラウドネイティブなゲームサーバ開発/運用事例【DeNA TechCon 2022】

DeNA_Tech
March 17, 2022

Go+GCP+Kubernetesを活用したクラウドネイティブなゲームサーバ開発/運用事例【DeNA TechCon 2022】

GCP上で Go や Kubernetes, Spannerを活用した開発や運用を、大規模なサービス、チームで実現するにはどうすればよいのか?本セッションでは、DeNA のクラウドネイティブなゲームサーバの開発と運用の取り組みや体制づくりについて紹介いたします。

まず、社内ゲームサーバー基盤Takasho(Go+GCP)を活用し、Kubernetes上にコンテナベースのゲームサーバを構築した開発/運用事例を紹介します。またさまざまな共通部門と協力しつつゲームサーバ開発を行っているため、それらの組織体制なども併せて紹介できればと思います。

データベースにはグローバル規模のRDBであるSpannerを採用しています。Spannerはシャーディング不要でどこまでもスケールさせることができるため、従来のゲームサーバ開発で問題になっていた運用負荷を軽減させてくれています。そんなSpannerの特性を生かしたデータ管理や運用事例、負荷試験を踏まえた上での工夫点に関して紹介します。

また、ゲームサーバ開発者がアプリケーションレイヤーだけではなくインフラレイヤーまでを一気通貫で見る体制をとっています。それを実現するために行ったさまざまな取り組み(CI/CD、Infrastructure as Codeの実践、各種運用ツールなど)に関しても紹介できればと思います。

資料内でのリンク集:
p27, https://cloud.google.com/spanner/docs/dml-versus-mutations#what_are_mutations_

◆ You Tube
https://youtu.be/IKMvWv1D_08

◆ You Tube チャンネル登録はこちら↓
https://youtube.com/c/denatech?sub_confirmation=1

◆ Twitter
https://twitter.com/DeNAxTech

◆ DeNA Engineering
https://engineering.dena.com/

◆ DeNA Engineer Blog
https://engineering.dena.com/blog/

◆ DeNA TechCon 2022 公式サイト
https://techcon2022.dena.dev/spring/

DeNA_Tech

March 17, 2022
Tweet

More Decks by DeNA_Tech

Other Decks in Technology

Transcript

  1. Go+GCP+Kubernetesを活用した クラウドネイティブなゲームサーバ開発/運用事例 2022年 03月 17日 (木) Track B 15:00 -

    16:00 発表者: 今江 健悟 (ゲーム事業本部 ディベロップメント統括部 技術部 第二グループ)
  2. ざっくりの概要 GCP上で Go や Kubernetes, Spannerを活用した開発や運用を、大規模なサービス、チームで実現するにはどうすればよいのか? 本セッションでは、DeNA のクラウドネイティブなゲームサーバの開発と運用の取り組みや体制づくりについて紹介いたします。 • 社内ゲームサーバー基盤Takasho(Go+GCP)を活用し、Kubernetes上にコンテナベースのゲームサーバを構築した

    開発/運用事例を紹介 • システム構成、組織体制、アーキテクチャ、データ管理周り、どんな開発環境なのか、具体的なコードの話 に関して順を追って説明 が本日のセッションの内容になります! 内容 • クラウドネイティブなゲームサーバのシステム構成 • Go や GCP, Kubernetes, Spannerを活用した開発/運用方法について • ゲームサーバ開発を効率化するための工夫点 (CI/CD、Infrastructure as Codeの実践、各種運用ツールなど) 得られる知見
  3. 自己紹介 今江 健悟 (Kengo Imae) 株式会社ディー・エヌ・エー ゲーム事業本部 ディベロップメント統括部 技術部 第二グループ

    経歴 • 2017年4月 株式会社ディー・エヌ・エー 入社 (17新卒) • 2017年6月 運用中タイトルにjoin ◦ 運営~新機能開発、新機能チーム リードエンジニア を経験 • 2019年10月 新規開発中タイトルにjoin ◦ Go言語、Google Cloud Platform(GCP)、Kubernetes、etc. ◦ E.G.G. Japan(Expert of GCP for Gaming Japan)プログラム 修了 ◦ GCP Professional Cloud Architect 認定試験
  4. ざっくりのシステム構成 • Go+GCP+Kubernetes構成、コンテナベース • DeNA内製のTakashoフレームワークをベースにしている • 様々な共通部門と連携しつつ、ゲームサーバ開発を行っている • クラウドネイティブ(※)なシステム ※

    クラウドネイティブ : はじめからクラウドを利用する想定で設計されたシステムのこと、 従来のシステムと区別する際にクラウドネイティブと呼ばれている。
  5. Takashoについて • DeNA内製のWebサーバフレームワーク(Go言語、ゲームサーバの共通基盤システム) • ゲームサーバ構築に必要な機能を提供しつつ、タイトルごとに組み込んで自由にできる高い拡張性がある • 加えて、Takasho環境を構築するためのインフラツールなども提供している developモード serviceモード •

    TakashoをWebフレームワークとして利用するモード • サーバ機能の開発と運用は基本的にタイトルチームが行う • 自由度が高いが、タイトル側にサーバエンジニアが必要 今回はこっち • Takashoをゲームサーバとして利用するモード • サーバ機能の開発と運用は基本的にTakashoチームが行う • タイトル独自の機能開発もTakashoチームが開発 • タイトル側にサーバの開発・運用が できるメンバーは必要ない • 開発工数やスケジュールなどはTakashoチーム に依存する Gopherの原作者はRenee Frenchさんです。
  6. Takashoについて developモード serviceモード • TakashoをWebフレームワークとして利用するモード • サーバ機能の開発と運用は基本的にタイトルチームが行う • 自由度が高いが、タイトル側にサーバエンジニアが必要 •

    Takashoをゲームサーバとして利用するモード • サーバ機能の開発と運用は基本的にTakashoチームが行う • タイトル独自の機能開発もTakashoチームが開発 • タイトル側にサーバの開発・運用ができるメンバーは必要ない • 開発工数やスケジュールなどはTakashoチームに依存する 他職種 サーバ 他職種 基本的に意思決定がタイトル内で完結する 内製タイトル 協働タイトル Takashoチーム 協働タイトル 協働タイトル 協働タイトル 複数のタイトルを同時開発・運用するのに適している
  7. 本セッションのアーキテクチャについて 全体的なシステム構成 1 ドメイン駆動設計(DDD)とクリーンアーキテクチャをベースにした設計思想 使用している技術 2 コンテナ(Docker)ベースのシステムでKubernetes上で構築されている Go言語、Protocol Buffers, Google

    Cloud Platform(GCP), CircleCI, etc. サービスの構成要素 3 APIサーバ、GMTool(管理ツール)、 バトルサーバ(MOサーバ)、Oyakata(マスタ管理)、etc. Takashoが提供している機能をベースに、タイトル独自に拡張/追加している要素がある
  8. ドメイン駆動設計(DDD)とクリーンアーキテクチャ • model, repository, service, usecase, endpoint + α の

    ディレクトリ/クラス構成 • クラス間の依存が整理しやすい、関連するクラスを探しやすい、データレイヤを置き換えやすい、など 基本的には1Endpoint = 1トランザクション でAPIを実装しています。複数のUse caseを組み合わせる必要があるAPIは例外。
  9. ドメイン駆動設計(DDD)とクリーンアーキテクチャ • model, repository, service, usecase, endpoint + α の

    ディレクトリ/クラス構成 • クラス間の依存が整理しやすい、関連するクラスを探しやすい、データレイヤを置き換えやすい、など 疎結合なコードになり、依存を作っているところも把握しやすい エディタでFindする関連クラスがまとめて出てくる
  10. 使用している技術 • Go+GCP+Kubernetesをベースに、クラウドネイティブな技術スタックを使っている ※クラウドネイティブ: はじめからクラウドを利用する想定で設計されたシステムのこと、従来のシステムと区別する際にクラウドネイティブと呼ばれている。 言語 • サーバ : Takashoフレームワーク(Go言語)

    • クライアント Unity (C#) • Protocol buffers, gRPC • REST API (JSON) 通信プロトコル CI/CD、管理ツール • CircleCI, Jenkins, ArgoCD • Vue.js (JavaScript) インフラ • コンテナ技術 Docker, Kubernetes • クラウドサービス (GCP) Google Kubernetes Engine(GKE), Cloud Spanner, Cloud Storage, Cloud MemoryStore, Cloud Pub/Sub, Operations(Cloud Logging & Monitoring), Cloud Load Balancing, Cloud DNS, etc. • Infrastructure as code Terraform This slide is not affiliated with or otherwise sponsored by CNCF.
  11. Google Kubernetes Engine (GKE) • GCPのマネージド Kubernetes サービス、自前でKubernetsクラスタを構築するのは大変。 • プロダクションでのDocker(コンテナ)の運用を考えるとオーケストレーションツールというのが必須

    コンテナ便利なので使いたい 簡単にマシン上にコンテナを 立ち上げられる/増やせる マシン マシン コンテナ運用での考慮事項 リソース管理 スケジューリング デプロイ 死活監視 障害時の復旧 マシン マシン もう限界や… 暇や… なぜKubernetesが必要? リソース管理 オートスケーリング セルフヒーリング etc. 排除 マシン マシン 助かった 神 全部自分がやるわ Kubernetesを利用することで、コンテナ運用に必要な仕組みを自前で構築せずとも利用できるようになる!
  12. サービスの構成要素(APIサーバ) • APIサーバ、管理ツール、WebView、マスタ管理、MBaaSなどが登場します。 • ゲーム系のサーバは全てGKE上で動いています。基本的に gRPC or REST で通信しています。 ゲームAPI

    ❶ Player API ❷ Support API ❸ Admin API • メインのAPIサーバ ◦ アプリ側と通信してゲームロジックを実行するAPIサーバ ◦ 主にプレイヤーに対する操作を行うPodです ◦ gRPCで通信する • サブのAPIサーバ ◦ WebViewやMBaaSの課金処理のコールバックに利用するAPIサーバ ◦ こちらはREST APIを実装してるPodです • 開発者用のAPIサーバ ◦ マスタデータ投入などで使われる開発用のAPIサーバ ◦ 専用のCLIを利用してgRPCで通信する、主にJenkinsなどから実行 This slide is not affiliated with or otherwise sponsored by CNCF.
  13. サービスの構成要素(その他サーバ) • APIサーバ、管理ツール、WebView、マスタ管理、MBaaSなどが登場します。 • ゲーム系のサーバは全てGKE上で動いています。基本的に gRPC or REST で通信しています。 ❺

    LCX (MBaaS) • 内製のモバイル向け共通基盤システム(MBaaS) ◦ 複数のゲームタイトルに対して共通機能を提供するサービスです。 ◦ 認証機能、アプリ内決済をハンドリングする課金機能、PUSH通知などを提供 ◦ Web API と コールバック通知を利用してゲームサーバ側と連携している ❻ マスタ管理(Oyakata) • マスタデータ管理の共通基盤システム ◦ Oyakata: 内製のモバイルゲームの運用に特化したマスタデータ管理用ツール 大規模モバイルゲーム運用におけるマスタデータ管理事例, CEDEC2019, 人西 聖樹, 2019/09/06 ❹ 管理ツール • 開発者用の管理ツール ◦ ユーザー情報の閲覧/アイテム補填などを提供するWebアプリ ◦ 管理ツール上からサーバの設定変更やメンテナンス設定ができる This slide is not affiliated with or otherwise sponsored by CNCF.
  14. • APIサーバ、管理ツール、WebView、マスタ管理、MBaaSなどが登場します。 • ゲーム系のサーバは全てGKE上で動いています。基本的に gRPC or REST で通信しています。 サービスの構成要素(データ管理) ❼

    Spanner ❽ MemoryStore(Redis) ❾ Google Cloud Storage • ゲームデータを管理しているデータベース ◦ Spanner: GCPのグローバル規模のマネージドRDBサービス ◦ 基本的に全てのデータがSpannerで管理されているのでタイトルの心臓部 ◦ 詳細な説明は、データ管理の章で説明します。 • マスタデータのキャッシュなどを管理している Key-Value ストア ◦ Memorystore for Redis : GCPのフルマネージド Redis サービス ◦ マスタデータや新着通知などを管理して、DBへの負荷軽減を行なっている • アセット配信などに使用しているストレージサービス ◦ アプリで使用するマスタデータ、アセットバンドル、WebViewなどを配信 ◦ CDNのオリジンサーバに指定して、アプリにアセット配信を行っている This slide is not affiliated with or otherwise sponsored by CNCF.
  15. Cloud Spanner GCPのグローバル規模のマネージドRDBサービス 1 プライマリーが複数あるプライマリー/レプリカ構成のMySQLのイメージ、NewSQLと呼ばれている種類のもの NewSQL: 新しい形態のSQLデータベースで、既存のRDBと比較して水平スケーリング・分散アーキテクチャなどの特徴を持つ RDBかつNoSQLの特性を備える 2 Spannerの実体はNoSQLで出来ている、RDBの皮を被ったNoSQL

    NoSQL(スケール)とRDB(スキーマ/強整合性/SQLクエリ)の特性を備えたすごいやつ、代わりにお値段が高い※1 シャーディングの複雑さを解消してくれる 3 これまではDBの負荷対策として、アプリ側でユーザー単位で保存するDBの割り振り等のロジックを実装してた このシャーディングを自動でやってくれるため、テーブルの設計さえ適切に行えばアプリ側の処理が不要になる Cloud Spanner ※1 現在は 1ノード(1,000 PU)以下のインスタンスのサイズ変更ができるようになったので更にお安くできます(PU: 処理ユニット 100PU単位の調整が可能)
  16. 4種類のデータタイプ ユーザーデータ • ゲーム内で可変のデータを保存 ◦ 例) ユーザーのクエスト進捗、装備の強化・ 進化状態、アイテムの個数など マスタデータ •

    ゲーム内で不変のデータを保存 ◦ 例) クエストの報酬設定、ボスのステータス、 装備のレアリティなど 翻訳データ • 多言語対応を行うための言語データ ◦ マスタデータのIDに対応して、JP, EN, CN, … で各言語用のカラムを持つ ◦ 例1) お知らせID: 1000 → 各言語のHTML ◦ 例2) 装備ID: 1001000 → 各装備の装備名 その他のデータ • 前述の3種類に含まれないデータ ◦ 例) サーバの設定情報など • ざっくり分けると、4種類のデータをSpanner上で管理しています。
  17. ユーザーデータ: 分散処理とUUIDについて • Spannerは分散DBなので、データが分散されて管理されている。 • PKはデータの性質に関係なく分散させておくのがベストプラクティスなのでUUIDv4を使ってる Root Node Split A

    ~ C D ~ G H ~ M N ~ S T ~ Z 例えばAのデータが たくさん書き込まれると こんな感じに内部でよしなにやってくれるが、できるだけPKの範囲をバラけさせるためにUUIDを使ってる とはいえ、UUIDを使っていても偏りは発生することがある Node Split AA~AH AI~AZ こんな感じにSplitが分割される B ~ G
  18. インターリーブの話 • Spannerにはインターリーブという、テーブル間の親子関係を作る仕組みがあります。 Node Split C ~ D E ~

    F A ~ B ユーザーA1 ユーザーA2 ユーザーA3 : UserId ItemId Num A1 Item1 1 A1 Item2 5 A1 Item3 3 UserId EquipmentId Level A1 EquipmentId1 10 A1 EquipmentId2 2 ▪ アイテム情報 ▪ 装備情報 • インターリーブにより、関連するテーブルのレコードが 「物理的に同じ場所(=Split)に配置される」ようになります • 同じ場所に必要なものがあるのでパフォーマンスも良くなる CREATE TABLE Users ( UserId STRING(36) NOT NULL, ) PRIMARY KEY(UserId); CREATE TABLE UserEquipments ( UserId STRING(36) NOT NULL, ID STRING(36) NOT NULL, EquipmentId INT64 NOT NULL, ) PRIMARY KEY(UserId, ID), INTERLEAVE IN PARENT Users ON DELETE CASCADE; DDLのサンプル
  19. ミューテーション の話 • ミューテーションは、Spanner によってアトミックに適用される一連の操作(挿入、更新、削除)を表す単位 • マスタデータをバージョン分けしている理由の一つに、このミューテーション制限によるものがあります。 20,000 ミューテーション 問題があるので、小分けにしてレコードを追加する必要がある

    テーブルのカラム数やINDEX、DB操作の種類によって算出方法が変わるので注意 マスタリビジョンA マスタリビジョンB マスタ投入 マスタリビジョンA マスタリビジョンB マスタ投入 制限超えないよう に頑張って操作する うむ 参照 切り替えた おわった “
 “
 https://cloud.google.com/spanner/docs/dml-versus-mutations#what_are_mutations_
  20. 開発環境のための取り組み • 大規模なシステムの開発を、運用効率良く行うためにやったこと • 開発サーバの管理 ◦ 開発環境を増やしすぎないための取り組み • 開発フロー ◦

    CI/CDツールを使ったGitOpsベースのデプロイフロー ◦ Infrastructure as Code の実践 • 開発ツール系 ◦ ゲーム用の管理ツール(Vue.js)の紹介 ◦ 属人的なデプロイフローを避けるためのツール開発 ◦ その他便利機能に関して (ユーザーインポートやカスタムタグ機能など ) やったこと 3 1 2
  21. 開発環境のサーバ群 • 基本的に開発環境は複数のサーバが必要で、大規模なチームになると必要なサーバ台数は相当数になります • 今回の例では 本番環境 > staging環境 > QA環境

    > sandbox環境 と その他専用環境を構築しています 安定 sandbox-01 sandbox-02 ・・・ qa-01 qa-02 ・・・ 開発者は作業内容に 応じて環境を切り替える 本番環境 staging 専用環境
  22. 開発環境が増える要因 = バージョン×用途×作業者 • 基本的にバージョンが変わるとサーバのコードも変わる • masterブランチ一本運用だと未来の機能が入るので厳しい “
 “
 バージョン

    用途 作業者 要注意!! ➔ v1.0.0開発、v1.1.0開発、v1.2.0開発、… • 開発環境とQA環境は一緒にできない • 最低1バージョンごとに2環境は必要 • あとはタイトルごとの都合で+αで増える ➔ → 開発環境、QA環境、LQA環境、専用環境、etc. ➔ → 作業者毎にサーバを分けないといけないパターンとは? 大きく分けると、経験則的に3パターン。 1. 作業中は環境全体に影響が出るタスク a. 例えばメンテナンスの実装とか特殊な検証作業など 2. 動作確認に時間変更が必要なもの a. サーバの時間を変えられるだけだと不十分 b. ユーザー毎に時間を変えられる機能が必要 3. 作業者毎にマスタ編集用の環境を用意する a. これをすると人が増えると サーバ台数が爆発してしまう。 3 1 2
  23. ユーザーごとにマスタデータを切り替えられる機能 • 作業者毎にマスタ編集する環境を用意しなくても良くするために作った機能、格段に必要なサーバ数が減る • バージョン×用途×作業者(n→1) 、チームがスケールしても必要な環境数が増えなくなった!! 1. 複数人がマスタデータを編集して開発環境に反映する 2. 自分の変更が他の人に影響するので個人環境を用意する

    必要があった 3. 開発人数が多くなるのと無限にサーバが増えるので辛い 従来の方式 1. マスタリビジョンを更新せず、自分用のマスタデータを登録できる 2. 各ユーザーごとに有効にするマスタリビジョンを設定できる 3. 開発人数が増えても一つのサーバでマスタデータを開発できる 今回の方式 sandbox Aさん環境 Bさん環境 … … 同じサーバ は無理 人が増える : マスタデータ編集のための個人環境はいらない
  24. やってみた結果の話 • 必要なサーバ台数は格段に減ったが、それでも開発環境が30個ほど必要になった • マスタを切り替えるための仕組みが、他の便利機能の土台になっていたりする (例えばアセット類とか)。 • ローカルサーバのマスタデータを編集するための仕組みが必要 (DB書き換える?ツール用意する?工数かかる) •

    ローカルサーバがバグったときに、サーバエンジニアが原因調査 するのが辛い • サーバ更新があるときに各作業者のローカルサーバを更新させる フローと仕組みが必要 マスタ切り替え以外の案 • ユーザーIDを打ち込むのがしんどいのでメールアドレスで切り替えられるようにした • ROMからデバッグ機能でバージョン一覧表示と切り替え機能を作ってもらった • 管理ツール上からマスターバージョン一覧が 見れるようになっている、など この仕組み自体の低難易度化の方法 作業者毎にローカルサーバを立ててもらう案 個人用サーバ方式よりは仕組みが難しい問題 プランナーにも個人適用→全体適用とやってもらえているので仕組みとしては根付いている 概念としてそこまで難しいものではないので、学習コストを下げるためにインタフェースを工夫するのが大切だった → 「個人でマスタと時間をいじれれば個人環境を用意する必要がなくなった」
  25. GitOps • GitHubを使用してアプリケーションとインフラの構成を宣言的に管理するためのCI/CDの手法です。 • Gitリポジトリを信頼できる情報源としてCIとCDの責任分界点を明確にしているという特徴があります ◦ 似た手法のCIOpsと比較すると CIOps: push型、GitOps: pull型

    で仕組みの違いがある ◦ またCIOpsの場合は、CIツールにデプロイに必要な権限を持たせる必要がある • これらの手法はワークフローが全てGitの操作で完結することやGitの機能をフル活用できる(バージョン管 理、変更履歴の追跡、権限管理など)というメリットがあります - GitHub - テスト - CI/CD - ビルド デプロイ ▼ - 環境 - Git操作 差分検知 アプリケーションコード インフラ設定 - Image Repo - 更新
  26. ゲームサーバのブランチ運用 • チーム全体のブランチ運用の話 GitHubを軸にフローを構築するので ブランチ運用がそのままデプロイフローに繋がる 1. X:メジャーアップデートバージョン。周年の大型アップデート時に数字を上げるイメージ 2. YY:クライアントアップデートで数字を上げる 3.

    ZZ:不具合修正やデータアップデート時に数字を上げる verXYYZZ (例: ver10000) 踏まえて、サーバのブランチ運用 • これに従う流れで、サーバのブランチ運用は大きく分けると「バージョンブランチ」と「開発環境ブランチ」というのを決めました。 1. リリース予定のバージョン用のブランチ 2. このブランチにPRがマージされると、そのバージョン用 のイメージのビルドが行われます。 バージョンブランチ 1. 開発環境に紐づくブランチ、開発環境に作業中の コードをデプロイするためのブランチです。 2. このブランチに修正をマージ & プッシュするとその 時点のコードが対応する環境にデプロイされます。 開発環境ブランチ 例: ver10100 例: sandbox-01 ver10100 → ver10110 → ver10111 → ver10200 → ・・・
 リリース データ 更新 不具合 修正 アプデ
  27. ゲームサーバのデプロイフロー 1. CircleCI経由 (開発環境ブランチにpush) 2. Jenkinsジョブ経由 (ボタンポチるだけ) 3. GitHub経由 (インフラの設定変更)

    Jenkinsジョブ ポチる 開発環境ブランチにpush インフラの設定変更 • 開発を続けていて3通りあるのが良さそうとなった 開発者が作業用のコードをデプロイするときに使う • コードをマージするとCI/CDツールが対応する 環境に自動的にデプロイしてくれる • 普段開発者が慣れ親しんでいるGitHub上の作業 だけでデプロイが完結する ビルド済みのイメージをデプロイする時に使う • デプロイするたびにビルド待ちはしたくない(QA環境反映など) • エンジニア以外の職種がGitのコマンド叩くは厳しい 本番反映時や仕組みを分かっている人が使う • 普段は自動化されて意識していない部分を 手で直してデプロイ • 具体的にはインフラリポジトリで管理されて いるGKEのYAMLファイルの設定を書き換えて PRをマージする
  28. ゲームサーバのデプロイフロー • 3種類のデプロイフローをメンテしてるのではなく、ユースケースに合わせてショートカットを用意してるイメージです アプリ CI Pipeline Image Repo インフラ CI

    Pipeline 環境 コード修正 手動デプロイ インフラ設定変更 Build デプロイ (いろんな職種向け) (分かってる人向け) (サーバエンジニア向け) 各フェーズ毎の作業者が最も使いやすいツールをインタフェースにしてる
  29. その他の便利機能 • ユーザーのImport/Export機能 ◦ 任意の環境からユーザデータ吸い出してくる機能 ◦ GMToolからユーザーデータをZIP形式でエクスポートして任意の環境のユーザーにコピーできる • WebView用のカスタムタグ機能 ◦

    スケジュールIDを開催期間表示に変換するタグ、アイテム/キャラの名前/説明をマスタデータの値に 変換するタグ、ユーザーのタイムゾーン&言語に合わせていい感じに時刻表記してくれるタグ、etc. ◦ グローバルタイトルならではの辛み軽減 & よくあるヒューマンエラー防止系の機能 [Date:DateTime format=g date=2021/4/7 time=3:00] → 2021/04/07 12:00 → 4/7/2021 at 3:00 a.m. → 07/04/2021 à 05:00 など [Label:ItemName id=11100001] → 普通の剣 → Common Sword など
  30. Spannerの負荷試験や運用を通しての注意点 RWトランザクションは比較的Abortしやすい • しかもAbortすると全体的に負荷がかかって、他のトランザクションもAbortし始める • RWトランザクションで他ユーザーがアクセスするテーブルはSELECTしてはならない • 誰か一人が書き込んで、他の人が読み込むテーブルはROトランザクションで読み込む • 同じレコードを複数人が更新するのは厳しいので、冗長でも自分専用のレコードに書き込む

    空SELECTは重いので基本的には避ける • MySQLとかでよくある SELECTして無ければINSERT、あったらUPDATE はあまりやらないほうが良い • 事前に全件取得しておいてコード上で存在確認する(空SELECTの発生数を抑える対処法) • 全件SELECTが空SELECTになるケースが高いものは初期レコードを入れておく ← 例えば、ギルド的な機能は  コード上で存在確認できるように  初期レコードを登録しておく方式を取ってます // … ← (省略) 1 2
  31. Spannerの負荷試験や運用を通しての注意点 SpannerのCPU負荷は60%超えるようだと危険 • 80%超えたらエラー率がかなり上がるので注意。Spannerのドキュメントにも65%以下にすることが推奨されている • 高 CPU 使用率に関するアラート: https://cloud.google.com/spanner/docs/cpu-utilization#recommended-max インデックスも出来るだけ貼らない

    • 基本的にはRWトランザクションはインターリーブしたテーブルだけを扱う • インデックスで検索するときもROトランザクションでやらないとAbortしやすい • ユーザーを横断した検索は苦手、管理ツールでもSpannerに対して主キー以外の検索が厳しい IN句もあまり使わない方が良い • 主キーでINで5件取ってくるより、100件全件取得したほうが負荷が軽かったりする※1 • また、クエリパラメータの上限950個にも注意(APIの入力パラメータに上限を設ける、将来のデータ増の考慮) • クエリに関する上限: https://cloud.google.com/spanner/quotas#query_limits 3 4 5 ※1 ただし、レコード数が膨大になると逆転する可能性がありえます、現状の想定は数百件オーダーです。
  32. まとめ • Takashoを使ったdevelopモードのシステム、専門チームと連携しつつ大規模システムを作ってる 導入(ざっくりのシステム構成 / 組織体制) アーキテクチャやサービスの構成要素について DBやデータ管理周りの話 開発環境について 具体的なコードの話

    01 02 • DDD+クリーンアーキテクチャをベースに、Go+GCP+Kubernetsを使ったコンテナベースの構成 03 04 05 • Spanner: シャーディング不要でどこまでもスケールするRDB、その特性を活かしたデータ管理など • Spannerを使ったマスタデータの並行開発の工夫、GitOpsやIasCの実践、便利ツールの紹介 • 自動生成を前提にしたAPI開発、独自の自動生成コードや運用ノウハウを紹介しました