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

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

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