Oracle Banking Microservice 및 OCI Kubernetes Engine 배포에 대해 알아보기
Oracle Cloud Infrastructure Kubernetes Engine 및 Oracle Banking Microservice를 사용하여 뱅킹 인프라를 현대화하는 방법을 알아봅니다. OCI Kubernetes Engine(OKE)은 확장 가능한 완전 관리형 고가용성 서비스로, 컨테이너형 애플리케이션을 클라우드에 배포하는 데 사용할 수 있습니다. 개발 팀이 클라우드 전용 애플리케이션을 안정적으로 구축, 배포 및 관리하려는 경우 OKE를 사용합니다. 애플리케이션에 필요한 컴퓨트 리소스를 지정하면 OKE가 기존 OCI 테넌시의 OCI에서 프로비저닝합니다.
구조
이 아키텍처는 마이크로서비스를 효율적으로 활용하기 위해 Oracle Banking Microservices 및 OCI Kubernetes Engine을 구현하는 방법을 설명합니다.
Oracle Banking Microservices Architecture
Oracle은 소매 및 기업 뱅킹과 고객 디지털 경험 계층에서 뱅킹 제품 프로세서 또는 핵심 뱅킹 도메인에 이르기까지 업계에서 가장 광범위한 도메인 기반 뱅킹 솔루션을 제공합니다.
이러한 모든 기능은 도메인 기반 설계를 사용하여 설계되고 최첨단 마이크로서비스 아키텍처를 사용하여 구현되는 일련의 자율 모듈로 제공됩니다. 모든 모듈은 비즈니스 도메인별 마이크로서비스 세트, 모든 모듈 전반의 공통 기능 기반 마이크로서비스 세트(공통 코어) 및 필요한 기술 기능을 제공하는 플랫폼 서비스로 구성됩니다.
다음 다이어그램은 분기 모듈에 있는 여러 레벨의 마이크로서비스를 보여 줍니다.
이 아키텍처는 최대의 배포 유연성을 제공합니다. 모든 마이크로서비스는 도커 이미지에 컨테이너화되어 별도로 배포할 수 있습니다. 이 옵션을 사용하면 배포를 완벽하게 제어할 수 있으므로 특정 고객 요구사항에 따라 특정 마이크로서비스를 업데이트하거나 확장할 수 있습니다.
일부 고객은 플랫폼 관리를 위해 해당 수준의 세분성을 요구하지 않을 수 있으며, 간소화된 접근 방식을 선호하여 마이크로서비스를 감소된 수의 도커 이미지로 그룹화할 수 있습니다. 이 접근 방식은 개별 수준에서 업데이트 및 확장에 대한 유연성을 줄이지만 확장성, 고가용성 등에 대한 표준 요구 사항을 고객에게 제공하는 데 필요한 수준의 제어 기능을 제공합니다. 이 시나리오에서는 마이크로서비스의 영향과 특정 특성을 고려하여 마이크로서비스를 그룹화하는 것이 중요합니다. 이 참조 아키텍처에서는 다음 요인을 고려하는 그룹화를 제안합니다.
- 작업 로드 유형: REST 기반, 일괄 처리 기반, 이벤트 기반, 워크플로우 기반.
- Critical 구성 요소: 플랫폼에 중요한 구성 요소도 있습니다. 다른 작업 로드보다 작업 로드가 높습니다.
다음 다이어그램은 제안된 그룹화를 보여 줍니다.
그림 obma-service-landscape-branch-module-proposed.png에 대한 설명
다음은 이러한 그룹화에 대한 설명입니다.
- 도메인 SD: 모듈의 비즈니스 도메인 마이크로서비스(이 경우 분기 모듈)를 포함합니다.
- CMC SD: 공통 핵심 또는 기능 기반 마이크로서비스.
- Plato SD: 별도로 배포되지 않은 기술 플랫폼 마이크로서비스를 포함합니다.
- Kafka: 플랫폼 Event Hub에서 마이크로서비스와 외부 시스템 간의 통신을 위해 사용합니다.
- 지휘자: 마이크로서비스를 통합관리하고 인적 워크플로를 생성하는 데 사용되는 플랫폼의 워크플로 엔진.
- 뱃치 서버: 비즈니스 도메인에 필요한 뱃치 프로세스를 실행합니다.
이 솔루션은 7개의 도커 이미지를 그룹화합니다.
OKE를 사용한 배치 구조
OCI Kubernetes Engine은 호스트 클러스터 전반에서 컨테이너화된 애플리케이션의 배치, 크기 조정 및 관리를 자동화하는 데 사용하는 오픈 소스 시스템인 Kubernetes를 사용합니다. Kubernetes는 간편한 관리 및 검색을 위해 애플리케이션을 구성하는 컨테이너를 POD(논리 장치)로 그룹화합니다.
Kubernetes에서 컨테이너를 실행하려면 컨테이너를 포드로 묶어야 합니다. 포드는 Kubernetes에서 가장 작은 원자 단위이며 동일한 네트워크, 스토리지, 메모리 및 IPC 네임스페이스를 공유하는 컨테이너 그룹을 실행하는 구성입니다. 포드에 하나의 주 컨테이너가 있으며, 후속 컨테이너는 주 컨테이너를 지원합니다. 애플리케이션 로그를 로깅 서버로 전송하는 지원 컨테이너가 있는 애플리케이션 컨테이너를 예로 들 수 있습니다. 이 아키텍처에서 다중 컨테이너 Pod 사용 사례에 대한 세부 정보를 얻지 못하지만 대부분의 경우 Pod당 하나의 컨테이너만 있습니다.
Oracle Banking 솔루션을 배포하기 위해 배포 중인 7개의 컨테이너 이미지를 각각 자체 Pod로 묶습니다. 이 작업은 각 컨테이너 이미지에 대한 Kubernetes Pod Manifest 파일을 정의하여 수행할 수 있습니다.
파드는 Kubernetes에 직접 배포할 수 있지만, Kubernetes 배포를 통해 파드를 배포하는 것이 더 강력합니다. Kubernetes 배포를 통해 Pod의 원하는 상태 또는 동작(예: 지정된 Pod의 복사본 수 또는 복제본 수)을 정의할 수 있습니다. 또한 Kubernetes 배포는 기존 포드를 새 애플리케이션 버전으로 업그레이드할 수 있습니다. 포드의 지정된 상태를 유지하는 것은 Kubernetes에 달려 있습니다.
Oracle 뱅킹 솔루션을 위해 총 7개의 배포가 있을 것입니다. 배포의 각 Pod에는 IP 주소가 지정되지만 Pod에 대한 IP 주소는 임시이며 Pod가 생성되고 삭제될 때 변경됩니다. 배포에서 Pod에 액세스할 수 있는 일관된 방법을 제공하기 위해 각 배포에 대해 Kubernetes 서비스가 생성됩니다. Kubernetes 서비스는 일련의 포드를 정의하는 추상화 서비스입니다. Kubernetes 서비스가 배치와 연관되면 배치의 모든 POD를 나타내고 각 POD에 대한 트래픽의 로드 밸런싱을 수행합니다. Pod에 액세스해야 하는 방식, Kubernetes 클러스터의 다른 리소스, OCI VCN 내의 다른 리소스 또는 인터넷을 통한 외부 리소스에 의해서만 액세스되는지에 따라 다양한 유형의 Kubernetes 서비스가 배치에 지정됩니다.
복원력을 제공하기 위해 OKE 노드 풀은 해당 지역의 세 가용성 영역에 걸쳐 있습니다. 가용성 영역이 실패하는 경우 실패한 가용성 영역의 노드에 배치된 모든 POD가 다른 가용성 영역의 노드에서 자동으로 재생성됩니다.
마이크로서비스에 대한 데이터를 저장하는 Oracle 데이터베이스의 경우, 마이크로서비스 각각에 대해 분리된 스키마를 사용하여 2개의 장애 도메인에 Oracle Real Application Clusters (Oracle RAC) 구성을 사용합니다.
다음 다이어그램에는 이 아키텍처가 설명되어 있습니다.
그림 obma-oke-architecture.png에 대한 설명
마이크로서비스에 대한 데이터를 저장하는 Oracle 데이터베이스의 경우 각 마이크로서비스에 대해 분리된 스키마를 사용하여 두 가용성 도메인에서 RAC 구성을 사용합니다(그림에 표시되지 않은 두 개의 결함 도메인 사용). 데이터는 두번째 가용성 도메인에서 Oracle Data Guard를 사용하여 복제됩니다.
구조에는 다음과 같은 구성 요소가 있습니다.
- 지역
Oracle Cloud Infrastructure 리전은 가용성 도메인이라고 하는 데이터 센터가 하나 이상 포함된 지역화된 지리적 영역입니다. 지역은 다른 지역과 독립적이며, 먼 거리가 그들을 분리 할 수 있습니다 (국가 또는 대륙에 걸쳐).
- 가용성 도메인
가용성 도메인은 한 지역 내의 독립형 독립 데이터 센터입니다. 각 가용성 도메인의 물리적 리소스는 결함 허용을 제공하는 다른 가용성 도메인의 리소스와 격리됩니다. 가용성 도메인은 전원, 냉각 또는 내부 가용성 도메인 네트워크와 같은 인프라를 공유하지 않습니다. 따라서 한 가용성 도메인의 장애가 해당 영역의 다른 가용성 도메인에 영향을 미치지 않아야 합니다.
- 결함 도메인
장애 도메인은 가용성 도메인 내 하드웨어 및 인프라 그룹입니다. 가용성 도메인에는 독립적인 전원 및 하드웨어를 갖춘 3개의 장애 도메인이 있습니다. 여러 결함 도메인에 리소스를 분배할 때 응용 프로그램은 결함 도메인 내의 물리적 서버 오류, 시스템 유지 관리 및 전원 오류를 허용할 수 있습니다.
- VCN(가상 클라우드 네트워크) 및 서브넷
VCN은 Oracle Cloud Infrastructure 지역에서 설정한 맞춤형 소프트웨어 정의 네트워크입니다. 기존의 데이터 센터 네트워크와 마찬가지로 VCN을 통해 네트워크 환경을 제어할 수 있습니다. VCN에는 VCN 생성 후 변경할 수 있는 겹치지 않는 CIDR 블록이 여러 개 있을 수 있습니다. VCN을 서브넷으로 분할할 수 있습니다. 서브넷은 지역 또는 가용성 도메인으로 범위가 지정될 수 있습니다. 각 서브넷은 VCN의 다른 서브넷과 겹치지 않는 연속적인 주소 범위로 구성됩니다. 서브넷 생성 후 크기를 변경할 수 있습니다. 서브넷은 공용 또는 전용일 수 있습니다.
- 로드 밸런서
Oracle Cloud Infrastructure Load Balancing 서비스는 단일 시작점에서 백엔드에 있는 여러 서버로 트래픽을 자동으로 배포합니다.
- 배스천 호스트
배스천 호스트는 클라우드 외부의 토폴로지에 대한 안전하고 제어된 시작점 역할을 하는 컴퓨팅 인스턴스입니다. Bastion 호스트는 일반적으로 DMZ(Demilitarized Zone)에 프로비저닝됩니다. 클라우드 외부에서 직접 액세스할 수 없는 전용(Private) 네트워크에 중요한 리소스를 배치하여 보호할 수 있습니다. 토폴로지에는 알려진 단일 시작점이 있으며, 주기적으로 모니터링하고 감사(audit)할 수 있습니다. 따라서 액세스를 방해하지 않으면서 토폴로지의 더 중요한 구성요소가 노출되지 않도록 할 수 있습니다.
- DB 시스템
소규모 배포의 경우 VM.Standard2.2 구성으로 충분합니다. 이 아키텍처는 Oracle Real Application Clusters(RAC)를 사용하는 Oracle Database Enterprise Edition - Extreme Performance가 포함된 DB 시스템을 사용합니다. 또한 최소 256GB의 Oracle ASM(Oracle Automatic Storage Management)을 사용합니다.
- 블록 볼륨
블록 스토리지 볼륨을 사용하면 스토리지, 성능 및 애플리케이션 요구 사항을 충족하기 위해 스토리지 볼륨을 생성, 연결, 연결 및 이동하고 볼륨 성능을 변경할 수 있습니다. 볼륨을 연결한 후 인스턴스에 연결하면 일반 하드 드라이브처럼 볼륨을 사용할 수 있습니다. 데이터 손실 없이 볼륨 연결을 해제하고 다른 인스턴스에 연결할 수도 있습니다.
- 오브젝트 스토리지
오브젝트 스토리지를 사용하면 데이터베이스 백업, 분석 데이터, 이미지 및 비디오와 같은 리치 컨텐츠 등 모든 컨텐츠 유형의 대량의 구조적 데이터와 비구조적 데이터에 빠르게 액세스할 수 있습니다. 인터넷 또는 클라우드 플랫폼 내에서 직접 안전하고 안전하게 데이터를 저장하고 검색할 수 있습니다. 성능 또는 서비스 안정성이 저하되지 않고 스토리지를 확장할 수 있습니다. 빠르고 즉각적이며 자주 액세스하는 데 필요한 "핫" 스토리지에 표준 스토리지를 사용합니다. 장기간 보존하고 거의 또는 거의 액세스하지 않는 "콜드" 스토리지에 아카이브 스토리지를 사용합니다.
- NAT(Network Address Translation) 게이트웨이
NAT 게이트웨이를 사용하면 VCN의 전용 리소스가 수신 인터넷 연결에 이러한 리소스를 노출시키지 않고 인터넷의 호스트에 액세스할 수 있습니다.
- 서비스 게이트웨이
서비스 게이트웨이는 VCN에서 Oracle Cloud Infrastructure Object Storage와 같은 다른 서비스로의 액세스를 제공합니다. VCN에서 Oracle 서비스로의 트래픽은 Oracle 네트워크 패브릭을 통해 이동하며 인터넷을 순회하지 않습니다.