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

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

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

WOMAN TECH TERRACE 2020での発表資料です。
https://cyberagent.events/site/554169

LINE Developers
PRO

September 13, 2020
Tweet

More Decks by LINE Developers

Other Decks in Technology

Transcript

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

    View Slide

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

    View Slide

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

    View Slide

  4. 今⽇話すこと
    • 主にIn-Game向けAPI周りの話
    • プロフィール
    • ランキング
    • フレンド
    • フォロー
    • ギルド
    • チャット
    • 運⽤開発フェーズのエンジニア視点で何を普段やっているの

    (よく聞かれますがLINE本体の話は詳しくありません)

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

  13. 実装例(プロフィール)
    • 1key 1data
    • JSON形式で保存、schemaはゲーム管理者が⾃由に決められ

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

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

  19. よく直⾯する問題

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

  26. THANK YOU

    View Slide