本文為英文版的機器翻譯版本，如內容有任何歧義或不一致之處，概以英文版為準。
技術要求評估範本
提供有關資料擷取類型的資訊：
資料擷取類型 |
Y/N |
Description |
Frequency (頻率) |
應用程式存 |
Y |
|
|
API 閘道 |
Y |
|
|
資料串流 |
N |
|
|
Batch 處理 |
N |
|
|
ETL |
N |
|
|
資料匯入 |
N |
|
|
時間序列 |
N |
|
|
提供有關資料使用類型的資訊：
資料消耗類型 |
Y/N |
Description |
Frequency (頻率) |
應用程式存 |
|
|
|
API 閘道 |
|
|
|
資料匯出 |
|
|
|
資料分析 |
|
|
|
資料彙總 |
|
|
|
報告 |
|
|
|
搜尋 |
|
|
|
資料串流 |
|
|
|
ETL |
|
|
|
提供資料量估算：
實體名稱 |
估計記錄數 |
記錄大小 |
資料量 |
玩家 |
1 毫米 |
小於 1 KB |
大約 1 GB （1 毫米 * 1 KB） |
遊戲實例 |
6 毫米 (100 克/天 * 60 天) |
小於 1 KB |
約 6 GB （6 毫米 * 1 KB） |
遊戲使用者對應 |
三百毫米 (6 公釐遊戲 *50 位玩家) |
小於 1 KB |
約三百 GB （300 毫米 * 1 千克） |
注意
資料保留期限為 60 天。60 天之後，資料必須存放在 Amazon S3 以進行分析，方法是使用 DynamoDB 存留時間 (TTL) 將資料自動從 DynamoDB 移出到 Amazon S3。
回答以下有關時間模式的問題：
用戶可以使用該應用程序的時間範圍（例如，工作日的 24/7 或上午 9 點到下午 5 點）？
白天的使用量是否有高峰？ 多少個小時？ 應用程式使用量的百分比是多少？
指定寫入輸送量需求：
實體名稱 |
寫入/日 |
小時/天 |
寫入次數/秒 |
玩家 |
1 萬次更新 |
18 |
< 1 |
遊戲實例 |
30 萬 |
18 |
< 5 |
遊戲使用者對應 |
1,800,000,000 |
18 |
〜 27.777 |
備註
玩家寫入操作：1% 的使用者每天都會更新他們的設定檔，因此我們預計 1,000,000 名使用者可獲得 10,000 次更新。
遊戲實例寫入操作：每天 10 萬遊戲。對於每個遊戲，我們至少有 3 個寫入操作-在創建，開始和結束-所以總共有 300,000 個寫操作。
遊戲用戶映射寫入操作：每場遊戲每天有 50 個玩家，每天 100,000 場比賽。平均遊戲持續時間為 30 分鐘，玩家位置每 5 秒更新一次。我們估計每位玩家平均可獲得 360 次更新，因此總計為 10 萬 * 50 * 360 = 1,800,000,000 次寫入操作。
指定讀取輸送量需求：
實體名稱 |
讀取/天 |
小時/天 |
讀取數/秒 |
玩家 |
200,000 |
18 |
3 |
遊戲實例 |
5,000,000 |
18 |
|
遊戲使用者對應 |
1,800,000,000 |
18 |
〜 27.777 |
備註
玩家讀取操作：20% 的使用者開始遊戲，所以 1 毫米 *0.2 = 20 萬。
遊戲實例讀取操作：每天 10 萬遊戲。對於每個遊戲，我們每個玩家至少有 1 次讀取操作，每場比賽有 50 個玩家，所以總共有 5,000,000 次讀取操作。
遊戲用戶映射讀取操作：100,000 場比賽/天，50 名玩家。平均遊戲持續時間為 30 分鐘，玩家位置每 5 秒更新一次。我們估計每位玩家平均會有 360 次更新，而且每個更新都需要讀取作業，因此總計為 100,000 個 * 50 * 360 = 1,800,000,000 次讀取作業。
指定資料存取延遲需求：
操作 |
百分位數 |
最大延遲 |
讀取 |
30 毫秒 |
一百毫秒 |
寫入 |
10 毫秒 |
50 毫秒 |
指定資料可用性需求：
要求 |
Y/N |
指標 |
備註 |
高可用性 |
Y |
99.9% |
|
RTO |
Y |
1 小時 |
恢復時間目標 |
RPO |
Y |
1 小時 |
復原點目標 |
災難復原 |
N |
|
|
區域內資料複製 |
N |
|
|
跨區域資料複製 |
N |
3 秒延遲 |
哪個AWS 區域？ |
指定安全性需求：
要求 |
Y/N |
備註 |
敏感資料存放區 |
N |
受保護的健康信息（PHI），支付卡行業（PCI）信息，個人身份信息（PII）？ |
靜態加密 |
Y |
|
傳輸中加密 |
Y |
|
用戶端加密 |
N |
|
任何專有或第三方供應商加密庫 |
N |
|
資料存取記錄 |
N |
|
資料存取稽核 |
N |
|
