컴맹 : 진화의 시작

Lambda(람다) 배포 방식에는 네 가지가 존재합니다. (1) 소스코드를 에디터에서 직접 개발 (2) ZIP 압축 파일을 업로드해서 배포 (3) S3 경로에 압축파일을 두고 배포 (4) 컨테이너 이미지를 통해 배포가 있습니다. 이번 글에서는 컨테이너 이미지를 통해 배포하는 방법을 알아볼 텐데요. 특이한 조건이 하나 붙일 겁니다. 테라폼 코드를 통해 Lambda와 ECR을 최초 배포할 때 컨테이너 이미지를 어떻게 처리해야 하는가입니다. 정확하게는 AWS 인프라를 테라폼으로 초기 구축하는 상황인 겁니다. 이런 상황에서 무엇이 문제가 되는지 살펴보려면 생성해야 하는 리소스를 알아야 합니다. 먼저 ECR(Elastic Container Registry)를 생성해줘야 합니다. 소스코드는 대충 아래와 같은 모양입..

지난번 글( 서버리스 Cloud Functions 사용하기 ) 에서 Cloud Functions 의 전반적인 내용에 대해서 훑어보았다. 작은 모듈 단위의 프로그램을 서버 구동 없이( 엄밀하게는 사용자가 신경 쓸 필요 없는 / 신경 쓸 수 없는 ) 사용할 수 있는 서버리스의 장점에 대해서 이야기를 했었는데 이번에는 그 한계에 대해 잠시 살펴보고 비판해보도록 하자. 이렇게 비판하는 정보를 공유하는 이유는 한계를 모르는 상태로 Serverless 서비스를 운영하는 것은 매우 위험하다고 생각하고 있기 때문이다.Google Cloud Functions 은 Serverless 의 역할을 충실히 수행하며 작은 모듈 단위를 클라우드 위에서 동작 시키는데, 타사의 FaaS 대비해서 무엇이 좀 많이 부족하다. 그렇기 때문..

이번에는 Cloud Functions 에 대해서 살펴보는 시간을 갖도록 한다. 기능은 단어 그대로 클라우드 위에 함수를 등록하고 트리거 ( Trigger )를 걸고 사용하는 개념이 되겠다. 쉽게 이야기해서 이벤트가 발생되면 등록해놓은 함수가 동작하는 방식이겠다. 이제 더 이상 작은 모듈을 위해 GCE 를 운영할 필요가 없겠다. Cloud Functions 은 서버리스로 동작하니까. AWS 에서는 Lambda 가 같은 개념이 되겠다. 아무튼, 서비스목록에서 Cloud Functions 를 선택해서 기능을 직접 사용해보도록 하자. 한국어로 봤을 때는 "Cloud 기능" 을 확인하면 된다. ( 근데 왜 아직도 베타인지? 는 아래쪽에서 추측해보도록 하자. )Cloud Functions 메뉴에 최초 진입시에는 A..

람다, 서버리스의 첫걸음을 통해 AWS 의 Lambda 서비스에 대해 간략하게 소개를 했다. 이번에는 조금은 더 심도 있는 이야기를 할 텐데 람다의 구조와 원리를 파악하고 자연스럽게 그 한계를 깨우치도록 하자. 내부 로직을 어느정도 이해하고 있어야 어떤 상황에 서버리스( Serverless ) 람다가 독이 되는지 알 수 있게된다. 어설프게 이해하고 사용 하다가는 독이 된다는 사실로 시작해보자.서버리스는 없다람다는 AWS 에서 서버리스를 대표하는 서비스 중 하나다. 앞선 글에서도 그렇게 밝혔고. 근데 이제와서 서버리스는 없다니 이게 무슨 소리지? 이건 클라우드로 넘어오면서 생긴 개념인데 EC2 와 같은 IaaS 는 이미 사용자에게 서버를 클라우드 상에서 제공하며 IDC 상황에서 겪었어야 했던 수 많은 작업..

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