편집

다음을 통해 공유


Adabas 및 Natural을 실행하는 메인프레임 컴퓨터 시스템 리팩터링

AKS(Azure Kubernetes Service)
Azure ExpressRoute
Azure Managed Disks
Azure NetApp Files

Software AG는 Natural 프로그래밍 언어 및 Adabas 데이터베이스를 기반으로 하는 인기 있는 4GL 메인프레임 플랫폼을 제공합니다. 이 문서에서는 Adabas & Natural을 실행하는 메인프레임 컴퓨터를 사용하고 이러한 워크로드를 현대화하고 클라우드로 이동하는 방법을 찾고 있는 조직을 위한 아키텍처를 제공합니다.

메인프레임 아키텍처

이 다이어그램에서는 Azure로 마이그레이션하기 전에 소프트웨어 AG의 Adabas 및 Natural 모듈이 설치된 메인프레임의 예를 보여 줍니다. 이 예제에서는 IBM z/OS 아키텍처를 보여 줍니다.

Azure로 마이그레이션하기 전에 소프트웨어 AG의 Adabas & Natural을 사용하는 메인프레임 아키텍처를 보여 주는 다이어그램.

이 아키텍처의 Visio 파일을 다운로드합니다.

워크플로

A. 입력은 TN3270 및 HTTP(S)를 포함한 TCP/IP를 통해 발생합니다. 메인프레임에 대한 입력은 표준 메인프레임 프로토콜을 사용합니다.

B. 수신하는 애플리케이션은 일괄 처리 또는 온라인 시스템일 수 있습니다.

C. Natural, COBOL, PL/I, Assembler 및 기타 호환되는 언어는 활성화된 환경에서 실행됩니다.

D. 일반적으로 사용되는 데이터 및 데이터베이스 서비스는 계층적/네트워크 데이터베이스 시스템 및 관계형 데이터베이스 유형입니다.

E. 일반적인 서비스에는 환경 내에서의 프로그램 실행, I/O 작업, 오류 검색, 보호가 포함됩니다.

F. 미들웨어 및 유틸리티는 환경 내에서 테이프 스토리지, 큐, 출력 및 웹 서비스와 같은 서비스를 관리합니다.

G. 운영 체제는 엔진과 엔진이 실행되는 소프트웨어 간의 인터페이스를 제공합니다.

H. 파티션은 별도의 워크로드를 실행하고 환경 내에서 작업 유형을 분리하기 위해 필요합니다.

Azure 아키텍처

이 다이어그램에서는 리팩터링 접근 방식을 통해 시스템을 현대화하여 레거시 아키텍처를 Azure로 마이그레이션하는 방법을 보여 줍니다.

Azure로 마이그레이션한 후 레거시 아키텍처를 보여 주는 다이어그램

이 아키텍처의 Visio 파일을 다운로드합니다.

워크플로

  1. 입력. 일반적으로 입력은 원격 클라이언트에서 Azure ExpressRoute를 통해 또는 현재 Azure를 실행하는 다른 애플리케이션을 통해 발생합니다. 두 경우 모두 TCP/IP 연결은 시스템에 연결하는 기본 수단입니다. TLS 포트 443은 웹 기반 애플리케이션에 대한 액세스를 제공합니다. 웹 기반 애플리케이션 프레젠테이션 계층을 실제로 변경하지 않고 유지하여 사용자 재학습을 최소화할 수 있습니다. 또는 요구 사항에 따라 최신 UX 프레임워크를 사용하여 이 계층을 업데이트할 수 있습니다. VM에 대한 관리자 액세스의 경우 Azure Bastion 호스트를 통해 열린 포트를 최소화하여 보안을 극대화할 수 있습니다.

  2. Azure의 액세스. Azure에서 애플리케이션 컴퓨팅 클러스터에 대한 액세스는 Azure 부하 분산 장치를 통해 제공됩니다. 이 접근 방식을 사용하면 스케일 아웃 컴퓨팅 리소스가 입력 작업을 처리할 수 있습니다. 수준 7(애플리케이션 수준) 또는 수준 4(네트워크 프로토콜 수준) 부하 분산 장치를 사용할 수 있습니다. 그러나 사용하는 부하 분산 장치 유형은 애플리케이션 입력이 컴퓨팅 클러스터의 진입점에 도달하는 방법에 따라 달라집니다. 계층 7 트래픽에 웹 애플리케이션 방화벽 기능이 있는 Azure 애플리케이션 게이트웨이를 사용하는 것이 좋습니다.

  3. 애플리케이션 컴퓨팅 클러스터. 아키텍처는 AKS(Azure Kubernetes Service)에 배포할 수 있는 컨테이너에서 실행되는 애플리케이션을 지원합니다. Adabas 및 자연 구성 요소는 Linux 기반 컨테이너 내에서 실행할 수 있습니다. 레거시 애플리케이션을 최신 컨테이너 기반 아키텍처로 다시 설계하고 AKS를 기반으로 작동할 수 있습니다.

  4. ApplinX 터미널 에뮬레이션(Software AG). ApplinX는 애플리케이션을 변경하지 않고도 핵심 시스템 애플리케이션에 웹 연결 및 통합을 제공하는 서버 기반 기술입니다. Natural Online을 사용하면 온라인 사용자가 웹 브라우저를 통해 Natural 애플리케이션에 연결할 수 있습니다. ApplinX가 없으면 사용자는 SSH를 사용하여 터미널 에뮬레이션 소프트웨어에 연결해야 합니다. 두 시스템은 모두 컨테이너에서 실행됩니다.

  5. EntireX(Software AG). EntireX를 사용하면 통합 서버에서 실행되는 서비스를 COBOL 및 Natural 같은 언어로 작성된 중요 업무용 프로그램에 쉽게 연결할 수 있습니다. Natural Business Services를 사용하면 Natural로 프로그래밍된 비즈니스 기능에 대한 API 액세스가 가능합니다. 두 시스템은 모두 컨테이너에서 실행됩니다.

  6. Adabas(Software AG). Adabas는 고성능 NoSQL 데이터베이스 관리 시스템입니다. Natural 일괄 처리(Software AG)는 일괄 작업을 실행하기 위한 전용 구성 요소입니다. 선택한 일괄 작업 예약 시스템에 의해 예약되는 Natural 일괄 작업은 성능에 영향을 주지 않도록 Adabas 데이터베이스와 동일한 노드에서 실행되어야 합니다.

  7. 스토리지. 데이터 서비스는 사용에 따라 로컬 중복 또는 지역 중복일 수 있는 고성능 스토리지(울트라/프리미엄 SSD), 파일 스토리지(NetApp) 및 표준 스토리지(Blob, 보관, 백업)을 함께 사용합니다. 노드 운영 체제는 관리 디스크 스토리지를 사용합니다. 데이터베이스 파일, 보호 로그, 애플리케이션 데이터, 백업 등의 모든 영구 데이터는 Azure NetApp Files를 사용합니다. AKS는 관리 디스크에 저장된 운영 체제 볼륨을 관리합니다. ASSO, DATA, WORK 파일 및 Adabas 보호 로그를 비롯한 데이터베이스의 모든 중요 비즈니스용 데이터는 Azure NetApp Files의 개별 볼륨에 기록되어야 합니다.

  8. CONNX. CONNX for Adabas 모듈은 .NET, ODBC, OLE DB 및 JDBC를 통해 OS/390, z/OS, VSE, Linux, Solaris, HP-UX, AIX 및 Windows에서 Adabas 데이터 원본에 대한 매우 안전한 실시간 읽기/쓰기 액세스를 제공합니다. CONNX는 Adabas에 대한 커넥터 및 Azure SQL Database, PosgreSQL용 Azure Database 및 Azure Database for MySQL과 같은 기타 데이터 원본에 대한 커넥터를 사용하는 데이터 가상화 계층을 제공합니다.

구성 요소

  • Azure ExpressRoute는 연결 공급자에서 지원하는 프라이빗 연결을 통해 온-프레미스 네트워크를 Microsoft 클라우드로 확장합니다. ExpressRoute를 사용하여 Azure 및 Microsoft 365와 같은 Microsoft 클라우드 서비스에 대한 연결을 설정할 수 있습니다. 또는 백업으로 Azure VPN Gateway와의 연결을 설정할 수 있습니다. 그러나 향상된 보안 고속 프라이빗 연결을 통해 Azure 환경에 연결할 수 있도록 ExpressRoute를 사용하는 것이 좋습니다.

  • AKS 는 컨테이너화된 애플리케이션을 배포하고 관리하기 위한 완전 관리형 Kubernetes 서비스입니다. AKS는 서버리스 Kubernetes, 통합된 CI/CD(연속 통합 및 지속적인 업데이트) 환경, 엔터프라이즈급 보안 및 거버넌스를 제공합니다. 이 시나리오에서는 Adabas 및 Natural 컨테이너가 AKS에 배포됩니다.

  • Azure 관리 디스크는 Azure에서 관리하고 Azure Virtual Machines와 함께 사용되는 블록 수준 스토리지 볼륨입니다. 울트라 디스크, 프리미엄 SSD, 표준 SSD, 표준 HDD 등의 다양한 유형을 사용할 수 있습니다. SSD 디스크는 이 아키텍처에서 사용됩니다. 이 시나리오에서는 모든 운영 체제 볼륨이 Azure 관리 디스크에 저장됩니다.

  • Azure NetApp Files는 NetApp에서 제공하는 엔터프라이즈급 Azure 파일 공유 기능을 제공합니다. Azure NetApp Files를 사용하면 코드를 변경하지 않고 복잡한 파일 기반 애플리케이션을 쉽게 마이그레이션하고 실행할 수 있습니다. 이 시나리오에서는 데이터베이스 파일, 보호 로그, 애플리케이션 데이터 및 백업 파일과 같은 모든 영구 데이터는 Azure NetApp Files를 사용합니다.

시나리오 정보

메인프레임 컴퓨터에서 실행되는 애플리케이션은 거의 50년 동안 대부분 비즈니스 운영의 핵심이었습니다. 이 메인프레임 시스템은 몇 년에 걸쳐 놀라운 안정성을 제공했지만, 경직되고 경우에 따라 유지 관리가 어렵고 운영 비용이 많이 들기 때문에 다소 문제가 되었습니다.

많은 조직에서 이 시스템을 현대화하는 방법을 찾고 있습니다. 이 시스템을 유지 관리하고, 비용을 제어하고, 시스템과 더 유연하게 상호 작용하는 데 필요한 제한된 리소스를 확보하는 방법을 찾고 있습니다.

Software AG는 Natural 프로그래밍 언어 및 Adabas 데이터베이스를 기반으로 하는 인기 있는 4GL 메인프레임 플랫폼을 제공합니다.

두 가지 클라우드 합리화 패턴을 사용하면 Azure 에서 Adabas 및 Natural 애플리케이션을 실행할 수 있습니다. 다시 호스트 및 리팩터링. 이 문서에서는 AKS에서 관리되는 컨테이너를 사용하여 애플리케이션을 리팩터링하는 방법을 설명합니다. 자세한 내용은 이 문서의 뒷부분에 있는 컨테이너 기반 접근 방식을 참조하세요.

잠재적인 사용 사례

이 아키텍처는 Adabas & Natural을 실행하는 메인프레임 컴퓨터를 사용하고 이러한 워크로드를 현대화하고 클라우드로 이동할 계획인 모든 조직에 적용됩니다.

고려 사항

컨테이너 기반 접근 방식

Azure의 유연성, 안정성 및 기능을 최대한 활용하려면 메인프레임 애플리케이션을 다시 설계해야 합니다. 모놀리식 애플리케이션을 마이크로 서비스로 다시 작성하고 배포에 컨테이너 기반 접근 방식을 사용하는 것이 좋습니다. 컨테이너는 실행에 필요한 모든 소프트웨어를 하나의 실행 파일 패키지로 번들로 묶습니다. 여기에는 애플리케이션의 코드와 앱 실행에 필요한 관련 구성 파일, 라이브러리 및 종속성이 포함됩니다. 컨테이너화된 애플리케이션은 CI(연속 통합) 및 CD(지속적인 배포)와 같은 인기 있는 DevOps 사례를 신속하게 배포하고 지원합니다.

Adabas 및 자연 컨테이너는 각각 특정 작업을 수행하는 Pod에서 실행됩니다. Pod는 동일한 노드에 함께 유지되고 호스트 이름, IP 주소 등의 리소스를 공유하는 하나 이상의 컨테이너 단위입니다. 기본 플랫폼에서 분리되므로 Pod의 구성 요소는 개별적으로 스케일링되고 더 높은 가용성을 지원합니다. 컨테이너화된 애플리케이션은 이식 가능하며 모든 인프라에서 균일하고 일관되게 실행됩니다.

컨테이너화된 서비스와 관련 네트워킹 및 스토리지 구성 요소를 오케스트레이션하고 관리해야 합니다. 클러스터 및 리소스 관리를 자동화하는 관리형 Kubernetes 서비스인 AKS를 사용하는 것이 좋습니다. 필요한 노드 수를 지정하면 AKS는 컨테이너를 올바른 노드에 맞게 조정하여 리소스를 최대한 활용합니다. AKS는 자동화된 출시 및 롤백, 서비스 검색, 부하 분산 및 스토리지 오케스트레이션도 지원합니다. 또한 AKS는 자동 복구를 지원합니다. 컨테이너가 실패하면 AKS에서 새 컨테이너를 시작합니다. 컨테이너 외부에 비밀 및 구성 설정을 안전하게 저장할 수도 있습니다.

이 문서의 아키텍처 다이어그램은 Adabas 및 Natural의 컨테이너 기반 구현을 보여 줍니다. AKS를 설정할 때 노드에 대한 Azure VM 크기를 지정합니다. 이 크기는 스토리지 CPU, 메모리 및 유형(예: 고성능 SSD(반도체 드라이브) 또는 일반 HDD(하드 디스크 드라이브))을 정의합니다. 사용자 인터페이스(Natural online plus ApplinX) 및 API 계층(Natural services plus EntireX)의 확장성 및 가용성을 높이기 위해 3개 이상의 VM 인스턴스(노드)에서 Natural을 실행해야 합니다.

데이터 계층에서 Adabas는 리소스 사용에 따라 자동으로 스케일 인 및 스케일 아웃되는 AKS 클러스터에서 실행됩니다. 동일한 Pod에서 Adabas의 여러 구성 요소를 실행하거나, 더 큰 규모에서는 AKS가 클러스터의 여러 노드에 해당 구성 요소를 분산할 수 있습니다. Adabas는 데이터베이스 파일, 보호 로그, 앱 데이터, 백업 등의 모든 영구 데이터에 대해 고성능 유료 파일 스토리지 서비스인 Azure NetApp Files를 사용합니다.

자연 배치 Pod를 Adabas Pod와 동일한 가용성 영역(데이터 센터)에 배치합니다. 근접 배치 그룹을 사용하여 Adabas 및 Natural Batch Pod를 동일한 가용성 영역 내의 동일한 노드 풀에 배치해야 합니다.

보안

우수한 보안은 중요한 데이터 및 시스템에 대한 고의적인 공격과 악용을 방어합니다. 자세한 내용은 보안성에 대한 디자인 검토 검사 목록을 참조하세요.

이 아키텍처는 주로 Pod 보안 표준 및 비밀과 같은 보안 구성 요소를 포함하는 Kubernetes를 기반으로 빌드됩니다. Azure는 Microsoft Entra ID, 컨테이너용 Microsoft Defender, Azure Policy, Azure Key Vault, 네트워크 보안 그룹 및 오케스트레이션된 클러스터 업그레이드와 같은 추가 기능을 제공합니다. 리팩터링된 컨테이너는 프라이빗 API 서버 및 내부 IP 주소를 통해 인바운드 액세스 권한이 있는 프라이빗 AKS 클러스터에 배포해야 합니다. 모든 아웃바운드 트래픽은 송신 방화벽 계층을 통해 라우팅되어야 합니다.

비용 최적화

비용 최적화는 불필요한 비용을 줄이고 운영 효율성을 높이는 것입니다. 자세한 내용은 비용 최적화를 위한 디자인 검토 검사 목록을 참조하세요.

  • 클러스터 자동 크기 조정기가로 Pod 자동 크기 조정기를 사용하여 트래픽 조건에 따라 Pod 및 노드 수를 조정합니다. Adabas Pod는 비용 최적화를 위해 수평 Pod 자동 크기 조정기를 사용할 수 있습니다.

  • 수직 Pod 자동 크기 조정기를 사용하여 Pod에 필요한 CPU 및 메모리 리소스를 분석하고 설정합니다. 이 방식은 리소스 할당을 최적화합니다.

  • 워크로드 요구 사항에 따라 노드 풀에 적합한 VM 크기를 선택합니다.

  • 특정 워크로드를 위해 VM 크기가 서로 다른 여러 노드 풀을 만듭니다. 노드 레이블, 노드 선택기, 선호도 규칙을 사용하여 리소스 할당을 최적화합니다.

  • Azure NetApp Files에 적합한 서비스 수준용량 풀 크기를 선택합니다. 비용 관리 권장 사항은 Azure NetApp Files에 대한 비용 모델을 참조 하세요.

  • Azure NetApp Files에 예약된 용량을 사용합니다.

  • 비용을 모니터링하고 최적화하려면 Azure Advisor, Azure Reservations 및 Azure 절감 계획같은 비용 관리 도구를 사용합니다.

  • 사용 비용을 예측하려면 Azure 비용 계산기를 사용합니다.

  • 비용 추적 및 관리를 개선하려면 Azure 태그를 사용하여 AKS 리소스를 특정 워크로드와 연결합니다.

운영 효율성

운영 우수성은 애플리케이션을 배포하고 프로덕션에서 계속 실행하는 운영 프로세스를 다룹니다. 자세한 내용은 Operational Excellence에 대한 디자인 검토 검사 목록을 참조하세요.

리팩터링은 더 빠른 클라우드 채택을 지원합니다. 또한 DevOps 및 Agile 작업 원칙의 채택을 촉진합니다. 개발 및 프로덕션 배포 옵션에 대한 완전한 유연성이 제공됩니다.

성능 효율성

성능 효율성은 사용자가 배치된 요구 사항을 효율적인 방식으로 충족하기 위해 워크로드의 크기를 조정할 수 있는 기능입니다. 자세한 내용은 성능 효율성에 대한 디자인 검토 검사 목록을 참조하세요.

Kubernetes는 클러스터 자동 스케일러를 제공합니다. 자동 스케일러는 노드 풀에서 요청된 컴퓨팅 리소스에 따라 노드 수를 조정합니다. Metrics API 서버에서 10초 간격으로 필요한 노드 개수 변경을 모니터링합니다. 클러스터 자동 스케일러가 변경이 필요하다고 판단하면 AKS 클러스터의 노드 수가 그에 따라 증가하거나 감소합니다. 

참가자

Microsoft에서 이 문서를 유지 관리합니다. 원래 다음 기여자가 작성했습니다.

보안 주체 작성자:

  • Marlon Johnson | Senior TPM

Contributor:

비공개 LinkedIn 프로필을 보려면 LinkedIn에 로그인합니다.

다음 단계

자세한 내용은 legacy2azure@microsoft.com에 문의하세요.

다음은 몇 가지 추가 리소스입니다.