코딩과로그

이전 실습 의 연장선입니다. POST 전용으로만 작동하게 만들기 람다의 게이트웨이에 접속한다. 기존 ANY 를 제거한다. (ANY: 모든 메서드 (CRUD)를 의미함) POST 를 추가한다. API 배포 를 한다. 적용됐는 지 테스트 람다 페이지로 이동하여 ENDPOINT 확인 GET 로는 접속이 되지 않는 것을 확인 curl https://ffvbmhwdzj.execute-api.ap-northeast-2.amazonaws.com/default/sam-app-LambdaPutDynamoDB-2dGVtrg4bGp0 # 접속 실패 {"message":"Missing Authentication Token"} POST 로 접속이 가능함을 확인 curl -X POST https://ffvbmhwdzj.execu..

참고 자료 https://serverlessland.com/patterns/lambda-dynamodb https://ihp001.tistory.com/216 목표 API Gateway의 endpoint 를 통해 접속해서 람다함수를 호출하고 dynamodDB 에 데이터를 저장하기 실습 선수 조건 AWS CLI 자격 증명 이 완료되어야 함. 실습 순서 Step 1: 공식 사이트에서 SAM 을 설치한다 Step 2: 예제를 다운받는다. 이 예제를 통해 lambda 와 dynamoDB 를 배포할 수 있다 $ git clone https://github.com/aws-samples/serverless-patterns/ $ cd serverless-patterns/lambda-dynamodb template.ya..

출처: 인파님 블로그 코드스테이츠 공부한 내용을 스스로 되새기기 위한 목적으로 작성되었습니다. API Gateway 서비스 규모에 상관없이 API 생성, 유지 관리, 모니터링과 보호를 할 수 있게 해주는 서비스 API 게이트웨이를 등록해주면, 모든 클라이언트는 각 서비스의 엔드포인트 대신 API Gateway로 요청을 전달하여 관리가 용이해 진다 (즉, 느슨한 결합 유지). 사용자가 설정한 라우팅 설정에 따라 각 엔드포인트로 클라이언트를 대리하여 요청하고 응답을 받으면 다시 클라이언트에게 전달하는 프록시(proxy) 역할을 하기 때문이다. api 경유지 역할 뿐만 아니라, 엔드포인트 서버에서 공통으로 필요한 인증/인가, 사용량 제어, 요청/응답 변조 등의 다양한 기능을 플러그인 형태로 제공함. ** La..

AWS Lambda AWS가 제공하는 서버리스 FaaS 솔루션 함수의 인스턴스를 실행하여 이벤트를 처리 FaaS 개발자가 자체 인프라를 유지관리할 필요 없는 일종의 클라우드 컴퓨팅 서비스 Stateless이고 런타임으로 특정 서버환경(eg. Node.js v14, Docker Image, etc)을 지정하여 사용 수평적 확장은 완전 자동이며 탄력적이며 공급자가 관리함 FaaS의 기능은 일반적으로 공급자가 정의한 이벤트 유형에 의해 트리거됨 특징 서버를 프로비저닝하거나 관리할 필요가 없음 즉, 자동으로 스케일 아웃이 됨 애플리케이션 또는 백엔드 서비스의 코드를 작성한 뒤 이벤트 트리거만 정의하면 동작이 됨 이벤트 주도 아키텍처에 적합 높은 가용성 AWS Lambda의 단점 Cold Start와 Warm S..

프로세스 간 통신 요청을 보내는 즉시 수신자로부터 응답이 오길 기대하는 "동기적 방법" 클라이언트-서버 아키텍처의 REST(HTTP)가 대표적 요청을 일단 보내놓고 수신자가 받을 때까지 보관했다가 처리하는 "비동기적 방법" 수신자가 받기 전에 누군가는 메시지를 보관해놓아야 한다 → 메시지 브로커 (메시지 큐) 메시지 브로커가 필요한 이유 분산 애플리케이션에서 프로세스 간의 느슨한 결합(loosely coupled)을 제공하는 것이 가장 큰 장점입니다. 그렇다면 강하게 결합된 시스템에서의 단점은 무엇일까요? 서로 연결되어 있는 시스템 중 한 곳에서 장애가 발생했을 때 그 장애가 연결된 다른 시스템들에 영향이 갑니다. 예를 들어 다음과 같은 상황에서, Server 2에 장애 상황이 발생하면, Server 1..

CAP란? 분산 데이터베이스는 방대한 데이터를 다루기에 유용한 시스템이다. 분산 데이터베이스는 수평 확장할 수 있기 때문에 트래픽이 증가하더라도 낮은 지연 시간을 유지할 수 있고, 일부 노드 장애에 적절히 대응할 수 있다. NoSQL 데이터베이스는 대표적인 분산 데이터베이스이며, 유연하게 데이터를 다룰 수 있다는 장점이 있다. NoSQL 데이터베이스는 서로 다른 특징을 가진 여러 제품이 있기 때문에 애플리케이션에 맞는 특성에 맞는 데이터베이스를 선택해야 한다. 이를 위해서는 각 제품의 특징뿐만 아니라 데이터베이스 이론 또한 이해해야 한다. CAP는 분산 데이베이스 속성에 관한 이론으로써, 분산 데이터베이스 활용이 많아지면서 최근 각광을 받고 있다. CAP 이론은 시스템 장애로 인해 몇몇의 인스턴스가 다른..

마이크로서비스 아키텍처의 정의 https://microservices.io/ 다음 특징을 갖는 서비스들의 조합으로 이뤄진 설계 유지보수에 유리하고, 테스트 가능해야 함 느슨하게 결합되어야 함 독립적으로 배포 가능함 비즈니스 역량을 중심으로 구성해야 함 작은 팀에 의해 소유됨 서비스로서의 컴포넌트화 컴포넌트: 독립적으로 대체하거나 업그레이드 가능한 소프트웨어 단위 컴포넌트화: 시스템을 구성 요소(Component)를 나누고 이를 연결하여 구축하는 것 컴포넌트화는 어떻게?: 소프트웨어를 여러 서비스로 분리하는 것 라이브러리 vs. 서비스 비즈니스 수행에 따른 구성, 프로젝트가 아니라 제품 before: 기술적 계층에 따른 팀 분류 예) UI 팀, 비즈니스 로직 팀, 데이터베이스 팀 단순한 변경이 필요한 경우..

출처: 인파님 블로그 공부한 내용을 스스로 되새기기 위한 목적으로 작성되었습니다. 서버리스 아키텍쳐 란? 서버리스(Serverless)는 직역하면 "서버가 없다"라는 뜻이 된다. 하지만 정말로 서버가 없는 것을 뜻하는게 아니다. 서비스를 하는데 있어 어찌되었든 저장소는 필요하고 서버는 필요하기 때문이다. 따라서 정확히 말하자면, 서버리스는 서버가 없는 백엔드 라는 뜻이 아닌 우리가 직접 서버를 관리하지 않아 신경 쓸 필요없는 경우를 뜻한다. 즉, 서버리스 아키텍처(Serverless Architecture)란 서버를 직접 관리할 필요가 없는 아키텍처를 칭한다. 서버리스는 특히, 사이드 프로젝트나 빠르게 프로토타입을 출시할 때 빠르고 쉽게 제품을 출시할 수 있고, 돈도 매우 절약할 수 있다. 서버리스 시장..