람다, 서버리스의 첫걸음

아주 오래전부터 있던 개념이지만 클라우드와 함께 MSA 가 뜨거워지자 그 다음 단계로 Serverless 가 등장했다. Rest API 처리나 어차피 평소에 할일없이 빈둥거리는 서버를 없애고 인스턴스 내부에서 소소한 역할을 수행하던 것들을 함수처럼 클라우드에 등록해놓고 필요할 때 적절한 이벤트 트리거를 걸어 사용하는 방식이 람다에 대한 짧지 않은 소개가 되겠다. AWS lambda 는 GCP 에서는 Cloud Function 이라는 이름으로 존재하는 기능이다. 아무튼 여기서 람다에 대해 살펴보고 작은 모듈을 등록해서 사용까지 해보도록 하자.

우선 AWS console 에 접속해서 lambda 서비스를 검색하도록 하자. 

검색후 서비스에 진입하게 되면 EC2 나 다른 서비스와 다르게 다소 심플한 메뉴로 구성되어있는 것을 확인할 수 있다. 좌측 햄버그 메뉴를 보면 대시보드와 함수. 두 가지 메뉴가 끝이다.

실제 프로그램을 등록해서 사용하는 부분이 함수되시겠다. 간단한 foo 함수를 등록해서 람다의 전체 흐름을 살펴보자. 함수 생성 메뉴를 누르면 아래와 같은 내용을 채워넣어야 한다. 우선 필수 항목인 이름과 기존 역할만 지정하고 넘어가도록 한다. 역할(롤)에 대한 등록이 필요하면 별도의 포스팅을 참고하도록 하자. 여기서 런타임은 노드를 기준으로 설명하도록 하겠다. 

잠시 기다리면 기본 템플릿이 생성되는데 사실 다른 모든 설정은 옵셔널이고 여기까지가 람다를 생성했다고 말할 수 있는 부분이다. 간단하게 옵션을 몇 가지 살펴보자. 

우선 람다에 코드를 등록하는 방법은 세 가지가 있는데 console 에서 바로 개발하는 인라인 방식이 있고, 모듈 추가나 코드양이 많아지는 경우 로컬에서 개발해서 zip 파일로 업로드 하는 방식이 있다. 끝으로는 S3 에 업로드해서 사용하는 방식이 있는데 CI/CD 를 위한 내용으로 이해하면 되겠다. 아래 그림과 같이 함수 코드 부분에 코드 입력 유형에서 내용을 볼 수 있다.

앞서 잠깐 이야기한 것 처럼 npm install 을 통해 새로 추가되어야하는 모듈이 있는 경우에는 로컬에서 개발을 하고 zip 형태로 압축해서 업로드를 하면 되는게 이때는 index.js 가 위치한 디렉터리에서 압축을 진행 하도록 하자. *NIX 환경이라면 대략 다음과 같겠다.

zip fooFunc.zip ./* -r

우측 상단에 테스트 버튼은 현재 보고 있는 람다를 즉시 실행할 수 있는 버튼이다. 로지컬한 부분에 대해서 다양한 테스트를 할 수 있겠다.

JSON 형태로 우리 람다에 데이터를 넘길 수도 있는데 이 정보는 event 인자에 담겨있다. ( 아래 코드에서 console.log 로 event 를 출력해본다 )

이렇게 테스트를 실행하거나 트리거에 의해 실행되었을 때 코드상에서 출력해놓은 console.log 는 어떻게 처리될까? GCP 가 stackdriver 로 로깅을 지원한다면 AWS 에는 CloudWatch 가 있다. 테스트를 실행시켰을 때 하단에 보이는 로그도 결국 클라우드와치의 로그가 되겠다. 아래는 event 를 console.log 로 출력하는 코드인데 실행결과를 통해 대충 람다에서 로그가 어떤식으로 활용되는지 알 수 있을 것이다.

클라우드와치는 로깅 이외에도 규칙을 생성하거나 대시보드를 지원하는 등 다양한 역할이 있지만 여기서는 로깅쪽만 집중하면된다. 클라우드와치의 기능에 대해서는 별도의 포스팅을 통해 다루도록 하겠다.

다음으로는 트리거를 등록해서 적절하게 서버리스 람다로의 역할을 충실히 수행할 수 있도록 설계하는 방법에 대해서 알아볼 텐데 아래 그림처럼 Designer 메뉴에서 람다를 트리거할 수 있는 목록을 확인할 수 있다. 주로 S3 이벤트를 받거나 API 게이트웨이, CloudWatch 조합으로 많이 사용된다. 사용하고자 하는 트리거를 드래그 앤 드롭으로 사용 설정할 수 있다.

람다는 기본적으로 서버리스 환경으로 동작하기 때문에 환경변수에 대한 부분을 궁금해할 수 있는데 이 부분도 옵션으로 제공해준다. 환경 변수 부분에 KEY - Value 개념으로 데이터를 넣어주면 된다. 아래 화면을 살펴보자. 

이제 람다 코드 안에서 process.env.foo 를 console.log 로 출력해보면 bar 라는 데이터를 확인할 수 있을 것이다. 여기에 TZ 에 대해 Asia/Seoul 을 설정해두면 timestamp 를 기반으로 date 를 뽑아낼 때 한국시간 기준으로 확인이 되기 때문에 습관적으로 넣어두는 것도 나쁘지 않겠다.

환경변수 관련해서 짚고 넘어가야 하는 것이 있는데 람다 코드가 수행중인 상태에서는 환경변수를 변경해도 의미가 없다는 것이다. 람다 코드가 실행되는 시점에는 코드가 모두 메모리(혹은 굳이 빗대어 컨테이너 같은 환경)에 올라가서 수행되는 상태기 때문에 런타임 중간에 변경되는 환경변수는 이미 실행중인 람다에 적용이 안된다고 이해하면 쉽겠다. 추가적으로 람다가 운영되는 환경의 조건을 아래와 같이 설정할 수 있다.

여기서 주의해야할 점은 제한 시간의 최대 설정값은 5분이라는 점이다. 5분이 넘어가는 코드는 람다로 구성하는 것보다는 인스턴스나 컨테이너 기반으로 운영하는 것을 고려해야하지 않을까 하는 생각을 해보면 왜 제한 시간의 최대 설정 값이 5분 밖에 안되는지 이해가 쉽게 된다. 끝으로 사용하지 않는 람다는 아래와 같이 삭제해서 정리하도록 하자.

마무리

여기까지 람다의 기본기능에 대해서 간략하게 살펴보았는데 사용해보기 전에는 막상 그 개념에 대해 이해하는 것이 쉽지 않았다. 하지만 일단 한번 사용해보시라. 왜 Serverless 의 첫 단추를 끼우기 위해서 람다가 필요한지, 또한 얼마나 강력한 기능인지 알 수 있을 것이다. 이제 Lambda 라는 재료를 통해서 다양한 요리를 도전해보도록 하자. :-)