lambda 썸네일형 리스트형 AWS에서 Serverless 배포 생각정리 고전적인 시스템환경의 APP의 배포방식은 기본적으로 다음의 방법을 따른다. APP 배포/업데이트 개발이 완료된것을 빌드(Jenkins,수동) , Repository(Nexus)에 등록 ALB(nginx와 같은 L7레이어)에서 배포할 인스턴스 타겟 제거 인스턴스에 앱 배포 ALB에 인스턴스 다시 추가 Scale out 늘리는 경우 새로운 인스턴스를 생성, 앱 배포후 ALB에 등록만 해주면 끝 줄이는 경우 ALB에서 인스턴스를 제거후, 앱의 동작이 완료된 시점에 앱 정지, 인스턴스 제거 일반적인 APP의 경우 APP 자체에서 외부 인터넷과 연결될 필요가 없기 때문에, Private Subnet안에 있어도 무방하며, 접근이 필요한 endpoint만 ELB에 연결되어 있어도 큰 문제가 되지 않는다. (cf. 외.. 더보기 EC2, Fargate, Lambda. 뭐쓰지? 서비스를 준비중인 상황에서, 가능한 서비스 기반을 검토해보았다. (Fargate, ECS Anywhere까지 몽땅 테스트는 해봤다. 🤗) (기본적인 EC2, Lambda는 나중에 좀더 구체적으로 정리할 일이 있을 것 같다. ) ECS는 기본비용이 없다. 사용한 Resource에 대한 비용만 내면 된다. 사용가능한 Resource는 EC2 Instance, Fargate, External(외부 머신) External은 ECS Anywhere라고 AWS 외부에 생성되어있는 서버들에 Agent를 설치해서 ECS 서비스를 배포할때 해당 위치들로 배포할 수 있게 해준다. 아직 ELB와 같이 연계된 서비스들은 지원하지 않는다. (지금은 걍 도커 명령 대신 날려주는 수준이다. 🤨) Fargate는 얼핏 비교하면 La.. 더보기 AWS CDK - API Gateway, Lambda (1) 회사에서 AWS로 EC2만 주구장창 사용하다가, 비용적인 문제와 Scale up / out 에 대한 고민이 깊어지기 시작했다. Spot Instance를 최대한 활용해보기도 했지만 기본적으로 24시간 EC2를 켜두는 것은 잘못된 방법인것 같았다. 그래서, AWS에서는 쓰는만큼만 사용하면 되는 Serverless한 서비스들로 눈을 돌렸다. 너무나 다양한 서비스들이 있기에, 기존에 사용하던 것들을 하나씩 대체하면서 개발 환경을 구성해보기로 했다. 우선 AWS Console에서는 (비교적🤔) 쉽게 Lambda와 API Gateway 구성을 할 수 있다. 그렇지만 개발자들이 매번 그 구성을 따라하면서 직접 개발하고 배포하기에는 너무나 리스키한 부분이 많다. (AWS Console에 들어와서 뭔가 직접 조작한다는.. 더보기 이전 1 다음