EFS利用事例 -Craft Warriorsのバトルを支える仕組み-
?
1 like?3,593 views
2018年10月10日に AWS Startup Tech Meetup #013 で発表したLT資料です。 Craft Warriorsでは、EFSをバトル関連のデータを保持するストレージとして採用しています。この資料では、EFSに関わる部分のアーキテクチャとトラブル事例を説明しました。
EFS利用事例 -Craft Warriorsのバトルを支える仕組み-
- 1. EFS利用事例 Craft Warriorsのバトルを支える仕組み 松下 雅和 (@matsukaz) 株式会社トランスリミット CTO 2018.10.10
- 2. @matsukaz 松下 雅和 株式会社トランスリミットCTO カメラ, 折りたたみ自転車,テニス, 卓球, ボウリング AWS歴 7年 自己紹介
- 5. サービス绍介
- 7. バトル画面
- 9. バトルアーキテクチャ
- 10. OpsWorks ALB EC2 EC2 Mediator (Node.js) App Server (Rails) EC2 MQTT Broker EC2 Async Worker (shoryuken) Route 53 Round Robin EFS EFS S3 SQS バトルアーキテクチャ Redis Aurora Aurora
- 11. OpsWorks ALB EC2 EC2 Mediator (Node.js) App Server (Rails) EC2 MQTT Broker EC2 Async Worker (shoryuken) Route 53 Round Robin EFS EFS S3 SQS Redis Aurora Aurora バトル開始 リアルタイム バトルデータ送信 バトル開始時の ユーザデータ保存 リアルタイム バトルデータ処理 リアルタイム バトルデータ保存 バトル開始時／バトル中
- 12. OpsWorks ALB EC2 EC2 Mediator (Node.js) App Server (Rails) EC2 MQTT Broker EC2 Async Worker (shoryuken) Route 53 Round Robin EFS EFS S3 SQS Redis Aurora Aurora バトル終了 ユーザデータ 読み込み バトルログ 非同期アップロード バトルログ アップロード バトル終了時
- 13. OpsWorks ALB EC2 EC2 Mediator (Node.js) App Server (Rails) EC2 MQTT Broker EC2 Async Worker (shoryuken) Route 53 Round Robin EFS EFS S3 SQS Redis Aurora Aurora バトル強制終了時（3分経過後） バトルログ アップロード ユーザデータ 読み込み リアルタイムバトル データ読み込み タイマー起動
- 14. EFSの選定ポイント ? 複数のサーバが同じデータにアクセス ? 同時書き込みはないが、Write直後のReadはある ? 1つのデータの最大サイズは数百KB ? 数秒単位でデータを追記 ? 追記したデータは最後に1つのデータとして利用
- 15. 贰贵厂利用状况
- 16. ファイルシステムの種類 ユーザデータ ユーザデータ x 1 リアルタイムバトルデータ x 4 バトルステップ数 バトル進捗データ 操作コマンド ※ バトル1回あたり アクセス頻度 データ量 Write/Read1回ずつ 2KB 前後 アクセス頻度 データ量 4.5秒に1度上書き 数byte アクセス頻度 データ量 5秒に1度上書き 数百byte アクセス頻度 データ量 10秒に1度追記 (3KB前後) 100KB 前後
- 17. ピーク時のアクセス ? バトル回数は1日216万回 ? 平均バトル時間は150秒程度 ? 平均同時バトル数は 216万回 * 150秒 / 1日 = 3750回 ? ピーク時間帯の同時バトル数は1万回以上 ? サイズが100GB超でバーストせずに安定した状態に
- 18. 贰贵厂利用时のトラブル
- 19. バーストクレジットの枯渇 ? コスト削減のためにこまめにファイルを削除? → 常にバーストし続けて、バーストクレジットを? 使いきった頃に障害発生… ? 導入時はBurstCreditBalanceを必ずチェック！ ? 安定したらサイズを調整
- 20. 宣伝
- 21. ただいま メンバー募集中！