Google Cloud에서 Oracle Exadata를 사용하는 Compute Engine VM의 엔터프라이즈 애플리케이션

Last reviewed 2024-09-30 UTC

이 문서에서는 Google Cloud에서 실행되는 Oracle Cloud Infrastructure(OCI) Exadata 데이터베이스에 대한 지연 시간이 짧은 연결을 통해 Compute Engine 가상 머신 (VM)에서 호스팅되는 고가용성 엔터프라이즈 애플리케이션의 참조 아키텍처를 제공합니다. 이 문서는 클라우드 설계자와 Oracle 데이터베이스 관리자를 대상으로 합니다. 이 문서에서는 Compute Engine 및 Oracle Exadata Database Service에 익숙하다고 가정합니다.

Oracle Exadata 또는 Oracle Real Application Clusters (Oracle RAC)를 사용하여 온프레미스에서 Oracle 데이터베이스를 실행하는 경우 애플리케이션을 Google Cloud로 효율적으로 이전하고 Oracle Database@Google Cloud에서 데이터베이스를 실행할 수 있습니다. Oracle Database@Google Cloud는 Google Cloud 내에서 직접 Oracle Exadata Database ServiceOracle Autonomous Database를 실행할 수 있는 Google Cloud Marketplace 제품입니다.

Oracle RAC 기능이 필요하지 않거나 19c 및 23ai가 아닌 Oracle 데이터베이스 버전이 필요한 경우 Compute Engine VM에서 자체 관리형 Oracle 데이터베이스를 실행할 수 있습니다. 자세한 내용은 Compute Engine에서 Oracle Database를 사용하는 엔터프라이즈 애플리케이션을 참고하세요.

아키텍처

다음 다이어그램은 아키텍처의 대략적인 뷰를 보여줍니다.

Oracle Database@Google Cloud를 사용하는 아키텍처의 개요입니다.

위의 다이어그램에서 외부 부하 분산기는 공개 애플리케이션 사용자의 요청을 수신하고 프런트엔드 웹 서버에 요청을 배포합니다. 웹 서버는 내부 부하 분산기를 통해 사용자 요청을 애플리케이션 서버로 전달합니다. 애플리케이션 서버는 Oracle Database@Google Cloud의 데이터베이스에서 데이터를 읽고 쓰고 관리자와 OCI 서비스는 Oracle 데이터베이스에 연결하고 상호작용할 수 있습니다.

다음 다이어그램은 아키텍처를 세부적으로 보여줍니다.

Oracle Database@Google Cloud를 사용하는 아키텍처의 세부 뷰

이 아키텍처에서 웹 계층과 애플리케이션 계층은 Google Cloud 리전 내 두 영역에 분산된 Compute Engine VM에서 활성-활성 모드로 실행됩니다. 애플리케이션은 동일한 Google Cloud 리전의 Oracle Exadata 데이터베이스를 사용합니다.

아키텍처의 모든 구성요소가 단일 Google Cloud 리전에 있습니다. 이 아키텍처는 리전 배포 원형에 따라 정렬됩니다. 멀티 리전 배포 원형을 사용하여 지역 중단에 강력한 토폴로지를 빌드하도록 이 아키텍처를 조정할 수 있습니다. 자세한 내용은 Compute Engine의 멀티 리전 배포와 이 문서의 뒷부분에 나오는 안정성 섹션의 안내를 참고하세요.

위 다이어그램에 표시된 아키텍처에는 다음 구성요소가 포함됩니다.

구성요소 목적
리전 외부 애플리케이션 부하 분산기 리전 외부 애플리케이션 부하 분산기가 사용자 요청을 수신하여 웹 계층 VM에 배포합니다.
Google Cloud Armor 보안 정책 Google Cloud Armor 보안 정책은 DDoS 공격 및 교차 사이트 스크립팅(XSS)과 같은 위협으로부터 애플리케이션 스택을 보호하는 데 도움이 됩니다.
웹 계층의 리전 관리형 인스턴스 그룹 (MIG) 애플리케이션의 웹 계층은 리전 MIG의 일부인 Compute Engine VM에 배포됩니다. 이 MIG는 외부 애플리케이션 부하 분산기의 백엔드입니다. MIG에는 두 영역에 있는 Compute Engine VM이 포함됩니다. 이러한 각 VM은 애플리케이션 웹 계층의 독립 인스턴스를 호스팅합니다.
리전 내부 애플리케이션 부하 분산기 리전 내부 애플리케이션 부하 분산기는 웹 계층 VM의 트래픽을 애플리케이션 계층 VM으로 분산합니다.
애플리케이션 계층 리전 MIG Oracle WebLogic Server 클러스터와 같은 애플리케이션 계층은 리전 MIG의 일부인 Compute Engine VM에 배포됩니다. 이 MIG는 내부 애플리케이션 부하 분산기의 백엔드입니다. MIG에는 두 영역에 있는 Compute Engine VM이 포함됩니다. 각 VM은 애플리케이션 서버의 독립적인 인스턴스를 호스팅합니다.
Virtual Private Cloud (VPC) 네트워크서브넷 아키텍처의 모든 Google Cloud 리소스는 단일 VPC 네트워크를 사용합니다. 요구사항에 따라 여러 네트워크를 사용하는 아키텍처를 빌드할 수 있습니다. 자세한 내용은 여러 VPC 네트워크 생성 여부 결정을 참고하세요.
Oracle Database@Google Cloud

애플리케이션 서버는 Oracle Exadata Database Service의 Oracle 데이터베이스에서 데이터를 읽고 쓰고 Google Cloud 데이터 센터 내에서 Oracle이 관리하는 하드웨어에 Oracle 데이터베이스를 실행할 수 있는 클라우드 마켓플레이스 제품인 Oracle Database@Google Cloud를 사용하여 Oracle Exadata Database Service를 프로비저닝합니다.

Google Cloud 콘솔, Google Cloud CLI, API와 같은 Google Cloud 인터페이스를 사용하여 Exadata Infrastructure 인스턴스를 만듭니다. Oracle은 Google Cloud 리전 내 데이터 센터에서 프로젝트 전용 하드웨어를 사용하여 필요한 컴퓨팅, 스토리지, 네트워킹 인프라를 설정하고 관리합니다.

Exadata Infrastructure 인스턴스 각 Exadata Infrastructure 인스턴스에는 두 대 이상의 실제 데이터베이스 서버와 세 대 이상의 스토리지 서버가 포함됩니다. 다이어그램에 표시되지 않은 이러한 서버는 지연 시간이 짧은 네트워크 패브릭을 사용하여 상호 연결됩니다. Exadata 인프라 인스턴스를 만들 때 프로비저닝해야 하는 데이터베이스 서버 및 스토리지 서버 수를 지정합니다.
Exadata VM 클러스터

Exadata Infrastructure 인스턴스 내에서 하나 이상의 Exadata VM 클러스터를 만듭니다. 예를 들어 별도의 Exadata VM 클러스터를 만들고 사용하여 각 비즈니스 부서에 필요한 데이터베이스를 호스팅할 수 있습니다. 각 Exadata VM 클러스터에는 Oracle 데이터베이스 인스턴스를 호스팅하는 하나 이상의 Oracle Linux VM이 포함됩니다.

Exadata VM 클러스터를 만들 때 다음을 지정합니다.

  • 데이터베이스 서버 수입니다.
  • 클러스터의 각 VM에 할당할 컴퓨팅, 메모리, 스토리지 용량입니다.
  • 클러스터가 연결되어야 하는 VPC 네트워크입니다.
  • 클러스터의 백업 및 클라이언트 서브넷의 IP 주소 범위입니다.

Exadata VM 클러스터 내의 VM은 Compute Engine VM이 아닙니다.

Oracle Database 인스턴스 OCI 콘솔 및 기타 OCI 인터페이스를 통해 Oracle 데이터베이스를 만들고 관리합니다. Oracle 데이터베이스 소프트웨어는 Exadata VM 클러스터 내 VM에서 실행됩니다. Exadata VM 클러스터를 만들 때 Oracle Grid Infrastructure 버전을 지정합니다. 라이선스 유형(사용자 라이선스 사용(BYOL) 또는 라이선스 포함 모델)도 선택합니다.
OCI VCN 및 서브넷 Exadata VM 클러스터를 만들면 OCI 가상 클라우드 네트워크 (VCN)가 자동으로 생성됩니다. VCN에는 클라이언트 서브넷과 지정된 IP 주소 범위가 있는 백업 서브넷이 있습니다. 클라이언트 서브넷은 VPC 네트워크에서 Oracle 데이터베이스로의 연결에 사용됩니다. 백업 서브넷은 데이터베이스 백업을 OCI 객체 스토리지로 전송하는 데 사용됩니다.
Cloud Router, Partner Interconnect, OCI DRG VPC 네트워크와 VCN 간의 트래픽은 VPC에 연결된 Cloud Router에 의해 라우팅되며 VCN에 연결된 동적 라우팅 게이트웨이 (DRG)를 통해 전송됩니다. 트래픽은 Google에서 Partner Interconnect를 사용하여 설정하는 지연 시간이 짧은 연결을 통해 흐릅니다.
비공개 Cloud DNS 영역 Exadata VM 클러스터를 만들면 Cloud DNS 프라이빗 영역이 자동으로 생성됩니다. 애플리케이션 서버가 Oracle 데이터베이스에 읽기 및 쓰기 요청을 전송하면 Cloud DNS는 데이터베이스 호스트 이름을 해당 IP 주소로 확인합니다.
OCI 객체 스토리지OCI 서비스 게이트웨이 기본적으로 Oracle Exadata 데이터베이스의 백업은 OCI 객체 스토리지에 저장됩니다. 데이터베이스 백업은 서비스 게이트를 통해 OCI 객체 스토리지로 라우팅됩니다.
공개 Cloud NAT 게이트웨이 이 아키텍처에는 내부 IP 주소만 있는 Compute Engine VM에서 보안 아웃바운드 연결을 사용 설정하는 공개 Cloud NAT 게이트웨이가 포함되어 있습니다.
Cloud InterconnectCloud VPN 온프레미스 네트워크를 Google Cloud의 VPC 네트워크에 연결하려면 Cloud Interconnect 또는 Cloud VPN을 사용하면 됩니다. 각 접근 방식의 상대적 이점에 관한 자세한 내용은 네트워크 연결 제품 선택을 참고하세요.
Cloud Monitoring Cloud Monitoring을 사용하여 애플리케이션과 Oracle Exadata 리소스를 비롯한 Google Cloud 리소스의 동작, 상태, 성능을 관찰할 수 있습니다. OCI 모니터링 서비스를 사용하여 Oracle Exadata 리소스의 리소스를 모니터링할 수도 있습니다.

사용 제품

이 참조 아키텍처에는 다음과 같은 Google Cloud 제품이 사용됩니다.

  • Compute Engine: Google 인프라에서 가상 머신을 만들고 실행할 수 있는 안전하고 맞춤설정 가능한 컴퓨팅 서비스입니다.
  • Cloud Load Balancing: 확장 가능한 고성능 전역 및 리전 부하 분산기 포트폴리오입니다.
  • Virtual Private Cloud (VPC): Google Cloud 워크로드에 확장 가능한 전역 네트워킹 기능을 제공하는 가상 시스템입니다. VPC에는 VPC 네트워크 피어링, Private Service Connect, 비공개 서비스 액세스, 공유 VPC가 포함됩니다.
  • Google Cloud Armor: 웹 애플리케이션 방화벽 (WAF) 규칙을 제공하고 DDoS 및 애플리케이션 공격으로부터 보호하는 데 도움이 되는 네트워크 보안 서비스입니다.
  • Cloud NAT: Google Cloud에서 관리하는 고성능 네트워크 주소 변환을 제공하는 서비스입니다.
  • Cloud Monitoring: 애플리케이션 및 인프라의 성능, 가용성, 상태에 관한 정보를 제공하는 서비스입니다.
  • Cloud Interconnect: 지연 시간이 짧은 고가용성 연결을 통해 외부 네트워크를 Google 네트워크로 확장하는 서비스입니다.
  • Partner Interconnect: 지원되는 서비스 제공업체를 통해 온프레미스 네트워크와 가상 프라이빗 클라우드 네트워크 및 기타 네트워크 간의 연결을 제공하는 서비스입니다.
  • Cloud VPN: IPsec VPN 터널을 통해 피어 네트워크를 Google 네트워크로 안전하게 확장하는 서비스입니다.

이 참조 아키텍처에는 다음과 같은 OCI 제품이 사용됩니다.

  • 전용 인프라의 Exadata Database Service: 전용 Exadata 하드웨어에서 Oracle 데이터베이스 인스턴스를 실행할 수 있는 서비스입니다.
  • 객체 스토리지: 대량의 구조화된 데이터와 비정형 데이터를 객체로 저장하는 서비스입니다.
  • VCN 및 서브넷: VCN은 OCI 리전의 리소스를 위한 가상 및 비공개 네트워크입니다. 서브넷은 VCN이 있는 연속적인 IP 주소 범위입니다.
  • 동적 라우팅 게이트웨이: VCN과 외부 네트워크 간의 트래픽을 위한 가상 라우터입니다.
  • 서비스 게이트웨이: VCN의 리소스가 특정 Oracle 서비스에 비공개로 액세스할 수 있는 게이트웨이입니다.

설계 고려사항

이 섹션에서는 이 참조 아키텍처를 사용하여 보안, 안정성, 운영 효율성, 비용, 성능에 대한 특정 요구사항을 충족하는 토폴로지를 개발할 때 고려해야 하는 설계 요소, 권장사항, 설계 권장사항을 설명합니다.

이 섹션의 안내는 일부일 뿐 모든 내용을 포함하지는 않습니다. 애플리케이션의 특정 요구사항과 사용하는 Google Cloud 및 서드 파티 제품 및 기능에 따라 고려해야 할 추가 설계 요소와 장단점이 있을 수 있습니다.

시스템 설계

이 섹션에서는 배포에 사용할 Google Cloud 리전을 선택하고 적절한 Google Cloud 서비스를 선택하는 데 도움이 되는 안내를 제공합니다.

리전 선택

배포할 Google Cloud 리전을 선택할 때는 다음 요소와 요구사항을 고려하세요.

  • 각 리전에서 Google Cloud 서비스 사용 가능성. 자세한 내용은 위치별 제공 제품을 참조하세요.
  • 각 리전에서 Compute Engine 머신 유형 사용 가용성. 자세한 내용은 리전 및 영역을 참조하세요.
  • 각 리전에서 Oracle Database@Google Cloud 사용 가능 여부 자세한 내용은 사용 가능한 구성을 참고하세요.
  • 최종 사용자 지연 시간 요구사항
  • Google Cloud 리소스 비용
  • 규제 기관 요구사항

이러한 요소와 요구사항 중 일부는 장단점과 관련될 수 있습니다. 예를 들어 가장 경제적인 리전에는 탄소 발자국이 가장 적을 수 있습니다. 자세한 내용은 Compute Engine 리전 선택 권장사항을 참고하세요.

컴퓨팅 인프라

이 문서의 참조 아키텍처는 Compute Engine VM을 사용하여 웹 계층과 애플리케이션 계층을 호스팅합니다. 애플리케이션 요구사항에 따라 다음과 같은 다른 Google Cloud 컴퓨팅 서비스 중에서 선택할 수 있습니다.

  • 컨테이너: Google Kubernetes Engine (GKE) 클러스터에서 컨테이너화된 애플리케이션을 실행할 수 있습니다. GKE는 컨테이너화된 애플리케이션의 배포, 확장, 관리를 자동화하는 컨테이너 조정 엔진입니다.
  • 서버리스: 인프라 리소스 설정 및 운영 대신 데이터와 애플리케이션에 대한 IT 노력에 집중하려는 경우 Cloud RunCloud Run 함수와 같은 서버리스 서비스를 사용할 수 있습니다.

VM, 컨테이너 또는 서버리스 서비스 사용 여부 결정에는 구성 유연성과 관리 노력 간의 균형이 맞아야 합니다. VM 및 컨테이너는 더 많은 구성 유연성과 제어 기능을 제공하지만 개발자가 리소스를 관리해야 합니다. 서버리스 아키텍처에서는 최소한의 관리 노력이 필요한 사전 구성된 플랫폼에 워크로드를 배포합니다. 이러한 서비스에 대한 설계 안내는 이 문서에서 다루지 않습니다. 서비스 옵션에 관한 자세한 내용은 Google Cloud에서 애플리케이션 호스팅을 참고하세요.

스토리지 옵션

웹 계층 및 애플리케이션 계층의 Compute Engine VM에 영구 스토리지를 제공하려면 애플리케이션의 용량, 확장, 가용성, 성능 요구사항에 따라 적절한 영구 디스크 또는 Google Cloud 하이퍼디스크 유형을 선택합니다. 자세한 내용은 스토리지 옵션을 참조하세요.

리전 내 영역 간에 중복된 저비용 스토리지가 필요한 경우 Cloud Storage 리전 버킷을 사용하세요.

웹 계층의 모든 VM에 대한 구성 파일과 같이 한 리전의 여러 VM 간에 공유되는 데이터를 저장하려면 Filestore Regional 인스턴스를 사용하면 됩니다. Filestore Regional 인스턴스에 저장하는 데이터는 리전 내 영역 3개에 동기식으로 복제됩니다. 이 복제를 사용하면 Filestore에 저장된 데이터의 고가용성을 보장하고 영역 서비스 중단에 대한 견고성을 보장할 수 있습니다. 공유 구성 파일, 일반적인 도구 및 유틸리티, 중앙 집중식 로그를 Filestore 인스턴스에 저장하고 인스턴스를 여러 VM에 마운트할 수 있습니다.

워크로드용 스토리지를 설계할 때는 워크로드의 기능적 특성, 복원력 요구사항, 성능 기대치, 비용 목표를 고려합니다. 자세한 내용은 클라우드 워크로드에 최적화된 스토리지 전략 설계를 참고하세요.

네트워크 설계

멀티 티어 애플리케이션 스택의 인프라를 빌드할 때는 비즈니스 및 기술 요구사항을 충족하는 네트워크 설계를 선택해야 합니다. 이 문서에 표시된 아키텍처는 단일 VPC 네트워크가 있는 간단한 네트워크 토폴로지를 사용합니다. 요구사항에 따라 여러 네트워크를 사용할 수 있습니다. 자세한 내용은 다음 문서를 참조하세요.

Exadata VM 클러스터에 사용할 클라이언트 및 백업 서브넷의 IP 주소 범위를 할당할 때는 최소 서브넷 크기 요구사항을 고려하세요. 자세한 내용은 Oracle Database@Google Cloud의 IP 주소 공간 계획을 참고하세요.

데이터베이스 마이그레이션

온프레미스 데이터베이스를 Oracle Database@Google Cloud로 마이그레이션할 계획이라면 데이터베이스 마이그레이션 평가 (DMA) 도구를 사용하여 현재 데이터베이스 환경을 평가하고 구성 및 크기 조정 권장사항을 확인하세요.

온프레미스 데이터를 Google Cloud의 Oracle 데이터베이스 배포로 마이그레이션하려면 Oracle GoldenGate와 같은 표준 Oracle 도구를 사용하면 됩니다.

프로덕션 환경에서 이전된 데이터베이스를 사용하기 전에 애플리케이션과 데이터베이스 간의 연결을 확인합니다.

보안

이 섹션에서는 이 참조 아키텍처를 사용하여 Google Cloud에서 워크로드의 보안 및 규정 준수 요구사항을 충족하는 토폴로지를 설계할 때 고려해야 하는 요소를 설명합니다.

외부 위협으로부터 보호

DDoS 공격 및 XSS와 같은 외부 위협으로부터 애플리케이션을 보호하려면 요구사항에 따라 적절한 Google Cloud Armor 보안 정책을 정의합니다. 각 정책은 평가할 조건과 조건이 충족될 때 취할 조치를 지정하는 일련의 규칙입니다. 예를 들어 규칙에서 들어오는 트래픽의 소스 IP 주소가 특정 IP 주소나 CIDR 범위와 일치하는 경우 트래픽이 거부되도록 지정할 수 있습니다. 사전 구성된 WAF 규칙을 적용할 수도 있습니다. 자세한 내용은 보안 정책 개요를 참조하세요.

VM의 외부 액세스

이 문서에서 설명하는 참조 아키텍처에서 웹 계층과 애플리케이션 계층을 호스팅하는 VM은 인터넷의 직접 인바운드 액세스가 필요하지 않습니다. 이러한 VM에 외부 IP 주소를 할당하지 마세요. 비공개 내부 IP 주소만 있는 Google Cloud 리소스는 Private Service Connect 또는 비공개 Google 액세스를 사용하여 특정 Google API 및 서비스에 계속 액세스할 수 있습니다. 자세한 내용은 서비스 비공개 액세스 옵션을 참고하세요.

이 참조 아키텍처의 Compute Engine VM과 같이 비공개 IP 주소만 있는 Google Cloud 리소스에서 보안 아웃바운드 연결을 사용 설정하려면 위의 아키텍처 다이어그램과 같이 Cloud NAT를 사용하거나 보안 웹 프록시를 사용하면 됩니다.

Exadata VM에서 사용하는 서브넷의 경우 비공개 IP 주소 범위를 할당하는 것이 좋습니다.

VM 이미지 보안

승인된 이미지는 정책 또는 보안 요구사항을 충족하는 소프트웨어가 포함된 이미지입니다. 웹 계층 및 애플리케이션 계층의 VM에서 승인된 이미지만 사용하도록 하려면 특정 공개 이미지 프로젝트에서 이미지 사용을 제한하는 조직 정책을 정의하면 됩니다. 자세한 내용은 신뢰할 수 있는 이미지 정책 설정을 참고하세요.

서비스 계정 권한

Compute Engine API가 사용 설정된 Google Cloud 프로젝트에서는 기본 서비스 계정이 자동으로 생성됩니다. 2024년 5월 3일 전에 생성된 Google Cloud 조직의 경우 이 동작이 사용 중지되지 않는 한 이 기본 서비스 계정에 편집자 IAM 역할 (roles/editor)이 부여됩니다.

기본적으로 기본 서비스 계정은 gcloud CLI 또는 Google Cloud 콘솔을 사용하여 만드는 모든 Compute Engine VM에 연결됩니다. 편집자 역할에는 다양한 권한이 포함되므로 기본 서비스 계정을 VM에 연결하면 보안 위험이 발생합니다. 이 위험을 방지하려면 애플리케이션 스택의 각 계층에 전용 서비스 계정을 만들고 사용하면 됩니다. 서비스 계정에서 액세스할 수 있는 리소스를 지정하려면 세분화된 정책을 사용합니다. 자세한 내용은 서비스 계정 권한 제한을 참고하세요.

네트워크 보안

아키텍처의 웹 티어와 애플리케이션 티어의 리소스 간에 네트워크 트래픽을 제어하려면 적절한 Cloud 차세대 방화벽 (NGFW) 정책을 구성해야 합니다.

데이터베이스 보안 및 규정 준수

Exadata Database 서비스에는 Oracle 데이터베이스의 보안 및 규정 준수 요구사항을 관리하는 데 도움이 되는 Oracle Data Safe가 포함되어 있습니다. Oracle Data Safe를 사용하여 보안 제어를 평가하고, 사용자 활동을 모니터링하고, 민감한 데이터를 마스킹할 수 있습니다. 자세한 내용은 Oracle Data Safe로 데이터베이스 보안 관리를 참고하세요.

추가 보안 고려사항

워크로드의 아키텍처를 빌드할 때는 엔터프라이즈 기반 청사진에서 제공하는 플랫폼 수준 보안 권장사항과 추천을 고려하세요.

안정성

이 섹션에서는 이 참조 아키텍처를 사용하여 Google Cloud 배포를 위한 안정적인 인프라를 빌드하고 운영할 때 고려해야 하는 설계 요소를 설명합니다.

VM 오류에 대한 견고성

이 문서에 표시된 아키텍처에서 웹 계층 또는 애플리케이션 계층의 Compute Engine VM이 충돌하면 관련 MIG가 VM을 자동으로 다시 만듭니다. 부하 분산기는 현재 사용 가능한 웹 서버 인스턴스와 애플리케이션 서버 인스턴스만으로 요청을 전달합니다.

VM 자동 복구

간혹 웹 계층 및 애플리케이션 계층을 호스팅하는 VM이 실행 중이고 사용 가능할 수 있지만 애플리케이션 자체에 문제가 있을 수 있습니다. 애플리케이션이 중단, 비정상 종료가 발생하거나 메모리가 부족할 수 있습니다. 이 시나리오에서 VM은 부하 분산기 상태 확인에 응답하지 않으며 부하 분산기는 응답하지 않는 VM으로 트래픽을 라우팅하지 않습니다. 애플리케이션이 예상대로 응답하도록 하려면 MIG의 자동 복구 정책의 일부로 애플리케이션 기반 상태 점검을 구성하면 됩니다. 특정 VM의 애플리케이션이 응답하지 않으면 MIG에서 VM을 자동 복구 (수리)합니다. 자동 복구 구성에 관한 자세한 내용은 고가용성을 위한 VM 복구 정보를 참고하세요.

리전 중단에 대한 견고성

리전 중단이 발생하면 애플리케이션을 사용할 수 없습니다. 지역 서비스 중단으로 인한 다운타임을 줄이려면 다음 접근 방식을 구현하면 됩니다.

  • 다른 Google Cloud 리전에서 웹 계층 및 애플리케이션 계층의 수동 (장애 조치) 복제본을 유지합니다.
  • 애플리케이션 스택의 패시브 복제본이 있는 동일한 리전에 필요한 Exadata VM 클러스터로 스탠바이 Exadata 인프라 인스턴스를 만듭니다. 데이터 복제 및 대기 Exadata 데이터베이스로의 자동 장애 조치를 위해 Oracle Data Guard를 사용합니다. 애플리케이션에 더 낮은 복구 지점 목표(RPO)가 필요한 경우 Oracle Autonomous Recovery Service를 사용하여 데이터베이스를 백업하고 복구할 수 있습니다.
  • 기본 리전에서 중단이 발생하면 데이터베이스 복제본 또는 백업을 사용하여 데이터베이스를 프로덕션으로 복원하고 장애 조치 리전에서 애플리케이션을 활성화합니다.
  • DNS 라우팅 정책을 사용하여 장애 조치 리전의 외부 부하 분산기로 트래픽을 라우팅합니다.

리전 중단이 발생해도 계속 사용할 수 있어야 하는 비즈니스 관련 중요도가 높은 애플리케이션의 경우 멀티 리전 배포 원형을 사용하는 것이 좋습니다. Oracle Active Data Guard를 사용하여 페일오버 리전에 읽기 전용 대기 데이터베이스를 제공할 수 있습니다.

Oracle은 Oracle Database@Google Cloud의 인프라를 관리합니다. 전용 인프라의 Oracle Exadata Database Service에 대한 서비스 수준 목표 (SLO)에 관한 자세한 내용은 Oracle PaaS 및 IaaS 퍼블릭 클라우드 서비스의 서비스 수준 목표를 참고하세요.

MIG 자동 확장

이 문서의 아키텍처는 웹 계층과 애플리케이션 계층에 리전 MIG를 사용합니다. 스테이트리스(Stateless) MIG의 자동 확장 기능을 사용하면 웹 계층과 애플리케이션 계층을 호스팅하는 Compute Engine VM이 단일 영역 중단의 영향을 받지 않습니다. 스테이트풀(Stateful) MIG를 자동 확장할 수 없습니다.

MIG의 자동 확장 동작을 제어하려면 평균 CPU 사용률과 같은 대상 사용률 측정항목을 지정하면 됩니다. 일정 기반 자동 확장을 구성할 수도 있습니다. 자세한 내용은 인스턴스 그룹 자동 확장을 참조하세요.

VM 배치

이 문서에서 설명하는 아키텍처에서 애플리케이션 계층과 웹 계층은 여러 영역에 분산된 Compute Engine VM에서 실행됩니다. 이러한 분산은 단일 영역 중단에 대해 웹 계층과 애플리케이션 계층의 견고성을 보장하는 데 도움이 됩니다. 이러한 견고성을 더욱 향상시키려면 분산 배치 정책을 만들고 MIG 템플릿에 적용하면 됩니다. 분산 배치 정책을 사용하면 MIG에서 VM을 만들 때 각 영역 내의 VM을 여러 물리적 서버 (호스트라고 함)에 배치하므로 VM이 개별 호스트 오류에 대해 견고합니다. 그러나 이 접근 방식의 단점은 VM 간 네트워크 트래픽의 지연 시간이 늘어날 수 있다는 점입니다. 자세한 내용은 게재위치 정책 개요를 참고하세요.

VM 용량 계획

MIG 자동 확장에 필요한 경우 Compute Engine VM의 용량을 사용할 수 있도록 보장하기 위해서는 예약을 만들면 됩니다. 예약을 사용하면 특정 영역에서 선택한 머신 유형에 지정된 VM 수에 따라 일정 용량을 보장할 수 있습니다. 예약은 프로젝트에 따라 다르게 지정할 수 있고 여러 프로젝트 간에 공유할 수 있습니다. 리소스가 프로비저닝되거나 사용되지 않더라도 예약된 리소스에 대한 요금이 발생합니다. 결제 고려사항을 포함하여 예약에 대한 자세한 내용은 Compute Engine 영역별 리소스 예약을 참고하세요.

스테이트풀(Stateful) 스토리지

애플리케이션 설계에서 권장사항은 스테이트풀(Stateful) 로컬 디스크가 필요하지 않도록 하는 것입니다. 하지만 요구사항이 있는 경우 VM을 복구하거나 다시 만들 때 데이터가 보존되도록 디스크를 스테이트풀(Stateful)로 구성할 수 있습니다. 하지만 새 버전이고 보안 패치가 적용된 최신 이미지로 영구 디스크를 간편하게 업데이트할 수 있도록 부팅 디스크를 스테이트리스(Stateless)로 유지하는 것이 좋습니다. 자세한 내용은 MIG에서 스테이트풀(Stateful) 영구 디스크 구성을 참조하세요.

데이터베이스 용량

필요에 따라 데이터베이스 서버와 스토리지 서버를 추가하여 Exadata 인프라를 확장할 수 있습니다. Exadata 인프라에 필요한 데이터베이스 서버 또는 스토리지 서버를 추가한 후 추가 CPU 또는 스토리지 리소스를 사용할 수 있도록 연결된 Exadata VM 클러스터에 용량을 추가해야 합니다. 자세한 내용은 Exadata 컴퓨팅 및 스토리지 확장을 참고하세요.

백업 및 복구

백업 및 DR 서비스를 사용하여 Compute Engine VM의 백업을 생성, 저장, 관리할 수 있습니다. 백업 및 DR 서비스는 백업 데이터를 애플리케이션에서 읽을 수 있는 원본 형식으로 저장합니다. 필요한 경우 시간이 많이 소요되는 데이터 이동이나 준비 활동 없이 장기 백업 스토리지에서 데이터를 직접 사용하여 워크로드를 프로덕션으로 복원할 수 있습니다. 자세한 내용은 Compute Engine 인스턴스 백업을 위한 백업 및 DR 서비스를 참고하세요.

기본적으로 전용 인프라의 Oracle Exadata Database Service에 있는 데이터베이스의 백업은 OCI 객체 스토리지에 저장됩니다. 더 낮은 RPO를 달성하려면 Oracle Autonomous Recovery Service를 사용하여 데이터베이스를 백업하고 복구하면 됩니다.

추가 신뢰성 고려사항

워크로드의 클라우드 아키텍처를 빌드할 때는 다음 문서에서 제공하는 신뢰성 관련 권장사항과 추천을 검토합니다.

비용 최적화

이 섹션에서는 이 참조 아키텍처를 사용하여 빌드하는 Google Cloud 토폴로지의 설정 및 운영 비용을 최적화하는 방법을 안내합니다.

VM 머신 유형

VM의 사용률을 최적화하는 데 도움이 되도록 Compute Engine은 머신 유형 권장사항을 제공합니다. 권장사항에 따라 웹 계층 및 애플리케이션 계층 VM의 컴퓨팅 요구사항과 일치하는 머신 유형을 선택합니다. 예측 가능한 리소스 요구사항이 있는 워크로드의 경우 커스텀 머신 유형을 사용하여 머신 유형을 필요에 맞게 맞춤설정하고 비용을 절약할 수 있습니다.

VM 프로비저닝 모델

애플리케이션이 내결함성인 경우 스팟 VM을 사용하면 웹 계층 및 애플리케이션 계층의 VM에 대한 Compute Engine 비용을 줄일 수 있습니다. 스팟 VM 비용은 일반 VM보다 훨씬 저렴합니다. 하지만 Compute Engine에서 스팟 VM을 사전에 중지하거나 삭제하여 용량을 확보할 수 있습니다.

스팟 VM은 선점을 허용할 수 있고 고가용성 요구사항이 없는 일괄 작업에 적합합니다. 스팟 VM은 일반 VM과 동일한 머신 유형, 옵션, 성능을 제공합니다. 하지만 영역의 리소스 용량이 제한되면 MIG는 필요한 용량을 다시 사용할 수 있게 될 때까지 지정된 대상 크기로 자동으로 수평 확장(즉, VM 만들기)하지 못할 수 있습니다.

VM 리소스 사용률

스테이트리스(Stateless) MIG의 자동 확장 기능을 사용하면 애플리케이션에서 웹 계층 및 애플리케이션 계층의 트래픽 증가를 원활하게 처리할 수 있습니다. 또한 자동 확장을 사용하면 리소스 수요가 적을 때 비용을 절감할 수 있습니다. 스테이트풀(Stateful) MIG를 자동 확장할 수 없습니다.

데이터베이스 비용

Exadata VM 클러스터를 만들 때 BYOL을 선택하거나 라이선스가 포함된 Oracle 데이터베이스를 프로비저닝할 수 있습니다.

동일한 리전에 있는 애플리케이션과 Oracle Exadata 데이터베이스 간의 데이터 전송에 대한 네트워킹 요금은 Oracle Database@Google Cloud 제품 가격에 포함되어 있습니다.

추가 비용 고려사항

워크로드의 아키텍처를 빌드할 때는 Google Cloud 아키텍처 프레임워크: 비용 최적화에서 제공하는 일반 권장사항과 추천도 고려하세요.

운영 효율성

이 섹션에서는 이 참조 아키텍처를 사용하여 효율적으로 운영할 수 있는 Google Cloud 토폴로지를 설계할 때 고려해야 하는 요소를 설명합니다.

VM 구성 업데이트

MIG의 VM 구성 (예: 머신 유형 또는 부팅 디스크 이미지)을 업데이트하려면 필수 구성으로 새 인스턴스 템플릿을 만든 후 새 템플릿을 MIG에 적용합니다. MIG는 자동 업데이트 또는 선택적 업데이트 방법을 통해 VM을 업데이트합니다. 가용성 및 운영 효율성 요구사항에 따라 적절한 방법을 선택합니다. 이러한 MIG 업데이트 방법에 대한 자세한 내용은 MIG에서 새 VM 구성 적용을 참조하세요.

VM 이미지

MIG 인스턴스 템플릿의 경우 Google에서 제공하는 공개 이미지를 사용하는 대신 애플리케이션에 필요한 구성과 소프트웨어가 포함된 커스텀 OS 이미지를 만들고 사용하는 것이 좋습니다. 커스텀 이미지를 커스텀 이미지 계열로 그룹화할 수 있습니다. 이미지 계열은 항상 계열 내에 있는 최신 이미지를 가리키므로 인스턴스 템플릿과 스크립트에서 특정 이미지 버전에 대한 참조를 업데이트하지 않아도 최신 이미지를 사용할 수 있습니다. OS 공급업체에서 제공하는 보안 업데이트 및 패치를 포함하도록 맞춤 이미지를 정기적으로 업데이트해야 합니다.

확정 인스턴스 템플릿

MIG에 사용하는 인스턴스 템플릿에 시작 스크립트(예: 서드 파티 소프트웨어 설치)가 포함된 경우 스크립트에서 소프트웨어 버전과 같은 소프트웨어 설치 매개변수를 명시적으로 지정해야 합니다. 그렇지 않으면 MIG에서 VM을 만들 때 VM에 설치된 소프트웨어가 일관되지 않을 수 있습니다. 예를 들어 인스턴스 템플릿에 Apache HTTP 서버 2.0(apache2 패키지)을 설치할 수 있는 시작 스크립트가 포함된 경우 스크립트에서 설치해야 하는 apache2 버전(예: 2.4.53)을 정확하게 지정해야 합니다. 자세한 내용은 확정 인스턴스 템플릿을 참조하세요.

데이터베이스 관리

Oracle은 전용 인프라의 Oracle Exadata Database Service에서 물리적 데이터베이스 서버, 스토리지 서버, 네트워킹 하드웨어를 관리합니다. OCI 또는 Google Cloud 인터페이스를 통해 Exadata Infrastructure 인스턴스와 Exadata VM 클러스터를 관리할 수 있습니다. OCI 인터페이스를 통해 데이터베이스를 만들고 관리합니다. Oracle Database@Google Cloud의 Google Cloud 콘솔 페이지에는 OCI 콘솔의 관련 페이지로 바로 이동하는 데 사용할 수 있는 링크가 포함되어 있습니다. OCI에 다시 로그인하지 않아도 되도록 하려면 OCI와 Google Cloud 간에 ID 제휴를 구성하면 됩니다.

추가 운영 고려사항

워크로드의 아키텍처를 빌드할 때 Google Cloud 아키텍처 프레임워크: 운영 우수성에 설명된 운영 효율성에 대한 일반적인 권장사항과 추천을 고려하세요.

성능 최적화

이 섹션에서는 이 참조 아키텍처를 사용하여 Google Cloud에서 워크로드의 성능 요구사항을 충족하는 토폴로지를 설계할 때 고려해야 하는 요소를 설명합니다.

컴퓨팅 성능

Compute Engine은 워크로드의 성능 요구사항에 따라 다양한 사전 정의되고 맞춤설정 가능한 머신 유형을 제공합니다. 웹 계층과 애플리케이션 계층을 호스팅하는 VM의 경우 해당 계층의 성능 요구사항에 따라 적절한 머신 유형을 선택합니다. 자세한 내용은 머신 시리즈 비교를 참고하세요.

네트워크 성능

애플리케이션 및 웹 계층 내에서 VM 간 네트워크 지연 시간을 줄여야 하는 워크로드의 경우 압축 배치 정책을 만들고 해당 계층에 사용되는 MIG 템플릿에 적용할 수 있습니다. MIG에서 VM을 만들 때 서로 가까운 물리적 서버에 배치합니다. 압축 배치 정책은 VM 간 네트워크 성능을 개선하는 데 도움이 되지만, 분산 배치 정책은 앞서 설명한 대로 VM 가용성을 개선하는 데 도움이 될 수 있습니다. 네트워크 성능과 가용성 간에 최적의 균형을 이루려면 압축 배치 정책을 만들 때 VM을 배치해야 하는 거리를 지정할 수 있습니다. 자세한 내용은 게재위치 정책 개요를 참고하세요.

Compute Engine에는 이그레스 네트워크 대역폭에 대한 VM별 한도가 있습니다. 이 한도는 VM의 머신 유형과 트래픽이 소스 VM과 동일한 VPC 네트워크를 통해 라우팅되는지에 따라 다릅니다. 특정 머신 유형의 VM의 경우 네트워크 성능을 개선하기 위해 Tier_1 네트워킹을 사용 설정하여 더 높은 최대 이그레스 대역폭을 얻을 수 있습니다. 자세한 내용은 VM당 Tier_1 네트워킹 성능 구성을 참고하세요.

애플리케이션 계층 VM과 Oracle Exadata 네트워크 간의 네트워크 트래픽은 Google에서 설정하는 지연 시간이 짧은 파트너 Interconnect 연결을 통해 라우팅됩니다.

Exadata 인프라는 데이터베이스 서버와 스토리지 서버 간의 고대역폭 및 짧은 지연 시간 네트워킹을 위해 통합 이더넷을 통한 RDMA (RoCE)를 사용합니다. 서버는 프로세서, 캐시 또는 운영체제를 사용하지 않고 기본 메모리에서 직접 데이터를 교환합니다.

추가 성능 고려사항

워크로드의 아키텍처를 빌드할 때 Google Cloud 아키텍처 프레임워크: 성능 최적화에서 제공하는 일반적인 권장사항과 추천을 고려하세요.

다음 단계

참여자

저자: Kumar Dhanagopal | 크로스 프로덕트 솔루션 개발자

기타 참여자: