메모리 저장소

*이 콘텐츠는 AI(베타)를 사용해 번역되었으며, 오류가 있을 수 있습니다. 이 페이지를 영어로 보려면 여기를 클릭하세요.

MemoryStoreService는 라이브 세션의 모든 서버에서 빠르게 액세스할 수 있는 높은 처리량과 낮은 대기 시간의 데이터 서비스입니다. 메모리 저장소 는 빠르게 변경되고 영구적으로 유지할 필요가 없는 자주 변경되는 임시 데이터에 적합하며, 최대 수명에 도달하면 액세스가 빠르고 사라지므로 내구성이 필요하지 않습니다.세션 간에 유지해야 하는 데이터는 데이터 저장소를 사용하십시오.

데이터 구조

원시 데이터에 직접 액세스하는 대신, 메모리 저장소에는 빠른 처리를 위해 서버 간에 공유되는 세 가지 기본 데이터 구조가 있습니다: 정렬된 맵, 큐열, 그리고 해시 맵.각 데이터 구조는 특정 사용 사례에 적합합니다:

  • 스킬 기반 매치메이킹 - 서버 간 공유 큐 에 스킬 레벨과 같은 사용자 정보를 저장하고 로비 서버를 사용하여 매치메이킹 기간을 정기적으로 실행합니다
  • 교차 서버 거래 및 경매 - 사용자가 실시간으로 변경되는 아이템에 대해 입찰할 수 있는 일반적인 거래를 활성화하여 키-값 쌍의 정렬된 맵으로 다른 서버 간의 거래를 수행합니다.
  • 글로벌 리더보드 - 정렬된 맵 내에서 공유 리더보드에 사용자 순위를 저장하고 업데이트합니다.
  • 공유 인벤토리 - 사용자가 서로 동시에 인벤토리 항목을 사용할 수 있는 공유 해시 맵 에 인벤토리 항목과 통계를 저장하여 인벤토리 항목을 저장합니다.
  • 영구 데이터용 캐시 - 데이터 저장소에서 캐시 및 메모리 저장소에 저장된 영구 데이터를 해시 맵으로 동기화하여 경험의 이행향상시킵니다.

일반적으로 특정 키에 따라 데이터에 액세스해야 하는 경우 해시 맵을 사용하십시오.데이터를 주문하려면 정렬된 맵을 사용하십시오.특정 순서로 데이터를 처리해야 하는 경우 큐를 사용하십시오.

제한 및 할당량

확장성과 시스템 이행유지하기 위해 메모리 저장소에는 메모리 크기, API 요청 및 데이터 구조 크기에 대한 데이터 사용량 할당량이 있습니다.

메모리 저장소에는 만료 시간에 따른 퇴거 정책, 즉 생존 시간(TTL)이 있습니다.아이템은 만료되면 퇴거되고 새 항목을 위한 메모리 할당량이 해제됩니다.메모리 제한에 도달하면 항목이 만료될 때까지 모든 후속 쓰기 요청이 실패하거나 수동으로 삭제해야 합니다.

메모리 크기 할당량

메모리 할당량은 경험이 소비할 수 있는 총 메모리 양을 제한합니다.고정된 값이 아닙니다.대신, 경험의 사용자 수에 따라 다음 수식에 따라 시간이 변경됩니다: 64KB + 1KB * [사용자 수] .할당량은 서버 수준이 아닌 경험 레벨적용됩니다.

사용자가 경험에 참여하면 추가 메모리 할당량이 즉시 사용할 수 있습니다.사용자가 경험을 떠날 때 할당량은 즉시 줄어들지 않습니다.할당량이 낮은 값으로 다시 평가되기 전에 추적 기간이 8일 있습니다. There's a traceback period of eight days before the quota reevaluates to a lower value.

경험이 메모리 크기 할당량에 도달하면 메모리 크기를 늘리는 모든 API 요청이 항상 실패합니다.메모리 크기를 줄이거나 변경하지 않는 요청은 여전히 성공합니다.

관찰 대시보드로 메모리 사용량 차트를 사용하여 실시간으로 경험의 메모리 크기 할당량을 볼 수 있습니다.With the 메모리 사용량 차트, you can view the memory size quota of your experience in real-time using the observability dashboard.

API 요청 제한

API 요청 제한에는 모든 API 호출에 적용되는 요청 단위 할당량이 있습니다.할당량은 1000 + 100 * [동시 사용자 수] 요청 단위당 분당입니다.

대부분의 API 호출은 몇 가지 예외를 제외하고 하나의 요청 단위만 소비합니다:

  • MemoryStoreSortedMap:GetRangeAsync()

    반환된 항목 수에 따라 유닛을 소비합니다.예를 들어, 이 메서드가 10개의 항목을 반환하면 호출은 10개의 요청 단위로 계산됩니다.빈 응답을 반환하면 요청 단위로 계산됩니다.

  • MemoryStoreQueue:ReadAsync()

    반환된 항목 수에 따라 유닛을 소비하지만, 읽는 동안 2초마다 추가 유닛을 소비합니다. just like MemoryStoreSortedMap:GetRangeAsync() , but consumes an additional unit every two seconds while reading.최대 읽기 시간을 waitTimeout 매개 변수로 지정하십시오.

  • MemoryStoreHashMap:UpdateAsync()

    최소 2개의 단위를 소비합니다.

  • MemoryStoreHashMap:ListItemsAsync()

    소비 [검색된 파티션 수] + [반환된 항목] 단위.

요청 할당량은 서버 수준 대신 경험 레벨적용됩니다.전체 요청 속도가 할당량을 초과하지 않는 한 서버 간에 요청을 할당할 수 있는 유연성을 제공합니다.This provides flexibility to allocate the requests among servers as long as the total request rate does not exceed the quota.할당량을 초과하면 서비스가 요청을 제한할 때 오류 응답을 받습니다.

관찰 가능 기능이 있으면 실시간으로 경험의 요청 단위 할당량을 볼 수 있습니다.

데이터 구조 크기 제한

단일 정렬된 맵이나 큐에 대해서는 다음 크기 및 아이템 수 제한이 적용됩니다:

  • 최대 아이템 수: 1,000,000
  • 정렬된 맵에 대한 키를 포함하여 최대 총 크기: 100MB

파티션별 제한

파티션 제한을 참조하십시오.

모범 사례

메모리 사용 패턴을 최적으로 유지하고 한계에 도달하지 않으려면 다음 모범 사례를 따르십시오:

  • 처리된 항목을 제거합니다.: 큐와 정렬된 맵에 대해 메서드를 사용하여 읽은 항목을 일관되게 정리하면 메모리를 해제하고 데이터 구조를 최신 상태로 유지할 수 있습니다.

  • 데이터를 추가할 때 가능한 가장 작은 시간 프레임으로 만료 시간을 설정합니다.: 기본 만료 시간은 둘 다 MemoryStoreQueue:AddAsync() 및 MemoryStoreSortedMap:SetAsync()에 45일이지만, 가능한 가장 짧은 시간을 설정하면 메모리 사용 할당량을 채우지 않도록 오래된 데이터를 자동으로 정리할 수 있습니다.

    • 메모리 할당량을 초과할 위험이 있고 전체 경험을 중단시킬 수 있는 문제를 일으킬 수 있기 때문에 긴 만료 기간으로 많은 양의 데이터를 저장하지 마십시오.
    • 항상 불필요한 항목을 명시적으로 삭제하거나 짧은 항목 만료 기간을 설정하십시오.
    • 일반적으로 메모리와 아이템 만료를 안전 장치로 방지하기 위해 사용 중지된 아이템이 메모리를 오랫동안 점유하지 않도록 명시적 삭제를 사용해야 합니다.

  • 메모리에 필요한 값만 유지합니다.

    예를 들어, 경매 집 경험의 경우 최고 입찰만 유지하면 됩니다.하나의 키에서 MemoryStoreSortedMap:UpdateAsync()를 사용하여 데이터 구조에 모든 입찰을 유지하는 대신 가장 높은 입찰을 유지할 수 있습니다.

  • 지수 백오프를 사용하여 API 요청 제한을 유지하도록 도와주세요.

    예를 들어, DataUpdateConflict 를 받으면 2초 후, 4, 8 등을 다시 시도할 수 있습니다.올바른 응답을 얻기 위해 지속적으로 MemoryStoreService에 요청을 보내는 대신

  • 샤딩으로 거대한 데이터 구조를 여러 작은 구조로 분할하여 데이터를 더 효율적으로 사용합니다.

    모든 것을 하나의 큰 데이터 구조에 저장하는 대신 더 작은 구조에서 데이터를 관리하는 것이 종종 더 쉽습니다.이 접근법은 사용 및 속도 제한을 피하는 데에도 도움이 될 수 있습니다.예를 들어, 키에 접두사를 사용하는 정렬된 맵이 있는 경우 각 접두사를 자체 정렬된 맵으로 분리하는 것을 고려하십시오.특히 인기 있는 경험의 경우, 사용자 ID의 마지막 숫자에 따라 사용자를 여러 맵으로 분할할 수도 있습니다.

  • 저장된 값 압축.

    예를 들어, 저장된 값 크기를 줄이기 위해 LZW 알고리즘을 사용하는 것을 고려하십시오.

관찰 가능성

관찰 대시보드 는 메모리 저장소 사용을 모니터링하고 문제를 해결하기 위한 통찰력과 분석을 제공합니다.메모리 사용량과 API 요청의 다양한 측면에 대한 실시간 업데이트 차트를 사용하여 경험의 메모리 사용 패턴을 추적하고, 현재 할당된 할당량을 보고, API 상태를 모니터링하고, 성능 최적화를 위한 잠재적 문제를 식별할 수 있습니다.

다음 표에서는 관측성 대시보드의 상태별 요청 수 및 API x 상태 차트에서 사용할 수 있는 API 응답의 모든 상태 코드를 나열하고 설명합니다.이러한 오류를 해결하는 방법에 대한 자세한 정보는 문제 해결을 참조하십시오.오류와 관련된 특정 할당량이나 제한에 대해서는 한도와 할당량을 참조하십시오.

상태 코드설명
성공성공.
데이터구조 메모리 오버리미트 DataStructureMemoryOverLimit데이터 구조 레벨 메모리 크기 한도(100MB)를 초과합니다.
데이터 업데이트 충돌동시 업데이트로 인한 충돌.
액세스 거부경험 데이터에 액세스할 수 없습니다. 이 요청은 요청 단위를 소비하거나 할당량을 사용하지 않습니다.
내부 오류내부 오류.
무효 요청요청에 필요한 정보가 없거나 잘못된 정보가 있습니다.
데이터구조 아이템 한도 초과데이터 구조 수준 항목 수 제한(1M)을 초과합니다.
아이템 찾을 수 없음MemoryStoreQueue:ReadAsync() 또는 MemoryStoreSortedMap:UpdateAsync() 에서 아이템을 찾을 수 없습니다. ReadAsync() 매 2초마다 조사하고 큐에 있는 아이템을 찾을 때까지 이 상태 코드를 반환합니다.
데이터구조 요청 한도 초과데이터 구조 레벨 요청 단위 한도(분당 10만 요청 단위)를 초과합니다.
파티션 요청 한도 초과파티션 요청 단위 한도를 초과합니다.
총 요청 한도 초과유니버스 수준 요청 단위 한도를 초과합니다.
총 메모리 제한 초과유니버스 수준 메모리 할당량을 초과합니다.
아이템 값 크기가 너무 커값 크기가 제한(32KB)을 초과합니다.

다음 표에서는 현재 관측성 대시보드에서 사용할 수 없는 클라이언트 측 상태 코드를 나열합니다.

상태 코드설명
내부 오류내부 오류.
게시되지 않은 장소MemoryStoreService를 사용하려면 이 장소를 게시해야 합니다.
무효한 클라이언트 액세스MemoryStoreService는 서버에서 호출해야 합니다.
유효하지 않은 만료 시간만료' 시간은 0과 3,888,000 사이여야 합니다.
무효 요청값을 JSON으로 변환할 수 없습니다.
무효 요청sortKey를 유효한 숫자나 문자열로 변환할 수 없습니다.
변환 콜백 실패변환 콜백 함수를 호출하지 못했습니다.
요청이 제한됨최근 MemoryStores 요청이 한 가지 이상의 제한을 충돌시켰습니다.
업데이트 충돌 업데이트Conflict최대 재시도 횟수 초과.

문제 해결

다음 표에서는 응답 상태 코드별로 권장되는 솔루션을 나열하고 설명합니다.

오류문제 해결 옵션
데이터구조 요청 한도 초과 / 파티션 요청 한도 초과

  • 다른 변수에 정보를 저장하여 30초와 같은 특정 시간 간격 후에 로컬 캐시를 추가하고 다시 확인합니다.: 상태별 요청 수를 사용하여 더 많은 성공 응답을 받고 있는지 여부를 확인하려면 RequestCount by Status 차트를 사용합니다.실패한 요청으로
    • 5> 번 타격 횟수를 제한하십시오.: 요청 사이에 짧은 지연 구현.:9> 최선의 방법론을 따르십시오, 포함:

    • 데이터 구조가 상당한 수의 DataStructureRequestsOverLimit / PartitionRequestsOverLimit 응답을 받으면 데이터 구조를 분할합니다.:
    • 합리적인 요청 보내다비율을 찾기 위한 지수 백오프 구현.
총 요청 한도 초과
데이터구조 아이템 한도 초과
  • 메모리 크기 줄이기에 대한 최선의 방법을 적용합니다.
데이터구조 메모리 오버리미트 DataStructureMemoryOverLimit
총 메모리 제한 초과
데이터 업데이트 충돌
  • 요청 간의 짧은 지연을 구현하여 여러 요청이 동시에 동일한 키를 업데이트하는 것을 방지합니다.:
  • 정렬된 맵의 경우, 다음 코드 샘플과 같이 요청을 취소하기 위해 메서드의 MemoryStoreSortedMap:UpdateAsync() 호출 함수를 사용하십시오:
    • Example of Aborting Request
    local MemoryStoreService = game:GetService("MemoryStoreService")

    local map = MemoryStoreService:GetSortedMap("AuctionItems")

    

    function placeBid(itemKey, bidAmount)

        map:UpdateAsync(itemKey, function(item)

            item = item or { highestBid = 0 }

            if item.highestBid < bidAmount then

                item.highestBid = bidAmount

                return item

            end

            print("item is "..item.highestBid)

            return nil

        end, 1000)

    end

    

    placeBid("MyItem", 50)

    placeBid("MyItem", 40)

    print("done")
  • 충돌을 피하기 위해 효율적으로 호출하고 있는지 조사하십시오 MemoryStoreService .이상적으로, 요청을 과도하게 보내면 안 됩니다.:
  • 큐와 정렬된 맵에서 읽기 방법을 사용하여 항목을 일관되게 제거합니다.
내부 오류

    Roblox 상태 페이지를 확인합니다. 경험의 유니버스 ID와 관련된 문제를 설명하는 오류 보고서를 파일합니다.

무효 요청
  • 요청에 올바르고 유효한 매개변수를 포함했는지 확인하십시오. 무효 매개변수의 예에는 다음이 포함됩니다.
    • 빈 문자열
    • 길이 제한을 초과하는 문자열
아이템 값 크기가 너무 커
  • 아이템 값을 여러 키로 분할하거나 분할합니다.
    • 그룹화된 키를 구성하려면 키에 prefix를 추가하여 알파벳순으로 정렬합니다.
  • 저장된 값을 인코딩하거나 압축합니다.

Studio에서 테스트 및 디버깅

MemoryStoreService의 데이터는 Studio와 프로덕션 사이에 격리되어 있으므로 Studio에서 데이터를 변경하면 프로덕션 동작에 영향을 주지 않습니다.즉, Studio의 API 호출이 프로덕션 데이터에 액세스하지 않아 프로덕션에 가기 전에 안전하게 메모리 저장소와 새로운 기능을 테스트할 수 있습니다.

스튜디오 테스트는 프로덕션과 동일한 제한과 할당량을 갖습니다.사용자 수에 따라 계산된 할당량의 경우 Studio 테스트용 유일한 사용자이기 때문에 결과 할당량이 매우 작을 수 있습니다.Studio에서 테스트할 때 액세스 및 권한을 확인하기 위한 몇 가지 추가 검사로 인해 프로덕션에서의 사용에 비해 약간 더 높은 대기 시간과 오류 발생률을 알게 될 수도 있습니다.

라이브 경험에서 메모리 저장소를 디버깅하거나 스튜디오에서 테스트할 때의 정보는 개발자 콘솔을 사용하십시오.