2부. 기존 개발 방법에 대한 문제점 및 개선 방안
지난 편 ▶︎ 1부. Day34 Serverless 기존 개발 방법에 대한 이해
저번 1화에서는 Day34 에서 아마존 환경에서 Serverless 를 어떻게 개발하고 아키텍처를 구성하고 있는지 살펴 보았다. 처음에 이 개발 방식을 채택하여 개발 했을 때는 기존에 신규 서비스가 생기고 BackEnd API 를 만들 때 개발 환경을 Setup하고 개발하고 배포하는 시간보다 훨씬 효율적이다 라는 것을 알게 되었다. 물론 장점이 있는 반면 단점도 존재 하였다.
Serverless 의 단점은 무엇일까?
- 트래픽이 많은 서비스/기능에 대해서는 적합하지 같다
→ 아직까지 트래픽이 정말 너무 많아서 Amazon Serverless 가 느리다고 느낄 정도의 실질적인 경험은 없었다. 트래픽을 감당할 수 있는 동시성에 대한 문제가 항상 존재할 수 있는데 람다의 동시성 의 한계가 존재한다. Region 마다 다르지만 1000개 정도가 기본적인 한계이다. 물론 이 부분은 Amazon 과 영업적인 부분으로 더 늘릴 수는 있다. 단, 정말 트래픽이 과도한 서비스라면 Serverless 를 이용하는 것 보다 컨테이너나 EC2의 AutoScailing 을 적용하여 서비스 하는 것이 더 효율적이지 않을까 생각이 든다.
- Cold Start 가 존재한다.
→ 함수를 만들고 함수가 호출 되는 횟수를 기반으로 요금을 내는 방식이다. 이 부분은 Azure나 Amazon이나 기타 IaaS를 하고 있는 Vendor에서 대부분 비슷한 요금 정책이 아닐까 생각이 든다. 트래픽이 많이 몰리지 않고 적정 수준에서 사용하는 람다 함수 라면 문제가 없을 부분이기도 하지만 간혹 꼭 필요하긴 한데 한달에 손에 꼽힐 만큼 호출 횟수가 적은 API 도 존재할 것이다. 이 때 Cold Start가 문제가 될 수 있습니다. 내부적으로는 람다가 매번 사용 되지 않는 함수의 경우 Amazon 에서는 Deactive 상태로 뒀다가 요청이 들어오는 순간 Active 상태로 변경 하면서 서버가 내부적으로 동작하는데 까지 걸리는 시간을 의미한다. 이러한 부분을 없애기 위해 일부 CloudWatch 의 CronJob을 통해 적절하게 한번 씩 호출 될 수 있도록 해준다면 이러한 문제를 피할 수 있지만 단점이라고 말할 수 있다.
그 외 딱히 걸릴 만한 단점은 우리 편에선 존재 하지 않았다. 장점이 단점을 삼킬 정도로 좋았기 때문에..-_-; 그 외 구조적으로 저희가 처음 도입하다 보니 여러가지 어려운 점들과 문제점이라고 생각하는 부분들이 존재 했었는데 그 부분은 아래와 같이 정리된다.
기존 개발 방법에 대한 문제점
우선 문제점을 말하기 전에 이 부분은 우리가 이 Tool 에 익숙하지 않았던 것으로 발생한 문제지 AWS 에서 기능을 제공하지 않았던 문제는 아니었다.
- Dev(개발)과 Prod(운영) 에 대한 개발 방법에 대한 최적화가 되지 않았다.
→ 실제로 같은 기능을 하고 있는 람다 함수를 어떻게 Dev 모드와 Prod 모드로 Flexible 하게 관리할 수 있을까? 가 최대의 궁금증이었다. 현재는 람다 함수를 Prod와 Dev 별도로 하나씩 만들어 관리하는 방법으로 하고 있다.
2. Code를 기존에 우리가 사용하고 있는 IntelliJ 나 Visual Studio Code 등의 훌륭한 IDE 툴로 사용하기보다 아마존에서 제공하는 Web Editor로 작업 해야만 했다.
→ AWS 에서 클라우드 9이라는 솔루션을 제공하지만 개발자들에겐 본인만의 익숙한 Tool들이 존재한다.. 설정도 말이다.. Shorcut이나 이런 것들을 대부분 외우고 작업들을 하기 때문에 코드 작성 시 생산성이 높고 최종적으로 Code Convention 을 지켜야 되는 경우 대부분 Tool 에서 Reformatting 기능을 사용하고 있기 때문에 Web IDE에서 작업하는 것이 편치만은 않았다. 그리고 가끔 코드를 작성하다 터치 바에 손을 잘못 갖다 대는 순간 뒤로 가기가 되서 코드가 날라가 버린다…-_-… 컴퓨터를 던져버리고 싶을 때가 많았다..
3. 자동화 되지 않은 개발 프로세스로 하다 보니 주먹구구식의 배포나 코드 관리에 대한 미흡한 부분이 존재 하였다.
→ 배포를 하기 위해서 console 에 접속해서 API Gateway , Lambda 를 건드리고 저장하는 과정이 주먹구구식이다 보니 문제가 많았다.. 또한 문제가 발생했을 때 예전 버전으로 Rollback을 진행해야 하는 상황에서 항상 난감했다.
그렇다면 개선 방안은 무엇인가?
현재 개발 방법에 대한 부분을 최적화 하고 사례를 찾기 위해 몇몇 사람을 만나보고 구글링이나 미디엄에서 리서치를 하기 시작했다. 거기서 위의 문제점들을 해결할 수 있는 방안으로 Serverless Framework 이 모든 것을 해결해 줄 수 있다는 것을 알게 되었다.
Serverless Framework 가 무엇인지 궁금한가? 궁금하면 500원…; 아재..
쿨럭… 다음 편에서 소개하도록 하겠다.
