🚀 항상 켜져 있던 우리 서버 이야기
Link Dropper는 링크를 수집하고 정리하는 서비스입니다.
이 과정에서 파이썬 기반 크롤링 서버를 운영하고 있어요.
• Docker로 이미지를 빌드하고,
• 빌드한 이미지를 레지스트리에 업로드하고,
• AWS EC2에서 컨테이너를 실행해서,
• 요청이 온 링크를 크롤링하는 방식이었죠.
평범하고 별문제 없어 보였지만,
몇 가지 고민이 생겼습니다.
⚡ 문제는 “시간”이었다
Link Dropper는 아직 베타 단계의 서비스입니다.
활성 사용자 수가 많지 않은 지금,
링크 크롤링 요청 빈도도 상대적으로 낮아요.
| 그런데 EC2는 어떤가요?
• 서버는 항상 켜져 있어야 하고
• 심지어 아무 요청이 없어도
• "시간" 단위로 요금이 계속 부과됩니다.
아무 일도 안 하고 있는데, 돈이 줄줄 새는 것이죠..
💡 그래서 내린 결론: 요청이 있을 때만 서버를 켜자!
"굳이 항상 서버를 켜둘 필요 있을까?"
• 크롤링 요청이 들어오는 그 순간만
• 서버를 잠깐 띄워서,
• 크롤링 작업을 하고,
• 끝나면 바로 종료.
이런 "필요할 때만 실행하는" 구조를 고민했습니다.
🛠️ 그리고 선택한 답: AWS Lambda
AWS Lambda는 서버를 직접 운영하지 않고
필요할 때만 코드를 실행하는 서비스입니다.
한마디로, 서버를 신경쓰지 않아도 되죠.
EC와 Lambda의 특징을 간단히 비교해보면
| 항목 | EC2 | Lambda |
|---|---|---|
| 서버 관리 | 직접 해야 함 | AWS가 알아서 |
| 비용 | 항상 과금 | 요청 있을 때만 과금 |
| 확장성 | 직접 스케일링 설정 | 자동 스케일링 |
| 실행 시간 | 무제한 | 최대 15분 |
| 사용 사례 | 대형 웹서버, DB 서버 | API, 이벤트 처리 |
Link Dropper의 링크 크롤링처럼 요청 기반으로 동작하는 서비스라면,
Lambda의 서버리스 구조가 훨씬 자연스러운 선택이 된다고 생각했죠!
🔧 그럼 기존 EC2 컨테이너는 어떻게 Lambda로 옮겼을까?
저희는 이렇게 작업했어요!
1. 컨테이너 이미지 저장소 변경
기존 도커 이미지를 AWS ECR(Elastic Container Registry)로 옮겼습니다.
(ECR은 AWS 환경에서 Lambda와 찰떡궁합이에요.)
2. Lambda 함수 생성
컨테이너 기반의 Lambda를 만들고,
ECR에 저장한 이미지를 선택해서 연결했습니다.
3. FastAPI를 Lambda에서 실행할 수 있도록 수정
FastAPI는 원래 자체 HTTP 서버(uvicorn 같은 것) 위에서 동작해요.
하지만 Lambda는 HTTP 서버를 띄우지 않죠.
→ 그래서 FastAPI를 Lambda용으로 감싸주는 작업이 필요했는데요,
이떄 Mangum이라는 라이브러리를 사용했습니다.
/* main.py */
from mangum import Mangum
app = FastAPI()
handler = Mangum(app)
이 handler가 Lambda 호출의 진입점이에요!또 Dockerfile에 컨테이너가 실행되는 진입점(ENTRYPOINT)도
위 main.py에 맞추어 다음처럼 추가했죠.
/* Dockerfile */
...
ENTRYPOINT ["python", "-m", "awslambdaric"]awslambdaric는 AWS Lambda용 런타임 인터페이스 클라이언트입니다.
Lambda가 보내는 이벤트를 받아서 → FastAPI 앱(handler)에게 넘겨주고 →
FastAPI의 응답을 다시 Lambda가 이해할 수 있는 형식으로 포장해주는 역할을 해요. 🚀
이 과정을 자동으로 처리해주기 때문에, 우리는 FastAPI 코드에만 집중할 수 있죠.
🥶 하지만 Lambda에도 단점은 있다: 콜드 스타트
Lambda는 요청이 없으면 컨테이너를 종료해요.
그리고 다시 요청이 오면 새로 띄우는데, 이때 약간 시간이 걸립니다.
이걸 "콜드 스타트"라고 부릅니다.
• 첫 요청은 약간 느릴 수 있어요.
• 다만, 요청이 계속 이어진다면, Lambda는 기존 컨테이너를 재사용합니다.
이를 "웜 스타트"라고 해요.
🧠 콜드 스타트, 어떻게 줄일 수 있을까?
• 일정 주기로 Lambda를 미리 깨워주는 "워머(warmer)" 요청을 보내거나,
• 메모리 할당량을 높여서 컨테이너 부팅 속도를 빠르게 하는 방법이 있습니다.
(※ Link Dropper 팀도 향후 요청 패턴을 보면서, 워머 도입을 고려할 예정입니다.)
✅ Link Dropper가 기대하는 효과
• 요청이 있을 때만 서버를 사용하니, 비용을 대폭 절감
• 운영/모니터링 부담 없이, AWS가 알아서 관리
• 필요할 때만 빠르게 스케일링
서비스 베타 초반에는 이런 구조가 훨씬 합리적이라고 생각했어요!
🧪 링크 드라퍼, 지금 베타 테스트 중입니다
링크 드라퍼는 단순한 저장 툴이 아닙니다.
정리하고, 수정하고, 다시 꺼내보게 만드는 링크 관리 도구입니다.
• 🔗 링크 삭제, 폴더 생성/수정 등을 낙관적으로 처리
• 🧠 링크 의미를 기억하게 만드는 메모 기능
• 🌐 폴더를 친구에게 공유 가능
• ⚡ OG 미리보기 자동 불러오기
지금 직접 써보시고,
즉각적인 UI 반응이 얼마나 사용자 흐름에 영향을 주는지 경험해보세요.
🙏 마치며
Link Dropper는 앞으로도
가볍고 효율적인 아키텍처를 지향합니다.
"항상 켜둘 필요 없다면, 꺼두자."
"필요할 때만 번개처럼 실행하자."
이 작은 변화가
Link Dropper의 속도와 비용 구조 모두를
한층 더 유연하게 만들어줄 거라 기대하고 있습니다.
👉 혹시 여러분도 비슷한 고민을 하고 계신가요?
댓글로 경험을 공유해주세요 🙌
5개의 댓글
람다는 호출수보다 실행시간이 훠어얼씬 크리티컬하게 작용합니다. 호출수는 거의 고려하지 않아도 되지만, 실행시간이 길어지면 오히려 비용 이점이 줄어들수 있습니다. 크롤링작업과 같은 경우, 즉 실행시간을 정량적으로 예측하기가 어려울 것 같은 유즈케이스에서는 호출이 늘어났을 때, 비용감소효과가 상쇄될 수 있어요.
만약 나중에 사용자 수가 많이 증가하게 되는 경우까지 생각해 보셨나요? 저도 지금 서버리스 함수로 프로젝트를 해보고 있어서요