[レポート] PlayStation Network のユーザメッセージ機能「Messages」を支える AWS 技術 #AWSSummit

はじめに

AWS Summit2016 Day3のランチセッションとして行われた、Sony Interactive Entertainment社が登壇した「PlayStation Network のユーザメッセージ機能「Messages」を支える AWS 技術」をレポートいたします。
ランチセッションということで気楽に見れるかとおもいきや、割とメモする内容の多い興味深いセッションでした。

セッション概要

セッション説明文

以下セッション概要を転載します。

PlayStation Network のサービスの一つとして、ユーザ間メッセージサービスの「Messages」があります。近年、Messages は、PS4 / PSVita / スマートフォンを介して利用されるようようになり、利用者数が激増しました。 そこで、利用者の急激な増加に対応するために、オンプレミスから AWS へサービスを継続しながら移行しました。 その中で、なぜ AWS を利用したのか、AWS を利用した開発方法、切り替え時の工夫、DynamoDB 利用時の設計上の工夫、現在から今のシステムを振り返った際の改良ポイントと今後の開発の方向性について、開発者としての視点からご紹介します。

スピーカー紹介

藤本 篤彦 氏

Sony Interactive Entertainment INC システム/ネットワークエンジニアリング＆オペレーション部門 サービス開発課

会社概要とPlayStationNetwork

ソニーインタラクティブエンタテインメント

2016年4月1日設立
「プレイステーション」に関するハードウェア、ソフトウェア、コンテンツ、ネットワークサービスの企画・開発・販売を行う

会場意識調査

PlayStation 4 所持者：2割程度

PlayStation Network(PSN)

• PlayStation 4/PlayStation 3/PSVita/PSPなどのPlayStation機器の楽しみを広げるオンラインサービス。
• ゲーム買ったり、ビデオ買ったり、ネットワークを介してPS4やPS3で参照することができる。
• PSNを通じてオンラインランキングやマルチプレイ、オンライン対戦を行う。
• メッセージの交換やパーティチャットなど、オンライン上で友達とコミュニケーションを取ることができる。

Gaming Function

• 楽しいを共有する「フレンド」
• やりこみ度の「トロフィ」
• 「メッセージ」を使ったコミュニケーション
• 世界と繋がる「オンラインマルチプレイ」
• 「チャット」機能で仲間とおしゃべり

この5つの要素が巡っている

PSNの歴史

• 2006年11月 PS3発売開始
  主にセーブデータの保存
• 2010年6月 PlayStation Plus提供開始
• 2011年12月 PS Vita発売開始
• 2013年11月 PS4発売開始
• 2015年3月 6500万以上 アクティブユーザー

Messagesの機能

• 1スレッド100名まで
• スレッド名やサムネイルの付与可能
• テキストやボイスメッセージ、写真やスタンプ
• メッセージは最大200まで一定期間保存される。
• メッセージ受信範囲設定あり。
  だれからも受け取らないとか、フレンドのみ受け取るとか設定できる

対応デバイス

• PS4
• PS Vita
• PlayStation Messages
  スマートフォンからメッセージを送ることが可能

AWS移行までの流れ

• 2011年12月 PS Vita発売と同時にサービスイン
  最初はオンプレで持っていた。
• 2013年11月 PS4発売・PS Messagesリリース
  アクセス増加
• 2014年7月 クラウド移行の検討開始
• 2015年4月 AWS移行

横軸が時間、縦軸がアクセス数。
オペレーションチームが昼夜頑張って増強していた。

メッセージのやり取りとか参照に大きな問題が発生していた
右下はロードアベレージグラフ
PS4が発売してからAWS移行するまで、毎週増強計画の見直しとか緊急対応に追われた。

メッセージフロントとメッセージバックエンドの2つのクラスタで出来ている。
バックエンドサーバーへのアクセスを極力少なくしたかった。

逼迫がひどすぎて、Re-Shardingをしなければならなかった

オンプレとShardingの限界

• リソース監視、増強から構築までのリードタイム
• ハードウェアの故障対応、セキュリティ対応、機器の保守切れ
  他のサービスで使っていないサーバーをリユースして賄ってる時期があった。
  メモリが少なかったり安定したサーバーではなかった。
• ユーザーの瞬発的なアクセス増加への対応
  ビッグタイトルが出るとそれがトリガーになってアクセス数が増えた。
• Re-Shardingはシステムを止めないで行うのは厳しい

ストレージに求められる要件

• 自動でShardingやスケールアウトしてくれること
• ロックが利用できること
  一つのスレッドに100人までしか入れないから、その100人を担保したくてロックしたかった。
• 運用コストが低いこと
• 可用性が高いこと

満たすのはKey Value Storage(KVS)が有力

KVSの選定

• 開発チーム内ではCassandra1.2の利用が主流
• オペレーションチームからCassandraの運用に難色を示された
  Nodeの総数がある一定数を超えると、線形的に性能が伸びない
  Node総数2桁は大丈夫だけど3桁ではだめだった
  問題発生で再起動するしか手がなかった
• オペレーションチームからAmazon DynamoDBを薦められた

Amazon DynamoDB

2014年7月、DynamoDBに関する情報がとても少なかった。

• 運用事例
• DynamoDBの特性
  要件を満たすかどうか

DynamoDBの調査をすることにした

DynamoDBとは

• KVSである
• 管理不要で信頼性が高い
• 設定値だけで自動スケール
  プロビジョンドスループット（後で説明）
• ストレージの容量制限がない

プロビジョンドスループット

• テーブルごとにReadとWrite、それぞれ必要な分だけスループットキャパシティを割り当てることが可能
• テーブルにアクセスがなくても課金されてしまうので注意しなければならない
• テーブルの特性でReadとWriteを別々に設定可能
  Read1000、Write100など（あくまで例
• ユニット
  Read：1秒あたりの項目読み込み数×4KBの項目サイズ
  Write：1秒あたりの項目書き込み数×1KBの項目サイズ

DynamoDB 機能調査結果

• プロビジョンドスループットを増加した時、線形的に性能が上がることを確認・・・◯
• メッセージスレッド管理のために、ロックが利用できる・・・◯
• 添付データ(画像データ、Voiceデータ)を扱えるか・・・×
  DynamoDBは1レコード最大400KByteまで
  添付データは無理そうだったのでS3を使った
• 一定期間を過ぎたメッセージを自動削除したい・・・×
  TTL設定がないので、アプリで自前対応している

DynamoDB 性能面の調査

• プロビジョンドスループットを増やした時の挙動
• API利用時の消費Capacity Unitの確認
• Java版Amazon SDKのパフォーマンス
  メモリの利用率やAPIの挙動

検証方法

• 検証はすべてAWSを使った
• EC2にJMeter Clientを載せた
• DynamoDBには100万ユーザーのデータを事前に登録した。
• 想定アクセスの2/10、4/10、6/10の負荷をかけた。
• 計測時間は900秒

検証結果

• プロビジョンドスループットの線形性・・・◯
  すべての応答が100ms以内だった
• API利用時の消費Capacity Unitの確認・・・◯
• Java版Amazon SDKのパフォーマンス・・・◯

メッセージストレージをAmazon DynamoDBに採用することに決定

Amazon DynamoDBを利用する上での設計ポイント

DynamoDBへのアクセスは直接コストに繋がるため、どうやってアクセス数を減らすかを共有したい

Amazon DynamoDBへのアクセス数を極力減らす

• Amazon DynamoDBの前段にAmazon Elasticacheを置いた。
• Cache更新は差分更新を行う
  Read Capacity Unitの節約
  パフォーマンスの向上
• 複数レコードを一度に取得したい場合はBatchGetItemではなくQueryを多用

プロビジョンドスループットとパーティション数

• マネジメントコンソールからキャパシティを変えればいいだけなので楽。
• 計画なくプロビジョンドスループットを行うと、パーティション数が増えて期待した性能が出ないことがある。
• パーティションは削減することが出来ない
• パーティションは、スループットとテーブルサイズで決まる

なるべく結果的にキャパシティユニットを増やしたら、パーティションが増えることを念頭に。

自前TTLの実現

TTLがないから自前で用意した。TTL対応しますよと言われて2年・・・
パーティションが分割されないように、いらないデータはなるべく保存したくない

削除はバッチが行うので、削除フラグを設けた。
下のGSIを使うパターンはアイデアで、まだ使っていない

MySQLで行っていた機能の置き換え

並列処理で参加したいというメッセージがあってもロックできるようにした

参照時のRevisionを用いて、条件付き書き込みを行い、楽観的ロックを実行した

新システムのAWSサーバー構成概要

オンプレミスからAWSへの移行

• 一気に移行しようとすると長いメンテンナンス期間が必要。
• メリットはメンテナンス後にオンプレミスを閉じることができる
• デメリットはデータ移行がどのくらいで終わるのか予測が難しい

デメリットが大きかったので逐次移行にした。
オンプレミスとAWSへのを並行稼動させ、逐次データを移行する。

どのようにして逐次データ移行を行うか

• 最初は参照だけ、問題なければ更新を開放ということをした。
• DNSの切り替えを用いた。
• ユーザが最初にAPIアクセスしたタイミングで、逐次データ移行
• 旧システムはメッセージを参照する。
• 一定期間でメッセージは削除するサービスだったので、DynamoDBへのコピーを行わなくて済んだ

AWSに移行してみて

オンプレミス vs AWS の運用コスト比

AWSに移行したらコストが1/4になった。

メリット

• 運用コスト・運用負荷の削減
• 急激な負荷上昇があっても容易に解決可能

課題

• 細かいモニタリングができない
  DynamoDBは思ったような性能が出ないことがある。
• たまにAWS謎挙動
• ホットキーが出来てしまった後の対応
  この問題は未だに解決できていない

今後

• さらなるサーバーの最適化
  GSIやDynamoStreamなどが増えているので検討
• コスト最適化
• ユーザーニーズに応じた機能強化
• PSNユーザーの期待に応えるサービス提供

開発環境

利用するAWSのサービス	開発環境
Amazon EC2	LocalのLinuxマシン
Amazon ElastiCache	LocaoのMemcached Server
Amazon DynamoDB	Amazon DynamoDB
Amazon S3	Amazon S3

開発向けのアカウントを利用。
開発環境の接続はそんなにスループット悪くなかった

感想

今回はPSNの中でも「Messages」サービスのみをピックアップしたセッションでした。
コストが膨らみがちになりやすいDynamoDBは、やはり前段にCache置いたり出来るだけコストを抑える設計をしており、どのプロダクトでもそのへんの設計は重要だということがわかりました。
DynamoDBは使いどころが難しいですが、容量を気にしなくても良いなど利点も多いため、ちゃんと特性を理解して使うことが重要ですね。