SoU 개발일지

영상을 올리면 API가 지연된다... 고쳐야겠지?

어느덧 클라임픽이 사용자 750명을 보유했다.덩달아 많은 영상들이 업로드되고 있다. 팀원이 운영 서버를 모니터링 하던 중.. 발견한 시그널 주기적으로 CPU가 난리난다.뭐가 뭔진 몰라도 일단 이러면 안될것같은 예감..!에 뜯어보기로 했다.대충 영상 업로드라고 예상을 해볼순있었다. 일단 어디가 문제인지 파악하기 위해 기존에 쓰고있던 Grafana 대시보드를 확인해보았다. 기존 정보로 알 수 있는 것은 원인이 영상 후처리일 가능성이 높다는 점이었다.같은 시간에 세가지가 함께 오른다.네트워크 수신: 아마 S3에서 영상을 내려받을 때 사용하는 걸로 보인다.메모리 사용량: 약 1.3GB에서 2.2GB까지 늘어난다CPU: 일반 작업이 약 70%까지 오른다.CPU의 나머지는 보라색(Busy Other)이었는데 정체..

Limbing - 클라이밍 플랫폼 2026. 10. 14. 23:57

Agentic Workflow 구축하고 잠자는 동안 개발시키기

앱을 출시하고 사용자가 모이기 시작하면서 알림 기능의 필요성이 커졌다.그동안 기술 부채로 후순위로 밀어두었는데 SNS 성격의 앱이 알림이 없다니! 누가 내 글에 좋아요를 누르고 댓글을 달아도 직접 다시 조회해보지 않으면 알 방법이 없다.사용자 리텐션을 생각해서도 빠르게 알림 기능이 필요했다.그래서 Agentic Workflow를 설계해서 알림 기능 개발을 맡겨보기로 했다. 들어가기 전 Agentic AI 용어 정리용어의미Agent특정 역할과 목표를 부여받고, 도구를 사용해 작업을 수행하는 AIOrchestrator여러 Agent의 실행 순서와 작업 흐름을 관리하는 역할Skill반복해서 사용할 작업 절차와 규칙을 정의해둔 것ToolAgent가 실제 작업을 수행하기 위해 사용하는 수단. 파일 읽기/수정, 명..

Limbing - 클라이밍 플랫폼 2026. 9. 26. 10:04

[ClimPick] 느린 쿼리를 찾아 개선하자 - Performance Schema/EXPLAIN ANALYZE로 병목 찾기(개선한건 없지만 배웠다...//)

개발자로서 DB 성능을 개선한다고 하면 어떤 방법들이 떠오를까? 인덱스 추가하기, N+1 문제 해결하게, 불필요한 데이터 조회 제거하기, 집계 쿼리 개선하기 등등이 있을 것이다. 그럼 어떤 쿼리에 대해 개선을 진행해야할까? 당연히 실제로 느린 쿼리를 찾아서 개선해야한다. MySQL의 Performance Schema에서는 실행된 SQL의 성능 통계를 확인할 수 있다. 이를 활용해서 코드만 보고 병목을 예상하는 것이 아니라, 실제 실행 통계를 바탕으로 성능 개선이 필요한 쿼리의 후보를 찾을 수 있다. 이번에는 ClimPick의 테스트 환경에 실제 서비스보다 큰 규모의 데이터를 생성하고 Performance Schema로 병목 후보 탐색 -> EXPLAIN ANALYZE로 실행계획 분석 -> 인덱스 및 쿼..

Limbing - 클라이밍 플랫폼 2026. 9. 18. 22:08

[Limbing #13] 영상 로딩이 느리다: S3 앞에 CloudFront CDN 붙이기

리밍이 인스타그램에 광고를 붙이며, 베타 테스트 모집에 들어갔다.실제 사용자가 유입될 것을 대비해서 앱을 이용해보고 있었는데, 영상의 로딩 속도가 느리다는 것이 걱정이 됐다.그동안 MVP 개발과 기능 구현을 우선하느라 미뤄두었던 CloudFront CDN을 본격적인 사용자 유입에 앞서 도입하기로 했다. 기존 미디어 처리 구조기존 리밍의 미디어 처리 구조는 S3에 파일을 저장하고, S3 URL을 클라이언트에 그대로 전달하는 방식이었다.영상 업로드 시 서버가 Presigned URL을 발급하고, 클라이언트가 S3에 직접 업로드한다. 업로드가 완료되면 S3 URL을 DBd에 저장하고, 피드 조회 시 해당 URL을 그대로 반환했다. [업로드]Client → Server : Presigned URL 요청Serv..

Limbing - 클라이밍 플랫폼 2026. 8. 29. 16:31

[Limbing #12] Outbox 이후 마주한 문제들(Retry, DLQ, 멱등성)

📑 Contents 1. 지난 글에서 미룬 이야기 2. 재시도하면 안 되는 실패가 있다 3. 재시도 정책에도 이유가 있다 4. 같은 메시지가 두 번 왔을 때 5. 실패를 복구 가능한 실패로 만들기 6. 마무리 지난 글에서 미룬 이야기https://sou330.tistory.com/106 [Limbing #8] 업로드한 영상이 영영 처리중이라면? Outbox Pattern📑 Contents 1. 기존 방식의 문제점 └ Dual-write 불일치 문제 └ 유실 시 복구 수단이 없음 2. Outbox Pattern이란? 3. 프로젝트에 적용한 구조 4. 배운 점 오늘은 Outbox Pattern을 적용한 부분에 대해 적어보sou330.tistory.com지난 번에 프로젝트에 O..

Limbing - 클라이밍 플랫폼 2026. 8. 8. 15:45

[Limbing #11] 배포를 안전하게 만들기: systemd, 버전형 릴리스, 자동 롤백

📑 Contents 1. 기존 Lightsail 배포 방식의 한계 2. 목표: 버전형 릴리스 + 자동 롤백 3. systemd로 배포 방식 전환 4. 버전형 릴리스 구조 설계 5. 안전한 배포 프로세스 구현 6. GitHub Actions 개선 7. 마무리 오늘은 백엔드 멘토님께서 과제로 내주신 CI/CD 배포 구조 개선 과정을 기록해보려 한다. 처음 배포 로직을 짠 거라 동작한다는 자체에 의미를 뒀었는데 다시 보니 배포 실패 시 복구가 어렵고, 배포 중 장애가 발생해도 안전하게 대응할 수 없는 등 여러 허점이 있었다. 이번 과제를 통해 실패하면 자동으로 롤백되고, 언제든 이전 버전으로 복구할 수 있는 배포 구조를 만드는 과정을 경험할 수 있었다. 기존 Lightsail 배포 방식..

Limbing - 클라이밍 플랫폼 2026. 7. 31. 14:54