Databases - 1

combi_jihoon·2022년 3월 6일
0

aws solutions architect

목록 보기
17/57
post-thumbnail

Database types

  • RDBMS(SQL/ OLTP(OnLine Transaction Processing): RDS, Aurora
    - RDS: Postgres, MySQL, MariaDB, ...
    - Aurora: 엔터프라이즈급 데이터베이스
    - 웹사이트에 제공하기 좋으며 join을 많이 하는 경우, 정규화된 데이터인 경우에 적합하다.
  • NoSQL: DynamoDB(Jason like), ElastiCache(key/ value pairs), Neptune(Graphs)
    - join을 하지 않으며 SQL을 사용하지 않는다.
  • Object Store: S3(object 당 5 terabytes까지 저장 가능(RDS는 400KB까지 저장)), Glacier(backup 또는 archive용으로 사용)
    - 데이터베이스처럼 보이지는 않지만 실제로는 데이터베이스가 맞다. 왜냐하면 데이터를 저장하고 가져오는 용도로 사용하고 있기 때문이다.
    - 한 객체의 크기가 매우 큰 경우 S3를 이용하는 것이 좋다.
  • Data Warehouse(SQL analytics/ BI): Redshift(OLAP(OnLine Analytic Processing)), Athena(S3를 쿼리할 때 사용)
  • Search: ElasticSearch(JSON)
    - 자유 텍스트 및 비정형화된 검색에 사용하기 좋으며 많은 쿼리와 검색 능력을 가지고 있다.
  • Graphs: Neptune
    - 데이터 간의 관계를 보여주는 데 사용한다.


Database 타입 별 특징

RDS

  • RDS의 백엔드에서는 EC2 인스턴스를 프로비저닝 하고 EBS volume 타입과 사이즈를 정해서 사용한다.
    - 사용자가 해당 EC2에 직접 접근할 수는 없다.
  • Read Replica와 multi AZ를 제공한다.
    - Read Replica는 읽기를 확장하는 데 사용한다.
    - Multi-AZ는 재난 극복에 사용할 수 있다.
  • 여러 보안을 사용할 수 있다.
    - IAM
    - 보안 그룹
    - KMS
    - 전송중 암호화(SSL)
  • 백업/ 스냅샷/ 특정 시점 복원 기능을 제공한다.
  • 관리 및 스케줄링 된 유지 보수 작업을 지원한다.
  • CloudWatch를 이용한 모니터링이 가능하다.

Solutions Architect 관점에서 보기

운영 관점

  • 장애 극복 기능 사용시 다운타임이 적다.
  • 읽기, 즉 ec2 instance를 조정하면 EBS는 복원되며 이 때는 수동 개입이 필요하다.
    - 즉, 약간의 작업을 해야 한다.

보안 관점

  • AWS가 자체적으로 os 보안을 책임지지만 사용자가 직접 KMS 세팅 또는 IAM 정책, 인바운드 설정, SSL 암호화 등을 해야 한다.

신뢰성 관점

  • multi-AZ를 지원하기 때문에 장애 극복이 가능하다.

성능 관점

  • EC2 instanc를 백엔드로 사용하기 때문에 인스턴스 타입에 따라, 그리고 EBS volumes 타입에 따라 성능이 달라진다.
  • 크기를 조정하고 읽기 능력을 향상시키고 싶은 경우 read replica를 추가하면 된다.
  • 저장 공간 auto-scaling 기능이 있어서 EBS volume이 클수록 더 많은 저장 공간을 사용할 수 있다.
  • 만약 인스턴스 사용량을 늘리려면 인스턴스를 수동으로 확장해야 한다.

비용 관점

  • 프로비저닝 된 EC2 타입과 EBS 볼륨 타입에 따라 시간 단위로 지불한다.

RDS backups

  • RDS는 자동으로 백업을 지원해 준다.
  • 자동 백업 덕분에 과거 어느 시점이든 복원이 가능함(~5분 전까지)
    - 매일 데이터베이스 전체 백업(유지 관리 기간 동안)이 진행되며 원하는 시간대(window)를 지정할 수 있다.
    - 트랜잭션 로그 백업(5분 마다)
    - 7일 동안 보관(35일까지 설정 늘릴 수 있음)
  • 스냅샷 생성
    - 유저 설정에 의해 수동으로 진행된다.
    - 원하는 기간 동안 보관이 가능하다.

RDS Storage Auto-scaling

  • 남는 저장 공간이 없을 경우 RDS가 이를 감지해 자동으로 저장 공간을 확장한다.
  • 이를 위해서는 최대 저장 공간 threshold(한계치)를 설정해야 한다.
    - 한계치 이상 저장 공간이 늘어나지 못하도록 하는 것이다(무한대가 되도록 할 수는 없으니까).
  • 만약 저장 공간 상태가 아래와 같은 조건 동안 유지되었다면 auto-scaling이 진행 된다.
    - 만약 할당된 저장 공간에서 남는 공간이 10% 이하라면,
    - 이 상태가 5분 이상 지났다면
    - 마지막 수정 이후 6시간이 지났다면
  • 모든 RDS 데이터베이스 엔진에서 지원되는 기능이다.


Read replicas vs Multi-AZ

Read replicas 확장

  • 5개까지 확장 가능하다.
  • AZ 내에, 여러 AZ, 또는 여러 리전에 read replicas를 확장할 수 있다.
  • read replicas가 확장 되어 여러개 생성 되면 Master로부터 read replica에 비동기적 복제가 일어난다.
    - 그런데 만약 read replica 복제가 다 일어나지 않은 상태에서 application으로부터 읽기 요청이 들어 온다면 이 경우 모든 데이터를 얻게 될 것이다.
    - 그렇기 때문에 결과적으로는 일관적인 비동기 복제라 일컬어 지는 것이다.
  • read replicas는 각각의 database로 promotion 된다.
    - 즉, read replicas 또한 하나의 데이터베이스가 되어 Master로 작동하게 된다.
    - 그러면 application은 RDS 클러스터에 있는 모든 read replica 리스트를 사용하기 위해서 connection string을 업데이트 해놔야 한다.
  • read replica는 읽기 작업만을 위해서 사용해야 한다.

Network cost

  • 데이터가 한 AZ에서 다른 AZ로 넘어갈 때 Network cost(복제비용)가 발생한다.
    - 만약 읽기 복제본이 같은 리전의 다른 AZ에 있다면 이 때는 비용을 지불하지 않아도 된다.


Multi-AZ

  • 서로 다른 가용영역에 있는 standby 인스턴스의 경우 Master에 대해 동기식 복제가 일어나게 된다.
  • 또한 standby 인스턴스와 Master 인스턴스는 서로 같은 DNS를 사용하기 때문에 장애가 발생할 경우 바로 standby 인스턴스가 장애 대응용으로 사용 된다.
    - 이를 통해 가용성을 높일 수 있다.
    - 그러면 이 때 Standby는 새로운 Master가 된다.
  • 따라서, read replica는 재해복구만을 위해 multi-AZ로 셋업해서 사용하게 될 수 있다.
    - 이 경우 해당 인스턴스에는 read, write 어느 것도 할 수 없으며 이는 그저 대기 용도로만 사용된다.

### Single-AZ에서 Multi-AZ로 업그레이드 하는 방법 * multi-AZ를 생성할 경우 다운타임은 발생하지 않는다. - 따라서, DB를 중단할 필요는 없다. - "modify"를 클릭해 multi-AZ로 만들기만 하면 된다. - 이를 통해 Master는 바로 standby 인스턴스를 갖게 되며 이 때 동기적 복제가 일어난다. * 내부적으로는 다음과 같은 일이 발생한다. 1. Master DB의 스냅샷을 생성한다. 2. standby DB에 저장한다. 3. 동기 복제가 완료된다. 4. 사용자는 Multi-AZ에 있게 된다.

헷갈리지 않아야 하는 점은,

  • standby는 동기 복제가 일어나며 읽기/쓰기 어느 것도 발생하지 않는다.
  • read replica는 비동기 복제가 일어나며 읽기만 가능하다.

이는 용도에 따라 달라진다.


Aurora

  • Postgres, MySQL과 호환 가능한 API이다.
  • 3개의 가용 영역에 6개의 replica가 존재한다.
  • Auto healing 능력이 있다.
  • Multi AZ이며 Read Replicas를 auto-scaling 할 수 있다.
  • Read Replica는 전세계적으로 존재할 수 있기 때문에 재해 복구 또는 지연 시간 단축이 가능하다.
  • 저장공간은 10 GB ~ 128TB까지 확장 가능하다.
  • 오로라 인스턴스는 EC2 인스턴스를 사용한다.
    - 만약 서로 다른 인스턴스를 사용 중이라면 커스텀 엔드포인트로 묶어서 사용할 수 있다.
  • RDS와 같은 보안, 모니터링 기능을 제공한다.
  • Aurora Serverless도 있다.
    - 예측 불가능한, 간헐적인 워크로드를 위해 사용 가능하다.
  • Aurora Multi-Mater 기능이 있다.
    - 지속적으로 쓰기의 실패에 대응해야 하는 경우 multi-master를 이용해 대응할 수 있다.

Aurora는 RDS와 전반적으로 유사하지만 적은 관리와 높은 유연성, 그리고 높은 성능을 원하는 경우 사용하기 좋다.


Solutions architect 관점에서 보기

신뢰성

  • RDS보다 더 높은 가용성을 지닌다.
  • Aurora serverless 옵션이 있다.
  • Aurora multi-master 옵션이 있다.

성능

  • Read replica를 15개까지 가질 수 있다.
    - RDS는 5개까지만 가능하다.
  • RDS보다 5배 더 좋은 성능을 갖는다.
    - AWS에 따르면 더욱 최적화된 architecture 덕분이라고 한다.

비용

  • RDS와 마찬가지로 프로비저닝 된 EC2 instance 종류에 따라, 그리고 저장 공간 사용 정도에 따라 시간 당 지불한다.
  • 오라클과 같은 엔터프라이즈 급 데이터베이스보다 저렴하다.
profile
쿄쿄

0개의 댓글