Unity - Playfab Event Log 붙이기 회고

Unity - Playfab Event Log 붙이기 회고

슬슬 클라이언트쪽 일도 끝났고,  8월 16일부터 23일까지 일주일간 사용자 로그를 붙였다. 담당자가 있었는데도, 왜 내가 하게 되었는가.. 하면 요청 자체는 6월부터 계속 있었지만, 담당자가 "유료 재화의 증/감을 제외한 로그는 불필요하다. 붙일 수 없다"라고 석달넘게 드러눕는 바람에.. 그냥 플레이팹 연구하고싶으니까 계정 등록 부탁드린다고 요청한다음 계정권한을 얻어 로그를 작성해 붙여버렸다. 

구현 방식은 다음과 같은데.

• 각 로그 클래스별로 버퍼를 가지고 있고 로그 요청이 들어오면 들어온 정보를 일단 버퍼에 저장한다. 
• 저장할 때 playerPrefs에도 클래스 이름을 키로 사본을 갱신해둔다.
• LogManager에서 일정 주기(10분)을 가지고, 각 클래스를 순회하면서 버퍼를 비우고 전송한다.
• 이 때 유료재화나 경쟁컨텐츠와 같은 중요한 정보는 주기를 무시하고 바로 전송한다,
• 잡템 1~2개 드랍과 같은 덜 중요한 로그는 추가적인 주기를 갖는다.
• 전송되는 순간 Manager는 주기를 갱신하고, 각 클래스는 playerPrefs의 사본을 지운다. 

와 같은 간단한 로직으로 되어있다. 이때 안드로이드에서는 OnApplicationQuit()을 통해 정상적으로 종료되는 상황이 드물기 때문에 (탭 누른다음 위로 밀어서 강제종료시키면 해당 함수가 호출되지 않는다!!) 미전송 로그가 소실되지 않도록, 버퍼에 저장된 로그는 playerPrefs에 사본을 저장해 두었고. Start 함수의 실행은 언제나 보장되어있기 때문에, 앱이 다시 시작되는 순간 playerPrefs내부의 키를 순회하면서 로그를 보내도록 했다.

그리고 너무 빈번하게 보내면 비용이 눈물나게 많이 나온다고 하니까.. 중요하지 않은 로그는 10분에 한번 남기기로 했다. 몇몇 로그가 사라질 위험성과 눈물나는 비용이 청구되는 상황을 비교해보았을 때 후자의 위험성이 훨씬 높다고 판단해서 좀 넓게 가져가기로 했다. 

마지막으로 로그별로 클래스를 나눈 이유는, 요청되는 전체 로그를 다 병합해야 하는 경우와. 시작과 끝을 남기면 되는 경우, 병합해도 괜찮지만 결과물의 리스트는 전부 보존해야하는 경우로 나눠서 관리하기 위함이었다. 그리고 이 클래스는 인터페이스로 공톰함수를 만들어서 LogManager가 각 클래스의 상세구현과 상관없이 사용할 수 있도록 했다.