WOMAN TECH TERRACE 2020での発表資料です。 https://cyberagent.events/site/554169
LINE GAME PLATFORMの中⾝を⾒てみようLINE株式会社 ゲームプラットフォーム開発室 @aira8132020.09.13
View Slide
登壇者紹介@aira813サーバーサイドエンジニア2011: (株)サイバーエージェント新卒⼊社Amebaマイページ、認証2016: LINE(株)⼊社ゲームプラットフォーム好きなもの⼤量のアクセス⼤量のデータ⼤事なデータ得意なもの0を1にする1を10にする10を10にするこの辺
LINE GAMEの開発者向けプラットフォームLINE GAME PLATFORMって︖※出典︓https://gdc.game.line.me/games/※個⼈向けには提供しておりません
今⽇話すこと• 主にIn-Game向けAPI周りの話• プロフィール• ランキング• フレンド• フォロー• ギルド• チャット• 運⽤開発フェーズのエンジニア視点で何を普段やっているのか（よく聞かれますがLINE本体の話は詳しくありません）
開発における特徴• ゲームごとに必要なモジュールは様々• 汎⽤的な設計vs特化型機能• 多様なAPIに共通の処理• レポジトリ、ソースコードの依存• 基本オンプレ• GHE、Jenkins、社内クラウド• メンテナンス時間はなし、全てonline作業
ALPHA 開発⽤多い環境は５フェーズBETA 開発QA⽤SANDBOX ゲーム開発⽤STAGING ゲームQA⽤RELEASE 本番
アーキテクチャについて
ゲームごとに環境を分離
Configuration⽤サーバー• ゲーム固有の設定からDB情報まで持つアプリケーション• クライアントサーバーにキャッシュ• 中⾝はMongoDB• JSONを保存• 更新履歴の確認も可能• Central dogmaに置き換えを検討中• https://line.github.io/centraldogma/
モジュールサーバー周り• サービス⽤データはHBase+Redis cluster• ログ⽤にHadoopやElasticsearchに⾮同期で保存• キューはApache Kafka• Redis Streamsに置き換え検討中（ミドルウェア減らしたい…）• 検索はElasticsearch• ゲームごと(さらに⽇付ごと)にindexをわける
HBase+Redis clusterをまとめた”AEGIS”• マスターデータ⽤のDB(=HBase)とキャッシュ⽤のDB(=Redis cluster)をまとめて処理できる独⾃ライブラリ• データに合わせてモード(※次ページ)を選択
選べるモードプロフィール等 フォロー、フレンド等 設定等 キャッシュ等※ https://engineering.linecorp.com/ja/blog/hbase-cross-row-cross-table-transaction-processing/
実装例（プロフィール）• 1key 1data• JSON形式で保存、schemaはゲーム管理者が⾃由に決められる• 1レコードあたりのデータ量が定まらない• 1ゲームあたりのデータ量も定まらない• HBaseはRowkeyでソートされてregionという単位に分けられてデータが格納される
HBase key設計（分散されない例）Keyを “GAME_ID:USER_KEY”とした場合regionごとにデータが偏る＝アクセスも偏るonlineでregion再割り当てはできるがオペレーションコストがかかる
HBase key設計（良い例）先頭にhashをつけてKeyを “hash:GAME_ID:USER_KEY”とした場合• hashはkeyのCRC32を計算して最初の２⽂字 → 00からffまで• ゲームごとにuser keyを抽出するのは絶望的になるので別途indexを作る。• Redis sorted set
各ゲームに対して⽤意する環境①• モジュールサーバー• ゲーム側で必要なものを選んで初期化→サーバーが⽤意される• ただし、VM,PMの場合は共通のものを使⽤• その他はdocker containerを起動専⽤の環境が⽤意される
各ゲームに対して⽤意する環境②• Redis cluster• 使われ⽅によってデータ量/アクセスの⼤⼩があるので、ゲーム専⽤に⽤意することもある• configuration serverで切り替え場合によっては新しい環境が⽤意される
各ゲームに対して⽤意する環境③• HBase• key設計とキャッシュさえうまくいっていれば特定のゲームに対して負荷が増加してても他のゲームに影響することがほぼない• クラスター管理のコストが⾼い• Elasticsearch• 現状そこまで負荷は⾼くない• Kafka• キューという特性上、⾮同期処理のためすぐにサービス影響が出ることが少ない既存のものを使う
よく直⾯する問題
移設(Hbase、Redis)• バージョンアップ、スケールダウンetc...• 単純なRedis double writeはConfigurationサーバー+Aegisですぐに開始できる• テーブル設計変えるならUserごとに移⾏ステータスを管理する必要がある• id1は未移⾏︖• id1を新しいDBにコピー• 古いデータと新しいデータを⽐較• id1の移⾏ステータスを更新• 古いデータと新しいデータを⽐較...
ゲームに設置したモジュールのバージョンが古い• ゲームが必要な時のみモジュールアプリを更新できる• ということは• 必要ない限り更新しないので、久々に更新して挙動が変わっていることに気づく• QAチームと密に連携すること• 前のバージョンのcontainerにすぐ切り替えられる
Redisはシングルスレッド• キャッシュ⽤途とデータストア⽤途として同時に使っているので気を使わなければならない• うっかり重いクエリを投げると⽌まる• データが⼤きくなると重くなる型がいくつかある• 公式のドキュメントの計算量を確認すること• 特にHash mapは順番に取ることができないので、うっかり⼤きいキーに対して操作しがち
低使⽤率APIの把握• 定期的にHAProxyのログを取得してSwaggerと突き合わせて低使⽤率APIを抽出• 使わないシステムの運⽤コスト > 必要になった時に新しく作るコスト• 捨てる勇気※ JSONを使⽤して表現されたRESTful APIを記述するためのインターフェース記述⾔語。
テスト⽤ページを忘れる• CI/CDは当然導⼊• DeployしたらURL付きでslackに通知
まとめ• いかに既存のサービス影響を最⼩限に開発するか、が最重要ポイント• 多すぎると把握もできなくなってくるので忘れないためのシステム作りも⼤事
THANK YOU
line_developers
devops_vtj
pauli
tomzoh
joere
kyonmm
yanzm
picardparis
ritou
brainpadpr
yukihiromori
keiji
mixi_engineers
brettharned
bkeepers
vanstee
sferik
shpigford
shlominoach
frogandcode
paulrobertlloyd
quramy
malarkey
paigeccino
denniskardys