마이그레이션된 MongoDB 워크로드를 Oracle Autonomous Transaction Processing Serverless@Azure에 배포
문서 및 문서 데이터베이스를 사용하여 데이터 스키마 및 애플리케이션을 발전시키는 워크로드 및 애플리케이션은 개발자에게 제공하는 유연성 때문에 널리 사용됩니다. 스키마 유연성, 신속한 개발 및 확장성을 통해 애플리케이션 기능의 프로토타이핑 가속화, 손쉬운 애플리케이션 개발, 대규모 사용자 기반을 처리하기 위해 개발자가 확장할 수 있는 반복적으로 작은 애플리케이션 및 기능을 구축할 수 있습니다. 그러나 이러한 유형의 워크로드에는 약한 트랜잭션 보증, 데이터 쿼리 다기능성, 분석 또는 머신 러닝과 같은 문서에서 다른 워크로드를 지원할 수 없는 등 당면 과제가 있습니다.
이러한 워크로드가 기존 문서 데이터베이스의 장점을 활용하고 관계형 데이터베이스의 이점을 활용할 수 있다면 어떨까요? 예를 들어, 데이터를 다른 데이터베이스나 시스템에 복제할 필요 없이 분석 및 머신 러닝과 같은 강력한 트랜잭션 보장 및 추가 기능을 사용할 수 있습니다.
Autonomous Transaction Processing(ATP) Serverless는 트랜잭션, 분석 및 일괄 처리 워크로드를 동시에 실행하도록 최적화된 완전 자동화된 데이터베이스 서비스입니다. 성능을 가속화하기 위해 행 형식, 인덱스 및 데이터 캐싱용으로 사전 구성되어 있으며 확장성, 가용성, 투명한 보안 및 실시간 운영 애널리틱스를 제공합니다. 애플리케이션 개발자와 DBA는 기능이나 원자성, 일관성, 격리 및 내구성(ACID) 속성을 희생하지 않고도 빠르고 비용 효율적으로 애플리케이션을 개발하고 배포할 수 있습니다.
기능적 구조
이 아키텍처는 애플리케이션 및 MongoDB 데이터베이스가 포함된 워크로드가 온프레미스 또는 클라우드 배포 중 하나로 존재하며 Azure 및 Oracle Database@Azure로 마이그레이션될 것이라고 가정합니다. 이후 상태 구조, 이점, 배치 방법 및 기존 작업 로드를 보강하는 데 사용할 수 있는 추가 기능에 대해 설명합니다.
One of the key features used in this architecture is Oracle Database API for MongoDB, which enables applications to interact with collections of JSON documents in Oracle Database using MongoDB drivers, tools, and SDKs. 기존 애플리케이션 코드는 코드를 리팩토링하지 않고도 Oracle Autonomous Transaction Processing Serverless에 저장된 데이터를 사용할 수 있습니다.
다음 다이어그램은 데이터베이스, 백엔드 및 프런트엔드 계층으로 구성된 일반적인 애플리케이션을 보여줍니다.
mongodb-atp-s-azure-logical-arch-migration.zip
MEAN 스택은 이 패턴을 구현하는 데 사용되는 인기 있는 스택입니다.
- MongoDB: 문서 데이터베이스
- Express: 백엔드 프레임워크
- 각도: 프런트엔드 프레임워크
Node.js
: 백엔드 서비스
이 문서는 Azure 및 ATP Serverless로 마이그레이션될 기존 배포의 예로 MEAN 스택을 사용합니다.
이 워크로드를 Azure 및 ATP Serverless로 마이그레이션하는 작업은 간단하며 다음과 같은 단계들로 구성됩니다.
- ATP 서버리스 인스턴스를 배치하여 생성 시 Oracle Database MongoDB API를 사용으로 설정합니다.
- MongoDB에서 ATP Serverless로 메타데이터 및 데이터를 마이그레이션합니다.
- 애플리케이션 서버를 배포하여 Azure App Service, VM, 컨테이너 또는 Kubernetes를 사용하여 ATP Serverless와 동일한 리전 및 가용성 도메인에
Node.js
및 Express를 실행합니다. - 응용 프로그램 서버에 백엔드 응용 프로그램 코드를 배치합니다.
- 현재 응용 프로그램에서 사용되는 것과 동일한 MongoDB 도구 및 드라이버를 사용하여 백엔드 응용 프로그램을 ATP Serverless에 연결합니다.
- 사용자를 새 응용 프로그램 URI에 연결합니다.
이 참조 아키텍처는 마이그레이션 프로세스 자체가 아니라 마이그레이션된 워크로드의 배포에 중점을 둡니다. 마이그레이션 프로세스에 대한 자세한 내용은 자세히 살펴보기 섹션을 참조하십시오.
ATP Serverless로 워크로드를 마이그레이션한 후 기존 기능을 보강하는 데 사용할 수 있는 기능은 다음과 같습니다. 1) 손쉽게 확장성, 복원성 또는 고가용성 개선과 같은 추가적인 비기능적 요구사항 지원, 2) 데이터베이스에서 데이터를 복사할 필요 없이 운영 보고, 분석 및 머신 러닝과 같은 추가 기능 제공.
확장성과 고가용성을 향상시키려면 Autonomous Transaction Processing 서버리스 자동 스케일링 기능을 사용합니다. 한 번의 클릭 또는 API 호출을 통해 워크로드는 다운타임 없이 최대 3배의 기준 용량을 사용할 수 있습니다. Autonomous Transaction Processing Serverless는 고가용성을 위해 Oracle Real Application Clusters(Oracle RAC) 기술을 사용합니다. 백엔드 계층의 경우 Azure VM 스케일 세트(자동 스케일 설정 포함) 또는 PaaS 서비스(예: 자동 스케일링 설정 포함 앱 서비스)를 사용하여 애플리케이션의 고가용성 및 확장성을 지원합니다.
ATP Serverless는 다중 모델, 다중 워크로드 데이터베이스 기술을 기반으로 구축되므로 기존 애플리케이션과 함께 작동하는 관계형, 공간, 그래프 또는 벡터 데이터 유형에 의존하는 기능을 추가할 수 있습니다.
물리적 구조
물리적 아키텍처에는 고가용성을 지원하기 위해 2개의 Azure 리전에서 위임된 서브넷을 사용하여 배포된 Autonomous Transaction Processing Serverless가 포함됩니다. OCI 서비스는 Oracle Cloud Infrastructure Object Storage에 대한 자동 백업을 지원합니다.
이 아키텍처는 다음을 지원합니다.
- 프론트엔드 계층
- 응용 프로그램 사용자는 인터넷 또는 회사 네트워크에서 연결할 수 있습니다.
- 사용자 연결은 Azure Front Door를 사용하여 애플리케이션을 실행 중인 활성 영역으로 라우팅됩니다.
- 사용자 연결은 Azure 웹 애플리케이션 방화벽을 사용하여 보호됩니다.
- 앱 서비스를 사용하여 애플리케이션에 대한 사용자 접속이 로드 밸런싱됩니다.
- 백엔드 계층
- 애플리케이션은 Azure 앱 서비스를 사용하여 고가용성 방식으로 배포됩니다.
- Azure 앱 서비스 AutoScale는 수평 확장성을 달성하는 데 사용됩니다.
- 데이터베이스 티어
- ATP Serverless는 Oracle RAC(Oracle Real Application Clusters) 및 서비스 인스턴스의 기반이 되는 여러 데이터베이스 노드로서 고가용성을 제공합니다. 따라서 기본적으로 데이터베이스 계층은 가용성이 높고 탄력적입니다.
- ATP Serverless에서 사용으로 설정된 Oracle Database API for MongoDB를 사용하면 변경 없이 기존 애플리케이션 코드를 사용할 수 있습니다.
- Oracle Database API for MongoDB는 매우 탄력적이며 ATP Serverless를 통해 내부적으로 복원력이 보장됩니다.
- ATP Serverless는 자동 스케일링을 사용하여 시스템 로드 증가 및 감소에 맞게 조정할 수 있습니다.
- ATP 서버리스 비즈니스 연속성은 지역 간 자율운영 Data Guard를 통해 달성됩니다.
- 장애 복구
- 두번째 영역은 전체적인 복구 시간 목표를 줄이기 위해 유사한 토폴로지와 함께 배치됩니다.
- 웜 DR 전략을 사용하여 전체 RTO를 줄입니다. 웜 DR 전략에서 백엔드 계층 클라우드 리소스는 이미 ATP 서버리스 대기 데이터베이스와 함께 프로비저닝되었습니다.
- 또는 장애 발생 시 백엔드 계층 리소스를 프로비저닝하여 DR 리소스 실행 비용을 줄이지만 전체 RTO가 증가할 수 있습니다.
- 네트워킹
- 온프레미스 및 인터넷에서 수신되는 모든 애플리케이션 트래픽은 Azure Front Door에 의해 라우팅됩니다.
- ATP Serverless는 보안 상태를 높이기 위해 전용 엔드포인트와 함께 배포됩니다.
- Azure App Service Web App은 통합 서브넷과 VNet를 사용하여 ATP 서버리스 인스턴스에 배치됩니다.
- 애플리케이션 VNet는 데이터베이스 VNet와 피어링되며 웹 앱과 ATP 서버리스 간에 트래픽이 흐를 수 있습니다.
- 보안
- 모든 데이터는 전송 중 및 미사용 상태입니다.
다음과 같은 잠재적인 설계 개선 사항은 단순성을 위해 이 배포에 설명되어 있지 않습니다.
- Azure Automation 런북을 사용하여 애플리케이션 재해 복구를 자동화하여 전면 도어 엔드포인트를 전환하고 사후 페일오버 앱 상태를 검증합니다.
- 허브 및 스포크 토폴로지를 활용하여 중앙 집중식 네트워크 보안을 적용합니다.
- 허브 VNet에 배포된 네트워크 방화벽을 활용하여 모든 트래픽을 검사하고 정책을 적용하여 전반적인 보안 상태를 개선합니다.
mongodb-atp-s-azure-physical-arch.zip
아키텍처에는 다음과 같은 Microsoft 구성 요소가 있습니다.
- Azure 방화벽 관리자
Azure Firewall Manager is a centralized security management service that simplifies the deployment and configuration of Azure Firewall across multiple regions and subscriptions. 계층적 정책 관리를 통해 전역 및 로컬 방화벽 정책을 일관되게 적용할 수 있습니다. Azure Firewall Manager는 Azure Virtual WAN(vWAN) 및 보안 허브와 통합될 때 사용자 정의 경로 없이도 트래픽 라우팅 및 필터링을 자동화하여 보안을 강화합니다. 이러한 통합을 통해 가상 네트워크, 지사 및 인터넷 간의 트래픽을 안전하게 관리 및 모니터링하여 강력하고 간소화된 네트워크 보안 솔루션을 제공할 수 있습니다.
- Azure 전면 도어
Azure Front Door는 웹 애플리케이션을 위한 글로벌 진입점 역할을 하는 클라우드 기반 서비스로, 고성능 콘텐츠 전송, 지능형 Layer 7 로드 밸런싱, WAF(Web Application Firewall) 및 DDoS 보호와 같은 통합 보안 기능을 제공하여 빠르고 안정적이며 안전한 사용자 경험을 보장합니다.
- Azure 영역
Azure 리전은 가용성 영역이라고 하는 하나 이상의 물리적 Azure 데이터 센터가 상주하는 지리적 영역입니다. 지역은 다른 지역과 독립적이며, 광대한 거리는 (국가 또는 대륙에 걸쳐) 그들을 분리 할 수 있습니다.
Azure 및 OCI 리전은 지역화된 지리적 영역입니다. Oracle Database@Azure의 경우, Azure 리전이 OCI 리전에 연결되고, Azure의 가용성 영역(AZ)이 OCI의 가용성 도메인(AD)에 연결됩니다. Azure 및 OCI 리전 쌍은 거리 및 대기 시간을 최소화하기 위해 선택됩니다.
- Azure 가용성 영역
Azure availability zones are physically separate locations within an Azure region, designed to ensure high availability and resiliency by providing independent power, cooling, and networking.
- Azure 가상 네트워크(VNet)
Azure Virtual Network(VNet)는 Azure에서 개인 네트워크의 기본 구성 요소입니다. VNet를 사용하면 Azure VM(가상 머신)과 같은 다양한 유형의 Azure 리소스가 서로, 인터넷 및 온프레미스 네트워크와 안전하게 통신할 수 있습니다.
- Microsoft Azure 앱 서비스
Microsoft Azure App Service를 사용하면 기본 인프라를 관리하지 않고도 웹 애플리케이션, API 및 모바일 백엔드를 구축, 호스팅 및 확장할 수 있습니다.
- Azure App Service 통합 서브넷
앱 서비스 계획에서 사용하도록 특별히 위임된 Azure 가상 네트워크 내의 전용 서브넷으로, 웹 앱이 가상 네트워크 또는 피어링된 네트워크 내의 개인 리소스에 대한 아웃바운드 연결을 만들 수 있지만 VNet에서 인바운드 트래픽을 수신하지 않도록 합니다.
- Azure 위임 서브넷
위임된 서브넷을 사용하면 관리되는 서비스, 특히 서비스형 플랫폼(PaaS) 서비스를 리소스로 가상 네트워크에 직접 삽입할 수 있습니다. 가상 네트워크 내에서 외부 PaaS 서비스의 전체 통합 관리가 가능합니다.
이 구조에는 다음과 같은 Oracle 구성 요소가 있습니다.
- OCI 리전
OCI 리전은 가용성 도메인을 호스팅하는 데이터 센터가 하나 이상 포함된 지역화된 지리적 영역입니다. 지역은 다른 지역과 독립적이며, 광대한 거리는 (국가 또는 대륙에 걸쳐) 그들을 분리 할 수 있습니다.
- Oracle Autonomous Database
Oracle Autonomous Database는 트랜잭션 처리 및 데이터 웨어하우징 워크로드에 사용할 수 있는 완전 관리형 사전 구성 데이터베이스 환경입니다. 하드웨어를 구성 또는 관리하거나 소프트웨어를 설치할 필요가 없습니다. OCI는 데이터베이스의 생성, 백업, 패치 적용, 업그레이드 및 튜닝을 처리합니다.
- Oracle Autonomous Data Guard
Oracle Autonomous Data Guard는 대기(피어) 데이터베이스가 Autonomous Database 인스턴스에 대한 데이터 보호 및 재해 복구를 제공할 수 있게 해줍니다. It provides a comprehensive set of services that create, maintain, manage, and monitor one or more standby databases to enable production Oracle databases to remain available without interruption. Oracle Data Guard는 이러한 대기 데이터베이스를 운용 데이터베이스의 복사본으로 유지 관리합니다. 그런 다음 계획된 운용중단이나 계획되지 않은 운용중단으로 인해 운용 중인 데이터베이스를 사용할 수 없게 되면 모든 standby database를 운용 중인 롤로 전환하여 운용중단과 연관된 작동 중지 시간을 최소화할 수 있습니다.
- OCI 오브젝트 스토리지
OCI Object Storage는 데이터베이스 백업, 분석 데이터, 이미지 및 비디오와 같은 리치 콘텐츠 등 모든 콘텐츠 유형의 대량의 정형 및 비정형 데이터에 대한 액세스를 제공합니다. 애플리케이션 또는 클라우드 플랫폼 내에서 직접 안전하고 안전하게 데이터를 저장할 수 있습니다. 성능 또는 서비스 안정성이 저하되지 않고 스토리지를 확장할 수 있습니다.
신속하고 즉각적이며 자주 액세스하는 데 필요한 "핫" 스토리지에 표준 스토리지를 사용합니다. 장기간 보관하며 거의 또는 거의 액세스하지 않는 "콜드" 스토리지에 아카이브 스토리지를 사용합니다.
- OCI 프라이빗 엔드포인트
OCI Private Endpoint는 VCN(가상 클라우드 네트워크) 또는 온프레미스 네트워크 내에서 많은 OCI 서비스 중 하나에 대한 무료 프라이빗 보안 액세스를 제공합니다.
아키텍처 변형
제안된 물리적 구조의 이 변형은 각 응용 프로그램 서버에서 실행되는 고객 관리 Oracle REST Data Services 배치를 사용합니다. 그러나 ATP Serverless가 제공하는 완전 관리형 MongoDB API는 관리가 더 쉬워지기 때문에 대부분의 워크로드에 가장 적합한 솔루션입니다.
Oracle REST Data Services의 구성 및 관리를 수동으로 제어해야 하는 요구 사항이 있는 경우 고객 관리 Oracle REST Data Services를 사용할 수 있습니다. 예를 들어, 응용 프로그램이 더 큰 연결 풀을 사용하도록 허용합니다.
주:
특정 작업 로드 요구 사항이 있는 경우 이 구조 변형을 사용합니다. 고급 사용자만 이 구조 변형을 배치해야 합니다.이 절에서는 이전에 설명된 물리적 아키텍처와 비교한 차이점만 설명하므로 달리 명시되지 않는 한 모든 물리적 아키텍처 설계 원칙이 유효합니다.
다음 아키텍처 다이어그램은 변형이 배포되는 방식을 보여줍니다. 단순성을 위해 JSON 작업 로드 VCN에 배포된 클라우드 리소스만 표시됩니다. 나머지 배포는 앞서 설명한 물리적 아키텍처와 동일하기 때문입니다.
mongodb-atp-s-azure-arch-variant.zip
- 수신되는 사용자 요청은 앱 서비스 로드 밸런서에 의해 분산되므로 프론트엔드 계층은 수평 확장 가능하며 단일 실패 지점이 없습니다.
- 백엔드 애플리케이션은 앱 서비스 스케일 단위의 워커에 배치됩니다.
- 응용 프로그램은 게시 방법으로 컨테이너를 사용하여 배치됩니다.
- 애플리케이션 및 Oracle REST Data Services를 사용하여 컨테이너를 생성, 설치 및 구성하여 동일한 컨테이너에서 둘 다 실행할 수 있도록 합니다.
- 각 작업자는 동일한 런타임 환경에서 애플리케이션과 Oracle REST Data Services를 함께 배치하는 컨테이너 이미지를 실행합니다.
- 고객 관리형 Oracle REST Data Services 작업자는 MongoDB API를 사용하도록 구성되므로 응용 프로그램이 MongoDB 도구 및 드라이버를 사용하여 데이터베이스에 연결할 수 있습니다.
- 고객 관리형 Oracle REST Data Services는 대규모 연결 풀을 구성하거나 다른 데이터베이스 서비스를 사용하여 작업 로드 비기능 요구 사항에 맞게 조정되도록 구성됩니다.
- 백엔드 코드와 고객 관리형 Oracle REST Data Services는 모두 Worker에서 사용되는 컨테이너 이미지에 사전 설치되고 사전 구성됩니다. 앱 서비스가 수평으로 확장되면 새로운 작업자가 백엔드 애플리케이션을 실행하고 프로비저닝 후 데이터베이스에 연결할 수 있습니다.
권장사항
- 애플리케이션 배치
- 앱 서비스에서 사용할 수 없는 고급 통합관리, 네트워킹 및 보안 기능이 필요한 경우 Azure Kubernetes Service(AKS)를 사용하여 컨테이너 기반 배포를 사용하는 것이 좋습니다.
- 보안
- Oracle Data Safe를 사용하여 작업 로드 보안 상태를 더욱 높이고 데이터베이스 감사를 수행하는 것이 좋습니다.
- 관찰성
- Azure Monitor를 사용하여 ATP Serverless 메트릭을 다른 모든 Azure 서비스 모니터링 데이터와 함께 모니터링하는 것이 좋습니다.
- 장애 복구
- Azure 사이트 복구 또는 장애를 감지하고 페일오버 프로세스를 시작하는 사용자 정의 스크립트를 사용하여 스택의 모든 계층에 대한 재해 및 복구를 자동화하고 조정하는 것을 고려합니다.
- 운영 효율성
- ATP 서버리스 작업 로드가 더 넓은 데이터베이스 플리트의 일부인 경우 비용 효율성을 높이기 위해 엘라스틱 풀을 사용하는 것이 좋습니다.
- 포괄적인 데이터베이스 성능 모니터링 및 관리 기능을 제공하는 OCI 서비스인 Oracle Cloud Infrastructure Database Management를 사용으로 설정하여 ATP 서버리스 인스턴스의 관리를 간소화하는 것이 좋습니다.
- 애플리케이션 진화
- 신뢰할 수 있는 실시간 데이터 분석을 위해 데이터베이스에서 데이터를 이동하지 않고 SQL 및 APEX 또는 PowerBI와 같은 프론트엔드를 사용하여 ATP Serverless에 운영 분석 및 실시간 보고를 배포하는 것이 좋습니다.
- Oracle Machine Learning(OML)을 사용하여 머신 러닝에 ATP Serverless를 사용하고, 데이터 이동 없이 JSON 데이터로 모델을 구축 및 교육하고, 기존 워크로드와 함께 모델을 배포하여 효율적인 추론을 수행하는 것이 좋습니다.
- 애플리케이션 코어 이외의 추가 사용 사례는 사용자가 자연어를 사용하여 JSON 데이터를 쿼리할 수 있도록 JSON을 쿼리하고 메타데이터를 보유하는 ATP Serverless Select AI 및 데이터베이스 뷰를 사용하는 것이 좋습니다.
- 추가 워크로드 기능 및 유연성을 위해 추가 데이터 유형(관계형, 벡터, 공간 또는 그래프)을 저장하려면 ATP Serverless를 사용하는 것이 좋습니다.
자세히 살펴보기
이 아키텍처의 기능에 대해 자세히 알아보십시오.
다음 추가 리소스를 검토하십시오.
- Oracle 데이터 플랫폼
- Oracle Autonomous Transaction Processing Serverless 설명서
- Azure용 Autonomous Database 서비스
- Oracle Database API for MongoDB
- Oracle Autonomous Database Serverless 사용
다음 추가 리소스를 검토하십시오.