본문 바로가기

데이터 사이언스 DataScience/Data Base 데이터베이스

Amazon RDS for Oracle Immersion Day

0. 계기

AWS 솔루션 아키텍트에게 AWS의 Oracle DBaaS 서비스인 Amazon RDS for Oracle 설명을 들을 기회가 생겼다.
 
여러 동작을 해보며 익힐 수 있었고, 온라인으로도 동일한 내용이 준비되어있다.
(아래 url의 온라인 워크샵으로도 내용은 파악할 수 있으나, 서버 자원 생성시 비용이 발생한다.)
url : https://catalog.workshops.aws/rdsora/en-US
 
 
Amazon RDS for Oracle에 대해서 개인적으로 찾아봤을때보다, 
더 자세한 내용을 들을 수 있었다.
기존에 찾아본 내용 : https://subbak2.tistory.com/124

[Oracle] 온프레미스에서 AWS 마이그레이션 1. 준비

IT서비스의 클라우드 전환은 피할 수 없는 흐름이다. 2027년까지 클라우드 마이그레이션 시장 규모는 연 평균 약 28.9%의 성장이 전망된다. [CLOUD MIGRATION MARKET - GROWTH, TRENDS, COVID-19 IMPACT, AND FORECASTS (2

subbak2.com

 
 

1. 생각해보면 좋은 내용 

 
1) Amazon RDS 서비스는 사용자 입장에선 완전 관리형 서비스이므로 "OS 로그인이 안된다" 가 중요한 포인트인데, 
  이를 AWS 입장에서 생각해보면 사용자 접근은 안되지만 내부적으로 EC2 자원을 생성해서 그 위에 Oracle 등 DBMS를 설치 후 제공하는 형태이다. 
→ 이 내용만 잘 숙지해도 Amazon RDS에 대한 전체적인 이해도가 올라간다.
     (백업, 복구를 할때라든가, OS 패치, DBMS 패치를 할 때 어떻게 자원이 생성될지)
     Ex1> OS 패치가 있을때 RDS 내부적으로는 EC2 하나를 신규 생성한 후,
             DBMS를 복원 후 스위치하는 형태로 서비스를 제공한다.  → 서비스 순단이 발생
     Ex2> CPU, Mem, 스토리지 등 자원은 DBMS에 대한 자원으로 착각하면 안되고,
               EC2 전체에 대한 자원으로 생각해야한다. (OS 에서 사용하는 영역을 감안해야한다)
 
 
2) Amazon RDS의 Disk는 EBS이다 => 여러개의 Volume을 묶는 경우 IOPS를 개선할 수 있다.
     단일 인스턴스 I/O(IOPS)는 스펙상 한계가 있어보이지만, 명시적인 스펙 외에 Volume을 묶어서 사용하는 방식으로 Bandwidth를 개선할 수 있다. (단, 정말로 8만 이상의 IOPS가 필요한 Enterprise 급 사용자의 경우 Case를 열어 AWS에 문의해볼 수 있다.)
 
 
3) 규모가 크지 않은 서비스의 경우 SE2 라이센스를 고려해볼 수 있다.
    * 라이센스 관련 참고 내용 : 
    -- BYOL 종류 : EE / SE2
    -- LI 종류 : SE2 
         --> EE의 경우 Auto Scaling 으로 늘리면 연간 계약 필수, 
               SE2의 경우 Auto Scaling 으로 사용한 만큼 계약.
               SE2 는 최대 16 thread 제약
    -- HA 구성의 경우 standby 까지 라이센스 비용 지불
 
 
4) 고가용성에 대한 이해
 - 온프레미스 HA와 유사 (Active - Standby)   ex> veritas 솔루션
   * 1개의 스토리지를 2개 인스턴스가 Active - Standby
   * AWS는 RDS for Oracle에 한해서
      Active(주DC) - Standby(부DC)  EBS를 솔루션으로 동기화 (EMC SRDF와 유사)
 
EBS는 깨질 수 있음 
 - Multi AZ 없을 경우 복구가 안됨
 - Physical 깨짐, Volume 레벨 깨짐 등
   --> 백업 본으로 복구해야함
 
Multi AZ의 경우 배치가 몰릴때 log file sync 가 몰릴수도 있음
 
* RDS 아키텍처 예시 (WAS가 Multi AZ인 경우)
 - AZ별 latency가 다름
 - cross AZ 트래픽의 경우 VPC가 다르므로 추가 요금 발

 
* 위 아키텍처의 Fail over 상황
 - DNS(Route 53)은 바로 recovery 되고, Crash Recovery의 경우 1~2분 걸린다.
   * RAC의 경우 약 5분 걸리는데(Remastering 작업), RDS(Active-Standby)의 경우 2분 정도 걸린다.
                                       ( RDS에서 Crash Recovery일때 의 Rollback이 많은 경우 더 걸릴 수 있음 )

 
 

2. Amazon RDS Custom for Oracle 

  * 인상적이었던 부분
  - 기존에는 EC2를 할당받아 자체 설치하는 1) 완전설치형과, RDS for Oracle을 이용하는 2) 완전관리형이 있었다면, 
    그 중간 형태인 Amazon RDS Custom for Oracle 이 출시됐다.
 
  * 주요 특징 : 
- OS 영역을 사용자에게 제공 → SLA 계약이 아니며 OS패치를 사용자가 관리해야함
- Multi AZ가 아직 안됨 → Dataguard 등을 통해 직접 구현해야함 (2023년 4월 기준)
- RAC를 사용할 수 있다.
 
 

 

3. DBA 입장에서 신경쓸 부분

 - DB Pump는 PL/SQL 패키지를 사용 https://docs.aws.amazon.com/ko_kr/AmazonRDS/latest/UserGuide/Oracle.Procedural.Importing.DataPump.html
 
- static IP를 구성하는 방법
https://aws.amazon.com/ko/blogs/database/how-to-use-amazon-rds-and-amazon-aurora-with-a-static-ip-address/
 
- DBA가 자주 사용할만한 RDS util 모음
https://docs.aws.amazon.com/AmazonRDS/latest/UserGuide/Appendix.Oracle.CommonDBATasks.Database.html
 

반응형