AWS Lamdba (코드 작성 및 관리)

람다를 사용할때 개발자가 고려해야하는 사항은 코드를 작성하는 부분과 코드를 관리하는 부분으로 나뉜다.

 

코드를 작성할때는 시스템 아키텍처, 설계패턴, 프레임워크 및 라이브러리, 등에 대해서 어떻게 서버리스환경에서 코드를 작성할 것인가? 코드를 관리할때는 도구 (IDE, SCM, 디버거 등),개발자 워크 플로우, 테스트/배포 자동화, 환경관리를 어떻게 할 것인가에 대해 고려해 봐야한다.

 

특히 람다를 짤대 유의해야할점은 다음과 같다.

람다를 통해 코드를 작성하고 AWS 콘솔에서 테스트 및 배포를 정말 간단하게 할 수 있다. 하지만 프로덕션 에플리케이션 환경(라이브 환경)이라면 객체 지향 코드 작성이 필요하다. 또한 "프로그래머는 항상 개을러야한다."는 노마드 코더의 '니콜라스'의 말 처럼 최대한 자동화 및 표준화를 해서 사람의 손을 덜 타게 해야하며 실수나 수동 변경사항을 막을 수 있는 가장 좋은 환경인 자동화 되어있는 환경, 배포 환경구성, 운영 등을 온프레미스 환경에서 적용하는것과 마찬가지로 적용해야한다.

 

그림1. 람다의 구조

 

그림1은 람다의 구조를 나타내고 있다. 람다는 헨들러, 컨트롤러, 서비스로 이루어져 있다. 
람다의 구조중 가장 핵심 헨들러 메서드는 Java의 메인 메서드와 동일한 엔트리 포인트의 개념으로 이해하면 편하다. 람다가 호출되면 시작이 되고 다 실행되고 나면 람다가 종료가 된다. 헨들러에는 특별히 너무 많은 내용을 포함하면 가독성도 떨어지며 언어적인 특성에 따라 좋지않은 효과를 나타낼 수 도 있기에 중요한 비즈니스 로직은 사용할 언어적 특성에 따라서 분리해서 사용해야한다.

즉 시작과끝을 관리하며 함수 구성, 람다 관련코드, 실제 비즈니스 로직을 제외한다.

 

컨트롤러는 이벤트를 처리하고 구체적인 핵심 비즈니스 로직을 처리하는 구간을 의미한다. 구체적으로 어떤 로직이 구동되는지 등에 대한 정보를 가지고 있다.

 

마지막으로 서비스 클레스는 AWS 관련 내부 및 외부 서비스를 통합하며 서비스를 추상화, 객체화 하는 부분이다.

 

핸들러 라는 개념을 제외하고는 실제 환경에서 사용하는것과 굉장히 유사한데 이는 서버리스 플렛폼에 종속된 개발을 추구하는것이 아닌 개발에 도움을 주고자 하는 플랫폼임을 알 수 있다.

 

조금 뜬금없는 이야기지만 윈도우XP를 사용할때랑 윈도우 10을 사용할때의 하드웨어 환경을 생각해 보자. 과거 윈도우 xp를 사용할때는 못해도 1분 이상 pc앞에 앉아서 부팅을 기다려야 했다. 하지만 최근은 SSD가 상용화됨에따라 빠르면1초 늦어봤자 30초 안에 pc가 부팅이된다. 이와 같이 프로그래밍을 할때도 빠르게 실행이되고 빠르게 종료가되는것이 중요하다.

이와같이 람다에서도 라이브러리 및 프레임 워크 사용을 할때 권장하는 것으로 부트스트랩 시간을 제한을 두는것이 있다. 실행 시간을 단축시킨다는 개념은 람다에서는 더 중요하다. 이때 외부의 라이브러리나 프레임워크를 적극적으로 사용하겠다 라고 한다면 콜드 스타트 라는 개념을 사용해야한다. 

 

* 콜드스타트 

일반적으로 전통적인 애플리케이션은 1번 실행되고나면 재실행되는 경우는 많지 않다. 반면 람다는 처음으로 실행되는 함수가 상대적으로 많을 수 밖에 없다. 이때 실행될때마다 실행환경이 초기화되면서 코드를 실행하는데까지 시간이 소모가되는데 이것을 의미한다.

 

* 부트스트랩

부트스트랩 작업은 Amazon EMR 이 Amazon Linux AMI 를 사용하여 인스턴스를 시작한 후 클러스터에서 실행되는 스크립트이다. 부트스트랩 작업은 사용자가 클러스터를 생성할 때 지정한 애플리케이션을 Amazon EMR 에서 설치하기 이전 및 클러스터 노드에서 데이터 처리를 시작하기 이전에 실행됩니다. 실행 중인 클러스터에 노드를 추가하는 경우, 부트스트랩 작업은 해당 노드에서도 같은 방식으로 실행됩니다. 사용자 지정 부트스트랩 작업을 생성한 다음 클러스터를 생성할 때 해당 작업을 지정할 수 있습니다. 1) (출저 AWS 관리안내서)

 

이때는 코드를 람다에 실행하는 실행 컨텐츠에 다운받거나 라이브러리등에 로드하는시간 즉 코드가 실행되기 위한 런타임환경을 셋업하는 부트스트랩시간이 걸린다. 따라서 콜드스타트 라고 하는것은 라이브러리 프레임워크 등을 무거운것을 사용할수록 길어진다. 

염두할 점은 전체 디펜던스를 포함하는 전체 람다의 배포 패키지 크기 자체를 최소화 하는게 중요하다. 이와 같은 맥락에서 시작하는데 걸리는 부트스트랩을 줄이는것은 중요하다. 예시로서 Java를 기반으로 하는 스프링과 같은 프레임워크의 경우 스프링 초기화할때 시간이 많이 걸리는 대표적인 프레임이있다.

 

콜드 스타트에 영향을 미칠 수 밖에 없는 환경은 콜드 스타트할때마다 초기화하며 이것은 추가적인 지출이 발생된다. 이것은 비용이 쓸대없이 낭비된다라는 것으로 귀결된다. 이것을 예방하기 위해서는 동적으로 실행될 때마다 가져오는것보다는 스테틱방식이 훨신더 효율적이다.

 

지금까지는 코드를 작성하는것에 대해 알아보았다. 다음의 내용은 코드를 관리하는 부분에 대해 알아보도록 하겠다.

 

기본적으로 람다에서 코드를 관리하는 방법면은 기본의 환경과 별 차이가 없다. 즉 코드 작성에 대한 방식(source control, ide, 빌드, 배포), 도구가 변경되지는 않다. 
하지만 여기에 빌드 결과물을 여러 서비리스 애플리케이션 프레임워크를 사용해서 다양한 구성요소를 같이 배포해야하는 경우가 생긴다. api gatway같은 상호작용 해야하는 경우 등이 있는데 이때 애플리케이션 프레임워크를 추가하기만 하면된다.

 

다음은 람다의 배포 과정에 대한 예시다.

람다 배포 과정(APIgateway를 트리거할때)

1. 코드를 빌드한다.
2. 1에서 빌드한 코드를 압축하고 그 결과물을

3. Amazon s3에 업로드한다
4. 람다에서 호출하는 다른 aws서비스 들에 대한 역할을 만들고 업데이트한다
5. 람다함수를 만들고 역할을 할당한다.

6. 여기에 트리거를 만들어야하는데 REST API를 설정해 준다. 
7. 이 API에 리소스, 메서드를 생성 하고
8. 각각의 http 리소스를 람다로 가도록 integration 업데이트 한다.
9. 필요시 다이나노 db테이블을 만들어서 정상적으로 읽고 쓴느데 필요한 테이블을 만든다

 

 

생각한것 이상으로 간편하다. 하지만 AWS에서는 더 간편하게 배포할 수 있는 방법을 다양하게 제시하고 있다. 그 대표적인것으로는 AWS CloudFormation, AWS SAM(Serverless Application Model)이 있으며 이것을 사용해서 한 번에 배포할 수 있다. 하지만 cloudformation은 사용해 본 사람은 알다시피 매우 길고 어렵기 때문에 조금 불편할 수 있다.(진짜 어렵다. 거짓말 아니라 진짜 너무 어렵다. 왜 어린 아이들에게 글을 알려줄때 글만 있는 책이 아닌 그림이 있는 책을 주는지 생각해보자.) 그렇기에 우리는 상대적으로 편하고 효율적인 SAM 을 사용하도록 하자. 

 

* 이것뿐 아니라 다른 서버리스 프레임워크 앱을 사용할 수 있다.

 

SAM CLI은 이름에서 알 수 있듯 로컬에서 커멘드를 사용해 실행 가능한 서비스 이다. 필요하다면 개발한 코드를 페키징, 빌드한 후 결과물 압축, 업로드 과정과 실제 람다로 베포하는 과정을 삼 cli를 통해서 간단하게 배포할 수 있다.

명령어도 다음 2개면 업데이트, 배포를 할 수 있다.
$sam package ==>s3에 업로드해 람다로 업데이트
$sam deploy ==> 실제 sam에 배포가 진행되고 람다에 그 결과물을 배포

 

그럼 개발자는 이런 람다를 이것저것 만들고 코드 리포지토리를 구성했다. 그러면 이것을 어떻게 보관(저장)할 것인가에 대해 고민을 해 본다. AWS에서 권장하기로는 서비스의 성격에 따라 한곳에 모든것을 보관할지 아니면 각각 함수별로 따로 분할할지에 대해 개발자 마음대로 해도 된다 라고 이야기한다. 하지만 이것을 나누는 기준은 명확한데 각각 상호 연관성이 없을땐 개별적으로 각 함수별로  연관성이 있다면 같이하는게좋다.

다음 파트에서는 람다를 개발하기 위한 개발 환경 설정 등에 대해 알아보도록 하겠다.