[68일 차] 21.10.29 : DevOps 9

AWS RDS

AWS DynamoDB

---

1교시

 

 

실습에 사용할 토폴로지는 어제 그대로

VPC 1개에 서브넷 2개

다중 영역에 Failover를 이용한 배포/데이터베이스를 다른 리전으로 복사하기

스택 배포 후 만들어진 RDS의 스냅숏 하나 생성

 

• 왜 다른 리전으로 DB를 복사하는가?

- 재해복구 목적 : 리전 전체에 일어난 재해에 대한 방비

- 리전 재배치 : 인프라를 다른 리전으로 이동하여 대기 시간을 줄이고 속도를 높여 고객 서비스를 개선

 

RDS 좌측 목록에 있는 Automated backups > 현재 리전에 가동 중인 RDS가 보인다. 원래 이걸 체크 > 작업 > 교차 리전 복제 관리 > 이렇게 들어가서 진행해야 하는데, MySQL이 지원되는 DB 엔진이 아니다.

-> MSSQL RDS 하나 대충 생성(MSSQL은 1433번 포트 사용)

RDS 생성 완료를 확인하면 리전 간 복제 관리 > 다른 AWS 리전에 복제 활성화 체크 > 대상 리전과 복제된 백업 보존 기간 지정 > 저장

https://docs.aws.amazon.com/ko_kr/AmazonRDS/latest/UserGuide/USER_ReplicateBackups.html#USER_ReplicateBackups.Regions

다른 AWS 리전에 자동 백업 복제 - Amazon Relational Database Service

리전 간 자동 백업 복제 관련 문서

 

복제되면 대상 리전의 '복제됨' 탭에 가서 삭제 가능

---

2교시

 

 

• 고가용성 DB 구성

https://docs.aws.amazon.com/ko_kr/AmazonRDS/latest/UserGuide/Concepts.MultiAZ.html

Amazon RDS를 위한 고가용성(다중 AZ) - Amazon Relational Database Service

고가용성 관련 문서

 

RDS 가용성 및 확장성(Multi AZ & Read Replica) : 하나의 가용 영역에만 DB를 두는 것은 안정적이지 못하다.

다중 AZ DB 인스턴스를 프로비저닝하면 AWS RDS는 기본 DB 인스턴스를 자동 생성하고, 다른 AZ에 있는 예비 인스턴스에 데이터를 복제한다(HA)

인프라 장애가 발생하더라도 예비 인스턴스로 자동 장애 조치를 수행하고, 조치 후에도 DB 인스턴스의 엔드포인트는 그대로 유지되므로 관리자가 직접 개입할 필요 없이 애플리케이션에서 DB 작업을 재개할 수 있다.

MySQL 및 PostgreSQL RDS는 읽기 전용 복제본을 사용해 읽기 중심의 DB Workload를 처리하기 위해 확장할 수 있다.

 

가용 영역 a, b, c에 DB를 복제해놓는다.

-> 앱은 기본적으로 a 영역의 DB로 접근한다(Primary). 그리고 마스터 DB인 a 영역의 DB는 b 영역과 c 영역의 DB로 계속 동기화된다.

-> c 영역에 있는 DB는 read-only DB다. 만약 a 영역의 마스터 DB에 문제가 생기면 앱은 자동으로 b 영역의 DB(Secondary)로 접근한다.

 

RDS에서 다중 AZ 설정은 '가용성 및 내구성' 부분에서 '대기 인스턴스 생성'을 체크하면 된다.

---

3교시

 

 

이미 만들어진 RDS를 변경하려면 수정 화면으로 들어가면 된다.

 

어쨌건 수정 후 CloudFormation의 출력으로 나온 엔드포인트로 Wordpress 접속

-> 일반적인 화면이 보인다.

그럼 RDS 인스턴스를 재부팅해보자.

-> RDS 인스턴스 체크 후 작업 > 재부팅 > 장애 조치로 재부팅 체크 > 확인

재부팅되는 동안은 마스터 DB가 중지되니, 재부팅 중일 때 웹 페이지 접속해서 잘 작동하는지 확인

(캐시는 지우고 접속하기)

-> Downtime이 조금 있지만, 아무튼 문제없이 접속할 수 있다.

https://docs.aws.amazon.com/ko_kr/AmazonRDS/latest/UserGuide/USER_RebootInstance.html

DB 인스턴스 재부팅 - Amazon Relational Database Service

DB 인스턴스 재부팅 관련 문서

 

여기까진 마스터-슬레이브 DB로 고가용성 실습이었고, 이제는 확장성 실습

-> 읽기 관련은 다른 가용 영역에 있는 읽기 전용 DB로 접속하고, DB 수정 관련은 마스터 DB로 접속

---

4교시

 

 

모든 작업을 마스터로 접근하면 부하가 걸릴 수 있으니 읽기만(SELECT) 다른 복제 DB로 접근하도록 설정하기.

-> SELECT가 들어간 PHP 구문을 작성할 때 복제 DB로 접속하도록 설정

-> INSERT, UPDATE, DELETE는 그대로 마스터 DB로 접속

 

RDS DB 선택 > 작업 > 읽기 전용 복제본 생성 > 만들 복제본의 설정 지정(원본과 유사하게 설정) > 스토리지 유형 SSD, 식별자 작성 후 생성 

(복제 RDS를 단일 RDS로 승격시킬 수도 있다)

 

 

읽기 전용 복제본 생성 시 백그라운드 작업

1. 소스 DB에서 스냅샷 생성

2. 해당 스냅샷을 기반으로 새로운 Replica 생성

3. 마스터 DB와 읽기 복제 DB 간의 복제(동기화) 활성화

4. 읽기 복제 DB에 대한 SQL 읽기 요청의 엔드포인트 생성

 

https://docs.aws.amazon.com/ko_kr/AmazonRDS/latest/UserGuide/USER_ReadRepl.html

읽기 전용 복제본 작업 - Amazon Relational Database Service

읽기 전용 복제본 작업 문서

 

 

만들어둔 Worpress가 수정하기 번거로워서 RDS DB 하나 생성

-> Amazon Aurora 유형으로 선택, 식별자 작성, 인스턴스 클래스는 버스터블, 나머지는 기본값으로 두고 생성

-> 가용성과 확장성을 동시에 챙길 수 있다.

---

5교시

 

 

일단 오전에 사용한 모든 리소스 삭제

 

• RDS 요약

- RDS는 관계형 DB를 사용하는 Managed 서비스다.

- MySQL, PostgreSQL, MSSQL, Oracle DB를 선택할 수 있다.

- RDS DB로 데이터를 가장 빠르게 가져오는 방법은 같은 리전에서 가상 서버에 데이터를 복사하고(스냅숏), 거기에서 RDS DB로 가져오기를 실행하는 것이다.

- RDS DB는 고가용성을 지원한다. 실제 운영 시에는 RDS Multi-AZ 모드로 시작해야 한다.

- 읽기 복제는 SQL DB의 읽기 집약적인 작업 부하의 처리 성능을 개선한다.

 

 

• NoSQL DB 서비스 프로그래밍 : DynamoDB

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

Amazon DynamoDB: 작동 방식 - Amazon DynamoDB

AWS DynamoDB 관련 문서

---

6교시

 

 

- 테이블 및 보조 인덱스 만들기

- 서비스 스택에 DynamoDB 통합하기

- '키-값' 최적화된 데이터 모델 설계

 

ACID 데이터베이스 Transaction을 보증하려면 DB의 모든 노드가 통신을 해야 하기 때문에 전통적인 관계형 DB 모델을 확장하기는 어렵다.

-> 해결하려면? ACID를 보증하지 않는 DB를 사용하는 것 = NoSQL

 

NoSQL DB에는 4가지 종류가 있다.

Document, Graph, Column, Key-Value 저장소 DB.

아마존은 DynamoDB라는 NoSQL DB 서비스를 지원하는데, 아마존만의 소스를 공개하지 않는 완전 관리형 키-값 저장소 DB다. 고가용성 및 고내구성 DB.

 

• DynamoDB의 특징

1. DynamoDB는 다운로드할 수 있는 SQ가 아니라 NoSQL 서비스로서의 DB다(DaaS). MySQL이나 MongoDB를 설치하는 것처럼 DynamoDB를 설치할 수는 없다. 즉, DB를 직접 업데이트할 필요가 없다는 것.

 

2. DynamoDB는 AWS가 운영하는 서버에서 실행된다. OS와 모든 보안 관련을 관리해준다. 보안 관점에서 DynamoDB 테이블 사용자에게 IAM의 적절한 권한을 부여하는 것은 사용자의 몫이다.

 

3. DynamoDB는 데이터를 여러 서버와 여러 IDC에 복제한다. 내구성 관점에서 백업은 더 이상 필요하지 않다.

 

 

실제 운영 환경에서 DynamoDB를 사용할 때 고려할 사항이 몇가지 있다.

-> 테이블 생성, 보조 인덱스 생성, 사용량 모니터링

 

스토리지 사용 GB당 비용은 대충 $0.27

처리량 중에서 프로비저닝 된 읽기/쓰기 용량 10단위에 대한 시간당 비용 $0.007

 

같은 리전에 있는 DynamoDB에 접근하기 위해 EC2 서버 등의 AWS 자원을 사용하는 경우에는 추가 트래픽에 대한 비용이 부과되지 않는다.

 

- 테이블 생성 시 관리 콘솔, SDK, CLI에서 aws dynamodb create-table 명령을 실행해서 생성

- 데이터 추가/갱신/삭제는 SDK를 통해 수행

- 데이터 조회는 기본 키 조회 시 SDK를 통하고, 키가 아닌 속성 조회는 불가능하고, 보조 인덱스 추가와 전체 테이블 스캔은 가능.

- 스토리지 증가는 조치할 필요 없다. 아이템이 추가되면 저절로 증가된다.

- 성능 증가는 용량을 증가함에 따라 수평적으로 증가한다. DynamoDB는 내부적으로 서버를 추가한다.

- 컴퓨터에 DB 설치는 할 필요도 없고, 할 수도 없다. 서비스 형태로만 사용 가능.

- DynamoDB는 특화된 숙련자 필요.

 

DynamoDB는 테이블에 데이터를 구성하는 키-값 저장소다.

각 테이블은 키로 식별되는 아이템(값)을 저장한다. 테이블은 기본 키 외에 데이터 검색을 위한 보조 인덱스를 유지하고 관리할 수 있다.

 

 

DynamoDB의 테이블은 이름을 가지며, 아이템의 집합을 구성한다. 아이템은 속성의 모음.

속성은 '이름-값'으로 이루어진 쌍으로 구성된다.

속성 값은 스칼라(숫자, 문자열, 바이너리, Boolean), 다중 값(숫자 집합, 문자열 집합, 바이너리 집합) 또는 JSON 문서(객체, 배열)가 될 수 있다. 같은 테이블의 각 아이템은 서로 다른 속성을 가져도 상관없다.

---

7교시

 

 

• 기본 키

기본 키는 테이블 내에서 고유하고 각 아이템을 식별한다. 아이템을 찾으려면 기본 키가 필요하다.

기본 키는 해시 키 단독으로 구성되거나 해시 키-범위 키의 쌍으로 구성된다.

해시 키는 Partition key로, 범위 키는 Range key로.

 

해시 키는 아이템의 속성 하나를 이용해서 해시 인덱스를 생성한다. 해시 키로 생성한 아이템을 조회하려면 정확한 해시 키를 알아야 한다. 사용자 테이블이라면 해시 키로 사용자의 이메일을 사용할 수 있다. 그러므로 우리가 해시 키(이메일)를 알고 있다면 사용자를 검색할 수 있다.

 

• 복합 기본 키(해시 키 + 범위 키)

복합 기본 키는 더 강력한 인덱스를 생성하기 위해 아이템의 속성 2개를 사용한다.

첫 번째 속성은 해시 부분이고, 두 번째 속성은 범위 부분이다.

아이템을 찾기 위해 키의 해시 부분은 정확하게 알아야 하지만, 범위 부분을 알 필요 없다.

범위 부분은 해시 내에서 정렬된다. 그러므로 특정 시작 지점부터 키의 범위 부분을 조회할 수는 있다.

메시지 테이블은 해시와 범위를 기본 키로 사용할 수 있다. 해시는 사용자의 이메일이고, 범위는 타임스탬프다.

이렇게 하면 특정 타임스탬프보다 나중에 생성된 사용자의 모든 메시지를 볼 수 있다.

 

NoSQL 종류

DynamoDB, MongoDB, Neo4k, 카산드라 등

 

 

• 테이블 생성하기

DynamoDB에서 테이블은 데이터를 구성하는 틀이다. 사용자는 테이블 아이템의 모든 속성을 정의할 필요가 없다. 

관계형 DB와 달리 정적 스키마를 필요로 하지 않는다. 하지만 테이블의 기본 키로 사용될 속성은 정의해야 한다. 

기본 키 정의는 AWS CLI로 하면 된다. 테이블을 생성하는 aws dynamodb create table 명령은 다음 4가지 필수 매개변수를 받는다.

1. table-name

테이블 이름(변경 불가)

2. attribute-definitions

기본 키로 사용되는 속성의 이름과 타입.

AttributeName=<속성_이름>, AttributeType=<속성_타입> 

형태의 정의를 공백 문자로 구분해서 여러 번 반복 지정할 수 있다.

3. key-schema

기본 키를 구성하는 속성의 이름(변경 불가)

AttributeName=<속성_이름>, keyType(키_타입)

형태로 하나 혹은 복합 기본 키에 대해 공백 문자로 구분해서 2개까지 저장할 수 있다.

유효한 키 타입은 HASH와 RANGE가 있다.

4. provisioned-throughput (프로비저닝 된 처리량)

ReadCapacityUnits=5, WriteCapacityUnits=5 형태로 테이블의 성능을 설정한다.

---

8교시

 

 

서비스 목록에서 DynamoDB를 찾아 들어간다.

좌측 목록을 쭉 보면 RDS와 달리 '데이터베이스' 메뉴가 없다. DynamoDB라는 DB가 이미 구성되어 있기 때문이다.

테이블 생성 > 테이블 이름과 파티션/정렬 키 입력 > 나머지는 기본값으로 두고 테이블 생성

AWS-CLI로 생성하려면

aws dynamodb create-table --table-name [테이블명] --attribute-definitions AttributeName=[속성명],AttributeType=[속성타입] --key-schema AttributeName=[속성명],KeyType=[키 타입] --provisioned-throughput ReadCapacityUnits=5,WriteCapacityUnits=5

 

항목 > 테이블 클릭 > 항목 생성 > 키 값들을 입력하고 생성

 

항목 조회를 CLI로 하려는데 에러가 발생해서 헤매다 끝났다.

---

쓰다 보니 생각났는데, 제목을 DevOps가 아니라 AWS로 해야 하나?