Azure Virtual Machines의 데이터베이스를 갖춘 Oracle 애플리케이션용 아키텍처
이 문서에서는 Oracle 데이터베이스가 상주하거나 공동 배치된 Azure IaaS에 Oracle 애플리케이션을 배포하는 참조 아키텍처를 제공합니다.
Oracle 워크로드는 Oracle 데이터베이스뿐만 아니라 Siebel, PeopleSoft, JD Edwards, E-Business Suite 또는 사용자 지정된 WebLogic 서버 애플리케이션과 같은 Oracle 자사 애플리케이션의 데이터베이스로도 구성됩니다. Azure IaaS(서비스 제공 인프라)에 Oracle 애플리케이션을 배포하는 것은 Oracle 데이터베이스와 함께 Oracle 워크로드에 클라우드를 사용하려는 조직에 대한 일반적인 시나리오입니다. Microsoft는 이 프로세스를 용이하게 하기 위한 참조 아키텍처 및 모범 사례를 제공합니다.
일반 애플리케이션 마이그레이션 지침
Oracle 애플리케이션이 Azure IaaS에서 이동함에 따라 애플리케이션 유형에 관계없이 따라야 하는 일반적인 디자인 고려 사항이 있습니다. 일부 고려 사항은 애플리케이션마다 다릅니다. 이 섹션에서는 모든 애플리케이션에 대한 일반적인 디자인 고려 사항을 나열하고, 애플리케이션 관련 고려 사항은 각 애플리케이션에서 다룹니다.
네트워크 및 보안
Azure의 Oracle 애플리케이션에 대해 제공된 네트워크 설정은 네트워크 및 보안 고려 사항의 여러 가지 측면을 다룹니다. 권장되는 네트워크 설정에 대한 세부 사항은 다음과 같습니다.
Microsoft Entra ID 및 SAML을 사용하는 SSO(Single Sign-On): SAML(Security Assertions Markup Language) 프로토콜을 사용하여 SSO(Single Sign-On)에 Microsoft Entra ID를 사용합니다. 이 SSO를 사용하면 사용자가 한 번 인증하고 여러 서비스에 원활하게 액세스할 수 있습니다.
Microsoft Entra 애플리케이션 프록시: 특히 원격 사용자에 대해 Microsoft Entra 애플리케이션 프록시를 사용하는 것이 좋습니다. 이 프록시를 사용하면 네트워크 외부에서 온-프레미스 애플리케이션에 안전하게 액세스할 수 있습니다.
ExpressRoute를 통해 내부 사용자 라우팅: 내부 사용자의 경우 Azure 서비스에 대한 전용 프라이빗 연결을 위해 Azure ExpressRoute를 통해 트래픽을 라우팅하여 짧은 대기 시간과 안전한 통신을 보장합니다.
Azure Firewall: 필요한 경우 보안 강화를 위해 애플리케이션 앞에 Azure Firewall을 구성할 수 있습니다. Azure Firewall은 무단 액세스 및 위협으로부터 리소스를 보호하는 데 도움이 됩니다.
외부 사용자용 Application Gateway: 외부 사용자가 애플리케이션에 액세스해야 하는 경우 Azure Application Gateway를 사용하는 것이 좋습니다. 웹 애플리케이션을 보호하기 위한 WAF(Web Application Firewall) 기능과 트래픽을 분산하는 7계층 부하 분산 기능을 제공합니다.
NSG(네트워크 보안 그룹): NSG(네트워크 보안 그룹)를 사용하여 서브넷을 보호합니다. NSG를 사용하면 보안 규칙을 정의하여 네트워크 인터페이스, Virtual Machines 및 서브넷에 대한 인바운드 및 아웃바운드 트래픽을 제어할 수 있습니다.
RBAC(역할 기반 액세스 제어): 특정 개인 또는 역할에 대한 액세스 권한을 부여하려면 Azure RBAC를 사용합니다. RBAC는 역할 및 권한에 따라 Azure 리소스에 대해 세분화된 액세스 제어를 제공합니다.
SSH 액세스용 Bastion 호스트: Bastion 호스트를 점프 서버(jump box)로 사용하여 SSH 액세스에 대한 보안을 강화합니다. Bastion 호스트는 관리자가 가상 네트워크의 Virtual Machines에 액세스할 수 있는 보안 게이트웨이 역할을 합니다. 이 호스트는 추가 보안 계층을 제공합니다.
추가 고려 사항:
- 데이터 암호화: 미사용 데이터와 전송 중인 데이터가 암호화되었는지 확인합니다. Azure는 이 목적을 위해 Azure Disk Encryption 및 SSL/TLS와 같은 도구를 제공합니다.
- 패치 관리: 알려진 취약성으로부터 보호하기 위해 EBS 환경을 정기적으로 업데이트하고 패치합니다.
- 모니터링 및 로깅: 보안을 위해 Azure Monitor 및 Azure Defender를 구현하여 환경에 대한 보안 위협 및 이상 현상을 지속적으로 확인합니다. 감사 및 포렌식 분석을 위한 로깅을 설정합니다.
요약하자면, 이러한 네트워크 및 보안 설정은 Azure IaaS에서 Oracle 애플리케이션을 호스트하기 위한 강력하고 안전한 환경을 제공하는 것을 목표로 합니다. 내부 및 외부 사용자를 위한 인증, 액세스 제어 및 네트워크 보안에 대한 모범 사례를 통합합니다. 또한 애플리케이션 서버에 대한 SSH 액세스의 필요성을 고려합니다. 이러한 권장 사항은 Azure IaaS에서 Oracle 애플리케이션 배포를 위한 완성도 높은 보안 태세를 설정하는 데 도움이 될 수 있습니다.
웹 계층: 웹 계층은 요청 부하를 분산하고 애플리케이션 계층, 데이터베이스 계층 및/또는 백업에 따라 요청을 보냅니다.
애플리케이션 계층: 애플리케이션 계층에는 일반적으로 애플리케이션 서버 및 공유 파일 시스템이 포함됩니다.
자동 크기 조정을 위해 Virtual Machine Scale Sets는 워크로드에 맞게 사용자 지정 크기 조정 규칙을 사용하여 수요에 따라 여러 Virtual Machines를 스케일 아웃하는 데 적합할 수 있습니다.
Azure SME(실무 전문가)와 협력하여 아키텍처에 대한 철저한 평가를 수행합니다. 성능, 가용성 및 확장성을 포함하여 특정 요구 사항에 따라 가장 적합한 Azure 서비스를 결정하는 데 도움이 될 수 있습니다. 아키텍처를 디자인할 때 비용, 데이터 보안, 규정 준수 및 재해 복구와 같은 요소를 고려해야 합니다.
또한 효율성과 비용 효율성을 보장하기 위해 Azure 리소스를 지속적으로 확인하고 최적화해야 합니다.
부하 분산 및 처리량: 애플리케이션 서버의 워크로드 특성을 평가하는 것이 중요합니다. 일부 서버는 더 많은 작업을 처리하고 다른 서버보다 더 높은 처리량을 만듭니다. 이 정보는 리소스가 효과적으로 할당되도록 Azure Virtual Machine Scale Sets 및 부하 분산 구성을 디자인할 때 중요합니다.
데이터베이스 계층: Azure IaaS의 Oracle Data Guard for Oracle에서 HA 아키텍처를 사용하는 것이 좋습니다. 애플리케이션에는 특정 유형의 HA 설정이 필요하며 각 애플리케이션 아래에 나열됩니다.
백업 - 백업은 애플리케이션 계층 및 데이터베이스 계층에서 전송됩니다. 이러한 두 계층을 두 개의 서로 다른 공급업체로 구분해서는 안 되는 여러 이유 중 하나일 뿐입니다. 데이터베이스의 백업은 Premium Files의 Azure Backup 볼륨 스냅숏을 통해 보조 지역으로 수행됩니다.
재해 복구 - 선택할 수 있는 다양한 솔루션이 있습니다. 솔루션은 요구 사항에 따라 달라집니다. 아키텍처는 고가용성으로 빌드되었습니다. 애플리케이션 계층을 복제하기 위해 Azure Site Recovery를 사용할 수 있습니다. 선택할 수 있는 또 다른 솔루션은 관리 디스크에 대한 중복 옵션입니다. 두 솔루션 모두 데이터를 복제합니다. 관리 디스크에 대한 중복 옵션은 아키텍처를 간소화할 수 있는 솔루션이지만 몇 가지 제한 사항도 함께 제공됩니다.
Azure의 Siebel
Oracle Siebel CRM은 계속해서 많은 기업에서 선호하는 엔터프라이즈급 CRM 솔루션입니다. Oracle 포트폴리오에서 가장 복잡한 애플리케이션 중 하나로, 고객 관련 작업을 관리하기 위한 트랜잭션, 분석 및 계약 기능의 조합을 제공합니다.
다음은 Azure Virtual Machines for Innovation Pack 16 이하 버전에서 권장되는 Siebel 애플리케이션 배포 아키텍처입니다.
다음 다이어그램은 Azure Virtual Machines for Innovation Pack 17 이하 버전의 Siebel 애플리케이션 배포 아키텍처입니다.
Oracle Siebel 디자인 고려 사항
네트워크 및 보안: 일반적인 네트워크 및 보안 고려 사항을 따르는 데 필요한 Azure의 Oracle Siebel에 대한 네트워크 설정입니다.
마이그레이션은 Siebel 도구 서브넷을 사용하여 수행해야 합니다.
애플리케이션 계층
- 버전 17 이상 – 애플리케이션 및 데이터베이스의 특정 서버 및 유틸리티 구성이 필요합니다.
데이터베이스 계층
- 데이터베이스 및 Siebel 버전이 일치하는지 확인합니다.
- Oracle Data Guard Oracle 참조 아키텍처를 사용하여 주 데이터베이스와 복제된 데이터베이스가 보조 데이터베이스에 복사되는지 확인합니다.
Azure의 E-Business 제품군
EBS(Oracle E-Business Suite)는 SCM(공급망 관리) 및 CRM(고객 관계 관리)을 포함하는 애플리케이션 제품군입니다. EBS는 SCM 및 CRM 시스템이므로 일반적으로 타사 시스템에 대한 많은 인터페이스가 있습니다. 다음 아키텍처는 한 지역 내에서 고가용성으로 빌드됩니다.
다음 다이어그램에서는 외부 사용자가 회사 네트워크를 통과하지 않는다고 가정합니다.
Oracle EBS 디자인 고려 사항
데이터베이스 계층 - 주 및 보조 데이터베이스는 하나의 데이터 센터 내에 있어야 합니다. 동기 구성을 사용해야 합니다. 데이터 센터 간에 애플리케이션을 설치하는 경우 비동기 모드에서 Data Guard를 구성해야 합니다.
Azure의 JD Edwards
Oracle의 JD Edwards는 포괄적인 엔터프라이즈 리소스 계획 소프트웨어의 통합 애플리케이션 제품군입니다. 현재 JD Edwards는 공급망, 웨어하우스 관리, 물류, 제조 리소스 계획 등에 사용됩니다. 애플리케이션을 사용하기 때문에 다른 시스템에 대한 인터페이스도 중요하다는 것을 알 수 있습니다.
다음 아키텍처는 고가용성으로 빌드되었습니다. 외부 사용자가 회사 네트워크를 통해 액세스하지 않는다고 가정했습니다. 외부 사용자가 회사 네트워크를 사용하여 애플리케이션에 액세스하는 경우 다음과 같이 네트워킹에서 아키텍처를 간소화할 수 있습니다.
JD Edwards 디자인 고려 사항
웹 계층: 애플리케이션 웹 계층은 일반적으로 여러 애플리케이션 서버로 구성됩니다. JD Edwards에서 규칙은 종종 이러한 애플리케이션 웹 서버에 저장됩니다.
프레젠테이션 계층: 프레젠테이션 계층의 각 인스턴스는 스토리지와 연결됩니다. 인스턴스 간의 종속성을 삭제하면 대기 시간이 높아질 수 있으므로 신중하게 평가하는 것이 중요합니다.
서버 성능 차이: 일부 서버는 더 많은 작업을 처리하고 다른 서버보다 더 높은 처리량을 만들 수 있습니다. 디자인 단계에서는 인프라가 최대 워크로드를 효율적으로 처리할 수 있도록 이 처리량 차이를 평가해야 합니다.
재설계: 자동 크기 조정에 Azure Virtual Machine Scale Sets를 사용하면 JD Edwards 설정을 재설계하지 않아도 됩니다. 애플리케이션 아키텍처를 크게 변경하지 않고도 구현할 수 있는 확장 가능한 솔루션입니다.
데이터베이스 계층 - 주 및 보조 데이터베이스는 하나의 데이터 센터 내에 유지되며 동기 구성을 사용해야 합니다. 데이터 센터 간에 애플리케이션을 설치하는 경우 비동기 모드에서 Data Guard를 구성해야 합니다. 데이터베이스 계층의 데이터는 Azure Storage로 직접 전송됩니다. 이 Storage는 현재 아키텍처 설정에 따라 달라집니다.
Azure의 PeopleSoft
Oracle의 PeopleSoft 애플리케이션 제품군에는 인적 자원 및 재무 관리를 위한 소프트웨어가 포함됩니다. 애플리케이션 제품군은 다중 계층이며 애플리케이션에는 HRMS(인사 관리 시스템), CRM(고객 관계 관리), FSCM(재무 및 공급망 관리) 및 EPM(엔터프라이즈 성능 관리)이 포함됩니다.
PeopleSoft 디자인 고려 사항
애플리케이션 계층: 애플리케이션 계층에는 여러 작업 및 서버가 포함됩니다. 비즈니스 논리 및 프로세스를 실행할 뿐만 아니라 데이터베이스에 대한 연결도 유지 관리합니다. 이 종속성이 끊어지면 바로 대기 시간이 발생합니다.
애플리케이션 계층과 데이터베이스 계층 간 종속성: 애플리케이션 계층과 데이터베이스 계층 간의 대기 시간을 최소화하는 것이 중요합니다. 애플리케이션 계층 및 데이터베이스 계층을 동일한 클라우드 공급자(이 경우 Azure)에 배치하면 네트워크 대기 시간을 줄일 수 있습니다. Azure는 계층 간의 짧은 대기 시간 연결을 보장하기 위해 VNet(가상 네트워크) 피어링 또는 ExpressRoute와 같은 다양한 네트워킹 옵션 및 서비스를 제공합니다.
운영 체제 고려 사항: Process Scheduler에 특히 Windows 운영 체제가 필요한 경우 Azure Virtual Machines에서 실행할 수 있습니다. Azure는 다양한 Windows Server 버전을 지원하므로 애플리케이션의 요구 사항을 충족하는 버전을 선택할 수 있습니다.
아키텍처 평가: 확장성, 가용성 및 성능을 포함하여 아키텍처 요구 사항을 신중하게 평가합니다. 고가용성 및 확장성을 보장하려면 부하 분산된 구성에서 여러 애플리케이션 서버 인스턴스를 설정하는 것이 좋습니다.
데이터베이스 계층 - 주 데이터베이스와 보조 데이터베이스에 복제된 데이터베이스는 하나의 데이터 센터 내에 있어야 합니다. 동기 구성을 사용해야 합니다. 데이터 센터 간에 애플리케이션을 설치하는 경우 비동기 모드에서 Data Guard를 구성해야 합니다.
다음 단계