【レポート】AWS Summit Tokyo 2017: PlayStation™Network のフレンド機能「Friendlist」の AWS 移行事例 #AWSSummit
『AWS Summit Tokyo 2017』が2017年5月30日(火)〜6月2日(金)、グランドプリンスホテル新高輪 品川プリンスホテル アネックスタワーで開催されています。
当エントリではDay3の導入事例トラックから「PlayStation™Network のフレンド機能「Friendlist」の AWS 移行事例 」をレポートしたいと思います。
セッション概要
当セッションの登壇者及び概要は以下の通りです。
セッションレポート
以下、セッションのレポートです。
本セッションの内容
- PSNのFriend ListサービスをオンプレからAWSへ無停止で移行した
- オンプレでの課題
- AWSでどんな構成に
- 何かおきたか
- 教訓
- 規模感
アジェンダ
- Play Station Network
- FriendListについて
- オンプレ版の問題
- AWS移行を決めるまで
- AWS上のFriendListについて
- まとめ
Play Station Network
- Play Stationのためのオンラインサービス
- Store
- 会社のブラウザでゲームを買ったら、ウチの本体に来るとか
- Plus
- 月額500円でゲームができる
- Now
- 対戦、パーティーチャットなど
開発運用体制
- 世界3拠点
- San Diego
- アカウントコマース
- San Francisco
- ストア、ソーシャル
- 東京
- ゲーム、ソーシャル
東京チームの担当
- プロファイル
- イベント/トーナメント
- トロフィー
- フレンド
PS4の発売からネットワークがより多く使われる傾向に
- CDN配信量が増加
- 毎年11-12月に大きく伸びる
- トラフィック15Tbps
- Monthly Active User 7000万人
- 延週利用時間 6億時間
- CloudFront使っている
FriendLlistについて
- いわゆるお友達リスト
- オンラインステータス、遊んでいるゲームなどを参照可能に
- PS4で上限2000人
- ブロックリスト、プライバシー設定
- 様々な機能から参照される
- トロフィーの取得状況など
Friend Listシステムへのアクセス
- 基本的に他のサービスから間接的にアクセスされる
- PSNのユーザエクスペリエンスに直結
- かなりヘビーに使われる
- 落ちた時ツイッターで死ねとか言われる
オンプレ版構成
- LB+フロント4台で1セット
- 24GB
- httpd,tomcat,memcached
- 更新系DB
- CPU Xeon E5 2.6G x2
- MySQL
- 256G
- ユーザ国別に3分割
- 350GB 2億ユーザ
- リード系を別途用意
- リード系とフロントは上記3セットをDNSラウンドロビン
Friend Listの歩み
- 2006/11 PS3発売 PSNの運用開始
- 2010/03 高負荷のためフレンド機能をFriend Listとして別システムから独立
- 2011/9 memcached導入
- 2011/12 PSVita
- 2013/9 フロントリプレイス
- 2013/11 PS4発売 FriendListの上限が100から2000人に増大
- 2014/4 DBリプレイス
Friend Listの問題点
- スケールの難易度の高さ
- メモリの上限256GBに限界
- スケール速度の遅さ
- 機材の物理調達だけで数ヶ月
- 障害時の復旧の遅さ
- レプリケーション
AWS移行の決断、経緯追加要件
- 2016/2 トランザクション数とメモリ利用率が増大、リプレイスしたものの限界が見えてくる
- 2017後半にTokyoオンプレ環境クローズの判断がされていた。リソース限界前にAWS環境に移行することを決定
- PS4向けのサービスがAWSで稼働しており3000以上のインスタンスが稼働
- PS4向けにDeploy Platformを構築済みだった
要求
- ビジネス上
- ダウンタイムを短く
- 万一に備えてロールバック可能な
- 将来のマルチリージョンを見越した構成に
- デベロッパ
- DBのプライマリキーを揃えたい(過去の経緯)
- アプリは新規で作り直したい
- オペレーション
- DBはマネージドサービスを使いたい
- 8月後の2016/10には終わらせたい 11/12月に負荷が上がる
移行プロジェクト
- 2016/10まで
- DBのPrimary Keyをconvertしながら
- アプリは新規作成
- この時点で2016/2
構成、ミドルウェア
- フロント
- ELB+EC2 c3.2xlarge apache
- DynamoDB
- ElastiCache Redis 2系
- Auroraを使わないのはなぜ
- いろいろ検討。マルチAZやリカバリタイムがポイント。
- Redis採用の理由
- 2系を採用
- 将来の追加。ロック機能を使いたい
3ステップで移行
- ダンプ、変換アプリ、データを配置
- シンクロナイザ SNS+SQS
- 最後切り替え
移行における前提
- writeとreadがFQDNが別だった
- ステータスファイルを参照
- メンテナンスモード時はアクセスしない
- 旧システムに更新時にSNSにPublishを追加
- ↑ただ一つ追加した機能
切り替えの進行
- 最初は全アクセスが旧システムに向いた状態
- SNS Publish機能を有効化
- 更新がSQSに貯まる
- 14日以内にSQSの中身を処理せねばならない
- DBからCSVでダンプを取る
- その後に発生した更新はSQSにある
- CSVをDynamoDBに格納
- Primary Keyの変換もやる
- シンクロナイザを使ってSQSのメッセージを新システムのDynamoDBに適用
- Primary Keyの変換も実施
- 1.5億件。空になるまで14時間かかった。開始したのが13日目でギリギリだった
- トラブル
- コンバータの変換が途中で止まったりした
- メモリを喰らい尽くす
- スレッドがロックを取り合う
- PK変換がうまくいかないユーザがいる
- 実装を修正して再実施
- サービスに影響を与えることなくリトライができる環境が重要だった
- コンバータの変換が途中で止まったりした
- 参照系アクセスの一部を新アクセスに向ける
- シンクロナイザのラグは数秒〜20秒
- 全リードアクセスを新しい方へ向ける
- Dynamoのキャパシティが超えていないか確認しつつ
- Redisのスワップ使用量が増加
- 切り戻してreserved memoryを確保、対策した
- ラグが許されないサービスのみ残してほとんどのリードを向ける
- Write系の切り替えのためメンテナンスモードに入れる
- 旧サーバを停止
- メンテナンスモードを解除
- 更新アクセスも新サーバで処理開始
トラブル
- なし(拍手)
結果
- ロールバックせずに済んだ
- Writeアクセスの切り替え
- ダウンタイムは1H以下で済んだ
- 切り替えは10/24に実施
- 11/12月を前に無事移行が完了
規模
- 350G 32億レコード
- read 1500万/H
- write 15k/h
- 12/27 4.4億readアクセス/day達成
- 49億アイテム 2つのテーブルに
AWSに移行してみて
- スケールにおける課題が大幅な改善
- DynamoDB ノーダウンタイム
- ホットパティションが課題
- Elasticache Redis
- ほとんど落ちない
- パラメータチューニングが課題
運用
- DynanamoDBデータバックアップ
- CloudFormation templateを使ってS3にダンプ
最後に
- PSNは今後もAWSを使ってユーザエクスペリエンスを提供していく
- 仲間募集中
- Webサイト見てね
感想
オンラインサービスをオンプレで構築した話から始まって、規模拡大から課題が明らかになり、クラウドに移行を決断、ノンストップでスムーズにサービスを移行した様子が明快に解説されました。実践から語られる知見は重みがありますね。大変わかりやすくて面白かったです。