Upgrade to Pro
— share decks privately, control downloads, hide ads and more …
Speaker Deck
Features
Speaker Deck
PRO
Sign in
Sign up for free
Search
Search
LINE GAME PLATFORM の中身を見てみよう / Let's see LINE G...
Search
LINE Developers
September 13, 2020
Technology
1
810
LINE GAME PLATFORM の中身を見てみよう / Let's see LINE GAME PLATFORM architecture
WOMAN TECH TERRACE 2020での発表資料です。
https://cyberagent.events/site/554169
LINE Developers
September 13, 2020
Tweet
Share
More Decks by LINE Developers
See All by LINE Developers
LINEスタンプのSREing事例集:大きなスパイクアクセスを捌くためのSREing
line_developers
1
2.3k
Java 21 Overview
line_developers
6
1.2k
Code Review Challenge: An example of a solution
line_developers
1
1.3k
KARTEのAPIサーバ化
line_developers
1
540
著作権とは何か?〜初歩的概念から権利利用法、侵害要件まで
line_developers
5
2.2k
生成AIと著作権 〜生成AIによって生じる著作権関連の課題と対処
line_developers
3
2.1k
マイクロサービスにおけるBFFアーキテクチャでのモジュラモノリスの導入
line_developers
9
3.5k
A/B Testing at LINE NEWS
line_developers
3
980
LINEのサポートバージョンの考え方
line_developers
2
1.3k
Other Decks in Technology
See All in Technology
AIエージェントが書くのなら直接CloudFormationを書かせればいいじゃないですか何故AWS CDKを使う必要があるのさ
watany
17
6.7k
DatabricksにOLTPデータベース『Lakebase』がやってきた!
inoutk
0
150
american airlines®️ USA Contact Numbers: Complete 2025 Support Guide
supportflight
1
120
サイバーエージェントグループのSRE10年の歩みとAI時代の生存戦略
shotatsuge
4
750
AWS CDKの仕組み / how-aws-cdk-works
gotok365
10
790
american aa airlines®️ USA Contact Numbers: Complete 2025 Support Guide
aaguide
0
480
IPA&AWSダブル全冠が明かす、人生を変えた勉強法のすべて
iwamot
PRO
2
220
LLM時代の検索
shibuiwilliam
2
620
Contributing to Rails? Start with the Gems You Already Use
yahonda
2
120
ソフトウェアテストのAI活用_ver1.25
fumisuke
1
540
VGGT: Visual Geometry Grounded Transformer
peisuke
1
580
Four Keysから始める信頼性の改善 - SRE NEXT 2025
ozakikota
0
170
Featured
See All Featured
Done Done
chrislema
184
16k
Git: the NoSQL Database
bkeepers
PRO
430
65k
Become a Pro
speakerdeck
PRO
29
5.4k
Reflections from 52 weeks, 52 projects
jeffersonlam
351
21k
Cheating the UX When There Is Nothing More to Optimize - PixelPioneers
stephaniewalter
281
13k
Evolution of real-time – Irina Nazarova, EuRuKo, 2024
irinanazarova
8
830
Improving Core Web Vitals using Speculation Rules API
sergeychernyshev
18
980
RailsConf 2023
tenderlove
30
1.1k
Side Projects
sachag
455
42k
StorybookのUI Testing Handbookを読んだ
zakiyama
30
5.9k
Optimizing for Happiness
mojombo
379
70k
Optimising Largest Contentful Paint
csswizardry
37
3.3k
Transcript
LINE GAME PLATFORM の中⾝を⾒てみよう LINE株式会社 ゲームプラットフォーム開発室 @aira813 2020.09.13
登壇者紹介 @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 開発⽤ 多い 環境は5フェーズ 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(=Red is 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を計算して最初の2⽂字 → 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