문제 영구 실패 영수증의 무한 재전송, 남의 것인 영수증, 검사에 막히는 정당한 결제. 결정 영구 실패는 terminal 신호와 거부 행(poison pill)으로 끊고, 소유권은 uuidv5로 대조하고, 로그엔 HMAC 지문만 남기고, 막힌 결제자는 런북을 붙인 수동 적립으로 구제한다. 대가 구제는 사람의 판단에 기대고, poison pill이 Pending 결제를 영구 거부하는 결함을 만들었다. 결과 같은 uid 동시 20…
문제 토픽 브로드캐스트를 서버가 받은함에 펼치면 발송 1건의 Firestore 쓰기가 구독자 수만큼 늘어난다. 게다가 순수 토픽은 서버가 구독자가 누구인지조차 모른다. 결정 서버가 수신자를 uid로 풀 수 있는 발송(uid 지정, 세그먼트, 동의 기반 토픽)은 쓰기 시점에 서버가 펼치고, 풀 수 없는 순수 브로드캐스트( lang-* )만 앱이 열릴 때 클라이언트가 채운다. 대가 멱등성, 동의 재검증, 커서 관리를 클라이언트가 직접 …
문제 GCS 직접 호출로 한 번 줄였는데도 이미지 한 장에 1.39s가 걸렸다. 원인은 파일 자체였다. 에셋이 전부 무손실 PNG였고, 측정한 이미지는 477KB였다. 결정 PNG를 품질 82의 WebP로 바꾸고, 변환과 GCS 업로드(캐시 헤더, URL 맵 포함)를 셸 스크립트 두 개로 묶었다. 대가 손실 압축이라 화질이 조금 깎이는데, 얼마나 깎였는지는 재지 않았다. WebP를 못 읽는 환경을 위한 폴백도 두지 않았다. 결과 …
문제 안드로이드와 영수증 형식이 전혀 다른 iOS(StoreKit 2 JWS)를 같은 원칙, 같은 지급 로직 위에 올려야 했다. 결정 JWS는 로컬에서 풀어 값싼 사전 거절에만 쓰고, 진위는 App Store Server API 조회로 판단한다. 플랫폼별 검증은 따로 두고 재화 지급은 공통 함수 하나로 모았다. 대가 결제마다 애플 서버 왕복이 필요하고, 플랫폼별 검증 코드라는 유지보수 대상이 하나 늘었다. 결과 두 플랫폼이 같은…
문제 2026년 3월 20일, main에 직접 푸시한 코드가 Cloud Run에 자동 배포된 뒤 채팅 요청이 500을 냈다. 원인은 Gemini 호출의 400 INVALID_ARGUMENT 였고 로컬에서는 한 번도 보지 못한 에러였다. 결정 외부 의존성을 mock으로 바꾼 pytest를 만들고, PR마다 포매터·린터·테스트·Docker 빌드를 돌리는 GitHub Actions CI를 붙였다. main에는 PR로, CI가 통과한 것만 들…
지난 글들에서는 Sleuth의 코어 로직을 클라이언트에서 분리하여 FastAPI로 백엔드를 구축하고, 이를 GCP Cloud Run이라는 서버리스 인프라에 안착시킨 과정을 정리했다. (Cloud Run의 Scale-to-Zero와 콜드 스타트 최적화에 대한 내용은 이전 포스팅 을 참고하길 바란다.) 내부 아키텍처가 갖추어졌으니, 이제 실제 운영 환경의 쏟아지는 트래픽을 견뎌낼 수 있는지 검증할 차례다. 하지만 테스트를 시작하자마자 코드가 아닌…
문제 트래픽이 없어 인스턴스가 0개일 때 첫 메시지를 보내면 컨테이너 기동과 Firestore 적재가 겹쳐, 응답까지 15.3초가 걸렸다(Cloud Run 요청 로그 1건). 결정 최소 인스턴스를 두지 않고, 기동할 때 스토리 데이터를 한 번에 메모리에 올리는 Startup Cache와, 유저가 프롤로그를 읽는 동안 앱이 /health 를 미리 부르는 Client-Side Warm-up으로 버티기로 했다. 대가 예열한 인스턴스가 실…
Our website uses cookies to improve your experience. Learn more
확인