어쩌다 보니 시작해보는 람다
위코드 기업협업이 시작되면서, 나에게 첫 번째로 주어지는 과제는 github 소셜 로그인을 lambda로 구현하는 것 이었다.
이를 위해 aws lambda를 공부하기 시작했고, 그 과정을 대략적으로라도 정리하고자 시리즈 포스팅을 시작해본다. 잘 유지될지... 이어질지는 모르겠으나 최선을 다해보는것으로....
서버리스란 무엇인가?
보통 내가 배워온 백엔드에서는 프로젝트를 시작할때 기본적인 설정들을 잡아주고 서버를 띄워주어야 했다. 개발용으로 내 컴퓨터를 서버로 이용하는 것이다. 하지만 서버리스는 그렇지않다. 서버는 aws(혹은 컴퓨팅 서비스 제공자)가 띄워준다. 관리도 해준다. 나(개발자)는 오직 코딩에만 신경쓰면 된다. 함수 단위의 기능을 만들어서 코딩만 해놓고, API Gateway 라는 aws의 또 다른 서비스의 힘을 빌려 API를 생성하고 붙여주면, 마치 내 프로젝트의 코딩이 모두 끝나고 EC2와 RDS를 통해 프로젝트를 배포한 것 마냥 작동된다.
왜 서버리스인가?
개발자는 서버관리를 신경 쓸 필요가 없다.
만약 내가 개발자이고, 초기 개발 환경을 세팅하고, 개발이 지속되어 우리 서비스가 출시되었다. 생각보다 반응이 좋다. 유저가 몰리기 시작하고, 부하가 몰려 현재의 서버 성능으로는 버텨낼 수 없다. 그렇게되면 서버를 증설하든 성능을 개선시키든 뭔가의 조치를 취해야하고, 그러한 작업은 거의 개발자와 엔지니어의 몫이 된다. 하지만 Lambda에서는 다르다. 처음부터 서버를 띄우고 세팅을 잡아줄 필요도 없고, 함수만 코딩해서 해당 함수가 잘 호출되어서 정상적으로 작동하는지만 보면 된다. 부하가 적건 크건, 내 서버는 항상 떠있고, 사용가능하며, 돈도 쓴만큼만 내면된다. 개발자는 코딩에만 집중하면 된다.
세팅하기
- aws 계정을 만든다.
- 서비스에서 Lambda를 선택한다.
- 끝....
거짓말 같겠지만 방금 나는 django에서 프로젝트의 세팅값을 조정한 후에 python manage.py runserver명령을 내린 것과 똑같은 일을 했다고 볼 수 있다.
