Today I Learned
날짜
2024년 7월 19일 금요일
내용
람다
AWS Lambda란 무엇인가요?
✔ 서버 프로비저닝 또는 관리, 워크로드 인식 클러스터 확장 로직 생성, 이벤트 통합 유지 또는 런타임 관리 없이 코드를 실행합니다.
✔ 사실상 모든 유형의 애플리케이션이나 백엔드 서비스에 대한 코드를 실행합니다. 코드를 ZIP 파일 또는 컨테이너 이미지로 업로드하기만 하면 Lambda는 자동으로 컴퓨팅 실행 능력을 할당하고, 모든 트래픽 규모에 대하여 수신 요청 또는 이벤트를 기반으로 코드를 실행합니다.
✔ Lambda 기능을 선호하는 언어(Node.js, Python, Go, Java 등)로 작성하고 서버리스 및 컨테이너 도구(AWS SAM 또는 Docker CLI)를 사용하여 기능을 구축, 테스트 및 배포합니다.
홈페이지에서 소개하는 람다 서비스다. 쉽게 요약하면, 내가 정의한 함수를 실행해준다는 의미. 이번에 개발한 서비스에서, 유저가 요청하면 네이버 API로 데이터를 가져오고, 데이터를 적절하게 가공해서 구글 스프레드 API에 추가해주어야 한다. 꽤나 무거운 작업이라 람다 함수를 이용하면 좋을 것 같다고 생각했다. 람다 함수는 서버와는 별도로 실행되기 때문에, 많은 작업이 동시에 진행되더라도 서버에 영향이 없기 떄문이다. 누군가 데이터를 임포팅하고 있다고 접속이 지연되는 일은 없어야 한다.
람다에 올리는 방식은 파일을 .ZIP으로 압축해서 올리는 것과 Docker image로 올리는 방식이 있다. 전자가 간편해서 시도했다.
내가 처리하려는 요청이 꽤나 복잡하고 커서 필요한 파일이 많았다. 데이터베이스 접근도 있어야했고… 스키마는 지우고 안써도 되긴 하나 그걸 일일이 수정하는 시간이 더 오래걸릴것 같아 우선 냅뒀다. 그런데 용량 제한이 초과되버렸다. ZIP 파일이 50MB를 넘으면 안되는데 52MB가 되버려서 올릴 수 없었다. 불가피하게 Docker Image로 올려서 처리했다. 이미지를 빌드하고, ECR에 올려서 람다가 불러올 수 있도록 해놨다.
처음에는 프로세스를 쪼개볼까 생각햇다. 람다 함수 하나에 올리지 말고, 임포팅 하는 람다, 데이터 가공하는 람다, 스프레드시트에 삽입하는 람다로 나눈 후 AWS Step Function으로 순차적으로 불러오면 재밌겠다고 생각했는데.. 저 코드를 나누어 서로 주고받는 변수를 통일하는 것도 쉽지 않을 뿐더러, 새로운 스택을 도입하기엔 시간이 많이 부족했다. 아마 플랫폼을 추가할때는 그 작업을 하면 좋겠다.
실서버 이슈
새로오신 PO님이 기능을 살펴보던 중 리뷰 요청 메일이 발송되지 않는다는 사실이 발견됐다. 어제 메일이 중복 발송된다는 이슈를 처리했기 떄문에, 그와 연관될거라고 생각했는데 역시나였다. 코드에 오타도 있었고 잘못된 필드를 처리하고 있었다. 뭐시여…
우선 잘못된 부분을 고치고 테스트 해보았는데 다행히 잘 작동했다. 배포만 잘 되면 되겠거니 했는데 웬걸? ECS가 이상했다. 보통 새로운 이미지가 빌드되면 컨테이너가 배포되고 40~50초 정도 후 기존 컨테이너가 종료되면서 새로운 컨테이너가 무중단 배포되기 마련인데, 기존 것이 살아남고 새로 생성된 컨테이너가 3~4분 정도 지속되다 사라지는 모양새가 계속 됐다. 분명 로컬, 테스트 서버에서 모두 잘 빌드됐었기 때문에 빌드의 문제는 아니라고 생각했다..
컨테이너의 로그를 살펴보니 gunicorn이 서버를 컴파일하는데 계속 실패하고 있었고, 컨테이너의 CPU 사용률은 100% 상태였다. 갑자기? 많은 요청이나 트래픽이 쏠린 것도 아니고 뜬금없이 올라가는게 이해가 안됐다. 구글링해보니 같은 문제를 겪는 사람들은 모두 똑같이 말하고 있었다. 왜 뜬금없이 CPU가 올라가는진 모르겠으나, 늘려줬더니 해결은 됐다.
나도 새롭게 서비스를 정의해줘서 CPU와 메모리를 2배로 늘려줬는데 빌드가 잘 됐다. 실서버에서 기능을 테스트해보고, 어제 코드를 바꾼 이후 생성된 주문건들에 대해서 필요한 경우 메일을 보내도록 커맨드를 돌렸다.
회고
결국 흑염소를 먹지 못했다. 하지만 냉채 족발도 좋았다.
