개발새발개발자 개발새발개발자

앱 시작 직후 간헐적으로 발생하는 피드 미노출 버그가 있었습니다.앱을 운영하다보면 이러한 버그를 만나는데, 항상 재현되는 것도 아니고 그렇다고 완전한 랜덤 버그도 아니였습니다.어떤 사용자에게는 가끔 보이고, 앱을 다시 켜면 또 멀쩡하게 동작을 했습니다.그래서 처음에는 네트워크 연결 문제로 인해 발생한 줄 알았습니다. 하지만 로그를 살펴보니 그게 아니였습니다.이번 문제의 증상을 살펴보니 두 가지 문제가 있었습니다. 앱 실행 직후 간헐적으로 FCM 토큰 저장이 실패했고, 같은 시점에 피드 API도 정상적으로 복구되지 못하는 경우가 있었습니다.사용장 입장에서는 "앱이 처음 켜질 때 가끔 뭔가 꼬인다" 정도로 느껴지는 문제였지만, 실제로는 인증 복구 흐름 안에 숨어 있던 race condition이 원인이었습니..

Flutter에서 latest=true를 보며 들었던 작은 고민특정 화면에 들어갈 때 URL 파라미터 하나가 붙고, 그 값에 따라 어떤 UI는 보이고 어떤 UI는 사라지는 상황입니다. 예를 들어 lastest=true 가 붙으면 최신 콘텐츠 영역을 보여주거나, 기본 탭을 조금 다르게 열거나, 평소와는 다른 진입 화면을 구성하는 식입니다. 이런 로직을 만들다 보면 한 번쯤 이런 생각이 듭니다. “이거 너무 프론트에서 편하게 처리하는 방식 아닌가?”“URL 파라미터 하나로 UI를 바꾸는 게 구조적으로 괜찮은 걸까?” 결론부터 말하면, 충분히 괜찮습니다.그리고 실제로도 꽤 자주 쓰는 방식입니다.다만 여기서 중요한 건 URL 파라미터를 썼다는 사실이 아니라,그 값을 어디까지 쓰고 어디서 멈출지를 정하는 일입니다..

Django 프로덕션 모니터링 시스템을 구축하며 바뀐 것들 서비스를 운영하다 보면 어느 순간 익숙한 장면이 반복됩니다. 누군가 "앱이 조금 느린 것 같아요" 라고 말하면, 그때부터 개발자는 서버에 접속해 로그를 뒤지기 시작합니다. 어떤 API가 느린건지, 진짜 느린 게 맞는지, 에러는 얼마나 발생했는지, Celery 작업은 밀려 있는지, CPU나 메모리는 버티고 있는지 하나씩 확인합니다. 문제는 이런 방식이 늘 한 박자 늦는다는 데 있습니다. 이미 사용자는 불편을 겪고 있고, 장애는 시작됐고, 로그는 여러 서버와 컨테이너에 흩어져 있고, 경우에 따라서는 장애 순간의 정보가 제대로 남아 있지도 않습니다. 실제로 기존 운영에서는 API 응답 지연을 사용자의 불만이 들어온 뒤에야 알게되었고, Celery 작업..

작은 DB로 시작한 선택, 연결 관리 부재, 그리고 AWS RDS Proxy 도입까지 서비스를 처음 만들 때 가장 어려운 것 중 하나는 얼마나 많은 사용자가 들어올지 모른다는 점 입니다.특히 소셜 기능이 있거나 사용자 바능에 따라 갑자기 트래픽이 튈 수 있는 서비스라면, 처음부터 모든 걸 넉넉하게 준비해두는 것도 쉽지 않습니다. 비용도 고려해야하고, 아직 검증되지 않은 서비스에 너무 큰 인프라를 미리 붙이는 것도 부담스럽기 때문입니다. 저도 그랬습니다.처음에는 일단 작게 시작하자는 판단을 했습니다. AWS RDS PostgreSQL 인스턴스를 작은 사양으로 두고, 사용자가 늘어나면 그때 키우자는 전략이었습니다. 당시 선택한 인스턴스는 db.t4.small 이었고 허용 가능한 최대 연결 수는 대략 150개..

처음에는 DB가 하나면 충분합니다.쓰기와 읽기 모두 Primary 하나에서 처리했고, 트래픽도 감당한 수준입니다. 그런데 어느 순간부터 이상한 일이 생기는데,쓰기 쿼리는 그렇게 많지 않은데, 특정 조회 API 때문에 DB CPU가 90%를 찍고, 주문이나 결제 같은 쓰기 트랜잭션이 느려집니다. 이때 도입한 게 Read Replica 기반 DB 라우팅이었습니다.왜 굳이 읽기/쓰기를 나눴을까핵심은 단순합니다. 쓰기 트랜잭션은 보통 짧고, 정확해야 하고, 롤백 비용이 큽니다.반면 읽기는 많고, 넓고, 무겁습니다. 이 둘을 같은 DB에서 처리하면 결국 쓰기가 피해를 봅니다. 그래서 구조를 다음과 같이 바꿨습니다.Primary → 쓰기 전용Replica → 읽기 전용애플리케이션 단에서INSERT / UPDATE ..

처음 AWS로 서비스를 구성하면 보통 이런 고민을 하게 됩니다. "ALB, NLB는 뭔가 다르지?""ALB가 있는데 Nginx를 또 써야 하나?""같이 쓰면 L7을 두 번 쓰는 거 아닌가?" 저도 처음에는 이게 단순히 기능 비교 문제라고 생각했습니다.그런데 실제로 트래픽이 늘어나고 구조가 복잡해지면서, 이건 기능의 문제가 아니라 설계 관점 문제라는 걸 알게 됐습니다.ALB(Application Load Balancer)와 NLB(Network Load Balancer)의 차이부터 정리해보면AWS에서 제공하는 로드밸런서는 대표적으로 두 가지가 있습니다. 하나는 AWS Application Load Balancer,다른 하나는 AWS Network Load Balancer 입니다. 이 둘의 가장 큰 차이는 ..

서비스를 운영하다 보면 어느 순간 이런 상황을 마주합니다.평소에는 잘 버티던 서버가 특정 시간대에 갑자기 느려지고, CPU가 치솟고, 일부 요청이 타임아웃이 납니다. 이때 가장 먼저 떠오르는 해결책은 단순합니다. “서버를 여러 대 두면 되지 않을까?”“그럼 Nginx도 여러 개 두면 되는 거 아닌가?” 맞는 말이지만, 실제 구조는 생각보다 조금 더 복합적입니다. 단순히 Nginx를 여러 대 두는 것만으로는 완전한 해결이 되지 않습니다. 왜 그런지 흐름으로 풀어보겠습니다.Nginx를 여러 대 두는 것만으로 충분할까?Nginx는 리버스 프록시이자 L7 로드밸런서 역할을 할 수 있습니다. 그래서 애플리케이션 서버 여러 대 앞에 두고 요청을 분산시킬 수 있습니다.Nginx → App Server ANginx →..

API를 처음 설계할 때는 이런 고민을 거의 하지 않습니다. "일단 동작하게 만들자." 하지만 서비스가 운영 단계로 들어가고, 클라이언트가 늘어나고, 모바일 앱이 배포되고 나면 상황이 달라집니다. 이미 배포된 앱은 바로 업데이트되지 않고, 외부 파트너는 구버전 API를 계속 사용합니다. 그때 깨닫게 됩니다. API는 한 번 공개되면 쉽게 바꿀 수 없다.그래서 등장하는 개념이 API 버전 관리 입니다. 왜 API 버전 관리가 필요한가API는 계약 입니다. 서버와 클라이언트 사이의 약속입니다. 예를 들어 이런 응답이 있다고 해봅시다.{ "id": 1, "username": "seungjin"}그런데 어느 날 username을 name으로 바꾸고 싶어졌습니다.서버에서는 간단한 변경이지만, 기존 클라이언트..