ロリポップ! for Gamersを支えるインフラ/lolipop for gamers infrastructure

https://gmo.connpass.com/event/322928/
15min

Transcript

1. ロリポップ！ for Gamers を 支えるインフラ 久米拓馬 @takumakume / GMO PEPABO inc. 2024.9.9 HosCon 2024
2. 2 自己紹介 ホスティング事業部　エンジニアリングリード 久米拓馬 @takumakume • 福岡在住 • ペパボでの職歴 ◦ インフラ: 3年 ◦ バックエンド: 2年 ◦ SRE: 2年 ◦ エンジニアリングリード: 5月〜 • 釣り・珈琲豆焙煎・ウイスキー買い漁り
3. GMOペパボのホスティング事業部 “ 技術の力でアウトプットのハードルを下げる ” ミッション
4. GMOペパボのホスティング事業部 … 他、全7サービスを運営 サービス開始から 23年 2024年2月リリース！
5. ロリポップ! for Gamers “ 誰でも簡単に マルチプレイが楽しめる ” 数クリックでサーバ を構築
6. タイムライン 2024/2/9 2/29 4/15 プロジェクト発足 無料モニター提供開始 正式版リリース 13 営業日 現在に至る
7. 本⽇お話すること • ロリポップ! for Gamersのインフラ • サービスやアーキテクチャにおける後悔ポイント • インフラにおける現在の取り組み
8. ロリポップ ! for Gamersの インフラ
9. 9 ロリポップ! for Gamersのインフラ 全体像 Frontend Backend (Go) コントロールパネル オンプレミスデータセンター Baremetal #1 (Ubuntu/LXD) Baremetal #n (Ubuntu/LXD) LXD Cluster VM #1 VM #2 VM #n ゲームサーバ Ceph Cluster
10. • オンプレミスデータセンター上のベアメタルサーバ を採用 • 競合他社に劣らない価格設定をすると、パブリッククラウドでは赤字 • canonical/maas を採用 • Metal-As-A-Service • ベアメタルサーバの管理と自動プロビジョニング 10 ロリポップ! for Gamersのインフラ
11. 11 • canonical/lxd を採用 • VM、コンテナのオーケストレーター • サーバの効率的な運用のためにオーケストレーションツールは必須 • なぜ LXD か？ • コントロールプレーンの導入が比較的楽である • VMとコンテナの両方を標準でサポートしている ロリポップ! for Gamersのインフラ
12. 12 • Ceph を採用 • 分散ストレージシステム • ユーザのデータを特定のサーバに依存しない構成とし、耐障害性やメンテナンス性を を向上 ロリポップ! for Gamersのインフラ
13. 13 主な機能の実装 ゲームサーバの操作 サーバの作成・起動・停止 など
14. 14 主な機能の実装 ゲームサーバの設定変更機能 ゲームサーバ内のファイルや プロセスを操作している
15. 15 主な機能の実装 サーバのプロビジョニングやサーバ内の設定変更は LXD APIで実装 Backend API LXD Cluster API LXD Agent ファイル、プロセス コントロールパネル VM ゲームサーバ ゲストOS内の操作は LXD Agent経由
16. 16 LXDを使えばここまで 13日で作れます！
17. 17 イメージ管理
18. 18 すべてのゲームイメージの 開発と運用
19. 19 イメージ管理 Ansibleを用いて ゲームイメージを開 発 Git build server LXD Cluster ︙ Github Actions Node Node Push Deploy Ansible
20. 20 イメージ管理 distrobuilder は使っていない • LXD内部で使われている LXCでは一般的には distrobuilderが使われる • シンプルなYAMLでイメージ を定義できる。 https://linuxcontainers.org/ja/distrobuilder/introduction/
21. 21 イメージ管理 なぜ Ansible ? • 社内的にAnsibleを活用していた • イメージ作成だけでなく、提供済みのユーザ向けのインスタンスへプロビジョニングをし たかった • 例えば、セキュリティアップデートやゲームのバージョンの追加 • distrobuilderはイメージを作るためのものであり、既存のインスタンスをプロビジョニングする ツールではない • Ansibleであればユーザ向けのインスタンスにプロビジョニングできる
22. 22 複数LXDクラスタの管理
23. 23 複数LXDクラスタの管理 • なぜ複数のLXDクラスタが必要になったか • 内部的な話として、ネットワークやベアメタルサーバの構成の都合 • どのような課題があるか • 前提としてLXDクラスタ同士でいい感じに連携してくれることはない • コントロールパネルのバックエンドアプリケーションがどの LXDクラスタにどのサーバが入ってい るかを判断する必要が出てきた • どこに新しくゲームサーバを作ればいいか判断する必要がある • LXDクラスタの増減をバックエンドアプリケーションが意識しなければならない • ホスト、認証情報等
24. 24 複数LXDクラスタの管理 複数のLXDクラスタを透過的に取り扱えるミドルウェアを開発し対応 LXDCC LXD Cluster #1 コントロールパネル … LXD Cluster #2 … Backend API 「LXDCC」 LXD Cluster Cluster by @k1LoW
25. サービス、アーキテクチャの 後悔ポイント
26. 26 サービス、アーキテクチャの後悔ポイント VPSベースのゲームサーバサービスとして始めた • 一般的にVPSはKernelを含むVM全体を操作する自由度と責務がある • 一方で、ゲームマネージャ機能とサーバ側の互換性を維持するために、メンテナンスを行う 必要がある • 責務が曖昧になっている Kernel OS ゲームサーバ、他 VM 利用者の責務 当社のメンテナンス
27. 27 サービス、アーキテクチャの後悔ポイント • VPSではセキュリティ対応の責務も利用者にある • パッケージが古くなって脆弱性がある場合はどうする？ Kernel OS ゲームサーバ、他 VM 利用者の責務
28. 28 利用者にとって、 「ゲームをプレイする」 ことが価値である サーバの管理をしたいわけではない
29. 2024/2/9 2/29 4/15 プロジェクト発足 無料モニター提供開始 正式版リリース 13 営業日 現在に至る この辺りで気づく
30. 30 サービス、アーキテクチャの後悔ポイント VPSではなくゲームサーバとしての提供に転換した • rootユーザを渡さない設計に変更 • セキュリティ対応等のメンテナンスは当社で行う • 利用者がゲームをプレイすることに集中できるサービスへ Kernel OS ゲームサーバ、他 VM 当社の責務
31. インフラにおける現在の取り組み
32. 32 不要なコストを落として より良いサービスへ
33. 33 Frontend Backend (Go) コントロールパネル オンプレミスデータセンター Baremetal #1 (Ubuntu/LXD) Baremetal #n (Ubuntu/LXD) LXD Cluster VM #1 VM #2 VM #n ゲームサーバ Ceph Cluster VPSベースのサービスとして始めたため VMで提供している
34. 34 コンテナ化して リソース効率を上げる
35. 35 • LXDを採用しているのでVMだけでなく、システムコンテナが利用できる • システムコンテナはコンテナ実行時に initを実行することを前提としている。つまり、複数プ ロセスを上げることができる。 • ゲームサーバ、SSH、etc… などを同時に実行できる。 https://ubuntu.com/blog/lxd-vs-docker コンテナ化について
36. 36 • Dockerはコンテナ実行時にinitを実行しない。アプリケーションプロセスを実行することを前 提として作られている。つまり、1コンテナ1プロセス。 • 本質としては同じなのでDockerでinitプロセスを上げることで、1コンテナ1プロセスの制約 がなくなる。 • しかしながら、Dockerは実行プロセスがダウンしたらコンテナがダウンしたり、ログに stdout/errを用いる点から、複数プロセスを前提としていない仕組みであると言える。 ゲームサーバとして提供する場合は、システムコンテナが向いている コンテナ化について
37. 37 コンテナ化について lxd 3301024 11.5 0.2 18760708 1170160 ? Sl 16:14 7:16 /snap/lxd/28373/bin/qemu-system-x86_64 -S -name ubuntu-jammy-vm -uuid 63868117-4c51-46c5-be46-a438ffebe40e -daemonize -cpu host -nographic -serial chardev:console -nodefaults -no-user-config -sandbox on,obsolete=deny,elevateprivileges=allow,spawn=allow,resourcecontrol=deny -readconfig /var/snap/lxd/common/lxd/logs/ubuntu-jammy-vm/qemu.conf -spice unix=on,disable-ticketing=on,addr=/var/snap/lxd/common/lxd/logs/ubuntu-jammy-vm/qemu.spice -pidfile /var/snap/lxd/common/lxd/logs/ubuntu-jammy-vm/qemu.pid -D /var/snap/lxd/common/lxd/logs/ubuntu-jammy-vm/qemu.log -smbios type=2,manufacturer=Canonical Ltd.,product=LXD -runas lxd RSSは約1.1GB quemでVMのプロセスが作られている 素のUbuntuのVMを起動したときのメモリ消費量
38. 38 root 1010234 0.0 0.0 1655816 15772 ... [lxc monitor] /var/snap/lxd/common/lxd/containers ubuntu-jammy-container 1065536 1010244 0.0 0.0 101688 12392 ... \_ /sbin/init 1065536 1010359 0.0 0.0 31344 13752 ... \_ /lib/systemd/systemd-journald 1065536 1010406 0.0 0.0 11100 5760 ... \_ /lib/systemd/systemd-udevd : : : : 1065536 1010562 0.0 0.0 110104 21200 ... \_ /usr/bin/python3 /usr/share/unattended-upgrades/unattended-upgrade-shutdown --wait-for-signal 1065536 1010568 0.0 0.0 15432 8868 ... \_ sshd: /usr/sbin/sshd -D [listener] 0 of 10-100 startups 1065636 1011555 0.0 0.0 16128 6540 ... \_ /lib/systemd/systemd-networkd 素のUbuntuのシステムコンテナを起動したときのメモリ消費量 コンテナを構成するプロセス全体 RSSを合計すると約113MB コンテナ化について
39. • 素朴なUbuntuで検証したところ、システムコンテナにすると RSSを約1GB程度削減できた • VMはコンテナに比べて、 QEMUの層とゲストOSのカーネルの層が必要である • 現状の構成ではメモリがリソースのボトルネックとなっているので、コンテナ化によって一定 のコスト削減効果が見込める 39 コンテナ化について
40. まとめ
41. まとめ • ロリポップ！for Gamers のインフラは、オンプレミスデータセン ターでLXDとCephを⽤いて構成している。 • イメージの管理や複数のLXDクラスタ管理における⼯夫について 紹介した。 • 現在は、コンテナ化によるリソースの効率化に取り組んでいる。
42. 42 Thank You! Thank You! GMOペパボのエンジニアに興味がある方は @takumakume までご連絡ください！ カジュアル面談でもお待ちしております。