가이드에 따르면 "일반 랭킹 조회에는 DB요금이 발생하지 않는다"라고 되어있습니다.
그런데 일반 랭킹을 구현하여 데이터를 읽어오면, 결제 관리 메뉴에서 DB요금(및 처리량)이 증가되어있었습니다.
랭킹 데이터 조회에 사용된 함수는 아래와 같습니다.
- Backend.Rank.GetMyRank
- Backend.Rank.GetRankByUuid
일반 랭킹의 경우 데이터 업데이트 외에는 DB요금이 발생하지 않는 것으로 이해했는데 아닌가요?
안녕하세요.
NoSQL 함수 사용시, 인증단계에서 DB를 사용하기 때문에 소량의 DB 사용량이 발생할 수 있습니다.
개발자문서에는 별도의 설명이 적혀있지 않아 혼란을 드려 대단히 죄송합니다.
이부분은 최대한 빠르게 개발자문서에 반영되도록 수정하겠습니다.
피드백 감사드립니다.
이대로라면 유저가 랭킹 기록을 조회할 때마다 DB요금이 발생한다는 말인데,
실시간 랭킹도 아니고 6시간마다 갱신되는 랭킹 데이터를 조회할 때마다
DB요금이 발생한다는 것은 과하다는 생각이 드네요.
게다가 제가 확인한 바로는,
위의 두 함수로 나의 랭킹 데이터 및 유저들의 랭킹 데이터를 조회 했을때
약 10의 읽기 처리량이 증가했습니다.
가이드에 따르면 읽기처리량 1은 8kb의 데이터를 처리한다고 되어있습니다.
그렇다면 랭킹을 한번 조회하는데 80kb의 데이터 처리를 했다는 것인데,
제가 랭킹에 사용하는 데이터는 score에 쓰이는 int값 1개와
extraData로 쓰이는 string값 1개(테스트 당시 5바이트 string) 그렇게 딱 두개였고,
랭킹 데이터도 테스트용으로 한명의 데이터밖에 없었습니다.
그런데 아무리 인덱스와 인증정보 등이 추가된다고해도 이해하기 어려운 데이터 처리량이었습니다.
이 상황에서 유저가 장난 또는 아무 생각없이 랭킹 조회를 계속 한다면 무시하기 힘든
DB요금이 발생할 수도 있다는 우려가 됩니다.
해당 케이스의 경우 읽기 처리량이 높게 데이터에 비해 보다 높게 측정된거 같아 저희쪽에서도 확인을 해보겠습니다.
확인 후, 다시 답변 드리겠습니다. 감사합니다.
오늘 중에는 답변이 오길 기대했는데, 답변이 아직 없으시네요.
빠른 확인 부탁드리겠습니다.
안녕하세요.
확인한 바로는 랭킹 조회시 최대 5미만의 읽기량이 사용되는 것으로 확인되었습니다.
혹시 로그인 이후에 바로 길드 랭킹을 조회하실 경우, 로그인 읽기&쓰기량과 동시에 계산될 수 있 수 있으니 확인해주시면 감사하겠습니다.
또한 출시설정에 테스트로 되어있는 경우 인증 부분에서 활성유저가 10명인지 체크하는 데 디비 사용량이 좀 더 많이 발생할 수 도 있으니 이부분도 체크해주시면 감사하겠습니다.
-랭킹 조회 전 데이터 사용량
-랭킹 조회 후 데이터 사용량
못 믿으시는 것 같아서 제가 테스트 한 결과를 올려드립니다.
이 결과는 출시 설정을 라이브로 둔 상태로, 유저 인증 및 초기화 단계를 모두 거치고 몇 분이 지나서
더 이상 데이터 처리량 증가가 더 이상 없는 것을 확인하고 오직 랭킹 데이터 조회로만 진행한 것 입니다.
보시는바와 같이 읽기 데이터 처리량은 10, 쓰기 데이터 처리량은 2가 증가하였습니다.
쓰기 데이터 사용량은 왜 증가하는지 이것도 이해하기 힘드네요.
아무튼 실제로 말씀하신 것보다 더 많은 데이터 처리 비용이 들고 있습니다.
(몇 번이고 반복해서 테스트해본 결과 똑같은 결과였습니다.)
그리고 말씀하신대로 "최대 5미만의 읽기 사용량"이 나왔다고 해도,
json데이터라 string으로 데이터가 길어질 수 밖에 없다고 해도,
40kb면 이미 이 정도는 처리 하고도 남을 많은 데이터량 입니다.
그리고 자꾸 데이터 처리량이 몇이냐로 답변주시는데, 그것은 부차적인 내용입니다.
가장 중요한 이 질문의 핵심인,
일반 랭킹에서는 6시간 마다 랭킹 집계를 하기 때문에,
여기에 데이터 처리량 요금이 드는 것은 부당하다고 말씀드렸는데,
그것에 관련한 답변은 없으시군요.
실시간 랭킹 집계의 경우에 랭킹 조회에 DB처리량이 사용된다는 것은 이해하지만,
일반 랭킹에서는 이미 집계된 결과를 불러오기만 하는데 왜 DB가 사용된다는 것인지
아무리 생각해도 이해가 안 됩니다.
실제로 콘솔에서 랭킹데이터를 조회하면 데이터 처리량 변화는 없습니다.
만약 이것이 말씀하신 인증단계 처리 때문에 그런 것이라면 무슨 인증을 어떻게 하는지
그것도 설명이 필요하겠습니다.
읽기 10, 쓰기 2의 데이터 처리량을 그냥 대충 인증 때문에 데이터 처리량이 늘어나니 이해하라고 하시면
백엔드 서버 내부에서 데이터 처리를 어떻게 하는지 저희가 어떻게 알겠습니까?
솔직히 랭킹에서 예상치도 못하게 많은 데이터 처리량이 발생하니까,
사용자 입장에서 모든 데이터 처리량이 효율적인지 비효율적인지 확인할 수도 없는 노릇이고,
다른 기능에서도 발생하는 데이터 처리량에 대해서도 신뢰할 수 있는가에 대한 의문이 듭니다.
이 문제는 앞으로의 사용 요금에 대한 문제로 백엔드를 선택하는데 중요한, 민감한 사항이라고 생각합니다.
그런데 꽤 오랜 시간 기다린 답변치고는 너무 간편한 답변만 주신 것 같네요.
좀 더 이해할 수 있는 명확한 답변을 바랍니다.
유저의 랭킹을 조회할때 콘솔에서는 1번의 읽기가 수행됩니다. 이는 랭킹의 정보를 확인하기 위해서 필요한 작업입니다.
SDK로 요청을 보내면 아래와 같은 작업이 일어납니다.
- 뒤끝 서버는 모든 요청에 대해서 인증과정을 거칩니다. 유저가 요청을 보냈을때 유효한 accessToken으로 요청을 보냈는지 확인하는 과정에서 1번의 읽기 처리가 수행됩니다.
이떄 서버로 요청을 보낸 유저의 정보와 서버에 저장되어있는 유저와 정보가 일치하는지 확인하기 위해 1번의 읽기가 더 수행됩니다. 그리고, 각 유저마다 저장되어있는 암호화키를 서버에서 읽어옵니다. 이때도 1번의 읽기가 수행됩니다. 이후 모든 요청을 암호화 합니다.
그리고 마지막으로 만약 accessToken이 생성된지 하루가 지났다면 accessToken을 갱신하기 위해 1번의 쓰기가 수행됩니다.
여기까지가 라이브로 설정된 프로젝트가 인증서버에서 진행하는 과정입니다.
만약 프로젝트가 라이브로 설정되어 있지 않다면 10au를 확인하기 위해 추가적으로 읽기 처리가 발생합니다.
-
https://developer.thebackend.io/unity3d/guide/ranking/rank/
에서 설명되어있는 특정 랭킹에서 게임 유저 랭킹 받아오기를 진행할 경우 콘솔과 같이 랭킹의 정보를 확인하기 위해 1번의 읽기 처리가 수행됩니다.
여기까지가 뒤끝이 특정 랭킹에서 유저의 랭킹을 받아올때의 처리 과정입니다.
6시간 마다 랭킹 집계가 수행되기 전에 특정 랭킹의 정보를 확인하는 부분에서 읽기 처리가 발생합니다. 이는 랭킹이 몇개가 만들어져있는지, 랭킹에 등록된 유저의 수가 몇명인지, 지급되는 보상이 있는지에 따라 조금씩 차이가 발생할 수 있습니다.
아마도 이부분에 대한 답변을 원하시는 것 같아 더 자세하게 설명을 드리겠습니다.
6시간마다 갱신되는 랭킹에는 길드 랭킹과, 일반 랭킹이 존재합니다. 이때 랭킹의 정보를 받아오는 부분에서 읽기 처리가 발생한다고 위에 말씀드렸습니다. 이는 sdk와 콘솔에서도 같은 처리가 발생합니다. 각 랭킹의 고유 UUID로 랭킹의 상세 정보를 확인하기 위함입니다.
이후 유저의 정보를 확인하는 부분에서 랭킹에 등록된 유저의 수만큼 읽기 처리가 수행됩니다.
랭킹 보상을 지급하는 랭킹일 경우 추가로 2번의 읽기 처리와 보상받는 유저의 수만큼 쓰기가 수행됩니다.
모든 로직이 어떻게 수행되고 이때 얼마의 DB 읽기/쓰기 처리가 발생하는지 일일이 다 말씀드리지 못하는 점 양해바랍니다.
더 궁금한 점이 있으시거나, 이해가 되지 않는 부분이 있으시면 추가로 질문을 남겨주시면 빠르게 답변 드리도록 노력하겠습니다. 감사합니다.
상세하고 빠른 답변 감사드립니다.
-accessToken 확인 1번
-유저정보 검증 1번
-암호화키 검증 1번
-랭킹의 UUID 확인 1번
-실제 랭킹 데이터 읽기 1번
제가 이해한게 맞다면 한번의 랭킹 데이터 조회를 위해 이렇게 5번의 읽기가 발생한다고 보여지는데,
모든 sdk의 요청에 해당한다고 하였고, 내 랭킹 정보와 특정 유저 랭킹 정보 두번을 호출했으니,
10번의 읽기가 발생하는게 대충 맞는것 같군요.
위에 설명을 해주 것으로 이해하건데, 위에서 쓰여지는 처리들이 보안과 관련된 부분이라
조금더 신뢰할 수 있는 데이터 처리를 위해서 필요하다는 것에 동의합니다.
한편으로는 그런 보안 장치가 되어있다는 것에 든든함을 느끼면서도,
한편으로는 백엔드를 거쳐가는 모든 처리에서 실제로 취급하는 데이터의 크기가 아무리 적은양이어도
한번의 요청에 기본적으로 위의 처리량만큼의 비용이 발생한다는 것이 조금 부담스럽게 느껴지기도 합니다.
이는 짐작하기로 위에 처리되는 단계에서 데이터가 8kb이하에서 발생되었어도
읽기처리가 모두 1회씩 처리되면서 처리하는 실제 데이터량 보다 많은 처리량이 집계된 것에서
비롯된 것 같이 보여지네요.
가이드에는 데이터의 1개의 로우당 200바이트 정도가 증가한다는 내용 외에는 없었기 때문에,
위의 설명해주신 내부적으로 보안 처리가 이루어지는 단계를 모른다면 예상보다 많이 늘어나는
데이터 처리량에 충분히 당황할 수 있다고 보여집니다.
데이터 처리의 단계가 많은 만큼 1회 처리되는 데이터의 양을 지금 보다 더 줄이고,
읽기 요금 또한 그에 맞춰 낮게 조정된다면, 사용자 입장에서는 조금 더 부담이 줄어들 것 같습니다.
뭐 이건 뒤끝 정책에 관련된 부분이라 건의 사항으로 받아주시면 좋겠습니다.
그리고 답변을 주신 부분에서 궁금한 것이 세 가지가 있습니다.
첫째는 가이드에는 8kb 미만의 데이터를 불러오는데 0.5의 읽기 처리량이 발생한다고 하였는데,
위에 설명해주신 인증 단계에서 사용되는 읽기처리는 처리되는 데이터 크기에 상관없이
한번 처리에 1의 처리량이 사용되는 건가요?
둘째는 랭킹에 등록된 유저수 만큼 읽기 처리가 된다고 하셨는데,
현재 랭킹에 등록된 유저가 5000명이라면, 5000번 읽기 처리가 된다는 것인가요?
셋째는 제가 위에 테스트한 사례는 이전에 접속한지 하루 이내의 계정으로 테스트한 것입니다.
그러니 accessToken을 갱신하지는 않았을 것이고, 랭킹 보상도 지정하지 않았습니다.
그런데 왜 쓰기 처리량이 발생하였을까요?
첫번째 질문은 그렇지 않습니다. 1번의 읽기처리라고 해서 1의 처리량을 사용하는것은 아닙니다.
두번째 질문은 랭킹이 집계되는 시간에는 유저의 수만큼 읽기가 진행되는 것은 맞습니다. ( 유저의 수만큼 처리량이 발생하는 것은 아닙니다. )
세번째 질문에 대한 답변을 하기 위해서는 서버쪽 로그를 확인해보는게 좋을것 같습니다.
해당 프로젝트 명을 알려주시면 서버 로그를 확인해보도록 하겠습니다.
-
그렇다면 내 랭킹 정보 및 유저 랭킹 정보 요청을 하였을 때 10의 읽기 처리량이 나온 것이 아무래도 조금 많아 보입니다. 처리 단계마다 쓰여진 처리량을 상세하게 명세해 주시면 더할나위 없겠지만, 그게 힘드시다면 그냥 인증단계에서 처리량을 많이 쓰는가보다라고 생각하고 넘어가겠습니다.
-
랭킹 집계 시에는 당연히 유저 수만큼 접근을 시도해야겠지요.
하지만 여쭤본것은 랭킹 조회 요청시에 말씀드린겁니다.
랭킹 데이터의 집계가 이미 끝난 상태에서 인증 단계를 제외하면,
실제 데이터 전송 부분은 유저수에 상관없이 DB사용량은 발생하지 않아야 한다고 생각하는데 맞나요? -
프로젝트명은 "Zombie Survivor"입니다.
- 이부분은 알려주신 프로젝트명으로 서버쪽 로그를 확인하여 추가로 답변드리도록 하겠습니다.
- 랭킹 조회요청에는 유저의 수와는 상관없이 위에서 말씀드렸던 인증+랭킹정보 관련한 부분에서만 DB를 사용합니다.
네. 확인 부탁드립니다.
서버쪽 로그를 확인중에 있습니다.
29일 18시36분 쯤 랭킹 리스트 받아오기와 유저의 랭킹 등수 확인하는 요청을 보낸것으로 확인이 되었습니다.
읽기처리가 많아진 이유는 현재 마켓에 출시를 하지 않은 상태(라이브상태가 아닌 개발상태)에 프로젝트가 설정되어있어 au를 확인하는 부분에서 읽기 처리가 추가로 발생한것으로 확인되었습니다.
라이브 상태로 전환하기 위해서는 각 마켓의 스토어 정보를 입력하시고 , 출시설정을 해주셔야 합니다.
위에 스크린샷을 올린 부분의 테스트는 "라이브가 아닌 상태"에서 테스트 한것이 맞습니다.
하지만 로그를 보셨다면 아시겠지만 그 뒤에도 몇 차례나 같은 방식으로 테스트를 하였고,
라이브로 변경을 한 후에 테스트를 진행한 것도 있습니다.
하지만 라이브 상태에서도 테스트 결과가 똑같이 나왔기에 그냥 저 스크린샷으로 올린겁니다.
아니면 콘솔 라이브 상태로 변경한 후에 실제 적용되는게(읽기 처리에 영향을 주는 시점이)
시간이 좀 걸리는 건가요?
현재 프로젝트 상태가 라이브가 아닌것으로 확인되고있습니다.
네. 읽기 처리량 확인 후에 다시 옵션을 라이브가 아닌 상태로 다시 변경하였습니다.
5번 부분을 확인해주시면 감사하겠습니다.
테스트 당시에 라이브로 설정을 바꾸고 테스트도 진행하였다고 말씀드렸습니다.
표현이 헷갈리실까봐 다시 말씀드리자면,
데이터 사용량을 체크 당시에 출시설정을 "테스트"와 “라이브” 로 모두 진행해보았으며,
두 부분 모두 같은 사용량을 보였습니다. (저의 경우는 읽기 10, 쓰기 2)
그리고 그 이후에 다시 출시 설정을 "테스트"로 돌려놓은 상황입니다.