Upgrade to Pro
— share decks privately, control downloads, hide ads and more …
Speaker Deck
Features
Speaker Deck
PRO
Sign in
Sign up for free
Search
Search
ロリポップ! for Gamersの立ち上げ/lolipop for gamers launch
Search
Takuma Kume
May 24, 2024
Technology
0
2.6k
ロリポップ! for Gamersの立ち上げ/lolipop for gamers launch
Road to SRE Next @ Fukuoka
https://sre-lounge.connpass.com/event/314694/
Takuma Kume
May 24, 2024
Tweet
Share
More Decks by Takuma Kume
See All by Takuma Kume
SRE/インフラエンジニアの市場価値とキャリアパス/Market value and career path for SRE-infrastructure engineers
takumakume
2
1.1k
【新卒研修】共通言語としてのSRE/SRE as a common language
takumakume
0
190
DDoSとの終わりなき戦い2025/endless_battle_with_ddos_attack_2025
takumakume
3
130
事業部CTOの現在地(パネルディスカッション)/Current-location-of-Division-CTO
takumakume
0
150
ロリポップ! for Gamersを支えるインフラ/lolipop for gamers infrastructure
takumakume
0
1k
ホモグラフドメインを検出してみた/detect homograph domain
takumakume
0
640
ソフトウェアの継続的アップデートをコンテナ化によって加速させる/Accelerate continuous software updates with containerization
takumakume
0
5.3k
KubernetesにおけるSBOMを利用した脆弱性管理/Vulnerability_Management_with_SBOM_in_Kubernetes
takumakume
2
2.7k
ホスティング事業におけるSREの取り組みと面白さ/SRE Efforts in the Hosting Business and the Interest of SRE
takumakume
2
3.1k
Other Decks in Technology
See All in Technology
QAを"自動化する"ことの本質
kshino
1
120
Dart and Flutter MCP serverで実現する AI駆動E2Eテスト整備と自動操作
yukisakai1225
0
530
「もっと正確に、もっと効率的に」ANDPADの写真書き込み機能における、 現場の声を形にしたエンハンス
andpad
0
110
ある編集者のこれまでとこれから —— 開発者コミュニティと歩んだ四半世紀
inao
5
3.2k
re:Invent完全攻略ガイド
junjikoide
1
360
お試しで oxlint を導入してみる #vuefes_aftertalk
bengo4com
2
1.5k
【M3】攻めのセキュリティの実践!プロアクティブなセキュリティ対策の実践事例
axelmizu
0
160
ググるより、AIに聞こう - Don’t Google it, ask AI
oikon48
0
910
Post-AIコーディング時代のエンジニア生存戦略
shinoyu
0
280
ABEJA FIRST GUIDE for Software Engineers
abeja
0
3.2k
[mercari GEARS 2025] Keynote
mercari
PRO
1
270
AIを前提に、業務を”再構築”せよ IVRyの9ヶ月にわたる挑戦と未来の働き方 (BTCONJP2025)
yueda256
1
730
Featured
See All Featured
Producing Creativity
orderedlist
PRO
348
40k
RailsConf 2023
tenderlove
30
1.3k
CSS Pre-Processors: Stylus, Less & Sass
bermonpainter
359
30k
What's in a price? How to price your products and services
michaelherold
246
12k
XXLCSS - How to scale CSS and keep your sanity
sugarenia
249
1.3M
Writing Fast Ruby
sferik
630
62k
Keith and Marios Guide to Fast Websites
keithpitt
413
23k
Building an army of robots
kneath
306
46k
Understanding Cognitive Biases in Performance Measurement
bluesmoon
31
2.7k
Automating Front-end Workflow
addyosmani
1371
200k
Helping Users Find Their Own Way: Creating Modern Search Experiences
danielanewman
31
2.9k
The Psychology of Web Performance [Beyond Tellerrand 2023]
tammyeverts
49
3.2k
Transcript
ロリポップ! for Gamersの 立ち上げ 久米拓馬 / GMO PEPABO inc. 2024.5.24
Road to SRE Next @ Fukuoka
2 自己紹介 ホスティング事業部 エンジニアリングリード 久米拓馬 @takumakume • 福岡在住 • ルアーフィッシング・珈琲焙煎 •
ウイスキーパトロール • 今年の4月までSREをやっていた • Kubernetes / Cloudnative
None
ロリポップ! 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 までご連絡ください! カジュアル面談でもお待ちしております。