테스트와 라이브로 각각 테스트 후 답변드리도록 하겠습니다.
아래는 저희가 사용하는 프로젝트에서 진행한 테스트의 결과입니다.
- 라이브 상태의 프로젝트
게이머의 랭킹 조회
인증 서버에서 처리하는 양
읽기량
읽기 { 사용유닛: 0.5 }
읽기 { 사용유닛: 1.5 }
읽기 { 사용유닛: 0.5 }
쓰기량
쓰기 { 사용유닛: 2 }
랭킹 확인을 위해 사용한 양
읽기량
읽기 { 사용유닛: 0.5 }
읽기 = 3, 쓰기 = 2
특정 랭킹 조회
인증 서버에서 처리하는 양
읽기량
읽기 { 사용유닛: 0.5 }
읽기 { 사용유닛: 1.5 }
읽기 { 사용유닛: 0.5 }
쓰기량
쓰기 { 사용유닛: 2 }
랭킹 확인을 위해 사용한 양
읽기량
읽기 { 사용유닛: 0.5 }
읽기 = 3, 쓰기 = 2
- 테스트 상태의 프로젝트에서
게이머의 랭킹 조회
인증 서버에서 처리하는 양
읽기량
읽기 { 사용유닛: 0.5 }
읽기 { 사용유닛: 5 }
읽기 { 사용유닛: 5 }
읽기 { 사용유닛: 5 }
읽기 { 사용유닛: 5 }
읽기 { 사용유닛: 5 }
읽기 { 사용유닛: 1 }
위 값은 accessToken이 적으면 조금 발생하고, 많으면 많이 발생합니다. 1개라도 존재하면 읽기 처리량이 증가합니다.
쓰기량
쓰기 { 사용유닛: 2 }
랭킹 확인을 위해 사용한 양
읽기량
읽기 { 사용유닛: 0.5 }
특정 랭킹 조회
인증 서버에서 처리하는 양
읽기량
읽기 { 사용유닛: 0.5 }
읽기 { 사용유닛: 5 }
읽기 { 사용유닛: 5 }
읽기 { 사용유닛: 5 }
읽기 { 사용유닛: 5 }
읽기 { 사용유닛: 5 }
읽기 { 사용유닛: 1 }
위 값은 accessToken이 적으면 조금 발생하고, 많으면 많이 발생합니다. 1개라도 존재하면 읽기 처리량이 증가합니다.
쓰기량
쓰기 { 사용유닛: 2 }
랭킹 확인을 위해 사용한 양
읽기량
읽기 { 사용유닛: 0.5 }
제가 확인한 바로는 라이브 상태와 테스트 상태일때는 확실히 읽기 처리량에 차이가 발생합니다.
여기서 accessToken이 만료되지 않았는데도 쓰기 처리량이 2로 나오는 이유는 암호화를 하는 키값이 노출됐을때를 대비하여 재사용이 불가능하게 하기 위해 암호키값을 변경하는 작업이 포함이 되어있어서 입니다.
위 작업들은 항상 동일한 사용량을 소비합니다.
확실히 "테스트"와 “라이브” 상태에서 사용하는 처리량이 차이가 많이 나는군요.
제가 테스트한 결과와는 조금 다르게 나왔지만, 어쨋든 확인해주신 부분이니
이것은 제가 출시 설정을 "라이브"로 설정해놓고 사용을 일정 기간해본 뒤 궁금한 점이 있다면
다시 여쭙도록 하겠습니다.
그리고 처리단계에서 쓰기가 항상 발생하는 것을 알았으니, 랭킹 조회 요청을
유저가 남발하지 못하도록, 게임 내부적인 부분에서도 처리가 별도로 필요하겠네요.
상세하게 답변주셔서 감사드립니다.
안녕하세요? 뒤끝의 개발PM을 담당하고 있는 정프로입니다.
먼저 뒤끝DB 요금에 대한 부족한 설명과 명확하지 않은 부분으로 인해 심려를 끼쳐드린 점 사과드립니다.
어제 서버 담당자분의 답변으로 어느 정도 궁금하신 점이 해소되었을 것으로 생각되지만, 여전히 DB요금 계산이 어렵고 관련 안내 역시 부족하다고 생각하고 있습니다.
그렇다고 DB 관련된 모든 기능을 로직 단위로 상세하게 안내드리기도 현실적으로 어려워 내부에서도 고민을 많이 하고 있습니다.
저희가 처음 의도한 것은 DB요금에 대한 설명은 가급적 심플하게 하고 대신 고객들께서 DB요금에 크게 신경 쓰지 않아도 될 정도로 DB 무료 사용량을 넉넉하게 드리자는 것이었습니다.(아시다시피 현재 월 10만 원까지의 DB요금은 무료로 제공해 드리고 있습니다)
출시 후 직접 사용해 보시면 느끼실 수 있겠지만 일반적인 인디 게임에서는 다 사용하기 힘들 정도의 분량이고, 만약 DB요금이 발생할 정도라면 (비정상적인 DB 사용이 없는 한) 이미 충분한 수익이 발생한다고 봐도 될 정도로 무료 제공 기준을 잡았습니다.
하지만 이건 저희 내부에서의 생각이었을 뿐, 실제 고객들은 DB요금 10만 원이 어느 정도나 되는지 예상하기 힘들고 그로 인해 우려를 하실 수 있다는 부분을 간과한 측면이 있었던 것 같습니다.
때문에 현재 DB요금과 DB 무료 제공에 대한 표현 방법 및 안내의 개선을 계획 중에 있으며, 말씀해 주신 점들을 참고하여 내부 DB 처리 로직도 좀 더 효율적으로 개선하는 작업을 진행하도록 하겠습니다.
아무쪼록 뒤끝이 개발 중이신 게임에 도움이 되길 바라며, 멋진 게임으로 완성되길 기대하겠습니다.
감사합니다.