RDS, 관리형 서비스와 비관리형 서비스

관리형 서비스와 비관리형 서비스

순서대로 

• 애플리케이션 최적화
• 크기 조정
• 고가용성
• 데이터베이스 백업
• 데이터베이스 소프트웨어 패치
• 데이터베이스 소프트웨어 설치
• OS 패치
• OS 설치
• 서버 유지 관리
• 랙 및 스택
• 전력, HVAC, 네트워킹

 

클라우드에서 리소스를 구축할 때는 클라우드를 제어해야 하는 수준, 그리고 해당 리소스를 관리하는 데 사용할 수 있는 보유 중인 리소스를 고려한다.

 

예를 들어 클라우드에서 데이터베이스 사용할 때 EC2에 직접 DB 설치할 수도 있고, RDS 등의 AWS가 관리하는 관리형 데이터베이스를 사용할 수도 있다.

 

• 위의 이미지에서 볼 수 있듯이, EC2 인스턴스에 DB를 설치하면 하드웨어를 제외한 데이터베이스의 모든 측면을 완벽하게 제어할 수 있다. 하지만 그 말은 제어 가능 수준이 높아지므로 직접 관리를 위한 전문 지식과 리소스가 많이 필요하다.
• 관리형 데이터베이스 서비스 사용하면은 데이터베이스 관리에 업무를 수행할 필요가 없다.

 

 

Amazon RDS 기능

• 하드웨어, OS 및 데이터베이스 소프트웨어 배포 및 유지 관리
• 기본 제공 모니터링
• ---
• 저장 데이터 및 전송 데이터 암호화
• ---
• 자동 다중 AZ 데이터 복제
• ---
• 컴퓨팅 및 스토리지 크기 조정
• 최소한의 애플리케이션 가동 중단

Amazon RDS는 클라우드에서 관계형 데이터베이스를 설치, 운영 및 크기 조정할 수 있게 해주는 웹 서비스이다.

이 서비스는 비용 효율적이고 크기 조정이 가능한 데이터베이스 용량을 제공해 주는 동시에 시간 소모적인 데이터베이스 관리 태스크도 처리해 준다.

Amazon RDS를 사용하면 애플리케이션과 비즈니스에 집중할 수 있다. (왜냐하면 순수 데이터베이스 사용하는 것 외에, 서버, 데이터베이스 프로그램 관리를 AWS가 해주는 완전관리형 서비스이기 때문이다.)

 

 

 

RDS 다중 AZ 배포 (장애 대응용 대기 인스턶스 생성)

다른 가용 영역의 대기 DB 인스턴스에 데이터 복제 (가용성 및 내구성을 높여줌)

다중 AZ DB 인스턴스를 프로비저닝하는 경우 RDS에서 다른 가용 영역에 있는 대기 인스턴스에 데이터를 동기식으로 복제한다. 

프라이머리 DB에 장애가 나면 대기 인스턴스가 프라이머리로 승격되어 EC2로 부터 트래픽을 받는다.

프라이머리로 승격됨과 동시에 새 대기 데이터베이스가 다른 가용 영역에 생성된다.

 

읽기 전용 복제본 (read replica, 확장성)

데이터베이스의 읽기 전용 복제본을 생성하여 read 부하를 줄일(나눌) 수 있다. (데이터는 비동기식으로 복제된다,)

• 추가 읽기 용량으로 프라이머리 노드에 대한 부하를 해소할 수 있다.
• 프라이머리 DB 인스턴스에 장애가 발생하는 경우 재해 복구(DR) 솔루션으로 읽기 전용 복제본을 독립 실행형 인스턴스로 승격할 수 있다.

 

 

데이터베이스 캐싱

성능을 최대한 높이기 위해 클라우드에서 데이터베이스를 캐싱하는 방법은 무엇인가?

ex : 흔히 실행하는 몇 가지 쿼리에서 읽기 트래픽이 많이 발생하는 것으로 나타남, 그럴 경우 데이터를 캐시하여 성능 개선 필요

 

 

캐시해야 하는 항목

• 쿼리 속도가 느리고 비용이 많이 드는 데이터
• 자주 엑세스하는 데이터
• 비교적 정적 상태로 유지되는 정보

캐싱 사용해야 하는지 여부 확인하려면 아래 사항 고려해야 함

 

속도와 비용

- 기본적으로 속도는 더 느리고 비용은 더 많이 드는 데이터베이스 쿼리도 있다.

- 예를 들어 여러 테이블에서 조인을 수행하는 쿼리는 단순한 단일 테이블 쿼리보다 훨씬 더 많은 시간과 비용이 든다.

요청하는 데이터를 수신하려면 속도가 느리고 비용이 많이 드는 쿼리를 실행해야 하는 경우 해당 데이터를 캐시할 수 있다.

 

데이터 및 액세스 패턴

- 캐싱할 항목을 결정할 때는 데이터 그 자체와 데이터 엑세스 패턴도 이해해야 한다.

- 예를 들어 빠르게 변경되거나 거의 액세스하지 않는 데이터는 캐시할 필요가 없다.

- 캐싱을 통해 유의미한 이점을 얻으려면 소셜 미디어 사이트의 개인 프로필과 같이 비교적 정적이면서도 액세스 빈도가 높은 데이터일때 유리하다.

 

캐시 유효성

데이터는 캐시에 저장되어 있는 동안 오래된 상태가 될 수 있다.

즉, 데이터베이스의 해당 데이터에 대해 수행되는 쓰기가 캐시된 데이터에는 반영되지 않을 수 있다.

사용 중인 데이터가 캐시하기에 적합한지를 결정할 때는 정확하지 않을 수도 있는 캐시 데이터에 대한 내결함성을 결정해야 한다.

 

 

일반적인 캐싱 전략 - 레이지 로딩

1. 애플리케이션이 캐시에 데이터 요청

2. 캐시 미스

3. 애플리케이션이 데이터베이스에서 누락된 데이터 요청

4. 데이터베이스에서 데이터 반환

5. 애플리케이션이 반환된 값을 캐시에 작성

 

 

일반적인 캐싱 전략 - 라이트 스루

1. 애플리케이션이 DB에 write

2. write 할 때 캐시에도 데이터 작성

 

캐시 관리

캐시 유효성 : 부실 데이터를 최소화하려는 경우 TTL(Time To Live) 값을 각 애플리케이션 쓰기에 추가할 수 있다.

메모리 관리 : 캐시 메모리가 가득 차면 선택한 제거 정책에 따라 데이터가 제거된다.

 - 엑세스한 지 가장 오래된 데이터

 - TTL

 - 엑세스 빈도가 가장 낮은 데이터