본문으로 건너뛰기
버전: SDK-5.11.7

뒤끝 요금 최적화 가이드

공통​

1. 게임 점검, 다른 기기 로그인 체크는 핸들러 이용​

뒤끝에서는 주기적으로 체크가 필요한 에러에 대해서는 핸들러를 제공해주고 있습니다.
해당 에러를 체크하기 위해 뒤끝 함수를 1초등의 단위로 반복적으로 호출하여 체크하는 것 보다는 핸들러를 이용하시는 것을 추천드립니다.

잘못된 로직
Backend.Utils.GetServerStatus() 함수를 1초마다 호출하여 프로젝트 상태값을 체크하는 로직

추천 로직
Backend.ErrorHandler.OnMaintenanceError 핸들러에서 응답 시 점검 관련 UI를 띄우는 로직

2. 차트, 내 게임 정보 등 고정된 데이터는 최초 1회만 호출​

차트 불러오기(Backend.Chart.GetChartContents)나 내 게임 정보 불러오기(Backend.GameData.GetMyData)와 같이 변경된 일이 적은 데이터는 데이터의 크기로 인해 DB 읽기량이 높게 발생할 수 있기에 최소한으로 호출하시는 것을 추천드립니다.

잘못된 로직
저장할 때마다 내 게임 정보를 불러와 클라이언트 데이터를 더한 후 저장

추천 로직
클라이언트의 데이터를 바로 저장

잘못된 로직2
상점에 들어갈 때마다 상점 아이템 관련 차트 불러오기 함수 호출

추천 로직2
로그인 이후 최초 상점 아이템 관련 차트 불러오기 함수를 호출한 후 캐싱하여 사용

3. 뒤끝 함수 에러 발생 시, 자동 재호출자제​

뒤끝 에러 로직 처리 중 예외 혹은 특정하지 않은 에러가 발생하였을 때 성공할 때까지 재호출을 하는 로직일 경우, 서버 점검이나 액세스토큰 소멸과 같은 케이스에서는 영구적으로 에러가 발생되며 '기타 항목'의 호출 비용이 발생하게 됩니다.

잘못된 로직
if 문으로 개발자 문서에 기재된 문서에 따라 에러 처리 후, 나머지 에러를 위한 else 문에서 반복처리

추천 로직
if 문으로 개발자 문서에 기재된 문서에 따라 에러 처리 후, 나머지 에러를 위한 else 문에서는 UI를 통해 에러 표시 후 게임 진행 중단

게임 정보관리​

1. 데이터 갱신 방식은 Insert가 아닌 Update로 이용​

뒤끝에서는 한 테이블에는 유저 한 명당 하나의 데이터(row)를 가지는 것을 추천하고 있습니다.
데이터 백업 및 운영을 위해 한 데이터를 덮어씌우는 형태(Update)가 아닌 계속해서 생성하는 로직(Insert)일 경우, 스토리지/백업 요금이 증가하게 됩니다.
데이터 백업은 자동 데이터 삭제 기능이 존재하는 게임 로그 기능을 이용하시는 것을 추천드립니다.

게임 정보 관리 기능으로 백업 데이터 저장을 하고 싶은 경우에는 뒤끝 블로그의 데이터 저장 팁을 참고해 주세요.

잘못된 로직
5분 주기로 Backend.GameData.Insert("Table", param)을 통해 데이터 새로 생성

추천 로직
indate 저장 후 Backend.GameData.UpdateV2("Table", param, indate, Backend.UserInDate)을 통해 데이터 덮어씌우기

2. 데이터의 중요도의 따라 저장 로직 설정​

아이템을 얻거나, 적을 처치하거나, 스테이지를 넘어갈 때마다 저장을 하는 로직일 경우, 유저별 게임 속도에 따라 저장 호출이 잦아질 수 있습니다.
따라서 데이터에 중요도에 따라서 저장 방식을 다르게 설정해야 합니다.
우편을 수령할 경우, 해당 우편은 제거되기 때문에 즉시 저장하는 것을 추천드립니다.
인앱 결제를 통한 아이템 수령의 경우, 데이터 저장이 이루어지지 않을 경우 재결제를 해야 하기 때문에 즉시 저장하는 것을 추천드립니다.
인 게임 내 재화로 아이템 구매, 재화 사용등은 데이터가 롤백 되어도 구매하기 전 상태로 돌아가며 다시 구매가 가능하므로, 모든 변경된 정보가 같이 저장되는 자동 저장 주기 때 저장되는 것을 추천드립니다.

잘못된 로직
아이템 하나, 경험치를 얻거나 적을 처치할 때마다 저장.

추천 로직
아이템, 경험치, 적 처치는 캐싱 된 값으로 사용하다가 특정 주기마다 저장.
우편, 영수증 등 호출이 제한되어 있는 경우는 바로 저장.

3. 데이터 저장 주기는 초단위 보다는 분단위로 설정​

뒤끝에서는 자동 저장 주기를 5분 ~ 20분 정도로 추천하고 있습니다.
주기는 게임의 운영 방식에 따라 알맞게 추천 주기로 적용해 주시기 바랍니다.

잘못된 로직
10초마다 저장 코루틴 호출

추천 로직
10분마다 저장 코루틴 호출 (호출이 꼭 필요한 것이 아니라면 저장 주기를 더 긴 시간으로 설정하는 것을 추천합니다.)

4. 다수의 데이터를 저장 혹은 불러올때에는 트랜잭션 기능을 이용​

한 테이블당 하나의 데이터 저장(Update), 조회(Get)함수를 호출할 경우 호출 수가 많이 발생하게 됩니다.
데이터를 한 번에 많이 저장하고자 할 경우에는 최대 10개까지 한 개의 호출로 데이터를 저장하는 트랜잭션 기능을 이용해 주시기 바랍니다.

잘못된 로직
10분마다 저장하는 로직에서 테이블 개수만큼 Backend.GameData.Update 함수 호출.

추천 로직
10분마다 저장하는 로직에서 테이블당 트랜잭션 리스트에 추가하여 해당 리스트를 Backend.GameData.TransactionWriteV2() 함수에 넣어 호출 1회로 저장.

랭킹​

1. 랭킹 UI를 띄울 때마다 랭킹 불러오기 함수 호출 배제​

랭킹 UI를 띄울 때마다 랭킹 불러오기 함수를 호출하는 로직일 경우, 유저에 따라 랭킹 불러오기 함수 호출의 주기가 다르며 많은 호출을 불러올 수 있습니다. 랭킹을 보여줄 때마다 호출하는 로직보다는 캐싱 하여 5~20분 주기로 갱신하는 로직을 사용하여 호출 횟수를 줄이는 것을 추천드립니다.

잘못된 로직
랭킹 UI를 띄울 때마다 Backend.URank.User.GetRankList(), Backend.URank.User.UpdateUserScore() 호출하여 UI에 적용

추천 로직
랭킹 UI를 띄울 때 Backend.URank.User.GetRankList(), Backend.URank.User.UpdateUserScore()를 호출한 시간 체크.
10분이 지나면 새로 호출하고 데이터 캐싱 한 후 캐싱 된 데이터 UI에 적용.
10분이 지나지 않을 경우 캐싱 된 데이터 UI에 적용.

우편​

1. 구버전 우편 함수(Backend.Social.Post.GetPostListV2) 사용 배제​

구버전 우편 관리 함수인 Backend.Social.Post.GetPostListV2의 경우, 호출할 때마다 최대 100개의 우편을 가져와 제외하는 형식의 로직이기 때문에, 우편이 많아질수록 DB의 읽기량이 증가하게 됩니다.

우편을 구현하고자 할 경우에는 신버전 우편 함수를 사용해주시기 바랍니다.

가이드문서 : https://developer.thebackend.io/unity3d/guide/upost/info/

2. 우편 알림을 구현하기 위해 주기적으로 짧게 우편 불러오는 로직 배제​

뒤끝 콘솔에서 우편을 보내자마자 유저들에게 우편이 발송되었다는 알림을 띄우고자 1초~60초에서의 텀으로 반복적으로 우편 불러오기 함수를 호출하는 경우가 있습니다. 뒤끝에서는 콘솔과 클라이언트 간의 실시간 알림을 지원하고 있지 않기 때문에 구현을 하실 경우에는 초 단위가 아닌 20분(혹은 30분) 주기로 호출하는 것을 추천드립니다.

잘못된 로직
Backend.UPost.GetPostList(PostType.Admin, 10)를 1초에서 10초 간격으로 호출

추천 로직
Backend.UPost.GetPostList(PostType.Admin, 10)를 20분 간격으로 호출

길드​

길드 UI 띄울 때마다 길드 함수, 길드 랭킹 함수 호출 자제​

길드 정보 관련 UI를 생성할 때마다 내 길드 정보 불러오기(Backend.Guild.GetMyGuildInfoV3), 길드 랭킹 불러오기(Backend.URank.Guild.GetRankList)할 경우 요금이 크게 증가할 수 있습니다.
랭킹과 마찬가지로 불러온 값을 캐싱 하여 일정 주기가 지났거나 길드에서 탈퇴할 경우에는 재호출을 하는 로직을 추천드립니다.

잘못된 로직
길드 UI 생성시 관련 길드 함수 호출

추천 로직
길드 UI 생성 시, 최근에 길드 랭킹 정보를 불러온 시간과 대조하고 5분이 지나지 않았다면 캐싱된 값으로 UI 구성.
5분이 지났을 경우에는 재호출 및 캐싱, 그리고 캐싱 된 값으로 UI 구성.

게임 로그​

장시간 보존할 필요가 없는 데이터는 보관 기간 조정​

게임 로그 삽입 시 별도의 graceDays(유예 기간)을 입력하지 않을 경우 90일로 자동 설정이 됩니다.
서버에는 90일 동안 존재하기에 스토리지 비용에 측정이 되며, 90일까지의 보관이 없다고 판단될 경우에는 7,15,30일 등으로 조정하시는 것을 추천드립니다.

잘못된 로직
Backend.GameLog.InsertLog("logType", param) graceDays 지정없이 호출

추천 로직
Backend.GameLog.InsertLog("logType", param, 15) graceDays 설정하여 호출

일정 시간마다 자동저장을 이용하고 있는 경우, 스토리지 및 DB 쓰기 요금 주의​

게임 로그 관리의 경우, 데이터 삽입만 제공하고 있기에 호출을 많이 할수록 스토리지 및 DB 쓰기 요금이 상승합니다.
해당 부분을 고려하여 에러, 인앱 결제 등의 필요한 정보만 로그로 저장하는 것을 추천드립니다.

랜덤 조회​

구버전 랜덤 조회 함수(Backend.Social.GetRandomUserInfo) 사용 배제​

구버전 랜덤 조회 함수인 Backend.Social.GetRandomUserInfo, Backend.Guild.GetRandomGuildInfoV3의 경우, DB 데이터에서 조건이 만족할 때까지 검색을 계속하기 때문에 데이터가 많아질수록 응답시간과 DB량이 높게 측정됩니다.

랜덤 조회를 구현하고자 할 경우에는 해당 문제점을 개선한 랜덤 조회(Backend.RandomInfo.GetRandomData) 함수를 사용해 주시기 바랍니다.

잘못된 로직
랜덤 조회 기능으로 Backend.Social.GetRandomUserInfo 함수 사용

추천 로직
랜덤 조회 기능으로 Backend.RandomInfo.GetRandomData 함수 사용