StudyDad Loop 제품을 만들며 배운 운영과 설계를 기록합니다.

FamBlend를 중심으로 실제 구현, 운영 메모, GitHub 포트폴리오를 연결해 쌓아가는 StudyDad의 작업 기록입니다.

상주서버 2

서버리스만으로 부족했던 운영 콘솔 백엔드 설계

운영 콘솔 아키텍처 시리즈 6/9서버리스는 운영 부담을 크게 줄여준다. 트래픽이 없을 때 비용이 거의 없고, 갑작스러운 요청도 자동으로 확장된다. 그래서 운영 콘솔을 만들 때 모든 API를 Lambda로 만들고 싶어질 수 있다.하지만 모든 요청이 Lambda에 잘 맞는 것은 아니다. 반대로 모든 요청을 상주 서버로 처리하는 것도 답은 아니었다.문제 상황운영 리포트 콘솔에는 성격이 다른 API가 섞여 있었다.하나는 대시보드나 목록 조회처럼 짧고 자주 호출되는 API다. 내부 운영자가 화면을 이동할 때마다 호출되고, 응답은 빠를수록 좋다. 내부 인증 쿠키를 확인하고, RDB 커넥션 풀을 사용해 여러 집계 쿼리를 실행한다.다른 하나는 리포트 생성처럼 드물지만 오래 걸리는 API다. 사용자가 버튼을 누르면 수 ..

서버리스, 상주 서버, 정적 호스팅을 나누는 기준

기술 실무 설계 시리즈 3/8운영 도구를 만들 때 백엔드를 어떻게 구성할지 고민하게 된다.모든 것을 Lambda로 만들까?EC2나 ECS 같은 상주 서버를 둘까?React SPA는 서버에서 서빙해야 할까?이 질문에는 하나의 정답이 없다.요청의 성격에 따라 실행 모델을 나누는 것이 더 현실적이다.먼저 워크로드를 나눈다기술을 고르기 전에 작업을 분류해야 한다.운영 콘솔에는 보통 다음 종류의 작업이 섞여 있다.정적 화면 제공짧고 잦은 조회 API인증과 쿠키 처리오래 걸리는 파일 생성이벤트성 동기화월별 통계 적재이 작업들은 같은 실행 모델을 요구하지 않는다.정적 화면은 S3와 CloudFront가 잘 맞는다.짧고 잦은 API는 상주 서버가 나을 수 있다.드물고 무거운 작업은 Lambda worker가 적합할 수..