흰 스타렉스에서 내가 내리지

> 기본 지식 - AWS Lambda - Amazon DynamoDB - Amazon EventBridge - Amazon SNS - Node.js - Serverless Framework > 주요 토픽 - AWS Lambda - AWS Lambda Layer - Amazon EventBridge Cron 규칙 - Puppeteer (Node.js 기반의 크롬브라우저를 컨트롤하는 프레임워크) - Serverless Framework 디시인사이드 지진희 갤러리에 지진이 일어나면 집중적으로 글이 올라온다. > 로직 - 다수의 유저가 지진을 느낄 경우 디시인사이드의 지진희갤러리에 글을 게시 - 일정 주기로 갤러리를 크롤링하여 게시글의 변동을 확인 - 디시인사이드에는 갤러리 글 별로 인덱스가 부여됨 - 주기적으..

Serverless Framework는 엄밀히 말해서 aws에서 제공하는 서비스는 아니고, aws 바깥에서 오픈소스로 제공되는 프레임워크다. > 기본 지식 - AWS CloudFormation - Amazon DynamoDB - AWS Lambda - Node.js > Serverless Framework "All-in-one development & monitoring of auto-scaling apps on AWS Lambda" - Serverless 아키텍처를 쉽게 구현할 수 있는 오픈소스 프레임워크 - 기능 - AWS Lambda의 배포 및 관리 - CloudFormation 기반으로 AWS의 인프라를 생성 - 참고 사항 - AWS Lambda에 관한 설정에 따라 기본적으로 프로비전하는 인프라 ..

# 이벤트의 특성 > 명령이 아닌 관찰한 내용 - 명령 : 생성 주체가 대상에 행동에 대한 관심을 가지고 회신을 기다림 - 이벤트 : 생성 주체는 대상의 행동에 관심이 없음 > 구성요소 - 사건의 내용 - 사건의 발생 시간 및 주체 - 불변성: 과거의 생성된 이벤트는 변경될 수 없음을 보장 > AWS의 이벤트 > Amazon EventBridge "Amazon EventBridge는 자체 애플리케이션, 통합 Software-as-a-Service(SaaS) 애플리케이션 및 AWS 서비스에서 생성된 이벤트를 사용하여 이벤트 기반 애플리케이션을 대규모로 손쉽게 구축할 수 있는 서버리스 이벤트 버스입니다. " > AWS의 이벤트 처리 "이벤트 버스" 라는 곳에서 이벤트가 발생하면 "규칙"들이 지켜보고 있다가,..

디커플링 : 서로 결합이 되어 있는 것을 분리시키는 작업. 어떻게 하면 좀 더 유연하게 아키텍처링을 할 수 있을까에 대한 고민에서 나왔다. 예를 들어 피자 주문은 [업체 연락, 돈 차감, 레코드 갱신] 과 연관되어 있다. '주문 이메일 발송'이라는 새로운 로직이 추가되었다고 하자. '주문 이메일 발송'이라는 애플리케이션 로직을 업데이트함과 동시에 '피자 주문' 애플리케이션도 업데이트가 불가피하다. 이러면 '긴밀한 결합'이 되어 있다고 부른다. 이것을 어떻게 유연하게 만들 수 있을까? 이렇데 하면, 주문 애플리케이션을 하는 일이 이벤트 큐에 주문을 밀어넣는 것 하나밖에 없다. 그럼 이벤트 큐를 다른 모듈들이 구독하고 있다가 변화가 생기면 각자 일을 하는 것이다. 만약 '배달업체 연락'이라는 로직을 추가한다..

# Static vs Dynamic Contents > 정적 컨텐츠 (Static Contents) - 서버에 저장된 파일이 모든 사용자에게 동일하게 전달되는 컨텐츠 - 매번 서버에 요청할 필요 없이 캐싱 가능 - HTML/Javascript 등으로 구성 - 예 : 이미지, 글 뉴스 등 > 동적 컨텐츠 (Dynamic Contents) - 시간, 사용자, 입력 등에 따라 내용이 변경되는 컨텐츠 - 매번 서버에 요청하여 내용을 구성하고 전달받아야 함 - PHP, JSP, ASP.net 등으로 서버 처리 - 예 : 로그인이 필요한 내용, 게시판, 댓글 등 # Amazon S3 Static Hosting - S3를 사용해서 정적(static) 웹 컨텐츠를 호스팅하는 기능 - 별도의 서버 없이 웹사이트 호스팅 ..

aws S3 권한을 관리하는 방법은 크게 두 가지가 있다. - Identity-based policied (자격 증명 기반 정책) - 자격증명 (IAM유저, 그룹, 역할)에 부여하는 정책 - 해당 자격증명이 무엇을 할 수 있는지 허용 - Resource-based policies (리소스 기반 정책) - 리소스 (예: S3, SQS, VPC Endpoint, KMS 등)에 부여하는 정책 - 해당 리소스에 누가 무엇을 할 수 있는지 허용 가능 - 예 : SQS 대기열에 Lambda Service가 접근 가능 # 1. S3 버킷 정책 - 버킷 단위로 부여되는 리소스 기반 정책 - 해당 버킷의 데이터에 "언제 어디서 누가 어떻게 무엇을" 할 수 있는지 정의 가능 - 리소스의 계층 구조에 따라 권한 조절 가능 ..

오토스케일링을 통해서 다수의 인스턴스를 생성하여 안정적인 서비스를 제공할 수 있다. auto scaling은 부하를 분산해주는 서비스가 없이는 활용이 거의 불가능하다. 그래서 나온 서비스가 Elastic Load Balancer (ELB)이다. 꼭 오토스케일링 그룹이 아니더라도 다수의 인스턴스들을 한 대로 묶어서 트래픽을 하나의 경로로 알아서 분산해 주는 서비스가 바로 로드밸런서다. 유저 입장에서는 각각의 인스턴스의 IP 주소로 접근하는 것이 아니라 하나의 주소로 접속하기만 해도 이 로드밸런서가 알아서 통신 트래픽들을 분산해 준다. 인스턴스가 unhealthy면 알아서 해당 인스턴스에 트래픽을 전송하지 않는다. 또 새로운 인스턴스들이 등록이 되면 자동으로 분산을 시켜준다. 그래서 로드밸런서의 기능은 간단..

#스케일링 스케일링의 종류: 1. Vertical Scale (Scale Up) - 성능을 4배로 하고 싶을 때 CPU가 4배 크고 메모리도 4배 큰 인스턴스를 사용하는 것 - 성능과 비용이 비례하지 않는다. 성능이 4배라고 비용이 4배가 되는것이 아니라 그 이상. 2. Horizontal Scale (Scale Out) - 인스턴스 각각의 성능을 올리는 것이 아니라 규모를 늘리는 것이다. - 성능을 4배로 하고 싶으면 인스턴스를 4개 가져다가 쓴다. - 성능과 비용이 비례한다. 클라우드 환경에서는 Scale Up 보다는 Scale Out을 하는 것이 좋다. 그리고 이 Horizontal Scale (Scale Out)을 위해서 나온 서비스가 AWS Auto Scaling이다. "AWS Auto Scal..

서버 - 컴퓨팅(CPU / RAM), 하드디스크, 랜카드 EC2 - 인스턴스(컴퓨팅), EBS(하드디스크), ✅ Amazon Elatstic Block Store(EBS) "EBS는 AWS 클라우드의 Amazon EC2 인스턴스에 사용할 영구 블록 스토리지 볼륨을 제공합니다. 각 Amazon EBS 볼륨은 가용 영역 내에 자동으로 복제되어 구성요소 장애로부터 보호해주고, 고가용성 및 내구성을 제공합니다. Amazon EBS 볼륨은 워크로드 실행에 필요한 지연시간이 짧고 일관된 성능을 제공합니다. Amazon EBS를 사용하면 단 몇 분 내에 사용량을 많게 또는 적게 확장할 수 있으며, 프로비저닝한 부분에 대해서만 저렴한 비용을 지불합니다." - 가상 하드드라이브 - EC2 인스턴스가 종료되어도 계속 유지..

컨테이너가 각곽을 받게 된 것은 빠르게 변하는 시장에서 예측할 수 없는 고객의 요구사항에 기인한다. 이런 환경에서 우리는 더욱 빠르고, 안정적이며 효율적인 시스템 구축이 필요했다. 이러한 환경에서 비즈니스의 목표를 달성하기 위해서는 신뢰할수 있는 인프라 환경에서 애플리케이션 개발에만 집중할 수 있어야 하며, 고객의 트래픽에 따라 유연하게 대응할 수 있어야 한다. 그리고 무엇보다 보안에 안전해야 한다. 이러한 목표를 이루기 위해서 컨테이너 기술이 등장하게 되었다. 우리가 애플리케이션을 개발할 때 생각해보면, 우리는 우선 비즈니스 로직을 코드로 구현해야 한다. 그리고 데이터를 저장하고 사용하기 위해 데이터베이스를 활용하며 이를 연결하기 위한 환경변수들은 설정 파일로 분리한다. 또한 코드 개발을 위해 여러가지..