성능 검증 및 벤치마크 결과
변경 제안
PDF
이 성과 검증의 목적은 어떤 성과를 내는 것이 아닙니다. 오히려 이 문서에 설명된 배포 절차와 모범 사례를 따르면 퍼블릭 클라우드에 Oracle 데이터베이스를 배포해도 비슷한 성능 지표를 기대할 수 있습니다.
우리는 OLTP 유형 작업 부하를 시뮬레이션하기 위해 Swingbench Sales Order Entry(SOE) 모듈을 사용했고, NFS 프로토콜의 FSx 스토리지 볼륨이 있는 M5 EC2 인스턴스에 배포된 Oracle 데이터베이스에 작업 부하를 적용했습니다. 기본 Swingbench SOE I/O 프로필은 읽기/쓰기 비율이 80/20에 가깝고, 이는 실제 OLTP Oracle 워크로드 프로필과 비슷합니다.
작업 부하량은 판매 주문 입력, 검색, 재고 조회 등을 수행하는 클라이언트 측의 동시 사용자 수를 늘려서 증가합니다. 테스트한 동시 사용자 수는 8, 16, 32, 64, 128명이었습니다. Swingbench가 사용하는 알고리즘은 적절한 거래량을 확보하고 Oracle 서버 한도를 테스트하기 위해 서버 측에서 집중적으로 사용됩니다. 동시 사용자가 128명일 때 EC2 인스턴스의 CPU 사용률이 약 80-90%에 도달하는 것을 확인했습니다.
다음 섹션에서는 설정 및 테스트 결과에 대한 세부 정보를 제공합니다.
테스트 환경 설정
컴퓨팅
우리는 8vCPU, 32G RAM, 10Gps의 네트워크 대역폭을 갖춘 EC2 M5 인스턴스를 배포했습니다.
FSx 스토리지
다음과 같이 3개의 데이터베이스 볼륨을 생성하고 EC2 인스턴스의 NFS로 볼륨을 마운트했습니다.
-
/u01 - Oracle 바이너리
-
/u02 - Oracle 데이터 파일, 제어 파일
-
/u03 - Oracle 로그 파일, 제어 파일
우리는 중복성을 위해 중요한 제어 파일의 사본을 두 개 보관했습니다.
FSx 파일 시스템은 80,000 IOPS 용량과 2GiBps I/O 처리량으로 구성됩니다.
오라클 구성
RU 패치 19.8이 적용된 Oracle 버전 19c를 설치했습니다. 서버에서 dNFS가 활성화되었습니다.
데이터베이스는 3개의 PDB를 갖춘 컨테이너화된 데이터베이스로 배포되었습니다. 성능 테스트를 위해 하나의 PDB 인스턴스를 사용했습니다. 다음 그림은 NFS 마운트 지점에서의 Oracle 스토리지 크기를 보여줍니다.
스윙벤치 구성
우리는 8vCPU와 32G RAM이 있는 Windows 호스트에 Swingbench 2.6(최신 버전)을 배포했습니다. 우리는 벤치마크를 위해 SOE plsql 테스트 모듈 버전 2를 사용했습니다. 기본 부하 프로필은 실제 OLTP 트랜잭션 작업 부하를 시뮬레이션하기 위해 80/20 읽기/쓰기 비율을 제공합니다.
우리가 사용한 스키마 축척 계수는 50이었는데, 이는 초기 데이터 로드 크기를 160G로 하고 임시 공간을 30G로 할당했습니다. 이러한 규모에서 SOE 스키마는 온라인 주문 처리 시뮬레이션을 위해 1,000개의 창고와 5,000만 명의 고객을 제공했습니다.
다음 화면 샷은 Swingbench Windows UI의 작업 부하 프로필과 일반적인 트랜잭션 실행 지표를 보여줍니다.
그래프에서 볼 수 있듯이, 거래 수준은 테스트 실행 내내 동일한 수준으로 유지되었습니다.
테스트 결과 분석
우리는 각 테스트 실행에 대한 Swingbench 결과를 수집하고 성능 분석을 위해 해당 Oracle AWR 보고서를 얻었습니다.
최종 사용자 측면에서는 거래량, 사용자 응답 시간과 같은 주요 지표를 살펴보았습니다. 두 가지 지표는 시스템에 동시에 로그인하는 사용자 수를 고려하여 판매 주문 입력 시스템에서 사용자가 얼마나 많은 거래를 실행할 수 있는지, 그리고 사용자가 주문을 입력한 후 얼마나 빨리 거래를 완료하고 응답을 받을 수 있는지를 보여줍니다.
Oracle 서버 측에서 Oracle AWR 보고서를 구문 분석하여 사용자 트랜잭션 속도를 늦출 수 있는 주요 대기 이벤트를 파악했습니다. 상위 10개 Oracle 대기 이벤트는 Swingbench 시뮬레이션 트랜잭션 테스트 실행 중 Oracle 서버가 대부분 I/O에 집중되어 있으며 데이터베이스 시간의 50%-60%가 I/O에 소요된다는 것을 나타냅니다. db file sequential read . log file sync 데이터베이스 시간 백분율 수준에서는 더 작은 요소이지만 트랜잭션 커밋으로 인해 Oracle 로깅 프로세스가 버퍼 캐시에서 디스크의 로그 파일로 로그 I/O를 플러시하기 때문에 기여 요인이기도 합니다.
우리는 거래 실행 중에 동시 사용자 수에 따른 사용자 거래량, 사용자 응답 시간, Oracle 주요 대기 이벤트를 차트로 나타냈습니다. 결과는 아래와 같습니다.
이러한 결과는 지속적으로 낮은 I/O 지연 시간과 사용자 응답 시간을 유지하면서 동시 사용자 수를 늘려도 사용자 거래량을 꾸준히 늘릴 수 있음을 나타냅니다. 이는 Oracle 애플리케이션에 적합한 성능입니다.
동시 사용자가 128명에 이르자 I/O 지연 시간과 사용자 응답 시간이 다소 증가하기 시작했습니다. 이는 다음 다이어그램에 표시된 것처럼 EC2 인스턴스가 전체 서버 용량에 접근하고 있기 때문에 예상됩니다.
마찬가지로, 다음 다이어그램은 사용자 거래량을 충족시키는 동안 해당 FSx IOPS와 처리량을 보여줍니다.
Oracle 서버 EC2 인스턴스가 제한 요소가 되면서 IOPS나 처리량 면에서 프로비저닝된 FSx 스토리지 용량에 도달하지 못했습니다. 따라서 섹션에서 설명한 대로 사용자 애플리케이션 수준 트랜잭션 볼륨을 기준으로 컴퓨팅 및 스토리지 크기를 적절히 조정해야 합니다."Oracle 데이터베이스 구축 시 고려해야 할 요소."