[Android/FCM] (3) Registration Token 관리

내용

FCM API를 사용해 프로그래밍 방식으로 Request Send를 build 하는 경우, 시간이 지남에 따라, 오래된 registration token이 있는 비 활성기기에 메시지를 보내 리소스를 낭비할 수 있다.

 

이러한 상황은, Firebase에 보고된 메시지 전송 데이터 또는 BigQuery로 내보낸 데이터에 영향을 미쳐, 전송률이 급격하게 감소할 수 있다.

이러한 점을 막기 위해 효율적인 메시지 타겟팅과 유효한 전송보고를 위해서 취할 수 있는 조치에 대한 것이다.

Basic Best practices

프로그래밍 방식으로 Request send를 build하기위해, 따라야하는 Fundamental practices는 다음과 같다

 

   1. 서버에 Registration Token 저장

      → 서버의 중요한 역할을 각 클라이언트의 Token을 추적하고, 업데이트된 Active Tokens 목록을 유지하는 것이다. 코드와 서버에 Token Timestamp를 구현하고, 정기적으로, 이 Timestamp를 업데이트하는 것이 좋다

 

   2. 저장이 오래된 Token 제거

      → invalid token 응답의 obvious 케이스 경우에 token을 제거하는 것 뿐만아니라, token이 오래되었다는 다른 현상들 또한 모니터링 해야 한다. 이를 위한 옵션에는 몇가지가 존재한다.

등록된 Registration Tokens 저장및 검색(retrieve)

처음 앱 시작시, FCM SDK는 클라이언트 앱 Instance에 대한 Registration token을 생성한다.
   → 이는 API로부터의 targeted send requests에 포함하거나 targeting topics을 위해 topic subscriptions에 추가해야하는 token이다.

 

클라이언트 Setup 가이드대로, 앱은 초기 시작시에(initial startup) 이 token을 검색하고,  앱 서버에 timestamp와 함께 저장해야 한다.

해당 timestamp는 FCM SDK에서 제공하지 않으므로, 스스로 구현해야 한다.

Timestamp 업데이트 주기

Token을 서버에 저장하고 변경될때마다 업데이트 해야하는데 그 예시 상황은 다음과 같다

   1. 앱이 새 기기에서 복원되는 경우

   2. 유저가 앱을 제거/재설치 하는 경우

   3. 유저가 앱 데이터를 지우는 경우

FCM Backend로부터 invalid token 응답을 감지

FCM에서 invalid token 응답을 감지하고, invalid한 것으로 알려진 모든 registration tokens들을 시스템에서 삭제해야 한다.

 

HTTP v1 API를 사용하는 경우, 이러한 오류 메시지는 전송 요청이 stale하거나, invalid token을 대상으로 함으로써 나타낼 수 있다.

• UNREGISTERED (HTTP 404)
• INVALID_ARGUMENT (HTTP 400)

targeted token에 대해 위와 같은 응답 중 하나를 수신하는 경우 해당 token의 record는 유효하지 않으므로, 삭제하는 것이 좋다.

그러나, token이 유효하지 않음에도, indication이 없는 경우가 여전히 존재한다.

 

예를 들어, FCM backend는 기기가 영구적으로 오프라인 상태가 되었는지에 대한 여부를 확인할 수 는 없다.

Registration Token fresheness 보장

Token이 최신인지 여부를 판단하는 것은 간단하지는 않다.

모든 케이스를 다루기 위해서는 Token이 오래되었다고 간주하는 경우에 대한 임계값을 설정해야 하며, 그 권장 기간은 2개월이다.

 

2개월 이상된 모든 Token은 inactive 기기일 가능성이 높다.

그렇지 않으면 active 기기가 token을 새로 고쳤을 것이기 때문이다.

정기적인 Token Update

서버에서 모든 registration tokens에 대해 주기적으로 검색하고 업데이트 하는것이 권장된다. 이를 위해선 다음을 필요로 한다.

• 클라이언트 앱에 앱 로직을 추가해, 적절한 API 호출을 사용해 현재 토큰을 검색한다.
  (Apple에선 token(completion): , Android에선 getToken() 사용)
  이후, 현재의 token을 앱 서버 저장소에 저장하기위해 타임스탬프를 포함해 보낸다.
  이것은 모든 클라이언트/토큰들을 포함하는 monthly 작업이 될 수 있다.
  (This could be a monthly job configured to cover all clients/tokens.)
• Token의 변경여부에 관계없이, 정기적으로 token의 timestamp를 업데이트하는 서버 로직을 추가한다

어떤 timing 패턴을 따르든, Token을 주기적으로 업데이트해야 한다.

권장되는 Token Update 주기

1달에 1번 업데이트 빈도는, 배터리 영향과 inactive registration token 감지간에 good balance를 이룰 가능성이 높다.

이 refresh을 수행하면, inactive된 기기가 다시 활성화 될 때 registration를 새로 고치도록 할 수 있다.

 

refresh주기를 1주 이하로 줄이는 경우엔 더이상의 이점이 없다.

Topics으로부터 오래된 토큰(stale token) 구독취소 (unsubscribe)

오래된 registration tokens을 제거하기 위해, topics subscription을 관리하는 것도 또 다른 고려 사항중 하나이다. 이 방법에는 2가지 단계가 포함된다.

 

   1. 앱은 1달에 1번, 또는 registration token이 변경될 때마다, topic을 다시 subscribe해야 한다. 이는 앱이 다시 active될때 subscription이 자동으로 reappear하는, self-healing solution이다.

 

   2. 만약 앱 Instance가 2달동안(혹은 자체적인 staleness window) idle(유휴상태)인 경우, FCM Backend에서 token/topic mapping을 삭제하려면, Firebase Admin SDK를 사용해 topic subscription을 취소해야한다.

 

이 2단계의 이점은 팬아웃할 오래된 token이 적기 때문에, 팬아웃이 더 빨리 발생하고, 오래된 앱 Instance가 다시 활성화되면, 자동으로 다시 구독한다는 것이다.

Delivery Success 측정

일반적으로 적극적으로 사용되는 앱 Instance에서 관찰하거나, 캡처한 작업을 기반으로 메시지를 타겟팅하는 것이 좋다.

구독자가 많은 topic에 정기적으로 메시지를 보내는 경우 특히 중요하다.

 

이러한 구독자 중 일부가 실제로 inactive상태인 경우, 시간에 따라 delivery statistics에 미치는 영향은 상당하다.

메시지를 token으로 targeting하기전에 고려해야 할 점은 다음과 같다.

 

   1. Google 애널리틱스, BigQuery에서 캡처한 데이터 또는 기타 추적 신호가 토큰이 활성 상태임을 나타내는가

   2. 이전 delivery 시도가 일정 기간 동안 지속적으로 실패하였는지

   3. 지난 2개월 동안 서버에서 registration token이 업데이트되었는지

   4. Android 기기의 경우 FCM 데이터 API 는 droppedDeviceInactive 로 인해 높은 비율의 메시지 전달 실패를 보고하는지