[공지] 뒤끝 요금 최적화 가이드 및 기존 프로젝트 지원 정책 안내
🎯목차
1️⃣ 뒤끝 요금 최적화 가이드
(1) 공통 사항💡
1. 게임 점검, 다른 기기 로그인 체크는 핸들러 이용
뒤끝에서는 주기적으로 체크가 필요한 에러에 대해서 핸들러를 제공하고 있습니다.
에러를 체크하기 위해 뒤끝 함수를 불필요하게 호출하기 보다, 핸들러를 이용하시는 것을 추천 드립니다.
잘못된 로직
Backend.Utils.GetServerStatus() 함수를 1초마다 호출하여 프로젝트 상태 값을 체크하는 로직
추천 로직
Backend.ErrorHandler.OnMaintenanceError 핸들러에서 응답 시 점검 관련 UI를 띄우는 로직
2. 고정된 데이터는 최초 1회만 호출 (차트, 내 게임 정보 등 ···)
차트 불러오기(Backend.Chart.GetChartContents)나 내 게임 정보 불러오기(Backend.GameData.GetMyData)와 같이 변경될 일이 적은 데이터는 데이터의 크기로 인해 DB 읽기량이 높게 발생할 수 있기 때문에, 최소한으로 호출하시는 것을 추천드립니다.
잘못된 로직 (1)
저장할 때마다 내 게임 정보를 불러와 클라이언트 데이터를 더한 후 저장
추천 로직
클라이언트의 데이터를 바로 저장
잘못된 로직 (2)
상점에 들어갈 때마다 상점 아이템 관련 차트 불러오기 함수 호출
추천 로직
로그인 이후 최초 상점 아이템 관련 차트 불러오기 함수를 호출한 후, 캐싱하여 사용
3. 뒤끝 함수 에러 발생 시, 자동 호출 자제
뒤끝 에러 로직 처리 중 예외 혹은 특정하지 않은 에러가 발생하였을 때 성공할 때까지 재호출을 하는 로직일 경우, 서버 점검이나 엑세스 토큰 소멸과 같은 케이스에서는 영구적을 에러가 발생되며 ‘기타 항목‘의 호출 비용이 발생하게 됩니다.
잘못된 로직
if문으로 개발자 문서에 기재된 문서에 따라 에러 처리 후, 나머지 에러를 위한 else문에서 반복처리
추천 로직
if문으로 개발자 문서에 기재된 문서에 따라 에러 처리 후, 나머지 에러를 위한 else문에서는 UI를 통해 에러 표시 후 게임 진행 중단
(2) 게임정보관리📂
1. 데이터 갱신 방식은 Insert가 아닌 Update로 이용
뒤끝에서는 한 테이블에 유저 한 명 당 하나의 데이터(row)를 가지는 것을 추천하고 있습니다.
데이터 백업 및 운영을 위해 한 데이터를 덮어 씌우는 형태(Update)가 아닌 계속해서 생성하는 로직(Insert)일 경우, 스토리지/백업 요금이 증가하게 됩니다.
데이터 백업은 자동 데이터 삭제 기능이 존재하는 게임 로그 기능을 이용하시는 것을 추천드립니다.
* 게임정보 관리 기능으로 백업 데이터를 저장하고 싶은 경우에는 여기를 참고해 주세요.
잘못된 로직
5부 주기로 Backend.GameData.Insert(“Table”, param)을 통해 새로 생성
추천 로직
indate 저장 후 Backend.GameData.UpdateV2(“Table”, param, indate, Backend,UserInDate)을 통해 데이터 덮어씌우기
2. 데이터 중요도에 따라 저장 로직을 '다르게' 설정
아이템을 얻거나, 적을 처치하거나, 스테이지를 넘어갈 때마다 저장을 하는 로직일 경우, 유저별 게임 속도에 따라 저장 호출이 잦아질 수 있습니다. 따라서 데이터의 중요도에 따라 저장 방식을 다르게 설정해야 합니다.
▪️ 우편을 수령할 경우, 해당 우편은 제거되기 때문에 즉시 저장하는 것을 추천
▪️ 인앱 결제를 통한 아이템 수령의 경우, 데이터 저장이 이루어지지 않을 경우 재결제를 해야하기 때문에 즉시 저장하는 것을 추천
▪️ 인게임 내 재화로 아이템을 구매, 재화 사용 등은 데이터가 롤백되어도 구매 전 상태로 돌아가며 다시 구매가 가능하므로, 5분 간격으로 저장하는 것을 추천
잘못된 로직
아이템, 경험치를 얻거나 적을 처치할 때마다 저장
추천 로직
아이템, 경험치, 적 처치는 캐싱된 값으로 사용하다가 특정 주기마다 저장
우편, 영수증 등 호출이 제한되어 있는 경우는 바로 저장
3. 데이터 저장 주기는 초단위 보다는 분단위로 설정
뒤끝에서는 자동 저장 주기를 5분 ~ 10분으로 추천하고 있습니다.
주기는 게임에 따라 알맞게 적용해 주시기 바랍니다.
잘못된 로직
10초마다 저장 코루틴 호출
추천 로직
5분마다 저장 코루틴 호출
4. 다수의 데이터를 저장 혹은 불러올 때에는 트랜잭션 기능을 이용
한 테이블 당 하나의 데이터 저장(Update), 조회(Get)함수를 호출할 경우, 호출 수가 많이 발생하게 됩니다.
데이터를 한 번에 많이 저장하고자 할 경우에는 최대 10개까지, 한 개의 호출 데이터를 저장하는 트랜잭션 기능을 이용해 주시기 바랍니다.
잘못된 로직
5분마다 저장하는 로직에서 테이블 개수만큼 Backend.GameData.Update 함수 호출
추천 로직
5분마다 저장하는 로직에서 테이블 당 트랜잭션 리스트에 추가하여 해당 리스트를 Backend.GameData.TransactionWriteV2() 함수에 넣어 호출 1회로 저장
(3) 랭킹🥇
랭킹 UI를 띄울 때마다 랭킹 불러오기 함수 호출 배제
랭킹 UI를 띄울 때마다 랭킹 불러오기 함수를 호출하는 로직일 경우, 유저에 따라 랭킹 불러오기 함수 호출의 주기가 다르며 과도한 호출이 발생할 수 있습니다. 랭킹을 보여줄 때마다 호출하는 로직보다는 캐싱하여 5~10분 주기로 갱신하는 로직을 사용하여 호출 횟수를 줄이는 것을 추천드립니다.
잘못된 로직
랭킹 UI를 띄울 때마다 Backend.URank.User.GetRankList(), Backend.URank.User.UpdateUserScore() 호출하여 UI에 적용
추천 로직
랭킹 UI를 띄울 때 Backend.URank.User.GetRankList(), Backend.URank.User.UpdateUserScore()를 호출한 시간 체크
▪️ 5분이 지나면 새로 호출하고 데이터 캐싱한 후 캐싱된 데이터 UI에 적용
▪️ 5분이 지나지 않을 경우 캐싱된 데이터에 UI에 적용
(4) 우편📨
1. 구버전 우편 함수(Backend.Social.Post.GetPostListV2) 사용 배제
구버전 우편 관리 함수인 Backend.Social.Post.GetPostListV2의 경우, 호출할 때마다 최대 100개의 우편을 가져와 제외하는 형식의 로직이기 때문에, 우편이 많아질수록 DB의 읽기량이 증가하게 됩니다.
우편을 구현하고자 할 경우에는 신버전 우편 함수를 사용해 주시기 바랍니다.
2. 우편 알림을 구현하기 위해 주기적으로 짧게 우편을 불러오는 로직 배제
뒤끝 콘솔에서 우편을 보내자마자 유저들에게 우편이 발송되었다는 알림을 띄우고자 1초~60초에서의 텀으로 반복적으로 우편 불러오기 함수를 호출하는 경우가 있습니다.
뒤끝에서는 콘솔과 클라이언트 간의 실시간 알림을 지원하고 있지 않기 때문에, 구현을 하실 경우 초 단위가 아닌 5분에서 10분 주기로 호출하는 것을 추천드립니다.
잘못된 로직
Backend.UPost.GetPostList(PostType.Admin, 10)를 1초에서 10초 간격으로 호출
추천 로직
Backend.UPost.GetPostList(PostType.Admin, 10)를 5분에서 30분 간격으로 호출
(5) 길드🏘️
길드 UI를 띄울 때마다 길드 함수, 길드 랭킹 함수 호출 자제
길드 정보 관련 UI를 생성할 때마다 내 길드 정보 불러오기(Backend.Guild.GetMyGuildInfoV3), 길드 랭킹 불러오기(Backend.URank.Guild.GetRankList)할 경우 요금이 크게 증가할 수 있습니다.
랭킹과 마찬가지로 불러온 값을 캐싱하여 일정 주기가 지났거나 길드에서 탈퇴할 경우에는 재호출을 하는 로직을 추천드립니다.
잘못된 로직
길드 UI 생성 시, 매번 관련 길드 함수 호출
추천 로직
▪️ 길드 UI 생성 시, 최근에 랭킹 정보를 불러온 날짜와 대조하고 5분이 지나지 않았다면 캐싱된 값으로 UI 구성
▪️ 5분이 지났을 경우에는 재호출 및 캐싱, 그리고 캐싱된 값으로 UI 구성
(6) 게임 로그✍️
1. 장시간 보존할 필요가 없는 데이터는 보관 기간 조정
게임 로그 삽입 시 별도의 graceDays(유예 기간)을 입력하지 않을 경우 90일로 자동 설정이 됩니다.
이때 데이터가 서버에 90일 동안 잔존하기 때문에 스토리지 비용이 부과되며, 90일까지의 보관이 없다고 판단될 경우에는 7, 15, 30일 등으로 조정하시는 것을 추천드립니다.
잘못된 로직
Backend.GameLog.InsertLog(“logType”, param, 15) graceDays 지정없이 호출
추천 로직
Backend.GameLog.InsertLog(“logType”, param, 15) graceDays 설정하여 호출
2. 일정 시간마다 자동 저장을 이용하고 있는 경우, 스토리지 및 DB쓰기 요금 주의
게임 로그 관리의 경우, 데이터 삽입만 제공하고 있기에 호출을 많이 할수록 스토리지 및 DB 쓰기 요금이 상승합니다. 해당 부분을 고려하여 에러, 인앱 결제 등의 필요한 정보만 로그로 저장하는 것을 추천드립니다.
(7) 랜덤 조회🔎
구버전 랜덤 조회 함수(Backend.Social.GetRandomUserInfo) 사용 배제
구버전 랜덤 조회 함수인 Backend.Social.GetRandomUserInfo, Backend.Guild.GetRandomGuildInfoV3의 경우, DB 데이터에서 조건에 만족할 때까지 검색을 계속하기 때문에 데이터가 많아질수록 응답 시간과 DB 사용량이 높게 측정됩니다.
잘못된 로직
랜덤 조회 기능으로 Backend.Social.GetRandomUserInfo 함수 사용
추천 로직
랜덤 조회 기능으로 Backend.RandomInfo.GetRandomData 함수 사용
2️⃣ 요금제 개편 안정화 지원 정책
◾ 지원 대상 프로젝트: 기존 출시 프로젝트
▫️ 출시 기준: 8월 31일 낮 12시 기준, 스토어 출시 및 뒤끝 콘솔 스토어 정보 등록이 완료되어 게임이 실제 서비스되고 있는 프로젝트
◾ 지원 제외 대상 안내 🚨
▫️ 스토어 출시가 이루어졌더라도, 뒤끝 콘솔에 스토어 정보가 등록되지 않은 프로젝트
▫️ 베타테스트 및 사전 등록 중인 프로젝트 제외
▫️ 이용 약관을 위반 중이거나 이용이 정지된 프로젝트
가이드를 참고하시어 사용량 절감을 위한 개선 작업을 진행하신다면,
기존보다 저렴한 비용으로 뒤끝을 이용하실 수 있을 것으로 기대합니다.
더불어,
요금제 개편으로부터 6개월 간 안정화를 위해 저희가 지원하겠습니다.
같이 개선할 방법을 찾고 게임 개선 작업을 진행하여 주신다면 감사하겠습니다.
뒤끝에서도 보다 나은 서비스를 제공해 드리기 위해 더욱 노력하겠습니다.
감사합니다.
