ロリポップ！ for Gamersの 立ち上げ 久米拓馬 / GMO PEPABO inc. 2024.5.24 Road to SRE Next @ Fukuoka

2 自己紹介 ホスティング事業部　エンジニアリングリード 久米拓馬 @takumakume ● 福岡在住 ● ルアーフィッシング・珈琲焙煎 ● ウイスキーパトロール ● 今年の4月までSREをやっていた ● Kubernetes / Cloudnative

No content

ロリポップ! for Gamers 4 https://news.yahoo.co.jp/articles/444e847fc6ad2a9d98c8951e325c674d8a995668

ロリポップ! for Gamers • パルワールドなどのマルチプレイ⽤ゲーム サーバを提供 • サーバに関する専⾨知識が少なくても、数 クリックで簡単にゲームを始められる

ロリポップ! for Gamers • ゲームの設定を簡単に変更できる機能の提供

タイムライン 2024/2/9 2/29 4/15 6/x イマこ こ プロジェクト発足 無料モニター提供開始 正式版リリース 有料提供開始 13 営業日 • 無料モニター提供開始：最短で市場参⼊するためにコントロールパネルからサーバを作るのでは なく予めセットアップしたサーバを払い出すようにして最⼩⼯数でサービスを開始 • 正式版：コントロールパネルの機能の拡充や、サーバの増強を実施。課⾦機能を除いてリリース • 現在、有料化に向けて進⾏中

本⽇お話すること • アーキテクチャ全体像 • SRE観点での技術選定 • 今後やっていきたいこと

アーキテクチャ全体像

• Webアプリケーションをすぐに実行可能な、Kubernetes クラスタを持っている。 • オンプレミスのデータセンターにゲームサーバが複数実行できる余剰サーバを 持っている。 • 実質13日で、ゲームサーバ市場に参入する。 10 アーキテクチャ 前提

11 アーキテクチャ 全体像 MySQL Frontend (Type script) Backend (Go) アプリケーション DB （Amazon RDS） コントロールパネル Kubernetes Cluster (オンプレミス ) オンプレミスデータセンター Baremetal #1 (Ubuntu/LXD) Baremetal #n (Ubuntu/LXD) LXD Cluster Ceph Cluster VM #1 VM #2 VM #n Webアプリケーション ゲームサーバインフラ

技術選定

• monorepoを採用 • Frontend、Backend、Kubernetes manifests などサービスに関わるコードは単一 のリポジトリで管理する • ソースコード全体の視認性向上 • SREとして、サービス内の各コンポーネントがどこで管理されているかを知るの は重要なポイントである • 1箇所で完結していると調査しやすい • Pull Request毎に動作確認環境を生成できる仕組みを作っており、サービスに関わ る全てのコンポーネントやインフラを一気通貫で結合テストができる 13 技術選定 リポジトリ

14 技術選定

15 技術選定 • Protocol Buffers を採用 • スキーマ駆動開発を行いたい • SREとしては、API仕様がコード化されていると調査が捗る • フロントエンド・バックエンドを効率よく開発したい • サービスの性質上一般的なリソースの CRUDに加えて、RPC的な要素が多く、無理に RESTfulなAPIに落とし込まないでよい • OpenAPIではなくProtocol Buffersである理由 Webアプリケーション

• Connectを採用 • 1つのコードでgRPC, gRPC-Web, Connectプロトコルに対応できる • Frontendからクライアントに配信されたJavaScriptからBackendのAPIを実行する必 要がある • gRPCはブラウザから直接実行することはできない • ブラウザのjsではgRPCが利用するHTTP/2を完全に制御できない • gRPC-Webが必要となる • EnvoyのようなプロキシなしでgRPCのAPIをgRPC-Webで利用できる • SREとしては、構成はシンプルになり調査が楽 16 技術選定 Webアプリケーション

• オンプレミスデータセンターでのベアメタルサーバ を採用 • 競合他社に劣らない価格設定をすると、パブリッククラウドでは赤字 • 今後、ゲームサーバビジネス以外にも柔軟に対応できるインフラ基盤としても活用し たい 17 技術選定 ゲームサーバインフラ

18 技術選定 • canonical/lxd を採用 • コンテナとVMのオーケストレーター • ゲームサーバの効率的な運用のためにオーケストレーションツールは必須 • なぜ LXD ？ • VMとシステムコンテナの両方を標準でサポートしている • コントロールプレーンの導入が比較的楽である ゲームサーバインフラ

19 技術選定 • ストレージとして Ceph を採用 • 分散ストレージシステム • ユーザのデータを特定のサーバに依存しない構成とし、耐障害性やメンテナンス性を 高めるのは今後の運用を見据えて必須である • SREとしては、単一母艦サーバの障害だけで夜間対応を強いられるのは厳しい • スモールスタートかつ短納期の条件下では、コストや時間の関係でエンタープライズ なストレージを調達することはできない ゲームサーバインフラ

20 リリース後に起きた障害を一つ紹介します

• 問題 • 突然一部のIPアドレスと疎通できなくなる • 気づきにくい、問い合わせで発覚 • 1日に数台のサーバで発生 • 正式版リリース以降に調達した新しいのハードウェアで発生していた • 原因 • Bondingで束ねたIntel NICをUbuntuのKernelで利用するとバグを踏む • 解決策 • Kernelのアップデートで解決した 21 障害 ネットワーク障害 Switch Switch Server bonding ハードウェアの違いで問題が起こるリスクも忘れてはいけない

今後のやっていきたいこと

• プロジェクト発足当初は「VPSベースのゲームサーバサービス」だった • 国内の競合はVPSをベースとして、ゲームサーバのテンプレートを提供するパターン • VPSはサーバ全体をユーザが自由に触ることができる • カーネルまで触ることができる、VMを提供するのが一般的 • そのため、ゲームサーバとしてVMを採用した 23 今後のやっていきたいこと ゲームインスタンスのコンテナ化

• 開発を進める中でプロダクトの価値は「ゲームを快適にプレイできるサービス」であると考え るようになった • ゲームをプレイしたり、ユーザがカスタマイズをできる余地があれば、VPSにこだわる必要が ない • コンテナも選択肢となる 24 今後のやっていきたいこと ゲームインスタンスのコンテナ化

25 コンテナ化のメリット • リソースのオーバーヘッドが少ない • 原価を抑えてよりよいサービスを提供するために重要な要素 • 起動が早い • LXDで管理しやすい • コンパネからゲームの設定を変更する機能は、LXDのAPI経由でインスタンスのコマンドを 実行している • VMの場合はゲストOS上のlxd-agentを経由してコマンドが実行されるため、不安定な場 合がある • コンテナの場合はlxdが直接コンテナに実行するため、比較的安定する ゲームインスタンスのコンテナ化 今後のやっていきたいこと

26 ゲームインスタンスのコンテナ化 今後のやっていきたいこと https://ubuntu.com/blog/lxd-vs-docker • LXDで使われているLXCではシステムコンテナが扱える • （語弊はあるが）VMのように扱えるコンテナ

27 • LXCはコンテナ実行時にinitを実行することを前提としている。つまり、複数プロセスを上げ ることができる。 • ゲームサーバ、SSH、etc… などを同時に実行できる。 • Dockerはコンテナ実行時にinitを実行しない。アプリケーションプロセスを実行することを前 提として作られている。つまり、1コンテナ1プロセス。 • 本質としては同じなのでDockerでinitプロセスを上げることで、1コンテナ1プロセスの制約 がなくなる。しかしながら、Dockerは実行プロセスがダウンしたらコンテナがダウンしたり、 ログにstdout/errを用いる点から、複数プロセスを前提としていない仕組みであると言え る。 ゲームインスタンスのコンテナ化 今後のやっていきたいこと

28 • システムコンテナによって、コストを抑えつつ、ゲームサーバのカスタマイズに必要なユーザ 体験を維持することができると考えている。 ゲームインスタンスのコンテナ化 今後のやっていきたいこと

まとめ

まとめ • ロリポップ！for Gamersというゲームサーバを提供するサービ スをリリースしました！ • SREの視点での技術選定 • 今後やっていきたいこと「システムコンテナ」

31 Thank You! Thank You! GMOペパボのSREに興味がある方は @takumakume までご連絡ください！ カジュアル面談でもお待ちしております。