이 백서는 기록 참조용입니다. 일부 콘텐츠는 오래되어 일부 링크를 사용하지 못할 수 있습니다.
기계 번역으로 제공되는 번역입니다. 제공된 번역과 원본 영어의 내용이 상충하는 경우에는 영어 버전이 우선합니다.
# 보안 및 성능을 위한 설계
Amazon RDS에서 Oracle Database를 실행하든 Amazon EC2에서 Oracle Database를 실행하든 인프라의 모든 구성 요소를 최적화하면 보안, 성능 및 안정성이 향상됩니다. 다음 섹션에서는의 Oracle Database 구현에서 네트워크 구성, 인스턴스 유형 및 데이터베이스 스토리지를 최적화하는 모범 사례를 AWS 설명합니다.
**Topics**
+ [네트워크 구성](network-configuration.md)
+ [Amazon EC2 인스턴스 유형](amazon-ec2-instance-type.md)
+ [데이터베이스 스토리지](database-storage.md)
# 네트워크 구성
Amazon Virtual Private Cloud(VPC)를 사용하면 계정 AWS 클라우드 전용의 논리적으로 격리된 섹션을 프로비저닝할 수 있습니다. 자체 IP 주소 범위 선택, 서브넷 생성, 보안 설정, 라우팅 테이블 및 네트워크 게이트웨이 구성 등 가상 네트워킹 환경을 완벽하게 제어할 수 있습니다.
*서브넷*은 Amazon VPC의 IP 주소 범위입니다. 선택한 서브넷에서 AWS 리소스를 시작할 수 있습니다. 인터넷에 연결되어야 하는 리소스에는 퍼블릭 서브넷을 사용하고, 인터넷에 연결되지 않는 리소스에는 프라이빗 서브넷을 사용하십시오.
각 서브넷의 AWS 리소스를 보호하기 위해 보안 그룹 및 네트워크 액세스 제어 목록(ACLs.
다음 표에서는 보안 그룹과 네트워크 ACLs 간의 기본 차이점을 설명합니다.
| **보안 그룹** | **네트워크 ACL** |
| --- | --- |
| 인스턴스 수준에서의 적용(1차 보안 계층) | 서브넷 수준에서의 적용(2차 보안 계층) |
| 허용 규칙만 지원 | 허용 규칙 및 거부 규칙 지원 |
| 상태 저장: 규칙에 관계없이 반환 트래픽이 자동으로 허용됩니다. | 상태 비저장: 반환 트래픽이 규칙에 의해 명시적으로 허용되어야 함 |
| 트래픽 허용 여부를 결정하기 전에 모든 규칙을 평가 | 트래픽 허용 여부 결정 시 규칙을 번호순으로 처리 |
| 인스턴스 시작 시 누군가 보안 그룹을 지정하거나, 나중에 보안 그룹을 인스턴스와 연결하는 경우에만 인스턴스에 적용됨 | 연결된 서브넷에서 모든 인스턴스에 자동 적용됨(백업 보안 계층이므로 보안 그룹을 지정하는 사람에게 의존할 필요 없음) |
Amazon VPC는 격리, 추가 보안 및 Amazon EC2 인스턴스를 서브넷으로 분리하는 기능을 제공하며 프라이빗 IP 주소 사용을 허용합니다. 이 모든 것이 데이터베이스 구현에 중요합니다.
프라이빗 서브넷에 Oracle Database 인스턴스를 배포하고 Amazon VPC 내의 애플리케이션 서버 또는 Amazon VPC 내의 접속 호스트만 데이터베이스 인스턴스에 액세스하도록 허용합니다.
지정된 포트를 통해 특정 IP 주소에 대한 액세스만 허용하는 적절한 보안 그룹을 생성합니다. 이러한 권장 사항은 Amazon RDS를 사용하든 Amazon EC2를 사용하든 관계없이 Oracle Database에 적용됩니다.
![\[Amazon VPC의 프라이빗 서브넷에 있는 Oracle Database\]](http://docs.aws.amazon.com/ko_kr/whitepapers/latest/oracle-database-aws-best-practices/images/oracle-db-private-subnet.png)
Amazon VPC의 프라이빗 서브넷에 있는 Oracle Database
# Amazon EC2 인스턴스 유형
AWS에는 많은 Amazon EC2 인스턴스 유형을 사용할 수 있으므로 워크로드에 가장 적합한 인스턴스 유형을 선택할 수 있습니다. 그러나 사용 가능한 모든 인스턴스 유형이 Oracle Database를 실행하는 데 가장 적합한 것은 아닙니다.
Oracle Database에 Amazon RDS를 사용하는 경우는 모범 사례를 기반으로 일부 인스턴스 유형을 AWS 필터링하고 T 클래스, M 클래스 및 R 클래스 인스턴스의 다양한 옵션을 제공합니다. AWS는 모든 엔터프라이즈 데이터베이스 워크로드에 대해 db.m 기반 또는 r 기반 Amazon RDS 인스턴스를 선택할 것을 권장합니다. R5 인스턴스는 고성능 데이터베이스와 같은 메모리 집약적인 애플리케이션에 매우 적합합니다.
RDS 인스턴스에 대한 최신 정보는 [Amazon RDS for Oracle Database 요금을](https://aws.amazon.com/rds/oracle/pricing/) 참조하세요. Amazon RDS 인스턴스 유형은 데이터베이스 워크로드와 사용 가능한 Oracle Database 라이선스를 기반으로 선택해야 합니다.
Amazon EC2에서 자체 관리형 데이터베이스를 실행하는 경우 Amazon EC2 인스턴스 유형에 사용할 수 있는 옵션이 더 많습니다. 이는 사용자가 Amazon RDS를 사용하는 대신 Amazon EC2에서 Oracle Database를 실행하기로 선택하는 이유 중 하나인 경우가 많습니다.
Oracle Database는 CPU 사용량에 대한 리소스 집약적이므로 매우 작은 인스턴스 유형은 적합하지 않습니다. 메모리 공간이 큰 인스턴스는 더 나은 캐싱과 더 큰 시스템 전역 영역(SGA)을 제공하여 데이터베이스 성능을 개선하는 데 도움이 됩니다. AWS 에서는 메모리와 CPU의 균형이 좋은 인스턴스를 선택할 것을 권장합니다.
사용하려는 Oracle Database 라이선스 및 구현하려는 아키텍처와 일치하는 인스턴스 유형을 선택합니다. 비즈니스 요구 사항에 가장 적합한 아키텍처는 [ Amazon EC2 기반 Oracle Database용 고급 아키텍처 백서를 참조하세요.](https://d1.awsstatic.com/whitepapers/aws-advanced-architectures-for-oracle-db-on-ec2.pdf)
Oracle Database는 읽기/쓰기 작업에 디스크 스토리지를 많이 사용하므로 Amazon Elastic Block Store(Amazon EBS)에 최적화된 인스턴스만 사용할 것을 AWS 적극 권장합니다. Amazon EBS 최적화 인스턴스는 Amazon EC2와 Amazon EBS 간에 전용 처리량을 제공합니다. 우수한 데이터베이스 성능을 위해서는 스토리지 하위 시스템에 대한 대역폭과 처리량이 매우 중요합니다. 더 나은 데이터베이스 성능을 위해 네트워크 성능이 더 높은 인스턴스를 선택합니다.
다음 인스턴스 패밀리는 Amazon EC2에서 Oracle Database를 실행하는 데 가장 적합합니다.
| **인스턴스 패밀리** | **Features** |
| --- | --- |
| M 패밀리 | [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/ko_kr/whitepapers/latest/oracle-database-aws-best-practices/amazon-ec2-instance-type.html) |
| X 패밀리 | [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/ko_kr/whitepapers/latest/oracle-database-aws-best-practices/amazon-ec2-instance-type.html) |
| R 패밀리 | [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/ko_kr/whitepapers/latest/oracle-database-aws-best-practices/amazon-ec2-instance-type.html) |
| 내 가족 | [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/ko_kr/whitepapers/latest/oracle-database-aws-best-practices/amazon-ec2-instance-type.html) |
| Z1d 패밀리 | [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/ko_kr/whitepapers/latest/oracle-database-aws-best-practices/amazon-ec2-instance-type.html) |
# 데이터베이스 스토리지
대부분의 사용자는 일반적으로 데이터베이스 스토리지에 Amazon EBS를 사용합니다. 일부 고성능 아키텍처의 경우 인스턴스 스토리지 SSDs 사용할 수 있지만 안정적인 지속성을 위해 Amazon EBS 스토리지로 보강해야 합니다.
높고 일관된 IOPS 및 데이터베이스 성능을 위해 AWS는 범용(GP2) 볼륨 또는 프로비저닝된 IOPS(PIOPS) 볼륨을 사용할 것을 적극 권장합니다. GP2 및 PIOPS 볼륨은 Amazon EC2 및 Amazon RDS 모두에서 사용할 수 있습니다. GP2 및 PIOPS 볼륨 유형 모두에 대한 볼륨당 IOPS의 최신 제한은 [ Amazon RDS DB 인스턴스 스토리지](https://docs.aws.amazon.com/AmazonRDS/latest/UserGuide/CHAP_Storage.html)를 참조하세요. GP2 볼륨은 대부분의 데이터베이스 요구 사항에 대해 가격과 성능의 뛰어난 균형을 제공합니다. 데이터베이스에 GP2가 제공할 수 있는 것보다 높은 IOPS가 필요한 경우 PIOPS 볼륨이 적합합니다.
PIOPS 볼륨의 경우 볼륨을 생성할 때 IOPS 속도를 지정하면 Amazon EBS는 지정된 해에 프로비저닝된 IOPS 성능의 10% 이내인 99.9%를 전달합니다. 요청된 볼륨 크기에 대해 프로비저닝된 IOPS의 비율은 최대 30일 수 있습니다. 예를 들어 3,000IOPS를 가져오려면 볼륨 크기가 100GB 이상이어야 합니다.
PIOPS 볼륨과 마찬가지로 GP2 볼륨도 SSD 기반이지만 GP2 볼륨에서 얻는 IOPS는 기준 IOPS에서 볼륨당 최대 3,000 IOPS까지 다양할 수 있습니다. 이는 데이터베이스에서 필요한 IOPS 성능이 로드 크기와 실행 중인 쿼리 수에 따라 일정 기간 동안 여러 번 다르기 때문에 대부분의 데이터베이스 워크로드에 매우 적합합니다.
범용(SSD) 볼륨 성능은 볼륨의 기본 성능 수준과 볼륨이 I/O 크레딧을 누적하는 속도를 결정하는 볼륨 크기에 따라 결정됩니다. 즉, 볼륨이 클수록 기본 성능이 높아지고 I/O 크레딧의 누적 속도도 빨라집니다.
I/O 크레딧은 기본 성능 이상이 필요할 때 범용(SSD) 볼륨이 대량의 I/O를 버스트하는 데 사용할 수 있는 가용 대역폭을 나타냅니다. 볼륨에 I/O에 대한 크레딧이 많을수록 기본 성능 수준 이상으로 버스트할 수 있는 시간이 늘어나고 성능이 더 필요할 때 성능이 향상됩니다.
처리량 최적화 HDD 볼륨(st1)은 IOPS는 적지만 처리량은 높은 집약적인 워크로드를 위해 설계된 저렴한 HDD 볼륨을 제공합니다. 데이터 웨어하우스 및 데이터 분석 목적으로 사용되는 Oracle 데이터베이스는 st1 볼륨을 활용할 수 있습니다.
높은 처리량이 필요한 Oracle 외부 테이블 또는 외부 BLOB 스토리지와 같은 모든 로그 처리 또는 데이터 스테이징 영역은 st1 볼륨을 활용할 수 있습니다. 처리량 최적화(st1) 볼륨은 볼륨당 최대 500IOPS를 처리할 수 있습니다.
콜드 HDD 볼륨(sc1)은 레거시 시스템을 처리하는 데 적합하며, 이는 가끔 참조 또는 아카이브 목적으로 유지됩니다. 이러한 시스템은 자주 액세스하지 않으며 볼륨에서 하루에 몇 번의 스캔이 수행됩니다.
데이터베이스에 지속적으로 필요한 IOPS 양을 추정하고 충분한 GP2 스토리지를 할당하여 IOPS를 확보하는 것이 좋습니다. 주기적 스파이크에 필요한 추가 IOPS는 사용 가능한 크레딧을 기반으로 버스트 성능에 포함되어야 합니다.
Oracle Database의 IOPS 요구 사항을 결정하는 데 사용할 수 있는 추정 방법에 대한 자세한 내용은 [AWS 기반 Oracle Database에 대한 IOPS 요구 사항 결정](https://docs.aws.amazon.com/whitepapers/latest/determining-iops-needs-oracle-db-on-aws/determining-iops-needs-oracle-db-on-aws.html) 백서를 참조하세요.
볼륨의 버스트 구간은 볼륨의 크기, 필요한 버스트 IOPS 및 버스트가 시작되는 크레딧 밸런스에 의해 결정됩니다. 볼륨 성능이 기본 수준(빈 I/O 크레딧 밸런스로 인해)으로 자주 제한되는 경우, 10,000 IOPS 이상의 지속적인 IOPS 성능이 필요한 워크로드의 경우 더 큰 범용(SSD) 볼륨(기본 성능 수준이 더 높음)을 사용하거나 프로비저닝된 IOPS(SSD) 볼륨으로 전환하는 것을 고려해야 합니다. GP2 볼륨에 대한 자세한 내용은 [Amazon EBS 볼륨 유형을](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/ebs-volume-types.html) 참조하세요.
Amazon RDS의 경우 범용(SSD) 스토리지는 프로비저닝된 GB당 3IOPS의 일관된 기준을 제공하고 최대 3,000IOPS까지 버스트할 수 있는 기능을 제공합니다. Amazon RDS용 마그네틱 스토리지를 이미 사용하고 있는 경우 범용(SSD) 스토리지로 변환할 수 있지만, 이렇게 하면 가용성에 짧은 영향이 발생합니다. 프로비저닝된 IOPS를 사용하여 현재 최대 스토리지 한도와 데이터베이스 인스턴스당 최대 IOPS까지 프로비저닝할 수 있습니다.
실제 실현된 IOPS는 데이터베이스 워크로드, 인스턴스 유형 및 데이터베이스 엔진에 따라 프로비저닝한 양과 다를 수 있습니다. 자세한 내용은 [*Amazon RDS 사용 설명서*의 실현된 IOPS 속도에 영향을 미치는 요소를 참조하세요](https://docs.aws.amazon.com/AmazonRDS/latest/UserGuide/CHAP_Storage.html).
Amazon EC2 기반 Oracle Database의 경우 더 많은 IOPS와 더 큰 용량을 위해 여러 볼륨을 함께 스트라이프합니다. 여러 데이터 파일에 대해 여러 Amazon EBS 볼륨을 개별적으로 사용할 수 있지만 함께 스트라이핑하면 밸런싱과 확장성이 향상됩니다.
Oracle Automatic Storage Management(ASM)를 스트라이핑에 사용할 수 있습니다. 데이터 파일, 로그 파일 및 바이너리를 별도의 Amazon EBS 볼륨에 보관하고 로그 파일 볼륨의 스냅샷을 정기적으로 생성합니다. 로컬 SSD 스토리지로 인스턴스 유형을 선택하면 스마트 플래시 캐시(운영 체제가 Oracle Linux인 경우)를 사용하고 임시 파일 및 테이블 공간에 로컬 스토리지를 사용하여 데이터베이스 성능을 높일 수 있습니다.
AWS의 VMware Cloud 기반 Oracle Database의 경우 vSAN은 베어 메탈 호스트에 필요한 가상화 스토리지 스트라이프를 제공합니다. vSAN 가상화 스토리지 기능은 Oracle RAC에서 고성능 공유 스토리지에 사용할 수 있습니다.
Oracle RAC용으로 생성된 VMDK(가상 머신 디스크) 파일은 두께가 0이 되도록 프로비저닝하고 다중 라이터 플래그를 활성화해야 합니다. VMware는 AWS의 VMware Cloud에서 Oracle 데이터베이스에 대한 [자세한 성능 연구를](https://www.vmware.com/content/dam/digitalmarketing/vmware/en/pdf/whitepaper/solutions/oracle/vmw-oracle-performance-on-the-vmware-cloud-on-aws.pdf) 게시했습니다.