LINE GAME PLATFORM の中身を見てみよう / Let's see LINE GAME PLATFORM architecture

by LINE Developers

Slide 1

Slide 1 text

LINE GAME PLATFORM の中⾝を⾒てみよう LINE株式会社ゲームプラットフォーム開発室 @aira813 2020.09.13

Slide 2

Slide 2 text

登壇者紹介 @aira813 サーバーサイドエンジニア 2011: (株)サイバーエージェント新卒⼊社 Amebaマイページ、認証 2016: LINE(株)⼊社ゲームプラットフォーム好きなもの⼤量のアクセス⼤量のデータ⼤事なデータ得意なもの 0を1にする 1を10にする 10を10にするこの辺

Slide 3

Slide 3 text

LINE GAMEの開発者向けプラットフォーム LINE GAME PLATFORMって︖ ※出典︓https://gdc.game.line.me/games/ ※個⼈向けには提供しておりません

Slide 4

Slide 4 text

今⽇話すこと • 主にIn-Game向けAPI周りの話 • プロフィール • ランキング • フレンド • フォロー • ギルド • チャット • 運⽤開発フェーズのエンジニア視点で何を普段やっているのか（よく聞かれますがLINE本体の話は詳しくありません）

Slide 5

Slide 5 text

開発における特徴 • ゲームごとに必要なモジュールは様々 • 汎⽤的な設計vs特化型機能 • 多様なAPIに共通の処理 • レポジトリ、ソースコードの依存 • 基本オンプレ • GHE、Jenkins、社内クラウド • メンテナンス時間はなし、全てonline作業

Slide 6

Slide 6 text

ALPHA 開発⽤多い環境は５フェーズ BETA 開発QA⽤ SANDBOX ゲーム開発⽤ STAGING ゲームQA⽤ RELEASE 本番

Slide 7

Slide 7 text

アーキテクチャについて

Slide 8

Slide 8 text

ゲームごとに環境を分離

Slide 9

Slide 9 text

Configuration⽤サーバー • ゲーム固有の設定からDB情報まで持つアプリケーション • クライアントサーバーにキャッシュ • 中⾝はMongoDB • JSONを保存 • 更新履歴の確認も可能 • Central dogmaに置き換えを検討中 • https://line.github.io/centraldogma/

Slide 10

Slide 10 text

モジュールサーバー周り • サービス⽤データはHBase+Redis cluster • ログ⽤にHadoopやElasticsearchに⾮同期で保存 • キューはApache Kafka • Redis Streamsに置き換え検討中（ミドルウェア減らしたい…） • 検索はElasticsearch • ゲームごと(さらに⽇付ごと)にindexをわける

Slide 11

Slide 11 text

HBase+Redis clusterをまとめた”AEGIS” • マスターデータ⽤のDB(=HBase)とキャッシュ⽤のDB(=Red is cluster)をまとめて処理できる独⾃ライブラリ • データに合わせてモード(※次ページ)を選択

Slide 12

Slide 12 text

選べるモードプロフィール等フォロー、フレンド等設定等キャッシュ等 ※ https://engineering.linecorp.com/ja/blog/hbase-cross-row-cross-table-transaction-processing/

Slide 13

Slide 13 text

実装例（プロフィール） • 1key 1data • JSON形式で保存、schemaはゲーム管理者が⾃由に決められる • 1レコードあたりのデータ量が定まらない • 1ゲームあたりのデータ量も定まらない • HBaseはRowkeyでソートされてregionという単位に分けられてデータが格納される

Slide 14

Slide 14 text

HBase key設計（分散されない例） Keyを “GAME_ID:USER_KEY”とした場合 regionごとにデータが偏る＝アクセスも偏る onlineでregion再割り当てはできるがオペレーションコストがかかる

Slide 15

Slide 15 text

HBase key設計（良い例）先頭にhashをつけてKeyを “hash:GAME_ID:USER_KEY”とした場合 • hashはkeyのCRC32を計算して最初の２⽂字 → 00からffまで • ゲームごとにuser keyを抽出するのは絶望的になるので別途indexを作る。 • Redis sorted set

Slide 16

Slide 16 text

各ゲームに対して⽤意する環境① • モジュールサーバー • ゲーム側で必要なものを選んで初期化→サーバーが⽤意される • ただし、VM,PMの場合は共通のものを使⽤ • その他はdocker containerを起動専⽤の環境が⽤意される

Slide 17

Slide 17 text

各ゲームに対して⽤意する環境② • Redis cluster • 使われ⽅によってデータ量/アクセスの⼤⼩があるので、ゲーム専⽤に⽤意することもある • configuration serverで切り替え場合によっては新しい環境が⽤意される

Slide 18

Slide 18 text

各ゲームに対して⽤意する環境③ • HBase • key設計とキャッシュさえうまくいっていれば特定のゲームに対して負荷が増加してても他のゲームに影響することがほぼない • クラスター管理のコストが⾼い • Elasticsearch • 現状そこまで負荷は⾼くない • Kafka • キューという特性上、⾮同期処理のためすぐにサービス影響が出ることが少ない既存のものを使う

Slide 19

Slide 19 text

よく直⾯する問題

Slide 20

Slide 20 text

移設(Hbase、Redis) • バージョンアップ、スケールダウンetc... • 単純なRedis double writeはConfigurationサーバー+Aegis ですぐに開始できる • テーブル設計変えるならUserごとに移⾏ステータスを管理する必要がある • id1は未移⾏︖ • id1を新しいDBにコピー • 古いデータと新しいデータを⽐較 • id1の移⾏ステータスを更新 • 古いデータと新しいデータを⽐較...

Slide 21

Slide 21 text

ゲームに設置したモジュールのバージョンが古い • ゲームが必要な時のみモジュールアプリを更新できる • ということは • 必要ない限り更新しないので、久々に更新して挙動が変わっていることに気づく • QAチームと密に連携すること • 前のバージョンのcontainerにすぐ切り替えられる

Slide 22

Slide 22 text

Redisはシングルスレッド • キャッシュ⽤途とデータストア⽤途として同時に使っているので気を使わなければならない • うっかり重いクエリを投げると⽌まる • データが⼤きくなると重くなる型がいくつかある • 公式のドキュメントの計算量を確認すること • 特にHash mapは順番に取ることができないので、うっかり⼤きいキーに対して操作しがち

Slide 23

Slide 23 text

低使⽤率APIの把握 • 定期的にHAProxyのログを取得してSwaggerと突き合わせて低使⽤率APIを抽出 • 使わないシステムの運⽤コスト > 必要になった時に新しく作るコスト • 捨てる勇気 ※ JSONを使⽤して表現されたRESTful APIを記述するためのインターフェース記述⾔語。

Slide 24

Slide 24 text

テスト⽤ページを忘れる • CI/CDは当然導⼊ • DeployしたらURL付きでslackに通知

Slide 25

Slide 25 text

まとめ • いかに既存のサービス影響を最⼩限に開発するか、が最重要ポイント • 多すぎると把握もできなくなってくるので忘れないためのシステム作りも⼤事

Slide 26

Slide 26 text

THANK YOU