セッション名:A-7 巨大化するスタンプ・着せかえ販売システム その危機と復活の記録
登壇者:Haruki.S氏

以下、メモと所感。
【メモ】

巨大化するのは何?

・サービスの規模のお話

・いくつかの事例を紹介

 

サービスの規模とは

・ユーザー数 or ユーザートラフィック

・システムの複雑度

 

単純化したユーザートラフィック

= [LINEのユーザー数] × [ショップを利用する割合]

 

人気商品の販売、大規模なイベントで利用する割合が増加

着せかえの場合、アプリのバージョンアップ

 急激な変化に備えたリソース計画が必要

 

 

スタンプショップの例

DB Shared拡張

現在のスタンプショップはMySQLを利用

どのユーザーがどのshardingに属しているかはアプリケーションレベルで振り分け

 

 

以前はプロモーションの時期を分割するなどしてトラフィックを減らしていた

 拡張の必要

 

DBapplicationにまたがったロジックがあった

ロジックが分散するのは大変なので、同じロジックは1箇所にあったほうがいい


IMG_1668
 

 

消費メモリを減らせ!

APIサーバのメモリが足りなくなり、サービスが提供できなくなる危機があった

メモリ要求量が増え、ついに -Xms128g -Xms128g

フルGCにおびえる日々、サーバーの再起動に3時間

 ナイーブな実装、クリエイターズマーケットが原因

IMG_1669
 

 

崩壊の始まり

・消費メモリは徐々に増大

Pre-compute(事前計算)に必要な時間も増大

SQL queryの負荷増大

 RedisCache BuilderAPIサーバとDBの間に入れる

Redisはインメモリにキーバリューをいれる典型的な利用方法

 

Redis1台では限界があるのでクラスタ化

LINE's Sharded Redis clusterを活用