note1

1. RTO, RPORecovery Time Objective: 복구 목표 시간재난 발생 시 다운타임 없이 견딜 수 있는 시간Reovery Point Objective: 복구 목표 시점재난 발생 시 견딜 수 있는 데이터 손실의 정도 -> 백업 주기와 관련중요한 시스템일수록 RTO, RPO 시간이 짧음2. 가용성고가용성 (High Availability: HA)애플리케이션의 중단 시간 최소화백업 (Backup)시스템의 복구를 위해 애플리케이션과 데이터를 안전하게 저장재해복구 (Disaster Recovery)재해가 발생하면 백업한 애플리케이션과 데이터를 이용해 시스템을 사용가능한 상태로 복원가용성 100%는 불가능, 고가용성을 높이려면 비용이 소비됨비용과 효과(이익)를 따져서 가용성 수준을 결정함3. 장애..

1. Hypervisor 가상화와 Container 가상화2. 클라우드 컴퓨팅 최적화확장성, 탄력성, 비용 관리가상머신 이미지를 이용해 필요한 만큼 인스턴스를 생성할 수 있음더 이상 필요 없다면 종료할 수 있음가상 서버 x -> 가상 인스턴스필요한 수요에 맞추어 탄력적으로 용량을 조절 가능Monolith(무조건 영향성 평가, 배포 주기 길어짐) vs MicroService컨테이너, 서버리스 -> MicroService2. API Gateway + LambdaALB + Auto Scaling Group + EC2로도 가능하지만 관리 운영 오버헤드 높음API GW + Lambda 조합Serveless3. 컨테이너 기반 서비스AWS가 제공하는 두 가지 컨테이너 오케스트레이션 서비스EC2: AWS가 자체적으로 ..

1. API Gateway어떤 규모에서든 개발자가 API를 손쉽게 생성, 게시, 유지 관리, 모니터링 및 보안 유지할 수 있도록 하는 완전 관리형 서비스Lambda, EC2의 HTTP 엔드포인트, AWS 서비스, VPC Endpoint 등의 리소스를 통합한 애플리케이션을 위한 단일 진입점을 제공함인증, 캐싱, 보안 기능을 손쉽게 통합할 수 있음인증: Cognito캐싱: API Gateway내에 자체적인 캐싱 기능 제공보안: AWS WAF와 통합모델, 사용량 계획, API KeyAPI Gateway 장점실제 엔드포인트가 노출되지 않음DDos, Injection 공격 방어 -> AWS WAFSignature V4를 이용한 API 액세스 승인Lambda과 잘 통합됨2. Step Function시각적 워크플로우..

1. Serverless서버를 직접 관리할 필요가 없음종량제 요금: 사용한 만큼 비용 지불수요에 따라 자동으로 크기 조정고가용성 기본 지원대표적인 서버리스 서비스Lambda, API Gateway, Step Function, Fargate, AppSyncSNS, SQSKinesis, Athena, S3, DynamoDB, Aurora2. Lambda완전 관리형 서비스 (서버리스)상태 비저장 함수 실행 (Stateless)사용 가능한 언어JAVA, Python, C#, Node.js, Go, Ruby 등기본 지원하지 않아도 부트스트랩만 설정하면 다른 언어들도 실행할 수 있음Lambda 구성종속성 (Dependency, 의존 라이브러리 등), 함수 코드, 구성Lambda 특징상태 비저장: 함수 호출이 완료되..

1. SQS (Simple Queue Service)완전관리형 메시지 큐 서비스생산자 (producer)와 소비자 (customer) 간의 버퍼 역할Loosely Coupled Architecture 구현비동기 처리 -> 사용자에게 신속하게 응답SQS 지표 -> 경보 -> 소비자 애플리케이션을 처리하는 인스턴스 확장DLQ (Dead Letter Queue)SQS의 큐 유형Standard최소 1회 처리 (여러 번 처리될 수도 있음)무제한 처리 용량순서대로 처리됨을 보장받지 못함FIFO정확히 1회 처리초당 300건의 메시지 처리 (배치처리 시 10건씩 묶어서 처리하므로 최대 3000건/초)순서대로 처리됨을 보장SQS의 메시지메시지의 최대 크기: 256KB따라서 대용량 데이터를 처리하려면 S3 등을 결합하여 ..

1. IAM보안주체 (Principal)Root Account User계정(Accout)을 처음 만들 때의 사용자모든 권한을 가지므로 비용 결제, 개인정보 관리 등의 작업을 제외하면 사용하지 않는 것이 좋음Access Key(Access Key ID + Secret Access Key)를 삭제하여 CLI, SDK로는 접근할 수 없도록 할 것User: 1 Account 하위의 N userGroup : 1 Group > N user (포함관계)Role : 임시권한을 위한 특별 보안 주체2. 정책 (Policy)JSON 문서로 저장되는 권한에 대한 형식 선언요청 시에 평가됨정책 종류자격증명 기반 정책: 보안 주체에 권한을 부여하는 정책AWS 관리형 정책고객 관리형 정책인라인 정책 (직접 JSON문서로 작성)리..

1. Elasticache란?AWS에서 인메모리 캐시 DB 기능을 제공하는 관리형 서비스읽기 성능 향상이 목적캐시 (x) -> 캐시 (0) 변경 시 애플리케이션 코드의 변경이 불가피함DB 엔진 선택Redis vs Memcached -> Redis!DB에서 다중 스레드 지원이 필요하다고 하면 맴캐시드 (Memcached선택)나머지는 Redis 선택연속 쓰기 (write through) 전략캐시부터 쓰고 RDB에 쓰기 수행캐시는 항상 최신 버전단점읽기가 많을지 아닐지 알 수 없는 경우에도 캐시에 기록함 -> 더 많은 캐시용량 필요레이지 로딩(Lazy Loading: 지연 로딩) 전략데이터가 필요한 시점에 읽기 시도 후 캐시가 없으면 생성캐시는 갱싱되기 전까지 과거 시점의 데이터일 수 있음일정 시간 후 파기되..

1. Amazon Dynamo DB란?완전히 관리되는 AWS 상의 NOSQL 데이터베이스장점Fully Managed SErviceEC2 + DB Engine ==> X대용량, 뛰어난 확장성, 신뢰성10ms 미만의 빠르고 일관된 성능Key-Value Store (Hashed Partition Key)이벤트 기반의 프로그래밍 (with Lambda)용량제한 없는 Storage3AZ에 데이터를 복제함 (고가용성 기본 지원)테이블 구성 요소Attributes (=columns), Partition key (PK+SK), sort key, table, items3개의 가용영역에 복제본을 저장함물리적인 저장 단위를 Partition이라고 함 ( Partition - 10GB)Range기반 - Partition Ke..

1. Aurora완전 관리형 관계형 데이터베이스 서비스아키텍처3개의 가용영역에 6개의 복제본으로 나눔 (고가용성 완벽히 지원)Read Replica도 16개 넣을 수 있음프라이머리를 여러 가용 영역에 여러 개, 즉 마스터가 여러 개가 됨Aurora Read Replica최대 15개 (RDS Read Replica는 최대 5개)자동 Fail over 지원 (RDS Read Replica는 미지원)Global Database다른 리전에 복제본 생성주 리전의 Aurora에 쓰기, 복제 리전에는 읽기만 가능함Aurora Serveless용량 온디맨드 자동 조정: 애플리케이션 요구사항에 따라 자동으로 확장, 축소MySQL, PosgreSQL 호환비용은 데이터베이스가 활성 상태일 때의 DB 용량, IO에 대해 지불..

1. AWS가 제공하는 DB 서비스RDS: 관리형 관계형 데이터베이스 서비스Aurora: 완전관리형 관계형 데이터베이스 서비스Redshift: 관리형 데이터웨어하우스 서비스DynamoDB: AWS의 관리형 Columnar NOSQL 데이터베이스DocumentDB: MongoDB API호환 Document 데이터베이스ElastiCache: Redis 또는 Memcached를 사용하는 인메모리 캐시 DBQuantum Ledger DB (QLDB): 완전관리형 원장 데이터베이스. 신뢰할 수 있는 중앙기관에서 소유하는 투명하고 변경 불가능하며 암호화 방식으로 검증 가능한 트랜잭션 로그 제공Neptune: 그래프 DB. 개체, 엔터티에 대한 관계 정보를 저장, 관리하는데 특화어떤 유형을 선택할 것인가?RDB vs..