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

Transcript

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

2. 登壇者紹介 @aira813 サーバーサイドエンジニア 2011: (株)サイバーエージェント新卒⼊社 Amebaマイページ、認証 2016: LINE(株)⼊社 ゲームプラットフォーム 好きなもの

   ⼤量のアクセス ⼤量のデータ ⼤事なデータ 得意なもの 0を1にする 1を10にする 10を10にする この辺

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

4. 今⽇話すこと • 主にIn-Game向けAPI周りの話 • プロフィール • ランキング • フレンド •

   フォロー • ギルド • チャット • 運⽤開発フェーズのエンジニア視点で何を普段やっているの か （よく聞かれますがLINE本体の話は詳しくありません）

5. 開発における特徴 • ゲームごとに必要なモジュールは様々 • 汎⽤的な設計vs特化型機能 • 多様なAPIに共通の処理 • レポジトリ、ソースコードの依存 •

   基本オンプレ • GHE、Jenkins、社内クラウド • メンテナンス時間はなし、全てonline作業

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

   RELEASE 本番

7. アーキテクチャについて

8. ゲームごとに環境を分離

9. Configuration⽤サーバー • ゲーム固有の設定からDB情報ま で持つアプリケーション • クライアントサーバーにキャッ シュ • 中⾝はMongoDB •

   JSONを保存 • 更新履歴の確認も可能 • Central dogmaに置き換えを検 討中 • https://line.github.io/centraldogma/

10. モジュールサーバー周り • サービス⽤データはHBase+Redis cluster • ログ⽤にHadoopやElasticsearchに⾮同期で保存 • キューはApache Kafka •

    Redis Streamsに置き換え検討中（ミドルウェア減らしたい…） • 検索はElasticsearch • ゲームごと(さらに⽇付ごと)にindexをわける

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

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

13. 実装例（プロフィール） • 1key 1data • JSON形式で保存、schemaはゲーム管理者が⾃由に決められ る • 1レコードあたりのデータ量が定まらない •

    1ゲームあたりのデータ量も定まらない • HBaseはRowkeyでソートされてregionという単位に分けら れてデータが格納される

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

15. HBase key設計（良い例） 先頭にhashをつけてKeyを “hash:GAME_ID:USER_KEY”とした場合 • hashはkeyのCRC32を計算して最初の２⽂字 → 00からffまで • ゲームごとにuser

    keyを抽出するのは絶望的になるので別途indexを作る。 • Redis sorted set

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

    専⽤の環境が⽤意される

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

    場合によっては新しい環境が⽤意される

18. 各ゲームに対して⽤意する環境③ • HBase • key設計とキャッシュさえうまくいっていれば特定のゲームに対して負 荷が増加してても他のゲームに影響することがほぼない • クラスター管理のコストが⾼い • Elasticsearch

    • 現状そこまで負荷は⾼くない • Kafka • キューという特性上、⾮同期処理のためすぐにサービス影響が出ること が少ない 既存のものを使う

19. よく直⾯する問題

20. 移設(Hbase、Redis) • バージョンアップ、スケールダウンetc... • 単純なRedis double writeはConfigurationサーバー+Aegis ですぐに開始できる • テーブル設計変えるならUserごとに移⾏ステータスを管理す

    る必要がある • id1は未移⾏︖ • id1を新しいDBにコピー • 古いデータと新しいデータを⽐較 • id1の移⾏ステータスを更新 • 古いデータと新しいデータを⽐較...

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

    • 前のバージョンのcontainerにすぐ切り替えられる

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

    • 特にHash mapは順番に取ることができないので、うっかり ⼤きいキーに対して操作しがち

23. 低使⽤率APIの把握 • 定期的にHAProxyのログを取得してSwaggerと突き合わせて 低使⽤率APIを抽出 • 使わないシステムの運⽤コスト > 必要になった時に新しく作るコスト • 捨てる勇気

    ※ JSONを使⽤して表現されたRESTful APIを記述するためのインターフェース 記述⾔語。

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

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

26. THANK YOU