gistfile1.md

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

15:10-15:50

• ショップ

  • スタンプショップ
  • きせかえショップ

• ショップサービスのユーザー

  • LINEのユーザー x ショップサービスを利用する割合
    • ユーザー：右肩上がり
    • 利用する割合：人気商品の配信開始、大規模なイベント、アプリのバージョンアップ等

• 拡張のきっかけ

  • 各地域のユーザー対象の無料スタンプの配布

• 拡張を行わない場合

  • 配信時間をずらしたり、1週間かけて少しずつプロモーションをしたりして分散する必要がある

• Sharded DBに関連するプロセスが多かった

  • APIサーバープロセス(Java)、Batchプロセス(Python)
  • 変更部分はこの全てに影響する
  • DBとApplicationにまたがったロジックが存在

• 教訓

  • ロジックが分散するのは大変。1箇所にまとまっていたほうが良い
    • DBへのアクセスを目的に応じて抽象化
    • DB Access gateway server(DBとApplicationにまたがったロジックをまとめる)

• システムの複雑度

  • アプリケーションの中での規模の問題

• 消費メモリが増えすぎてしまい、減らさなければという問題

  • 現象

    • APIサーバー20台。メモリ要求量が増え続け、ついに128GBまで到達
    • フルGCが走ると、サービスが止まる
    • サーバーの再起動に3時間かかる
      • サーバーを3つのグループに分けて、1時間x3で分けて対応する必要があった

  • 原因

    • Naiveな実装の内情
      • APIサーバーの要求事項
        • 可能な限り「早い」API。グローバルなモバイルサービスで使われることが主であり、長いResponsetimeはよくない
        • クリエーターズスタンプが台頭し、崩壊が始まった
      • サービスの要求事項
        • 地域や、スタンプの種類、サポートversionによる区別

  • 対策

    • API ServerからRedisへ一部のデータを移譲
      • 消費メモリを削減
      • 水平分散もできる
    • Redisを使っても溢れてしまう -> Redisをクラスタ化
      • モニタリングツールも使える

  • 教訓

    • ナイーブな実装をするときは、その影響やトレードオフについて認識
    • 対処する場合は迅速に

• まとめ

  • システムの規模
    • ユーザー数 or ユーザーTraffic
  • 複雑度
    • サービスの実現したいこと、扱うデータ量
  • 複数の要素が同時に増えると組み合わせで爆発
    • 増える質・量をスケーラブルに解決する技術があるので、それを選択する
  • サービスのいろいろな要求にスケーラブルに答える
    • 新たな機能の追加
    • 量的拡大