람다는 우리가 작성한 함수를 오로지 필요할 때만 실행하고 그리고 자동으로 스케일 아웃 해준다. 오로지 우리가 사용한 컴퓨팅 시간만큼만 비용을 지불하면 되기 때문에 좋다. 람다를 쓰면 일단 모든 하드웨어적 리소스에 대해 전혀 신경쓸 필요가 없기 때문에 좋다. 그리고 람다

AWS에서는 계정당 총 1000개 까지의 lambda concurrency를 가질 수 있다. 따라서 특정 람다에 갑자기 1000개 이상의 리퀘스트가 폭주해버리면 다른 람다는 실행될 수가 없기에 다른 람다에 대한 리퀘스트는 거부된다. 이것은 throttling이라고 하는

SendMessage 요청에 대한 응답 속에는 시스템이 부여한 해당 메시지의 id가 들어 있다. 이 id로 메시지를 식별할 수는 있지만 이것으로 메시지를 큐에서 삭제할 수는 없다. 메시지를 큐로부터 받을 때 대신 우리는 receipt handle이라는 것을 받는데 이것

1. 개요 Dead-Letter Queue는 하나 이상의 Source Queue가 성공적으로 컨슘되지 못한 메시지들을 재전송하기 위해 사용하는 별도의 큐이다. SQS는 DLQ를 자동으로 생성해주지 않기 때문에 그것을 사용하려면 미리 생성해두어야 한다. FIFO 큐의

Unlimited Throughput: SendMessage, ReceiveMessage, or DeleteMessage 같은 API 호출을 초당 무제한에 가깝게 호출 가능At-Least-Once Delivery: 보통은 하나의 메시지가 컨슈머로 전송되지만 간혹 같은

리퀘스트가 오면 캐시에 데이터가 존재하는지 여부를 확인 후에 필요하면 DB에 접근쓰기 리퀘스트인 경우 일단 캐시에 먼저 쓴 후에 나중에 주기적으로 캐시의 내용을 DB에 옮겨 씀주요 용도인증 토큰: Strings 또는 HashRanking 보드: Sorted Set유저

Apollo Server는 에러가 발생하면 그 응답에 errors 배열을 준다. 그리고 이때 배열의 각 원소는 extensions라는 객체를 갖고 있는데 해당 객체는 code라는 필드의 각 에러의 이름을 갖고 있다. 이것들은 모드 ApolloError 객체들이다. 어

DataLoader 유틸리티는 캐싱 및 배채 로드에 활용된다. memoization 캐시를 제공함으로써 하나의 GraphQL 리퀘스트 동안 같은 객체가 여러번 로드되는 것을 방지해준다. 한번의 event loop 틱 동안 발생한 로드들을 하나의 배치성 리퀘스트(한번에

Apollo Server를 사용할 수 있는 다양한 패키지가 있는데 보통은 apollo-server를 쓰다가 좀더 세밀한 설정을 할 수 있는 apollo-server-express로 갈아타는 경우가 많다. (apollo-server도 내부적으로는 apollo-server

GraphQL에서 원하는 모든 필드에는 argument를 넣을 수 있다. 보통 이런 식으로 조회를 할 수 있는데이렇게 하기보다는 이런 식으로 정의해두고 info variable를 사용하는 것이 권장된다.

A resolver is a function that's responsible for populating the data for a single field in your schema.GraphQL의 핵심 개념이다. 프론트엔드에서 특정 필드를 요구할 때 해당 필드를 담당

GraphqQL의 장점은 개발용 목적으로 현재 서버에서 지원하는 스키마 현황을 조회해볼 수 있다는 점이다. 물론 실제 프로덕션에서는 이러한 기능이 지원되면 안 되기 때문에 Apollo Server에서는 NODE_ENV가 production일 때 이 기능이 꺼져있다.

Apollo는 프론트엔드와 백엔드 사이의 communication layer(=a unified graph)를 만들기 위한 플랫폼이다. graph의 중심에는 GraphQL이라고 불리우는 query language가 있다. GraphQL을 쓰는 다양한 이유가 있지만 그

이 데이터는 2주간 기록된다. 그리고 이 데이터는 CloudWatch로 1분마다 전송된다. 그리고 실행되고 있는 태스크가 있는 경우에만 CloudWatch에 전송된다.Fargate를 사용하는 경우 별도로 해줄 설정은 없으나 만약 EC2 launch type이라면 Lin

ECS에서 Auto Scaling 관련 옵션을 설정할 때는 최소 태스크 수 / 희망 태스크 수 / 최대 태스크 수를 설정할 수 있고스케일링을 할 때 사용하는 정책은 크게 다음과 같이 둘로 나뉜다. (1) Target tracking scaling policies(Rec

1. 태스크 생명주기 하나의 태스크는 다음과 같은 생명주기를 갖는다. (1) PROVISIONING ECS가 태스크 시작 전 준비하는 단계로 예를 들어 만약 awsvpc 네트워크 모드를 사용한다면 ENI가 프로비저닝되어야 한다. (2) PENDING Contain

EC2 타입의 ECS 태스크들의 네트워킹은 task definition에 정의된 network mode에 의해 결정된다. 다음과 같은 모드들이 있다. (1) awsvpc: 각 태스크는 그것만의 ENI와 private IPV4 주소를 할당받는다. 이렇게 되면 각 태스크는

Task Definition에 정의할 수 있는 각 파라미터 관련 주의사항들을 정리해본다.새로운 태스크가 시작될 때 ECS는 해당 이미지를 pull해서 컨테이너화한다. 다만 이미 태스크가 실행된 후에는 이미지를 업데이트해봤자 이미 실행 중은 태스크에 반영되는 것은 아니다

실무에서 ECS를 쓰다가 좀더 깊은 레벨까지 알고 싶은 마음에 공식 문서를 정독하고 이때까지 잘 몰랐던 내용을 정리해보았습니다. 1. 필수 개념 (1) Task Definition 사용할 컨테이너(들)에 관한 정의로 JSON format으로 된 텍스트 파일이다. 최

말 그대로 템플릿을 제공하는 패턴이다. 부모 클래스(보통 추상 클래스)에서 각 작업에 대한 전반적인 로직의 알고리즘을 나타내고각 자식 클래스에 각 로직들에 대해서는 구체적인 커스텀 로직을 구현하는 패턴이다. 여러 자식 클래스들의 전반적인 로직의 알고리즘이 대부분 비슷한