Firebase remote config란?

IOS앱에서 특정 URL은 다른 네비게이션 바를 사용해야한다는 요구사항이 있었어서 네이티브가 백엔드에 API를 호출해서 URL 리스트를 받아올까 이런 여러가지 고민을 했었습니다.

가장 좋은 것은 네이티브에서 직접 다른 곳에서 값을 가져오는 것 같더라구요

그래서 이미 네이티브 앱에서도 FCM을 사용하고 있기에 Firebase를 활용해보자는 생각을하였습니다.

Firebase에서도 많은 저장소를 제공하는데, 그중에서도 KV저장소 비슷한 역할을 하는 Firebase Remote Config에 대해서 조금 찾아보고, 바로 적용했습니다.

Firebase Remote Config란

irebase Remote Config는 클라우드에 올려둔 key-value 설정값을 앱이 런타임에 가져다 쓰는 서비스입니다. 무려 무료로 사용할 수 있고, 일일 활성 사용자 수에도 제한이 없습니다.

동작 방식은 이러합니다. fetchAndActivate() 한 번을 호출하면 Firebase 서버에서 설정한 최신 값을 앱에 즉시 가져올 수 있습니다. 그래서 Feature Flag를 사용한다거나, A/B 테스트및 이벤트 배너 문고, 이미지 URL 교체, 이런 곳들에 많이 사용됩니다.

그럼 AWS의 Secret Manager와 차이점은 뭔가요?

시크릿 매니저는 계정 단위 TPS가 있지만, Remote Config는 디바이스 단위의 fetch 간격 제한이 존재합니다. 그래서 서버 전체의 호출 제한은 없어요.

또한 기본 캐시 간격은 12시간이라, 기간 내에 fetch를 여러 번 호출해도 실제로 서버 요청은 한 번만 발생합니다. minimumFetchIntervalInSeconds 로 조절할 수 있습니다.

하지만, 막 엄청난 트래픽의 시크릿값을 동시에 참조하는 곳에서는 사용하지 않는 것이 좋다고 합니다. Remote Config는 언제까지나 클라이언트 동작 제어 도구로 사용하는 것이 좋다고 합니다.

이유는 여러가지입니다. 예시를 드는 것이 보안이 취약하다거나, 값이 로컬 캐시에 평문으로 저장된다거나, 패턴이 오래 캐시를 하는 것에 최적화 되어있다고 합니다.

근데 조금 더 찾아보니, 역시 서버에서도 많이 사용합니다. 2024년부터 서버 사이드의 SDK에서도 공식 지원을 시작했다고 합니다. 그래서 피쳐 플래그라던가, API 호출에 캐싱으로 사용한다거나, 외부의 키값 저장소로 많이 사용한다고 합니다.

더 좋은 것이 아까 말한 캐시 간격인데요, 이 Remote Config는 매번 값을 호출하는 Secret Manager와 다르게 기본적으로 다음과 같은 동작을 합니다.

서버 기동 시 → 전체 템플릿 1회 다운로드 → 메모리에 캐시
요청마다    → 로컬에서 evaluate() → 네트워크 없음 → 레이턴시 거의 0

근데 이건 Secret Manger에서도 애플리케이션 실행시 처음 로드하고, 로컬 캐시에 전역변수로 박아두면 되는 거라.. 큰 장점을 모르겠네요. 동시 TPS 제한이 없는 것?

아무튼 이러저래 쓸모가 많이보입니다. 쓸 일이 있으면 한번쯤 떠올릴만한 옵션이 것 같아요!