9. Serverless Architecture Design for Web

1. 웹 기반 스토리지 저장 기본

 

1.1 웹 기반 애플리케이션의 현실

애플리케이션을 사용할 수 없게 되면

-  매출 손실

-  고객 충성도와 브랜드 이미지에 타격

 

성능은 곧 다음을 말함

-  높은 페이지 뷰

-  더 나은 고객 경험

-  높은 전환율

 

1.2 웹 이미지 저장 개요

 

CloudFront의 캐싱 및 가속화 기술을 통해 AWS는 정적 이미지에서 사용자 입력 콘텐츠까지 모든 콘텐츠를 제공할 수 있음.

-  정적: TTL(Time-To-Live)이 높은 이미지, js, html등

-  동영상: rtmp 및 http 스트리밍 지원

-  동적: 사용자 정의 콘텐츠 및 캐싱할 수 없는 콘텐츠

-  사용자 입력: http 작업 지원(Put/Post 등 포함)

-  보안: SSL(HTTPS)을 통해 콘텐츠를 안전하게 제공

 

2. 정적 자산을 Amazon S3를 통해 저장

 

-  정적 자산을 Amazon S3에 저장

 

-  문제

 ㅁ  웹 서버에서 대규모 파일을 전송하는 것은 네트워크 지연 시간 측면에서 문제가 됨

 ㅁ  사용자 생성 콘텐츠는 모든 웹 서버에 분산되어야 함

 

-  솔루션

 ㅁ  정적 자산 파일(CSS, 멀티미디어 등)등을 Amazon S3에 저장하고 파일을 Amazon S3에서 제공

 ㅁ  Amazon S3에 저장된 객체는 퍼블릭으로 설정된 경우 사용자가 직접 액세스 가능

 

2.1 Amazon S3 저장의 장점

 

-  Amazon S3에 저장하는 항목은 내구성이 높음

 ㅁ  Amazon S3는 리전 내 여러 시설에 객체를 중복으로 저장

 ㅁ  Amazon S3는 체크섬을 사용해 데이터의 무결성 확인

 ㅁ  버전 관리를 사용해 모든 객체의 모든 버전을 보존, 검색 및 복원 가능

 

2.2 Amazon S3 데이터 일관성 모델

 

ㅁ  쓰기 후 읽기 일관성 제공

ㅁ  업데이트 후 읽기 일관성 없음  최종 일관성 제공

ㅁ  삭제 후 읽기 일관성 없음  최종 일관성 제공

ㅁ  삭제 후 목록 일관성 없음  최종 일관성 제공

 

2.3 Amazon S3 최대 활용 방법

 

-  리전 선택

 ㅁ  성능은 사용자와의 물리적 거리에 따라 달라짐

 ㅁ  컴퓨팅 및 다른 AWS 리소스와 Co-Location하면 성능에 영향을 줌

-  객체 이름 지정 체계 주의

 ㅁ  버킷의 일관된 성능을 원하는 경우

 ㅁ  일상적으로 초당 100개 PUT/LIST/DELETE 또는 초당 300개 GET 요청을 초과하는 버킷 성능을 원하는 경우

 ㅁ  기본 규칙

    3~63자를 사용

    소문자, 숫자, 마침표(.) 및 하이픈(-)만 사용

    버킷 이름을 하이픈으로 시작하거나 끝내지 말고, 하이픈 다음에 또는 앞에 마침표를 사용하지 않음

    키에는 UTF-8 문자로 올바르게 인코딩된 이름 사용

 

2.4 버킷에 지속적인 로드 발생 시

 

Amazon S3는 파일 접두사에 따라 버킷을 자동 분할

-  일반적으로 적은 수의 객체 저장 시 파일 이름의 마지막 숫자를 증가시키는 방법으로 저장

-  Amazon S3 버킷에 저장된 객체가 수천 개 초과 시 Amazon S3가 버킷을 파티션 할 때 이런 파일 이름이 성능 저하 가능

-  키에 임의의 값을 추가하여 성능을 높임

 ㅁ  동일한 파티션에서 요청 시 동시에 여러 번 읽힐 가능성을 줄이려면 16진수 해시 접두사를 키에 추가

 ㅁ  검색 가능한 체계적인 키를 사용하면 저장된 객체를 좀 더 쉽게 사용 가능

-  파일을 좀더 쉽게 검색하려면 보조 인덱스를 유지하고 모든 키 이름을 해시함

 ㅁ  DynamoDB 테이블에 저장할 수 있는 보조 인덱스 예제

 

3. Amazon CloudFront 사용

 

3.1 캐싱 사용

 

아키텍처의 여러 계층에서 캐싱을 구현하여 비용과 지연 시간을 줄이고 애플리케이션의 성능을 높임

-  요청자와 영구 스토리지 중간 위치에 임시로 데이터 또는 파일을 저장

 

3.2 정적 및 재사용 가능한 콘텐츠 개시

 

         

-  일반적으로 정적 콘텐츠만 캐싱 하지만, 동적 또는 고유한 콘텐츠가 애플리케이션의 성능에 영향을 줌

-  수요에 따라, Amazon S3에서 동적 또는 고유한 콘텐츠를 캐싱 함으로 성능 향상에 도움이 될 수 있음.

-  정적 콘텐츠 오프로딩

 ㅁ  정적 자산에 대해 상대 URL 대신에 절대 URL 참조 생성

 ㅁ  정적 자산을 Amazon S3에 저장

 ㅁ  Write Once Read Many에 대해 최적화 함.

 

3.3 AWS 크라우드 아키텍처: 웹 호스팅

 

기본 웹 호스팅 아키텍처는 아키텍처를 Front 계층, Application 계층 및 Persistence 계층으로 나눈 일반 3티어 웹 애플리케이션 모델을 구현한다. 확장성은 Front, Application 또는 Persistence 계층에 포스트를 추가하여 제공

 

        

-  Amazon Route 53은 도메인 관리 및 Zone APEX 지원을 간소화하기 위한 DNS 서비스 제공

-  Amazon CloudFront는 대용량 콘텐츠를 위한 엣지 캐싱 제공

-  Elastic Load Balancing은 이 다이어그램의 웹 서버 Auto Scaling 그룹으로 트래픽 분산

-  외부 방화벽은 보안 그룹을 통해 모든 웹 서버 인스턴스로 이동

-  백엔드 방화벽은 모든 백엔드 인스턴스로 이동

-  Amazon EC2 인스턴스의 앱 서버 로드 밸런서는 앱 서버 클러스터 전반에 트래픽 분산

-  Amazon ElastiCache는 앱에 대한 캐싱 서비스 제공하여 데이터베이스 티어에서 로드 제거

 

3.4. Amazon CloudFront 주요 기능

 

Amazon CloudFront는 .html, .css, .php 및 이미지 파일과 같은 정적 및 동적 웹 컨텐츠를 최종 사용자에게 더 빨리 배포하도록 지원하는 웹 서비스

 

-  CDN(Contents Delivery Networks)

 ㅁ  Contents는 전 세계에 캐시됨

 ㅁ  지리적 근접성은 짧은 지연 시간을 의미

 ㅁ  더 나은 사용자 경험

 ㅁ  핵심 인프라의 부담 경감

 

-  주요 기능

 ㅁ  네트워크 경로에 TCP/IP 최적화

 ㅁ  왕복 시간을 줄여주는 Keep-Alive 연결

 ㅁ  최종 사용자에게 가까운 SSL/TLS 종료

 ㅁ  POST/PUT 업로드 최적화

 ㅁ  지연 시간 기반 라우팅

 ㅁ  리전 엣지 캐시를 통한 성능 향상

 

-  추가 기능

 ㅁ  RTMP(플래시) 및 HTTP 전송

 ㅁ  라이브 및 VOD(Video On-Demand) 스트리밍

 ㅁ  ABR(Adaptive Bit-Rate) 스트리밍

 ㅁ  HTP/HTTPS 파일 전송

 ㅁ  프라이빗 콘텐츠

 ㅁ  프로그래밍 방식 무효화

 ㅁ  업계의 규정을 준수하는 상세 액세스 로그 제공

 ㅁ  API를 통한 완벽한 제어

 ㅁ  Origin 선택(Amazon S3, Amazon EC2 등)

 ㅁ  Cloud Front 일반 사용 사례

  > 정적 웹 사이트

  > 동영상 및 리치 미디어

  >  온라인 게임

  >  대화형 에이전시

  > 소프트웨어 다운로드

ㅁ  CloudFront 상세 내용

    https://aws.amazon.com/ko/cloudfront/details/

콘텐츠 전송 네트워크의 주요 기능 | 성능, 보안 | Amazon CloudFront

 

3.5 CloudFront 활성화 방법

 

-  정적 콘텐츠의 개별 CNAM 사용

 ㅁ  정적 콘텐츠는 캐시되고, 동적 콘텐츠는 오리진에서 직접 제공

 ㅁ가장 효율적

 ㅁ  설정 및 관리에 더 많은 노력 필요

-  전체 URL로 CloudFront 가리킴

 ㅁ  관리하기에 가장 간편

 ㅁ  URL 패턴을 사용하여 동적 콘텐츠를 스테이징

 ㅁ  모든 콘텐츠가 엣지 로케이션을 통해 전송

 

3.6 엣지 로케이션 검토

 

-  엣지 로케이션은 CloudFront가 객체의 복사본을 캐시하는 지리적 사이트

-  최종 사용자가 객체 중 하나 요청 시 CloudFront가 요청을 지원하기에 가장 적합한 엣지 로케이션이 어디인지 결정

-  객체가 해당 엣지 로케이션에 없는 경우 CloudFront는 오리진 서버에서 복사본을 가져와 최종 사용자에게 제공 후 해당 엣지 로케이션에 캐시로 이를 저장

 

3.7. CloudFront 배포

 

-  CloudFront 설정 시 배포 라는 것을 생성, 그러면 DNS가 배포를 가리키게 됨

-  배포가 오리진이라고 부르는 원본 콘텐츠를 가리키도록 구성

-  콘텐츠가 여러 위치에 있는 경우, 배포는 여러 개의 오리진을 가질 수 있으며 URL 패턴에 따라 올바른 오리진으로 라우팅 됨

       

-  두가지 배포 유형

 ㅁ  웹 배포: 최대 10개의 Amazon S3 버킷과 사용자 정의 오리진의 조합으로 웹 콘텐츠에 액세스

 ㅁ  RTMP 배포: RTMP 배포의 오리진은 언제나 Amazon S3 버킷

 

3.8 CloudFront가 웹사이트 속도 향상을 위해 사용하는 방법

 

- 캐시 제어 헤더 사용

 ㅁ  파일에 설정된 캐시 제어 헤더는 정적 및 동적 콘텐츠를 식별

 ㅁ  단일 Amazon CloudFront 배포를 사용하여 모든 컨텐츠를 전송하면 전체 웹사이트의 성능 최적화 가능

 ㅁ  만료 기간이 0초로 설정된 경우, Amazon CloudFront는 모든 요청을 오리진 서버에서 다시 확인

 

-  오리진 파일에 캐시 제어 헤더를 설정하여 만료 기간 설정

 ㅁ  파일이 자주 변경되지 않는 경우 만료 기간을 길게 설정

 ㅁ  캐시 제어 헤더를 설정하지 않으면 각 엣지 로케이션은 24시간이 지나 업데이트 확인 요청 받고 그 때마다 파일에서 업데이트 사항을 확인함.

 

3.9 콘턴츠 만료 방법

 

일반적으로 TTL을 사용하여 처리

          https://docs.aws.amazon.com/ko_kr/AmazonCloudFront/latest/DeveloperGuide/RequestAndResponseBehaviorS3Origin.html

Amazon S3 오리진에 대한 요청 및 응답 동작 - Amazon CloudFront

- Time To Live(TTL)

 ㅁ  기간 고정(만료 기간)

 ㅁ  사용자가 설정

 ㅁ  CloudFront에서 오리진으로 GET 요청에 If-Modified-Since 헤더 사용

 

-  객체 이름 변경

 ㅁ  Header-v1.jpg를 Header-v2.jpg로 변경

 ㅁ  새 이름이 생기면 새로 고침 수행됨

 

-  객체 무효화

 ㅁ  마지막 수단: 매우 비효율적이고 비용이 많이 듦

 

3.10. CloudFront와 AWS 플랫폼

 

-  Amazon CloudFront는 AWS 리소스와 통합

 ㅁ  DNS, 비디오 트랜스코딩, 스토리지, 컴퓨팅, 로드 밸런싱, AWS Marketplace 등

-  다른 Amazon 리소스의 확장성을 향상

-  Amazon EC2 또는 Amazon S3 리소스의 로드를 줄여줌

-  사용자 정의 오리진 지원

-  AWS 에코시스템을 사용 시 장점

 ㅁ  Amazon EC2 또는 Amazon S3 오리진의 로드 감소

 ㅁ  Amazon S3, CloudFront, Elastic Load Balancing 및 CloudFront 간의 요금 할인으로 비용 절감

 

4. 비관계형 데이터를 NoSQL 데이터베이스에 저장

 

다양한 관계형 데이터베이스 엔진, NoSQL 솔루션, 데이터 웨어하우징 옵션 및 검색 최적화 데이터 스토어 중에서 선택

즉, 워크로드를 기술에 맞추는 것이 아니라 기술을 워크로드에 맞춤

 

4.1. 데이터베이스 솔루션 선택 시 고려 사항

 

-  읽기/쓰기 요구

-  총 스토리지 요구 사항

-  일반적인 객체 크기 및 이러한 개체에 대한 액세스의 특성

-  내구성 요구 사항

-  지연 시간 요구 사항

-  지원해야 하는 최대 동시 사용자 수

-  쿼리의 특성

-  필요한 무결성 제어의 강도

 

4.2 관계형/SQL 및 NoSQL 데이터베이스  비교

구분	관계형/SQL	NoSQL
데이터 스토리지	행 및 열	키 값, 문서 및 그래프
스키마	고정	동적
쿼리	SQL 사용	문서 수집에 집중
확장성	수직적	수평적

 

4.3 NoSQL 데이터베이스

 

-  일부 유형의 애플리케이션의 경우에 관계형 데이터베이스의 대안이 될 수 있음

-  대용량 데이터를 높은 가용성으로 처리할 수 있음

-  다양한 구현 및 데이터 모델로 범주가 광범위 함

-  분산 내결함성의 일반 기능 지원

-  NoSQL에 대한 간단한 설명

 ㅁ  https://blog.naver.com/newelite?Redirect=Update&logNo=221092414130

https://blog.naver.com/PostUpdateForm.nhn?blogId=newelite&Redirect=Update&logNo=221092414130&redirect=Update&widgetTypeCall=true

 

4.4 NoSQL 데이터베이스 사용 조건

 

-  사용 중인 앱이 트랜잭션 지원, ACID(원자성, 일관성, 격리성, 내구성) 준수, 조인, SQL이 필요한가?

 ㅁ  ACID 내용: https://www.lifewire.com/the-acid-model-1019731

-  이들 모두 또는 일부, 아니면 데이터 모델의 일부가 없어도 실행할 수 있는가?

 ㅁ  데이터베이스 핫 스팟을 NoSQL 솔루션으로 리팩터링

-  유연성, 가용성, 확장성 및 성능을 향상 시킬 필요가 있는지

 

4.5. Amazon에서 제공하는 데이터 베이스

 

-  Amazon EC2상의 NoSQL

 ㅁ  Cassandra, HBase, Redis, MongoDB, Couchbase 및 Riak

 

-  관리형 NoSQL

 ㅁ  Amazon DynamoDB

 ㅁ  Amazon Neptune

 ㅁ  ElastiCache with Redis

 ㅁ  HBase 지원 Amazon EMR

 

4.6 기능을 NoSQL로 이동

 

-  사용 사례

 ㅁ  순위표 및 점수 매기기

 ㅁ  클릭 스트림 또는 로그 데이터의 빠른 수집

 ㅁ  임시 데이터 필요(장바구니 데이터)

-  핫 테이블

 ㅁ  메타 테이블 또는 룩업 테이블

 ㅁ  세션 데이터

 

4.7. Amazon DynamoDB

 

4.7.1.  주요 특징

-  짧은 지연 시간

 ㅁ  SSD 기반 스토리지 노드

 ㅁ  지연 시간 = 10밀리초 미만

 

-  원활한 대규모 확장

 ㅁ  테이블 크기 및 처리량 제한이 없음

 ㅁ  스토리지 및 처리량 변경에 대한 실시간 재파티셔닝

 

-  안정성 및 보안

 ㅁ  SSD 스토리지 자동 3방향 복제 기능으로 성능, 안정성 및 보안이 기본 제공

   인증된 암호화 방법을 사용하여 안전하게 사용자를 인증하고 데이터에 대한 무단 액세스 차단

 

-  예측 가능한 성능

 ㅁ  프로비저닝된 처리량 모델

 

-  내구성 및 가용성

 

-  일관된 디스크 전용 쓰기

 ㅁ  온디맨드 백업

 

-  완전 관리형 NoSQL 데이터베이스 서비스

 

-  Amazon EMR과 통합

 ㅁ  Amazon EMR을 통해 AWS에서 호스팅된 하둡 프레임워크를 사용하여 복잡한 대규모 데이터 세트 분석 가능

 ㅁ  DynamoDB 는 Amazon EMR 사용하여 DynamoDB에 저장된 데이터 세트 분석 후 결과의 보관이 가능하며 DynamoDB에 원래의 데이터 세트 보존

 ㅁ  Amazon EMR을 사용하여 여러 스토어(DynamoDB, Amazon RDS 및 Amazon Se)에 잇는 데이터에 액세스 가능

 ㅁ  통합된 데이터 세트에 대해 복잡한 분석을 수행하고, Amazon S3에 작업 결과 저장 가능

 ㅁ  Amazon EMR은 Hive를 통해 DynamoDB와 상호 작용 가능

 

4.7.2.  Amazon DynamoDB 데이터 모델

   

-  DynamoDB에는 스키마가 없음, 테이블에 항목이 있음

-  항목에는 키-값 페어를 갖는 변수 속성이 있으며(결합형 배열 또는 해시와 비슷) 이를 키 및 속성이라고 부름

-  DynamoDB는 사용자 정의 기본 키(파티션 키 또는 해시 키)를 사용한 키 값 GET/PUT 작업을 지원

 ㅁ  기본 키는 테이블 항목 중 유일한 필수 속성으로 각 항목을 고유하게 식별해 줌

 ㅁ  테이블을 만들 때 기본 키를 지정

-  글로벌 보조 인덱스와 로컬 보조 인덱스를 사용하여 비기본 키 속성을 쿼리

-  기본 키는 단일 속성 파티션 키 또는 복합 파티션 정렬 키가 될 수 있음

-  복합 파티션 정렬 키는 파티션 키 요소 및 정렬(범위) 키 요소로 인덱싱 됨

 ㅁ  이 멀티 파트 키는 “UserID” 파티션과 “Timestamp” 정렬의 조합이 될 수 있음

 ㅁ  파티션 키 요소를 일정하게 유지함으로 정렬 키 요소를 검색하여 항목을 검색 할 수 있음

-  자동 파티셔닝은 데이터 세트 크기가 커지고 프로비저닝된 용량이 증가함에 따라 발생

 

4.7.3.  DynamoDB 사용 사례: 소셜 네트워크

 

       

-  사용자는 친구가 있으므로 “User”와 “Friend” 테이블 생성

-  User 테이블

 ㅁ   ‘User’를 파티션 키로 사용하여 데이터를 쿼리함

 ㅁ  사용자의 각 항목에는 속성이 있으며 이 예제에서는 Nicknames가 됨

 ㅁ  속성의 길이는 같을 필요가 없으며 속성은 문자열, 숫자, 바이너리, 문자열 세트, 숫자 세트 등이 될 수 있음

-  Friends 테이블

 ㅁ  복합 기본 키를 사용함

 ㅁ  ‘User’를 파티션 키로 사용하며 정렬 키는 “Friends”

 ㅁ  사용자 파티션 키와 친구 정렬 키를 함께 결합하면 해당 친구 관계를 파악할 수 있는 고유 기본 키를 갖게 됨

-  항목 크기는 속성 이름 바이너리 길이(UTF-8)와 속성 값 길이(바이너리 길이)를 모두 포함하여 400KB를 초과할 수 없음

-  속성 이름도 크기 제한에 포함

-  복제 테이블 항목의 모든 변경 사항은 동일한 글로벌 테이블 내 다른 모든 복제 테이블에 복제

-  이 항목의 총 크기는 23 바이트

 

4.7.4.  Amazon DynamoDB 일관성 – 글로벌 테이블

-  AWS 리전의 세개의 시설에 데이터를 동기식 복제

ㅁ 글로벌 테이블

ㅁ  복제 테이블 항목의 모든 변경 사항은 동일한 글로벌 테이블 내 다른 모든 복제 테이블에 복제

ㅁ  새롭게 작성된 항목은 보통 몇 초내 모든 복제 테이블로 전파

ㅁ  글로벌 테이블을 사용하여 각 복제는 동일한 데이터 항목 세트를 저장

ㅁ  DynamoDB는 항목의 일부만 부분 복제하는 것을 지원하지 않음

-  읽기 요청 시, 최종적 또는 강력한 일관된 읽기 중에서 원하는 읽기를 지정할 수 있음

 ㅁ  애플리케이션은 모든 복제 테이블의 데이터를 읽고 쓸 수 있음

 ㅁ  애플리케이션이 최종 일관성 읽기만 사용하고 AWS 리전에 대한 읽기만 발생한다면 어떠한 수정없이 작업이 이루어짐

 ㅁ  애플리케이션이 견고한 일관성 일기가 필요한 경우 동일한 리전에서 모든 견고한 일관성 읽기 및 쓰기를 수행해야 함

 ㅁ  DynamoDB는 AWS 리전 간 견고한 일관성 읽기를 지원하지 않음

-  동일 항목 업데이트 시 충돌 가능

 ㅁ  최종 일관성을 보장하려면 DynamoDB에서 최종 작성자를 결정하는 데 최선을 다하면서 DynamoDB 글로벌 테이블이 동시 업데이트 간 “최근 작성자 성공” 조정을 사용

 ㅁ  이 충돌 해결 메커니즘을 사용하면 모든 복제가 최신 업데이트에 동의하고 모두 같은 데이터를 가진 상태로 수렴

 

4.7.5.  글로벌 테이블 생성 단계

        

①.    AWS 리전에서 DynamoDB 스트림이 활성화된 일반 DynamoDB 테이블을 생성

②.    데이터를 복제하려는 다른 모든 AWS 리전에 1단계를 반복

③.    생성된 테이블을 기준으로 DynamoDB 글로벌 테이블 정의

글로벌 테이블 생성 상세 내용

https://docs.aws.amazon.com/ko_kr/amazondynamodb/latest/developerguide/globaltables.tutorial.html

전역 테이블 생성 - Amazon DynamoDB

1.4.7.6.  Amazon DynamoDB 모범 사례

-  항목 크기를 작게 유지

-  메타데이터는 DynamoDB에 그리고 대용량 BLOB은 Amazon S3에 저장

-  시계열 데이터를 저장할 때는 일별, 주별, 월별 등의 테이블을 사용

-  조건부 또는 낙관적 동시성 제어(OCC) 업데이트를 사용

-  핫 키와 핫 파티션을 사용하지 않음

 

5. 관계형 데이터를 Amazon RDS에 저장

 

5.1. 고객과 AWS 책임 범위

 

 

5.2. Amazon RDS 같은 관리형 DB  서비스를 선택하는 경우

 

 

5.3 Amazon RDS로 개발자 생산성을 최적화

 

5.4. Amazon RDS 보안

 

-  보안 그룹을 사용해 Amazon RDS 인스턴스 액세스를 제어

-  현재 Amazon RDS가 지원하는 모든 데이터베이스 엔진에서 암호화된 인스턴스를 사용할 수 있음

-  IAM을 사용해 개별 사용자가 호출할 권한이 있는 RDS 작업을 제어

-  IAM을 사용해 개별 사용자가 호출할 권한이 있는 RDS 작업을 제어

-  SSL/TLS를 사용하여 애플리케이션과 DB 인스턴스 간의 연결을 암호화 함

-  SQL Server와 Oracle에서 TDE(Transparent Data Encryption)가 지원됨

-  RDS 인스턴스에서 발생할 수 있는 중요 이벤트의 알림 수신 가능

 

5.5 Amazon Aurora 개요

 

-  서비스 지향적 아키텍처를 사용해 제공된 관계형 데이터베이스

-  Amazon DynamoDB가 Amazon EC2호스팅 NoSQL 엔진의 관리형 버전인 것과 비슷

-  Amazon S3를 활용하여 확장성과 가용성이 뛰어남

-  MySQL 5.6과 즉시 호환

-  기존 애플리케이션이 그대로 작동

-  Amazon RDS MySQL 고객은 마이그레이션 옵션 선택 가능

-  Amazon EC2(또는 온프레미스)MySQL 사용자는 데이터 파일을 가져올 수 있음

-  PostgreSQL과 호환됨

-  상세 내용

 ㅁ  https://aws.amazon.com/ko/blogs/aws/highly-scalable-mysql-compat-rds-db-engine/

Amazon Aurora – New Cost-Effective MySQL-Compatible Database Engine for Amazon RDS | Amazon Web Services

 

5.6 Amazon Aurora 특징

 

5.6.1.  확장 가능한 성능

- Amazon S3와 통합되어 지속적인 백업 제공

  3개의 가용 영역에 걸쳐 6개의 복사본 복제

-  로깅 및 스토리지 계층을 멀티 테넌트의 확장 가능한 서비스 계층으로 이동

-  최대 64TB DB 볼륨의 SSD 데이터 플레인

 ㅁ  사용한 양만큼만 비용 지불

 ㅁ  10GB 단위로 추가됨

5.6.2.  복원력이 뛰어난 설계

-  99.99% 가용성

-  즉각적인 장애 복구

 ㅁ  모든 로그를 단일 스레드에서 재생하는 기존 DB와 비교

 ㅁ  Aurora는 디스크 읽기의 일부로 재실행 레코드를 재생함

 ㅁ  비동기식 병렬 분산 복구

-  DB를 다시 시작해도 캐시 계층 보존되어 읽기 응답 개선

-  즉각적인 프로모션을 위해 설계된 읽기 전용 복제본

 ㅁ  복제본 최대 15개

 ㅁ  최대 10밀리초의 복제 지연(MySQL에서는 몇 초 또는 몇 분)