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

ロリポップ! for Gamersの立ち上げ/lolipop for gamers launch

ロリポップ! for Gamersの立ち上げ/lolipop for gamers launch

Takuma Kume

May 24, 2024
Tweet

More Decks by Takuma Kume

Other Decks in Technology

Transcript

  1. タイムライン 2024/2/9 2/29 4/15 6/x イマこ こ プロジェクト発足 無料モニター提供開始 正式版リリース

    有料提供開始 13 営業日 • 無料モニター提供開始:最短で市場参⼊するためにコントロールパネルからサーバを作るのでは なく予めセットアップしたサーバを払い出すようにして最⼩⼯数でサービスを開始 • 正式版:コントロールパネルの機能の拡充や、サーバの増強を実施。課⾦機能を除いてリリース • 現在、有料化に向けて進⾏中
  2. 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アプリケーション ゲームサーバインフラ
  3. • monorepoを採用 • Frontend、Backend、Kubernetes manifests などサービスに関わるコードは単一 のリポジトリで管理する • ソースコード全体の視認性向上 •

    SREとして、サービス内の各コンポーネントがどこで管理されているかを知るの は重要なポイントである • 1箇所で完結していると調査しやすい • Pull Request毎に動作確認環境を生成できる仕組みを作っており、サービスに関わ る全てのコンポーネントやインフラを一気通貫で結合テストができる 13 技術選定 リポジトリ
  4. 15 技術選定 • Protocol Buffers を採用 • スキーマ駆動開発を行いたい • SREとしては、API仕様がコード化されていると調査が捗る

    • フロントエンド・バックエンドを効率よく開発したい • サービスの性質上一般的なリソースの CRUDに加えて、RPC的な要素が多く、無理に RESTfulなAPIに落とし込まないでよい • OpenAPIではなくProtocol Buffersである理由 Webアプリケーション
  5. • 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アプリケーション
  6. 18 技術選定 • canonical/lxd を採用 • コンテナとVMのオーケストレーター • ゲームサーバの効率的な運用のためにオーケストレーションツールは必須 •

    なぜ LXD ? • VMとシステムコンテナの両方を標準でサポートしている • コントロールプレーンの導入が比較的楽である ゲームサーバインフラ
  7. 19 技術選定 • ストレージとして Ceph を採用 • 分散ストレージシステム • ユーザのデータを特定のサーバに依存しない構成とし、耐障害性やメンテナンス性を

    高めるのは今後の運用を見据えて必須である • SREとしては、単一母艦サーバの障害だけで夜間対応を強いられるのは厳しい • スモールスタートかつ短納期の条件下では、コストや時間の関係でエンタープライズ なストレージを調達することはできない ゲームサーバインフラ
  8. • 問題 • 突然一部のIPアドレスと疎通できなくなる • 気づきにくい、問い合わせで発覚 • 1日に数台のサーバで発生 • 正式版リリース以降に調達した新しいのハードウェアで発生していた

    • 原因 • Bondingで束ねたIntel NICをUbuntuのKernelで利用するとバグを踏む • 解決策 • Kernelのアップデートで解決した 21 障害 ネットワーク障害 Switch Switch Server bonding ハードウェアの違いで問題が起こるリスクも忘れてはいけない
  9. 25 コンテナ化のメリット • リソースのオーバーヘッドが少ない • 原価を抑えてよりよいサービスを提供するために重要な要素 • 起動が早い • LXDで管理しやすい

    • コンパネからゲームの設定を変更する機能は、LXDのAPI経由でインスタンスのコマンドを 実行している • VMの場合はゲストOS上のlxd-agentを経由してコマンドが実行されるため、不安定な場 合がある • コンテナの場合はlxdが直接コンテナに実行するため、比較的安定する ゲームインスタンスのコンテナ化 今後のやっていきたいこと
  10. 27 • LXCはコンテナ実行時にinitを実行することを前提としている。つまり、複数プロセスを上げ ることができる。 • ゲームサーバ、SSH、etc… などを同時に実行できる。 • Dockerはコンテナ実行時にinitを実行しない。アプリケーションプロセスを実行することを前 提として作られている。つまり、1コンテナ1プロセス。

    • 本質としては同じなのでDockerでinitプロセスを上げることで、1コンテナ1プロセスの制約 がなくなる。しかしながら、Dockerは実行プロセスがダウンしたらコンテナがダウンしたり、 ログにstdout/errを用いる点から、複数プロセスを前提としていない仕組みであると言え る。 ゲームインスタンスのコンテナ化 今後のやっていきたいこと