A-7 巨大化するスタンプ・着せかえ販売システム その危機と復活の記録

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

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

巨大化するのは何？

・サービスの規模のお話

・いくつかの事例を紹介

サービスの規模とは

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

・システムの複雑度

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

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

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

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

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

スタンプショップの例

DB Shared拡張

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

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

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

→　拡張の必要

DBとapplicationにまたがったロジックがあった

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

 

消費メモリを減らせ！

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

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

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

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


 

崩壊の始まり

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

・Pre-compute（事前計算）に必要な時間も増大

・SQL queryの負荷増大

→　RedisとCache BuilderをAPIサーバとDBの間に入れる

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

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

LINE's Sharded Redis clusterを活用