피드로 돌아가기
Dev.toBackend
원문 읽기
신뢰성 중심의 Async-first 구조를 통한 안정적 Screenshot API 설계
How I Built a Screenshot API That Doesn't Suck
AI 요약
Context
Headless Chrome의 무거운 의존성과 불안정한 브라우저 Lifecycle 관리로 인한 잦은 렌더링 실패 발생. 운영 오버헤드 증가 및 기존 호스팅 서비스의 비용 효율성 저하로 인해 예측 가능한 자가 호스팅 구조의 필요성 대두.
Technical Solution
- Fresh Browser Context 채택을 통한 각 작업별 독립적 렌더링 환경 구축 및 상태 오염 방지
- Async-first Workflow 설계를 통한 요청 제출-상태 확인-결과 다운로드의 비동기 처리 구조 구현
- FastAPI 기반의 Concurrency Limit 설정으로 CPU 및 Memory 자원 고갈 방지
- Playwright와 Chromium의 조합을 통한 렌더링 안정성 확보 및 자동화된 Lifecycle 관리
- Docker-first Deployment 전략을 통한 브라우저 런타임 환경의 일관성 유지 및 배포 단순화
- Webhook Callback 구조 도입을 통한 작업 완료 시점의 효율적인 알림 체계 구축
실천 포인트
1. 브라우저 자동화 시 상태 공유를 피하기 위해 작업당 독립적인 Context를 생성하는가
2. 무거운 렌더링 작업의 Request-Response 타임아웃 방지를 위해 Async Queue를 도입했는가
3. 리소스 집약적인 작업에 대해 시스템 붕괴를 막는 Concurrency Limit이 설정되어 있는가
4. 인프라 복잡도를 낮추기 위해 Docker 기반의 단일 배포 패키지로 구성했는가