AWS Lambda 서울 리전 이전기
현재 개발하고 있는 로톡에서는 Lambda를 쓰는 몇몇 서비스들이 있다.
그 중 가장 사용 빈도가 높은 법률 분야 추천 API는 서울 리전에서 Lambda를 서비스 하기 전에 만들었던 것이라,
도쿄 리전에 배포를 해서 사용을 하고 있었다.
그동안 손댈일이 없어서 계속 도쿄 리전에 두고 있던 상태였는데, 몇몇 추천 파라미터를 변경하게 되면서 서울 리전으로 이전하기로 했다.
한국 - 일본을 오가는게 영 찝찝했기 때문이다.
법률 분야 추천 API
법률 분야 추천 API를 간략하게 소개하면,
입력받은 텍스트를 분석해 해당 텍스트가 어떤 법률 분야에 속할 수 있는지 추천하는 API이다.
(한때 머신러닝좀 배우겠다고 설쳐댔을때 내부 데모용으로 만들었던게 제품으로 들어갔다.)
예를 들어,
지난 금요일 밤 강남역의 한 술집에서 술을 마시다가 옆 테이블 일행과 시비가 붙었습니다.
상대방이 제 멱살을 잡자 제가 화가 너무 난 나머지 주먹질을 했고 전치 4주의 상해를 입혔습니다.
저는 어떤 처벌을 받게 되나요?
라는 텍스트를 입력받으면 ‘폭행/협박’ 이라는 분야를 추천해 응답하는 것이다.
(사실 추천이라기 보다는 분류기에 가깝다.)
기존 구성
구성은 별거 없다.
문제는 Lambda를 제외한 모든 리소스들이 서울에 있다는 것이다. 서울 안에서도 AWS랑 KT의 ucloud biz가 짬뽕되어 있다.
API 서버에서 도쿄 리전에 있는 analysis
function을 호출할때에도 지연이 있는데,
function 안에서 또 한국과 일본을 오가게 되어서 추가적인 지연이 생기게되어 더 느렸다.
서울 리전으로 배포 시도
기존에 이미 Apex로 구성을 해둔터라 그냥 리전만 바꾸고 다시 배포를 시도했다.
베포는 문제가 없었는데… 테스트를 위해 함수를 호출해보니 에러가 뜬다… 읭?
Error: function response: Cannot find module ‘debug’.
코드에 손도 안댔는데…. 문제가 생겼다.
logger로 debug
패키지를 쓰는건 맞는데, 왜 안되는지 모르겠다. apex build analysis > built.zip
으로 built zip을 떨구고 unzip -l built.zip
으로 확인해봐도 분명 node_modules/debug
라는 경로에 파일은 있었다.
혹시라도 AWS에서 debug
란 패키지 네임을 쓰기 시작했나? 싶어서 require('debug')
로 불러오던걸 무식하게 (?) require('./node_modules/debug')
로 불러오도록 바꿔도 봤지만, 소용이 없었다.
시간은 자꾸만 흐르고 해결은 되지 않아서 Apex Slack에 푸념을 늘어놓던 와중….
debug
패키지의 내부 스캐폴딩이 바뀐걸 발견했다….
문제는 이렇게 생긴 것이었다:
- Apex의 function build hook에
npm install && npm update
가 들어있어서 빌드 전 debug 패키지가 자동으로 업데이트가 되었고, - 하필이면
.apexignore
에 babel이 transpile하는 원본 코드를 배포에 포함시키지 않게 하려고src/
가 들어있었는데, debug
패키지의 내부 구성이 바뀌면서.apexignore
에 기재된src/
glob이node_modules/debug/src
를 매치시키면서 파일이 누락되어 배포 패키지가 만들어졌고- 깨졌다…
(예전에 도쿄에 배포할땐 debug
패키지의 내부 구성이 변경되기 전이므로 영향을 받지 않았다.)
.apexignore
에 들어있는 src/
glob을 ./src/
로 바꾸고 다시 배포해보니 문제가 사라졌고, 기존처럼 그대로 잘 동작했다.
아… 다시 생각해봐도 황당하다 ㅋㅋㅋㅋㅋㅋㅋ
서울 리전으로 배포 후
이제 모든 리소스들은 서울에 있다. 더이상 해외망을 오갈 필요가 없다!!!
서울 리전으로 무사히 이전하고 나서 서비스 안에서 이리저리 써보니 확실히 많이 빨라진걸 체감할 수 있었고,
벤치마크를 돌려봐도 많이 빨라진 것을 알수있다.
아래는 간단하게 벤치마크를 돌려본 결과이다.
첫번째가 도쿄 리전, 두번째가 서울 리전이다.