1. 람다를 이용한 분산 작업 처리 구축기
동기
맵샷에는 여러 지도 종류가 있습니다. 그리고 지도마다 관련 데이터를 호출하는 방식이 다릅니다. 그 중 문제가 되는 것이 카카오 지도인데, 해당 타입은 서버에서 관련 이미지를 렌더링해서 유저에게 전송해 주어야 합니다.
일일 활성 유저가 늘어날수록 해당 기능이 서버에 많은 부하를 유발시켜 이미지 생성 방식을 변경해야 할 필요성을 느꼈습니다.
문제 상황
초기 이미지 생성 방식
초창기 서비스 작동 방식은 http 요청을 3초 간격으로 보내고, 서버는 현재 자원이 사용 가능한 상태라면 요청을 처리했습니다. 이 방식은 다음과 같은 문제점을 안고 있었습니다.
해당 방식을 채택했던 이유는, 서비스 수요에 대해 잘못된 예측을 했기 때문입니다. 오픈 전에 평균적인 DAU를 많아도 10명 안팎으로 생각했었는데, 이 예측은 완전히 빗나가고 말았습니다. 가끔 사내 메신저 등을 통해 서비스가 홍보 된 것으로 추정되는 일들이 있었는데, 1시간 동안 100명 정도가 서비스에 접속했고, 이 상황을 더 이상 보고만 있을 수 없었습니다.
해결
1차 개선
WebSocket과 Queue를 이용해서 서비스를 개선했습니다. 큐에 유저 요청을 순차적으로 담고, 웹소켓을 이용해서 실시간으로 대기열 상황을 유저에게 전달했습니다. 이러한 개선 방안은 기존의 문제점들을 일부 해소했으나, 아직 모든 문제 상황을 완전히 해결하지는 못했습니다.
여전히 요청이 누적된다면 대기 시간은 길어졌고, 다른 해결 법을 강구해야 했습니다.
최종 개선
AWS의 Lambda를 이용해서 서비스를 개선 했습니다.
람다는 AWS에서 제공하는 서버리스 플랫폼으로, 서버에 대한 관리 부담을 AWS로 전가한 기능입니다. 개발자는 람다에 원하는 함수를 입력하고, 필요에 따라 함수를 호출할 수 있습니다. 서로의 작업 환경을 공유하지 않고, 마치 여러 대의 개별 서버를 대여한 듯한 효과를 기대할 수 있습니다. 하지만 함수 실행 시간에 제약이 있고(최대 15분), 호출 시 Cold Start로 인해 초기 지연 시간이 발생할 수 있습니다. 최대 응답 용량(6MB)도 제약이 있습니다.
이제 유저 요청이 누적되지 않고 개별 처리되는 시스템을 구축해 볼 수 있었습니다.
하지만 새로운 문제들이 추가되었는데, 람다는 서버를 계속 켜둘 수 있는 시스템이 아니다 보니
Cold Start + JVM 초기 구동 시간이 더해져서 작업 딜레이가 발생했습니다.
이를 해결하기 위해 람다의 코드는 Node.js를 통해 작성했고, 이제 마지막 문제만이 남았습니다.
람다의 단일 응답 만으로는 제작된 이미지를 한번에 전송할 수 없었습니다. 현재 1대의 API 서버로만 서비스가 운영되고 있다는 점과, DB에 지도 이미지를 저장하는 것을 금지하는 카카오의 정책을 고려하였고 다음과 같은 서버 구조를 가지게 되었습니다.
이미지를 분할한 후 POST 요청을 통해 EC2 서버에 임시 보관을 하였고, 유저는 자신이 요청한 이미지에 해당되는 Key 값을 통해 관련 이미지를 찾을 수 있게 구성하였습니다.
해당 이미지는 유저에게 전달됨과 동시에 서버에서 삭제되기 때문에 메모리 관리에도 큰 문제가 없었고, 이로 인해 초창기 서비스의 문제점들을 모두 개선할 수 있게 되었습니다.
Last updated