전체 글 (41) 썸네일형 리스트형 음반 리뷰 블로그 만들기 - 7 RDS에서 Neon으로 — 비용 때문에 DB를 옮긴 이야기서버리스로 전환하고, 검색 구조를 정리하고, SQS/Worker까지 도입했다. 구조적으로는 만족스러웠는데, 비용 문제가 남아있었다.RDS가 비싸다서버리스로 전환하면서 EC2 고정비는 없앴다. Lambda는 요청이 없으면 비용이 0이니까. 그런데 RDS는 다르다. RDS는 인스턴스가 항상 켜져 있어야 한다. 가장 작은 인스턴스를 써도 월 고정비가 나간다.개인 블로그라 트래픽이 거의 없다. 하루에 쿼리가 몇 번 안 날아가는데, DB는 24시간 떠 있다. 서버리스로 전환한 취지가 "사용한 만큼만 내자"였는데, RDS가 그 원칙에 맞지 않았다.Neon을 선택한 이유서버리스 PostgreSQL을 찾아봤다. 몇 가지 후보가 있었는데, Neon이 가장 적합했다.. 음반 리뷰 블로그 만들기 - 6 SQS/Worker 도입 — Spotify 레이트리밋 줄이기5편에서 검색을 DB-first로 바꿨다. 기본 검색은 DB에서 끝나고, 최신 데이터가 필요할 때만 Sync 버튼으로 Spotify를 호출한다. 상세 조회는 DB-only.검색 자체는 안정적이 되었다. 하지만 Sync 버튼을 눌렀을 때의 처리에 문제가 남아있었다.Sync 버튼의 초기 구조Sync 버튼을 누르면 이런 흐름이었다.Sync 클릭 → Music API가 Spotify에 검색 요청 → Spotify 응답으로 후보(candidates) 목록을 받음 → 후보를 사용자에게 보여줌 → 동시에 각 앨범의 상세 데이터를 Spotify에서 가져옴 → DB에 저장 (앨범, 트랙, 아티스트 upsert) → 모든 처리가 끝나면 응답 완료문제는 .. 음반 리뷰 블로그 만들기 - 5 검색 구조 개선 — DB-first로 정리한 이유서버리스 전환이 끝나고, 기능을 다듬기 시작했다. 가장 먼저 손댄 건 검색이었다.초기 검색 구조처음에는 단순했다. 사용자가 검색하면 Spotify API를 직접 호출해서 결과를 보여주고, 그 결과를 DB에 저장하는 방식이었다.사용자 검색 → Music API → Spotify API 호출 → 결과 반환 + DB 저장검색할 때마다 매번 Spotify에 요청이 나간다. 동작은 했다. 하지만 쓰다 보니 문제가 하나둘씩 생겼다.문제 1: Spotify 레이트리밋(429)Spotify API에는 호출 횟수 제한이 있다. 짧은 시간에 요청이 몰리면 429(Too Many Requests) 응답이 온다. 개인 블로그니까 트래픽이 많을 리 없다고 생각했는데, 개발 중에 .. 음반 리뷰 블로그 만들기 - 4 서버리스로 전환하다EC2 하나로 돌리면서 문제를 확인했다. 고정 비용, 배포 불편, 추적 어려움, 확장 한계, DB 불안정. 이 문제들을 안고 계속 기능을 만드는 건 지금은 쉽게 만들 수 있지만, 나중엔 끊김 없이 문제에 저항하다가 포기해버릴 것 같았다.그래서 기반부터 바꾸기로 했다.기능을 더 만들기 전에 전환하는 게 낫다고 생각했다. 나중에 서비스가 커진 다음에 옮기면 더 복잡해질 테니까. 지금은 백엔드 하나와 DB뿐이라 옮기기에 가장 쉬운 시점이었다.왜 서버리스인가3편에서 정리한 문제들을 다시 보면, 대부분 "EC2가 항상 켜져 있다"는 데서 출발한다.고정 비용 → 요청이 없을 때는 과금되지 않으면 된다.배포 불편 → SSH 접속 없이 코드만 올리면 배포되면 된다.확장 한계 → 서비스별로 독립적으로 .. 음반 리뷰 블로그 만들기 - 3 인스턴스 하나로 먼저 만들어보기기술 스택을 정했으니, 이제 실제로 만들어야 한다. 처음부터 복잡하게 구성하지 않기로 했으니, 가능한 한 단순한 형태로 시작했다.처음 구성EC2 인스턴스 하나를 띄우고, 그 안에 백엔드(FastAPI)와 데이터베이스(PostgreSQL)를 함께 올렸다. Docker Compose로 컨테이너를 구성해서 API 서버와 DB를 같이 돌리는 형태였다.프론트엔드(Astro)는 별도로 빌드해서 올렸다. 정적 사이트니까 빌드 결과물을 S3에 업로드하고 CloudFront로 서빙하는 구조를 초기부터 가져갔다. 읽기 트래픽은 CDN에서 처리하는 게 맞다고 생각했다. 정리하면 이런 그림이었다.[사용자] → CloudFront → S3 (Astro 정적 사이트) ↓ .. 음반 리뷰 블로그 만들기 - 2 기술 선택 — 블로그에 맞는 스택 찾기이전 글에서 필요한 기능을 정리했다. 이제 그걸 실제로 만들기 위한 기술을 골라야 한다.선택해야 할 게 크게 세 가지였다.블로그(프론트엔드)를 어떤 프레임워크로 만들 것인가백엔드는 어떤 언어와 프레임워크로 만들 것인가음반 데이터는 어디서 가져올 것인가프론트엔드 — 정적 사이트 프레임워크 비교블로그의 본질은 글이다. 글은 한번 작성되면 자주 바뀌지 않는다. 즉, 대부분의 페이지가 정적이다. 매 요청마다 서버에서 렌더링할 필요 없이, 미리 빌드해둔 HTML을 그대로 내려주면 된다.그래서 정적 사이트 생성(SSG)을 지원하는 프레임워크를 찾았다.후보Hugo — Go 기반의 정적 사이트 생성기다. 빌드 속도가 매우 빠르고 블로그에 많이 쓰인다. 하지만 템플릿 문법이 독특하고.. 음반 리뷰 블로그 만들기 - 1 음반을 기록하는 블로그를 만들기로 했다음악을 듣고, 기록하는 습관나는 음악을 들을 때 앨범 단위로 듣는다. 싱글 곡 하나를 반복하기보다는, 앨범을 처음부터 끝까지 순서대로 듣는 편이다. 아티스트가 이 앨범으로 무슨 이야기를 하려 했는지, 곡 배치는 왜 이렇게 했는지, 가사에서 반복되는 표현은 어떤 의미인지 — 그런 걸 생각하면서 듣는다.그래서 예전부터 들은 앨범에 대해 메모장이나 노션에 기록해왔다. "이 앨범은 이런 느낌이었다", "이 트랙에서 흐름이 바뀐다", "전작이랑 비교하면 이런 점이 다르다" 같은 것들이다. 사실 이건 평가라기보다는 기록에 가깝다고 생각하긴 한다.이렇게 정리를 했을 때 문제점은 찾아보기 쉽지 않았고, 기억하기 쉽지 않았다.왜냐하면 시각적으로 확보이지 않았기 때문이다. 뿐만 아니라.. Spring Cloud Gateway JWT - 2 (Redis) Spring Cloud Gateway JWT 검증 2탄: Redis 폐기 목록을 추가하고 다시 측정해보았다이전 글 요약이전 글에서는 Spring Security Resource Server(표준 필터)와 커스텀 WebFilter의 성능을 k6로 비교했다. 결과는 예상과 달리 커스텀이 22배 빠르다는 것이었다. 원인은 Spring Security 리액티브 체인의 파이프라인 비용이 단순한 HMAC 서명 검증보다 훨씬 무거웠기 때문이다.하지만 1탄의 실험에는 빠진 것이 있었다. 실제 운영 환경에서는 서명 검증만으로 끝나지 않는다. 토큰 폐기 목록 조회라는 I/O 작업이 추가된다.이번 글에서는 Redis를 추가해 폐기 목록 조회까지 포함한 상태에서 동일한 비교를 수행한다. 그리고 이 실험을 통해 "왜 그럼에도 .. 이전 1 2 3 4 ··· 6 다음