Azure에서 Oracle 데이터베이스 설계 및 구현Design and implement an Oracle database in Azure

가정Assumptions

  • 온-프레미스에서 Azure로 Oracle 데이터베이스 마이그레이션할 계획입니다.You're planning to migrate an Oracle database from on-premises to Azure.
  • 마이그레이션하려는 Oracle Database에 대 한 진단 팩 이 있습니다.You have the Diagnostics Pack for the Oracle Database you're looking to migrate
  • Oracle AWR 보고서의 다양한 메트릭에 대해 이해하고 있습니다.You have an understanding of the various metrics in Oracle AWR reports.
  • 애플리케이션 성능 및 플랫폼 사용률에 대해 기본적으로 이해하고 있습니다.You have a baseline understanding of application performance and platform utilization.

목표Goals

  • Azure에서 Oracle 배포를 최적화하는 방법을 이해합니다.Understand how to optimize your Oracle deployment in Azure.
  • Azure 환경에서 Oracle 데이터베이스에 대한 성능 튜닝 옵션을 탐색합니다.Explore performance tuning options for an Oracle database in an Azure environment.

온-프레미스와 Azure 구현 간의 차이점The differences between an on-premises and Azure implementation

다음은 온-프레미스 애플리케이션을 Azure로 마이그레이션할 때 유의해야 할 몇 가지 중요 사항입니다.Following are some important things to keep in mind when you're migrating on-premises applications to Azure.

중요한 차이점 중 하나는 Azure 구현에서 VM, 디스크 및 가상 네트워크와 같은 리소스가 다른 클라이언트와 공유된다는 것입니다.One important difference is that in an Azure implementation, resources such as VMs, disks, and virtual networks are shared among other clients. 또한 리소스는 요구 사항에 따라 제한될 수도 있습니다.In addition, resources can be throttled based on the requirements. Azure에서는 실패 방지(MTBF)에 집중하는 대신 실패 극복(MTTR)에 더 많이 집중합니다.Instead of focusing on avoiding failing (MTBF), Azure is more focused on surviving the failure (MTTR).

다음 표에는 Oracle 데이터베이스의 온-프레미스 구현과 Azure 구현 간의 차이점이 나열되어 있습니다.The following table lists some of the differences between an on-premises implementation and an Azure implementation of an Oracle database.

온-프레미스 구현On-premises implementation Azure 구현Azure implementation
네트워킹Networking LAN/WANLAN/WAN SDN(소프트웨어 방식 네트워킹)SDN (software-defined networking)
보안 그룹Security group IP/포트 제한 도구IP/port restriction tools NSG (네트워크 보안 그룹)Network Security Group (NSG)
복원력Resilience MTBF(평균 고장 간격)MTBF (mean time between failures) MTTR(평균 복구 시간)MTTR (mean time to recovery)
계획 된 유지 관리Planned maintenance 패치/업그레이드Patching/upgrades 가용성 집합(Azure에서 관리되는 패치/업그레이드)Availability sets (patching/upgrades managed by Azure)
리소스Resource 전용Dedicated 다른 클라이언트와 공유Shared with other clients
지역Regions 데이터 센터Datacenters 지역 쌍Region pairs
스토리지Storage SAN/실제 디스크SAN/physical disks Azure 관리 스토리지Azure-managed storage
크기 조정Scale 수직적 확장Vertical scale 수평적 확장Horizontal scale

요구 사항Requirements

  • 데이터베이스 크기 및 증가 속도를 결정합니다.Determine the database size and growth rate.
  • Oracle AWR 보고서 또는 다른 네트워크 모니터링 도구에 따라 예측할 수 있는 IOPS 요구 사항을 결정합니다.Determine the IOPS requirements, which you can estimate based on Oracle AWR reports or other network monitoring tools.

구성 옵션Configuration options

Azure 환경에서 성능을 향상시키기 위해 조정할 수 있는 잠재적인 네 가지 영역이 있습니다.There are four potential areas that you can tune to improve performance in an Azure environment:

  • 가상 머신 크기Virtual machine size
  • 네트워크 처리량Network throughput
  • 디스크 형식 및 구성Disk types and configurations
  • 디스크 캐시 설정Disk cache settings

AWR 보고서 생성Generate an AWR report

기존 Oracle 데이터베이스가 있고 Azure로 마이그레이션하도록 계획하는 경우 몇 가지 옵션이 있습니다.If you have an existing an Oracle database and are planning to migrate to Azure, you have several options. Oracle 인스턴스에 대 한 진단 팩 이 있는 경우 oracle AWR 보고서를 실행 하 여 메트릭 (IOPS, Mbps, gid 등)을 가져올 수 있습니다.If you have the Diagnostics Pack for your Oracle instances, you can run the Oracle AWR report to get the metrics (IOPS, Mbps, GiBs, and so on). 그런 다음 수집한 메트릭을 기반으로 하여 VM을 선택합니다.Then choose the VM based on the metrics that you collected. 또는 인프라 팀에 문의하여 유사한 정보를 얻을 수 있습니다.Or you can contact your infrastructure team to get similar information.

일반 및 최대 워크로드 모두에서 AWR 보고서를 실행하여 비교하는 것이 좋을 수도 있습니다.You might consider running your AWR report during both regular and peak workloads, so you can compare. 이러한 보고서에 따라 평균 워크로드 또는 최대 워크로드를 기준으로 VM 크기를 조정할 수 있습니다.Based on these reports, you can size the VMs based on either the average workload or the maximum workload.

다음은 AWR 보고서를 생성 하는 방법에 대 한 예입니다 (현재 설치 되어 있는 경우 Oracle 엔터프라이즈 관리자를 사용 하 여 AWR 보고서 생성).Following is an example of how to generate an AWR report (Generate your AWR reports using your Oracle Enterprise Manager, if your current install has one):

$ sqlplus / as sysdba
SQL> EXEC DBMS_WORKLOAD_REPOSITORY.CREATE_SNAPSHOT;
SQL> @?/rdbms/admin/awrrpt.sql

주요 메트릭Key metrics

다음은 AWR 보고서에서 얻을 수 있는 메트릭입니다.Following are the metrics that you can obtain from the AWR report:

  • 총 코어 수Total number of cores
  • CPU 클럭 속도CPU clock speed
  • 전체 메모리(GB)Total memory in GB
  • CPU 사용률CPU utilization
  • 최대 데이터 전송 속도Peak data transfer rate
  • I/O 변경률(읽기/쓰기)Rate of I/O changes (read/write)
  • 다시 실행 로그 속도(MBPs)Redo log rate (MBPs)
  • 네트워크 처리량Network throughput
  • 네트워크 대기 시간 비율(낮음/높음)Network latency rate (low/high)
  • 데이터베이스 크기(GB)Database size in GB
  • 클라이언트 간 SQL*Net을 통해 수신된 바이트 수Bytes received via SQL*Net from/to client

가상 머신 크기Virtual machine size

1. AWR 보고서의 CPU, 메모리 및 i/o 사용량에 따라 VM 크기를 예상 합니다.1. Estimate VM size based on CPU, memory, and I/O usage from the AWR report

시스템 병목 현상이 발생하는 위치를 나타내는 상위 5개 시간 지정 전경 이벤트를 확인할 수 있습니다.One thing you might look at is the top five timed foreground events that indicate where the system bottlenecks are.

예를 들어 다음 다이어그램에서는 로그 파일 동기화가 맨 위에 있습니다.For example, in the following diagram, the log file sync is at the top. LGWR에서 로그 버퍼를 다시 실행 로그 파일에 쓰기 전에 필요한 대기 수를 나타냅니다.It indicates the number of waits that are required before the LGWR writes the log buffer to the redo log file. 이러한 결과는 더 효율적으로 수행되는 스토리지 또는 디스크가 필요함을 나타냅니다.These results indicate that better performing storage or disks are required. 또한 다이어그램에서는 CPU(코어) 수와 메모리 양도 보여 줍니다.In addition, the diagram also shows the number of CPU (cores) and the amount of memory.

테이블 맨 위에 있는 로그 파일 동기화를 보여 주는 스크린샷

다음 다이어그램에서는 읽기 및 쓰기의 총 I/O 수를 보여 줍니다.The following diagram shows the total I/O of read and write. 보고서 시간 동안 59GB의 읽기 및 247.3GB의 쓰기가 있었습니다.There were 59 GB read and 247.3 GB written during the time of the report.

읽기 및 쓰기의 총 i/o를 보여 주는 스크린샷

2. VM 선택2. Choose a VM

다음 단계에서는 AWR 보고서에서 수집한 정보에 따라 요구 사항을 충족하는 비슷한 크기의 VM을 선택합니다.Based on the information that you collected from the AWR report, the next step is to choose a VM of a similar size that meets your requirements. 메모리 최적화 문서에서 사용 가능한 VM 목록을 찾을 수 있습니다.You can find a list of available VMs in the article Memory optimized.

3. ACU에 따라 유사한 VM 시리즈를 사용 하 여 VM 크기를 미세 조정 합니다.3. Fine-tune the VM sizing with a similar VM series based on the ACU

VM을 선택한 후에는 해당 VM에 대한 ACU에 주의해야 합니다.After you've chosen the VM, pay attention to the ACU for the VM. 요구 사항에 더 적합한 ACU 값에 따라 다른 VM을 선택할 수도 있습니다.You might choose a different VM based on the ACU value that better suits your requirements. 자세한 내용은 Azure 컴퓨팅 단위를 참조하세요.For more information, see Azure compute unit.

ACU 단위 페이지의 스크린샷

네트워크 처리량Network throughput

다음 다이어그램에서는 처리량과 IOPS 간의 관계를 보여 줍니다.The following diagram shows the relation between throughput and IOPS:

처리량 스크린샷

총 네트워크 처리량은 다음 정보를 기반으로 하여 예측합니다.The total network throughput is estimated based on the following information:

  • SQL*Net 트래픽SQL*Net traffic
  • MBps x 서버 수(Oracle Data Guard와 같은 아웃바운드 스트림)MBps x number of servers (outbound stream such as Oracle Data Guard)
  • 애플리케이션 복제와 같은 다른 요소Other factors, such as application replication

SQL*Net 처리량의 스크린샷

네트워크 대역폭 요구 사항에 따라 다양한 게이트웨이 유형을 선택할 수 있습니다.Based on your network bandwidth requirements, there are various gateway types for you to choose from. 여기에는 기본, VpnGw 및 Azure ExpressRoute가 포함됩니다.These include basic, VpnGw, and Azure ExpressRoute. 자세한 내용은 VPN Gateway 가격 페이지를 참조하세요.For more information, see the VPN gateway pricing page.

권장 사항Recommendations

  • 네트워크 대기 시간은 온-프레미스 배포에 비해 더 높습니다.Network latency is higher compared to an on-premises deployment. 네트워크 왕복 수를 줄이면 성능이 크게 향상될 수 있습니다.Reducing network round trips can greatly improve performance.
  • 왕복을 줄이려면 동일한 가상 머신에서 트랜잭션이 많은 애플리케이션 또는 "채팅 가능한(chatty)" 앱을 통합합니다.To reduce round-trips, consolidate applications that have high transactions or “chatty” apps on the same virtual machine.
  • 네트워크 성능을 향상 시키려면 가속화 된 네트워킹 을 사용 하는 Virtual Machines를 사용 합니다.Use Virtual Machines with Accelerated Networking for better network performance.
  • 특정 Linux 배포판의 경우 트리밍/매핑 해제 지원을사용 하도록 설정 하는 것이 좋습니다.For certain Linux distributions, consider enabling TRIM/UNMAP support.
  • 별도의 가상 컴퓨터에 Oracle Enterprise Manager 를 설치 합니다.Install Oracle Enterprise Manager on a separate Virtual Machine.
  • 기본적으로 큰 페이지는 linux에서 사용 하도록 설정 되지 않습니다.Huge pages are not enabled on linux by default. 큰 페이지를 사용 하도록 설정 하 고 Oracle DB에 설정 하는 것이 좋습니다 use_large_pages = ONLY .Consider enabling huge pages and set use_large_pages = ONLY on the Oracle DB. 이렇게 하면 성능을 향상 시킬 수 있습니다.This may help increase performance. 자세한 내용은 여기를 참조하세요.More information can be found here.

디스크 형식 및 구성Disk types and configurations

  • 기본 OS 디스크: 이러한 디스크 유형은 영구 데이터 및 캐싱을 제공합니다.Default OS disks: These disk types offer persistent data and caching. 시작 시 OS 액세스에 최적화되며, 트랜잭션 또는 데이터 웨어하우스(분석) 워크로드용으로는 설계되지 않았습니다.They are optimized for OS access at startup, and aren't designed for either transactional or data warehouse (analytical) workloads.

  • 비관리 디스크: 이러한 디스크 유형을 사용하면 VM 디스크에 해당하는 VHD(가상 하드 디스크) 파일을 저장하는 스토리지 계정을 관리할 수 있습니다.Unmanaged disks: With these disk types, you manage the storage accounts that store the virtual hard disk (VHD) files that correspond to your VM disks. VHD 파일은 Azure Storage 계정에 페이지 Blob으로 저장됩니다.VHD files are stored as page blobs in Azure storage accounts.

  • 관리 디스크: Azure에서 VM 디스크에 사용하는 스토리지 계정을 관리합니다.Managed disks: Azure manages the storage accounts that you use for your VM disks. 필요한 디스크 유형(프리미엄 또는 표준)과 디스크 크기를 지정합니다.You specify the disk type (premium or standard) and the size of the disk that you need. Azure에서 사용자에게 맞는 디스크를 만들고 관리합니다.Azure creates and manages the disk for you.

  • Premium Storage 디스크: 이러한 디스크 유형은 프로덕션 워크로드에 가장 적합합니다.Premium storage disks: These disk types are best suited for production workloads. Premium Storage는 특정 크기 시리즈 VM(예: DS, DSv2, GS 및 F 시리즈 VM)에 연결할 수 있는 VM 디스크를 지원합니다.Premium storage supports VM disks that can be attached to specific size-series VMs, such as DS, DSv2, GS, and F series VMs. 다양한 크기로 제공되며 32GB에서 4,096GB까지 다양한 디스크를 선택할 수 있습니다.The premium disk comes with different sizes, and you can choose between disks ranging from 32 GB to 4,096 GB. 디스크 크기마다 자체 성능 사양이 있습니다.Each disk size has its own performance specifications. 애플리케이션 요구 사항에 따라 하나 이상의 디스크를 VM에 연결할 수 있습니다.Depending on your application requirements, you can attach one or more disks to your VM.

포털에서 새 관리 디스크를 만드는 경우 사용하려는 디스크 유형에 대한 계정 유형 을 선택할 수 있습니다.When you create a new managed disk from the portal, you can choose the Account type for the type of disk you want to use. 사용 가능한 모든 디스크가 드롭다운 메뉴에 표시되는 것은 아닙니다.Keep in mind that not all available disks are shown in the drop-down menu. 특정 VM 크기를 선택하면 해당 VM 크기를 기반으로 하여 사용할 수 있는 Premium Storage SKU만 메뉴에 표시됩니다.After you choose a particular VM size, the menu shows only the available premium storage SKUs that are based on that VM size.

관리되는 디스크 페이지의 스크린샷

VM에서 스토리지를 구성한 후 데이터베이스를 만들기 전에 디스크를 로드하여 테스트할 수 있습니다.After you configure your storage on a VM, you might want to load test the disks before creating a database. 대기 시간 및 처리량 모두와 관련된 I/O 속도를 알고 있으면 VM에서 대기 시간 목표로 예상되는 처리량을 지원할 수 있는지 확인하는 데 도움이 됩니다.Knowing the I/O rate in terms of both latency and throughput can help you determine if the VMs support the expected throughput with latency targets.

Oracle Orion, Sysbench 및 Fio와 같이 애플리케이션 부하 테스트를 위한 여러 가지 도구가 있습니다.There are a number of tools for application load testing, such as Oracle Orion, Sysbench, and Fio.

Oracle 데이터베이스를 배포한 후에 부하 테스트를 다시 실행합니다.Run the load test again after you've deployed an Oracle database. 일반 및 최대 워크로드를 시작합니다. 그러면 결과에서 사용자 환경의 초기 계획을 보여 줍니다.Start your regular and peak workloads, and the results show you the baseline of your environment.

스토리지 크기 대신 IOPS 속도에 따라 스토리지 크기를 조정하는 것이 더 중요할 수 있습니다.It might be more important to size the storage based on the IOPS rate rather than the storage size. 예를 들어 필요한 IOPS가 5,000이지만 200GB만 필요한 경우 200GB 이상의 스토리지가 있어도 P30 클래스 프리미엄 디스크를 받을 수도 있습니다.For example, if the required IOPS is 5,000, but you only need 200 GB, you might still get the P30 class premium disk even though it comes with more than 200 GB of storage.

IOPS 속도는 AWR 보고서에서 얻을 수 있으며,The IOPS rate can be obtained from the AWR report. 다시 실행 로그, 물리적 읽기 및 쓰기 속도로 결정됩니다.It's determined by the redo log, physical reads, and writes rate.

AWR 보고서 페이지의 스크린샷

예를 들어 다시 실행 크기는 초당 12,200,000바이트이며, 11.63MBps와 같습니다.For example, the redo size is 12,200,000 bytes per second, which is equal to 11.63 MBPs. IOPS는 12,200,000 / 2,358 = 5,174입니다.The IOPS is 12,200,000 / 2,358 = 5,174.

I/O 요구 사항에 대해 명확히 알고 있으면 이러한 요구 사항에 가장 적합한 드라이브 조합을 선택할 수 있습니다.After you have a clear picture of the I/O requirements, you can choose a combination of drives that are best suited to meet those requirements.

권장 사항Recommendations

  • 데이터 테이블스페이스의 경우 관리되는 스토리지 또는 Oracle ASM을 사용하여 I/O 워크로드를 여러 디스크에 분산합니다.For data tablespace, spread the I/O workload across a number of disks by using managed storage or Oracle ASM.
  • 읽기 및 쓰기 집약적 작업에 대한 I/O 블록 크기가 늘어남에 따라 데이터 디스크를 더 많이 추가합니다.As the I/O block size increases for read-intensive and write-intensive operations, add more data disks.
  • 대규모 순차적 프로세스에 대한 블록 크기를 늘립니다.Increase the block size for large sequential processes.
  • 데이터 압축을 사용하여 I/O를 줄입니다(데이터 및 인덱스 모두에 해당).Use data compression to reduce I/O (for both data and indexes).
  • 개별 데이터 디스크에서 다시 실행 로그, 시스템, 임시 디스크를 분리하고 TS를 실행 취소합니다.Separate redo logs, system, and temps, and undo TS on separate data disks.
  • 기본 OS 디스크(/dev/sda)에 애플리케이션 파일을 배치하지 않습니다.Don't put any application files on default OS disks (/dev/sda). 이러한 디스크는 빠른 VM 부팅 시간에 맞게 최적화되지 않으며, 애플리케이션에 좋은 성능을 제공하지 않을 수 있습니다.These disks aren't optimized for fast VM boot times, and they might not provide good performance for your application.
  • Premium storage에서 M 시리즈 Vm을 사용 하는 경우 redo logs 디스크에서 쓰기 가속기 를 사용 하도록 설정 합니다.When using M-Series VMs on Premium storage, enable Write Accelerator on redo logs disk.

디스크 캐시 설정Disk cache settings

호스트 캐싱에는 세 가지 옵션이 있습니다.There are three options for host caching:

  • ReadOnly: 모든 요청은 이후 읽기에 대해 캐시 됩니다.ReadOnly: All requests are cached for future reads. 모든 쓰기는 Azure Blob Storage에 직접 유지됩니다.All writes are persisted directly to Azure Blob storage.

  • ReadWrite: "미리 읽기" 알고리즘입니다.ReadWrite: This is a “read-ahead” algorithm. 읽기 및 쓰기가 향후 읽기에 대해 캐시됩니다.The reads and writes are cached for future reads. 연속 쓰기(write-through) 이외의 쓰기 작업은 먼저 로컬 캐시에 유지됩니다.Non-write-through writes are persisted to the local cache first. 또한 가벼운 워크로드에 대해 가장 낮은 디스크 대기 시간을 제공합니다.It also provides the lowest disk latency for light workloads. 필요한 데이터를 유지하도록 처리하지 않는 애플리케이션에 ReadWrite 캐시를 사용하면 VM이 충돌할 경우 데이터 손실이 발생할 수 있습니다.Using ReadWrite cache with an application that does not handle persisting the required data can lead to data loss, if the VM crashes.

  • 없음(사용 안 함): 이 옵션을 사용하면 캐시를 무시할 수 있습니다.None (disabled): By using this option, you can bypass the cache. 모든 데이터가 디스크에 전송되며 Azure Storage에 유지됩니다.All the data is transferred to disk and persisted to Azure Storage. 이 메서드를 사용하면 I/O 집약적 워크로드에 대해 가장 높은 I/O 속도를 얻을 수 있습니다.This method gives you the highest I/O rate for I/O intensive workloads. "트랜잭션 비용"도 고려해야 합니다.You also need to take “transaction cost” into consideration.

권장 사항Recommendations

처리량을 최대화 하려면 호스트 캐싱에 대해 아무것도 시작 하지 않는 것이 좋습니다.To maximize the throughput, we recommend that you start with None for host caching. Premium Storage의 경우 읽기 전용 또는 없음 옵션을 사용하여 파일 시스템을 탑재할 때 "barrier"를 사용하지 않도록 설정해야 합니다.For Premium Storage, keep in mind that you must disable the "barriers" when you mount the file system with the ReadOnly or None options. /etc/fstab 파일을 UUID로 디스크에 업데이트합니다.Update the /etc/fstab file with the UUID to the disks.

ReadOnly 및 None 옵션을 보여 주는 관리 디스크 페이지의 스크린샷

  • OS 디스크의 경우 기본 읽기/쓰기 캐싱을 사용합니다.For OS disks, use default Read/Write caching.
  • 시스템, 임시 및 실행 취소 디스크의 경우 캐싱에 없음 을 사용합니다.For SYSTEM, TEMP, and UNDO use None for caching.
  • 데이터 디스크의 경우 캐싱에 없음 을 사용합니다.For DATA, use None for caching. 그러나 데이터베이스가 읽기 전용이거나 읽기 집약적인 경우 읽기 전용 캐싱을 사용합니다.But if your database is read-only or read-intensive, use Read-only caching.

데이터 디스크 설정을 저장한 후에 OS 수준에서 드라이브를 분리한 다음 변경한 후에 다시 탑재하지 않는 한 호스트 캐시 설정은 변경할 수 없습니다.After your data disk setting is saved, you can't change the host cache setting unless you unmount the drive at the OS level and then remount it after you've made the change.

보안Security

Azure 환경을 설정하고 구성한 후의 다음 단계는 네트워크를 보호하는 것입니다.After you have set up and configured your Azure environment, the next step is to secure your network. 몇 가지 권장 사항입니다.Here are some recommendations:

  • NSG 정책: NSG는 서브넷 또는 NIC에서 정의될 수 있습니다.NSG policy: NSG can be defined by a subnet or NIC. 응용 프로그램 방화벽과 같은 항목에 대 한 보안 및 강제 라우팅을 위해 서브넷 수준에서 액세스를 제어 하는 것이 더 간단 합니다.It's simpler to control access at the subnet level, both for security and force routing for things like application firewalls.

  • Jumpbox: 더 안전한 액세스를 위해 관리자는 애플리케이션 서비스 또는 데이터베이스에 직접 연결하면 안됩니다.Jumpbox: For more secure access, administrators should not directly connect to the application service or database. Jumpbox는 관리자 컴퓨터와 Azure 리소스 간 미디어로 사용됩니다.A jumpbox is used as a media between the administrator machine and Azure resources. Jumpbox 토폴로지 페이지의 스크린샷Screenshot of the Jumpbox topology page

    관리자 컴퓨터는 Jumpbox에 대해 IP가 제한된 액세스만 제공해야 합니다.The administrator machine should offer IP-restricted access to the jumpbox only. Jumpbox에는 애플리케이션과 데이터베이스에 대한 액세스 권한이 있어야 합니다.The jumpbox should have access to the application and database.

  • 사설망(서브넷): NSG 정책에 따라 더 나은 제어를 설정할 수 있도록 애플리케이션 서비스와 데이터베이스를 별도의 서브넷에 두는 것이 좋습니다.Private network (subnets): We recommend that you have the application service and database on separate subnets, so better control can be set by NSG policy.

추가 자료Additional reading

다음 단계Next steps