(기초) AWS - RDS

AWS에 대해 알아봅니다.

정민호정민호

1. RDS

RDS(Relational DB Service) 관계형 데이터베이스(그 외 NoSQLDB)

  • 데이터베이스

  • 테이블

  • 필드(컬럼)

  • 데이터

1.1. Relational DB 종류

AWS RDS에서 사용가능

  • Microsoft SQL

  • Oracle

  • MySQL

  • Postgre

  • Aurora (AWS에서 제공하는 DB 형태이며, FreeTier 아님)

  • MariaDB

1.2. Data Warehousing

  • Business Intelligence

  • 리포트 작성, 데이터 분석시 사용(Production Database → DataWarehousing)

  • 매우 방대한 분량의 데이터 로드시 사용

1.3. OLTP vs OLAP

1.3.1. OLTP

Insert와 같이 종종 사용되어지는, 혹은 규모가 작은 데이터를 불러올 때 사용되는 SQL 쿼리가 필요할 때 유용

예) Order # 210 에만 해당되는 customer 이름, 주소, 시간 정보 Insert

1.3.2. OLAP

매우 큰 데이터를 불러올 때 사용. 주로 덩치가 큰 Select 쿼리가 사용됨

예) 특정 회사 부서의 Net Profit, Products

2. Database Back-ups

  • 자동백업 (Automated Backups)

  • DB 스냅샷 (DB Snapshots)

2.1. 자동백업 (Automated Backups; AB)

  • RDS 생성시 디폴트 셋팅으로 적용되어 있음.

  • Retention Period(1-35일) 안의 어떤 시간으로 돌아가게 할 수 있음 (Point In Time;PIT)

  • AB는 그 날 생성된 스냅샷과 Transaction Logs(TL)을 참고함

  • 디폴트로 AB기능이 설정되어 있으며 백업 정보는 S3에 저장 (특정 조건을 달성할 시 S3는 과금 주의)

  • AB동안(S3에 데이터를 저장할 때) 약간의 I/O suspension이 존재할 수 있음 → Latency (체감은 낮음)

2.2. DB 스냅샷 (DB Snapshots)

  • 주로 사용자에 의해 실행됨

  • 원본 RDS Instance를 삭제해도 스냅샷은 존재함(vs AB)

2.3. DB 백업

  • original.ap-northeast-2.rds.amazonaws.com → restored.ap-northeast-2.rds.amazonaws.com

  • RDS Instance → RDS Endpoint

3. Multi AZ 그리고 Read Replicas

3.1. Multi AZ(Availability Zones)

  • 원래 존재하는 RDS DB에 무언가 변화(Write 등)가 생길 때 다른 Availability Zone에 똑같은 복제본이 만들어짐 = Synchronize

  • AWS에 의해서 자동으로 관리가 이루어짐 (No admin intervention)

  • 원본 RDS DB에 문제가 생길 시 자동으로 다른 AZ의 복제본이 사용됨(Disaster Recovery)

  • Disaster Recovery Only! (성능개선을 위해서 사용되지 않음. 성능 개선을 위해선 Read Replica 사용)

3.2. Read Replica

  • Production DB의 읽기 전용 복제본이 생성됨

  • 주로 Read-Heavy DB 작업시 효율성의 극대화를 위해 사용됨(Scaling이 주목적)

  • Disaster Recovery 용도가 아님!

  • 하나의 RDS에 대해 최대 5개 Read Replica DB 허용

  • Read Replica의 Read Replica 생성 가능(단 Latency 발생)

  • 각각의 Read Replica는 자기만의 고유 Endpoint 존재(IP 주소가 아님)

4. ElasticCache

  • RDS의 개념이 아니라 Cache

  • 클라우드 내에서 In-Memory 캐시를 만들어줌

  • 데이터베이스에서 데이터를 읽어오는 것이 아니라 캐시에서 빠른 속도로 데이터를 읽어옴

  • Read-Heavy 어플리케이션에서 상당한 Latency 감소 효과 누림

  • 초반 APP 개발이나 테스트 용도에는 적합하지 않음

4.1. Memcached

  • Object 캐시 시스템으로 잘 알려져 있음

  • ElastiCache는 Memcached의 프로토콜을 디폴트로 따름

  • EC2 Auto Scaling 처럼 크기가 커졌다 작아졌다 가능함

  • 오픈소스

4.1.1. Memcached 사용처

  • 가장 단순한 캐싱 모델이 필요할 때

  • Object caching이 주된 목적일 때

  • 캐시 크기를 마음대로 scaling하기를 원할 때

4.2. Redis

  • Key-Value, Set, List 와 같은 형태의 데이터를 In-Memory에 저장 가능함

  • 오픈소스

  • Multi-AZ 지원

4.2.1. Redis 사용처

  • List, Set과 같은 데이터셋을 사용할 때

  • 리더보드처럼 데이터셋의 랭킹을 정렬하는 용도가 필요할 때

  • Multi AZ 기능이 사용되야할 때

(기초) AWS - EC2

AWS에 대해 알아봅니다.

정민호정민호

1. EC2

EC2(Elastic Compute Cloud)는 클라우드환경에서 스토리지가 유연하게 변경될 수 있도록 제공

EC2를 사용하기 위해 EBS라는 디스크 볼륨을 요구함

1.1. EC2 과금 정책

  • On-demand : 시간 단위로 가격이 고정되어 있음

  • Reserved : 한정된 EC2 용량 사용 가능, 1-3년동안 시간별로 할인 적용 받을 수 있음

  • Spot : 입찰(경매) 가격 적용. 가장 큰 할인률을 적용 받으며 특히 인스턴스의 시작과 끝 기간이 전혀 중요하지 않을 때 매우 유용.(갑자기 켜지고 꺼지는 경우 발생)

1.2. EC2 과금 활용 방안

  • On-demand : 오랜시간동안 선물을 내지 않고 최소한의 비용을 지불하여 EC2 인스턴스를 사용하고 싶을 때, 특히 개발 시 최초로 EC2 인스턴스에 deploy 할 때 매우 유용.(개발 시작과 끝의 기간을 알 수 없을 때 권장)

  • Reserved : 안정된, 예상 가능한 workload 시 Reserved 사용 권장, 선불로 인한 컴퓨팅 비용 대폭 감소(개발 시작과 끝의 기간을 알 수 있을 때 권장)

  • Spot : 경매와 유사. 단순히 비용 절감 시 유용함. 인스턴스의 시작/끝 시점에 구애 받지 않을 경우 권장

2. EBS

EBS(Elastic Block Storage)

  • 저장 공간이 생성되어지며 EC2 인스턴스에 부착됨

  • 디스크 볼륨 위에 File System이 생성됨

  • EBS는 특정 Availability Zone에 생성됨

2.1. Availability Zone(AZ)

하나의 Region 안에 여러개의 Availability Zone(이하 AZ)가 존재 할 수 있음

서버가 다운되었을 때 AZ라는 백업을 통해 서비스 제공을 가능하게 해줌

일종의 Disaster Recovery

2.2. EBS 볼륨 타입

2.2.1. SSD

  • (GP2) General Purpose SSD : 최대 10K IOPS를 지원하며 1GB당 3 IOPS 속도가 나옴(보편적으로 사용됨)

  • (I01) Provisioned IOPS SSD : 극도의 I/O률을 요구하는 환경에서 주로 사용됨. 10K 이상의 IOPS를 지원함 (예: 매우 큰 DB관리)

2.2.2. Magnetic/HDD

  • (ST1) Throughput Optimized HDD : 빅데이터 Datawarehouse, Log 프로세싱시 주로 사용

  • (SC1) CDD HDD : 파일 서버와 같이 드문 volume 접근시 주로 사용되며 매우 저렴한 비용(boot volume으로 사용 불가능, OS 설치 불가)

  • (Standard) Magnetic : 디스크 1GB당 가장 싼 비용을 자랑함. (Boot volume으로 사용 가능)

3. ELB

ELB(Elastic Load Balancers)

  • 수많은 서버의 흐름을 균형있게 흘려보내는데 중추적인 역할을 함

  • 하나의 서버로 traffic이 몰리는 병목현상(bottleneck) 방지

  • Traffic의 흐름을 Unhealthy instance → healthy instance로 (Unhealthy는 인스턴스 Shutdown, 등으로 발생)

3.1. ELB 타입

3.1.1. Application Load Balancer

OSI Layer 7에서 작동됨(Application Layer)

  • HTTP, HTTPS와 같은 traffic의 load balancing에 가장 적합함

  • 고급 request 라우팅 설정을 통하여 특정 서버로 request를 보낼 수 있음(root를 변경하는 것)

3.1.2. Network Load Balancer

OSI Layer 4에서 작동되고 매우 빠른 속도를 자랑하며 Production 환경에서 종종 쓰임 (Transport Layer)

  • 극도의 performance가 요구되는 TCP traffic에서 적합함

  • 초당 수백만개의 request를 아주 미세한 delay로 처리 가능

3.1.3. Classic Load Balancer

현재 Legacy로 간주됨, 따라서 거의 쓰이지 않음(Legacy ELB 라고도 함)

  • 성능은 뒤쳐지지만 Layer 4, 7 지원

  • Layer 7의 HTTP/HTTPS 라우팅 기능 지원

  • Layer 4의 TCP traffic 라우팅 기능도 지원

3.2. Load Balancer Error : 504 Error

EC2는 언제나 정상 동작한다는 보장이 없기 때문에 ELB에서 Error를 발견하여 504 Error를 사용자에게 보여줌

Application 또는 Server가 응답받지 못할 때 나타나는 현상

  • 웹서버/DB Layer에서 해결 가능

3.3. X-Forwarded-For 헤더

  • USER --(DNS)-→ ELB -→ EC2

  • public IP address --(DNS)-→ Private IP -→ EC2

  • 152.12.3.225 --(DNS)-→ 10.0.0.23 -→ 10.0.0.23

  • 따라서 EC2는 Private IP address 밖에 볼 수가 없음

  • 하지만 EC2는 X-Forwarded-For 헤더 를 사용해 public IP address 를 알 수 있음

4. Route53

AWS에서 제공하는 DNS 서비스. 도메인 주소를 구매하여 아래 3가지와 연결가능

  • S3 Bucket

  • EC2 instance

  • Load Balancer

(기초) AWS - 개요

AWS에 대해 알아봅니다.

정민호정민호

1. 학습 동기

관심있는 분야이기도 했고, 회사에서 AWS 관리할 좋은 기회가 생겨 늦게나마 학습을 시작하게되었습니다.

학습은 인프런의 AWS(Amazon Web Service) 입문자를 위한 강의 란 강의를 통해 진행을 하려고 합니다.

그리고 부족한 부분은 아래 두 책을 통해 채우려고 합니다.

빠른 학습 진행을 위해 블로그에 실습 과정을 담진 않을 생각이고, 강의에 있는 개념정리 정도만 기록해두려고 합니다.

선행 강의가 끝나면 AWS(Amazon Web Service) 중/상급자를 위한 강의 란 강의를 추가로 들을 예정입니다.

2. 강의 내용

아래 내용은 AWS(Amazon Web Service) 입문자를 위한 강의에서 '강의 소개’에 있는 내용입니다.

2.1. IAM

AWS를 사용하는데 있어 필요한 유저/그룹의 생성 및 다양한 관리 방법들을 배울 수 있습니다.

2.2. EC2

원격으로 인스턴스를 생성하여 nginx를 사용한 간단한 웹사이트 생성을 할 수 있으며 다양한 인스턴스의 유형 및 생성 방법을 배울 수 있습니다.

2.3. RDS

AWS에서는 MySQL, PostgresDB등 다양한 데이터베이스 서비스를 제공합니다. 어떻게 AWS에서 데이터베이스를 사용할 수 있을지를 배우고, 데이터베이스를 운영하는데 있어 중요한 개념(백업, 보안 등)들을 알아봅니다.

2.4. S3

AWS에서 가장 오래된 서비스 중 하나이며 주로 파일(오브젝트)들을 업로드하고 다운로드하는 용도로 사용됩니다. 그러나 S3에서는 많은 스토리지 유형이 존재하며 그들의 차이를 이해하고 있어야 필요할때 적재적소에 원하는 서비스를 사용할 수 있습니다. 따라서 비용적인 측면, 성능면에서도 이득을 볼 수 있습니다. S3를 어떻게 사용하며 다양한 접근 방법에 대해서 배우실 수 있습니다.

2.5. CloudWatch

클라우드 서비스를 사용하게 된다면 꼭 접해볼 수 있는 기본적인, 그러나 매우 강력한 기능들을 제공합니다. 실시간 시스템 Logging서비스 및 알람 설정 기능을 통하여 개발자들에게 필요한 정보를 전달해줍니다. 이를 통하여 손쉬운 디버깅을 가능케 해줍니다. 다양한 Metrics를 통해 더 효율적인 AWS 관리를 가능케 해줍니다.

2.6. Lambda

AWS내에 존재하는 수많은 이벤트들이 발동될 시 구현된 Lambda함수가 실행되어 전처리 역할을 가능케 해줄 뿐만 아니라 또다른 AWS 리소스들을 불러오는데 사용됩니다. 특히 Lambda는 Serverless 아키텍쳐를 디자인하는데 매우 중추적인 역할을 담당합니다.

2.7. CloudFront

Contents Delivery Network(CDN)에 기반을 두고 있으며 전세계에 흩어져있는 유저들에게 최상의 서비스를 제공하는데 필요되어지는 리소스입니다. 처음 구현하기에 요구되어지는 설정사항은 다소 복잡하나 이후에는 매우 편리한 기능들이 제공됩니다. 약간의 네트워크 지식을 가지고 계시다면 CloudFront를 훨씬 이해하는데 수월합니다.

2.8. DynamoDB

AWS에서 제공하는 NoSQL 데이터베이스입니다. Batch data와 Stream data를 load하는데 적합한 서비스이며 NoSQL만이 지니고 있는 강력한 장점들이 어우러져 있는 매우 효용가치가 큰 데이터베이스입니다. 본 강의에서는 기존 관계형 데이터베이스와 어떤 차이가 있으며 DynamoDB만이 가지고 있는 장점들에 대해서 학습합니다.

2.9. API Gateway

API Gateway를 사용하여 나만의 API를 만들고 RestAPI에서 제공되어지는 다양한 메소드들을 호출하고 테스트하며 AWS에서 제공되어지는 다양한 리소스들(예시 Lambda Function)과 병합하여 더욱 정교한 파이프라인을 만들고 유지할 수 있습니다. 실제 웹에서 사용되어지는 API역시 API Gateway를 통하여 구현 가능합니다.

2.10. CI/CD

소프트웨어 및 어플리케이션 배포는 한번으로 끝나지 않습니다. 지속적인 유지보수 및 관리가 필요합니다. 이를 매우 용이하게 해주는 AWS 리소스중 Code Commit, Code Deploy, Code Pipeline을 배움으로써 전반적인 소프트웨어 개발 및 배포과정을 이해하실 수 있으며 AWS를 통한 CI/CD파이프라인 구축을 체험하실 수 있습니다. 나만의 코드를 repository에 업로드하여 branch를 통한 간편한 코드 유지가 가능합니다. AWS에서 제공하는 다양한 배포 방법을 학습합니다. 대표적으로 Rolling 배포방식과 Blue/Green 배포방식이 있습니다.