KR20200004835A

KR20200004835A - 모놀로식 레거시 애플리케이션들에 기초한 마이크로서비스들의 컨테이너화된 전개

Info

Publication number: KR20200004835A
Application number: KR1020197034913A
Authority: KR
Inventors: 얀 예거; 디디에 뒤랑; 피에르-장 디차이드; 장-뤽 뷔아뚜
Original assignee: 엘제트랩스 게엠베하
Priority date: 2017-04-28
Filing date: 2017-04-28
Publication date: 2020-01-14
Also published as: ES2830438T3; PT3411785T; AU2023266241A1; EP3411785B1; CN110730951B; AU2017411068B2; EP3693848A1; AU2022200853B2; KR102551182B1; AU2022200853A1; JP7057571B2; BR112019022546A2; WO2018197928A1; CN117055957A; RU2733507C1; CA3062743A1; EP3411785A1; JP2020518073A; KR20220028194A; SG11201909903VA

Abstract

본 개시내용은 비-일시적 매체에 저장된 컴퓨터 명령들로 구현되는 스케일러블 컨테이너-기반 시스템을 제공한다. 본 개시내용은 스케일러블 컨테이너-기반 시스템을 생성 및 동작시키는 방법을 추가로 제공한다.

Description

모놀로식 레거시 애플리케이션들에 기초한 마이크로서비스들의 컨테이너화된 전개

본 발명은 컨테이너화된, 스케일러블 및 플렉시블 오퍼레이팅 환경에서 실행되는 마이크로서비스들로서 전개를 위한 모놀로식 레거시 애플리케이션들을 파티셔닝하기 위한 기술들 시스템들에 관한 것이다.

레거시 메인프레임 컴퓨팅 환경들에 있어서, 단일 오퍼레이팅 환경의 초 모놀리식 구조에서 모두 함께 실행되는 수천개 및 심지어 수만개의 개별 프로그램들을 포함하는 모놀리식 애플리케이션들을 고안하여 발견하는 것은 흔한 일이다. 이러한 모놀로식 구조의 프로그램들은 그들의 기반 코드 개발에 상당한 시간(최대 수천년)과 자원들이 요구될 수 있으며, 소프트웨어 프로그램들의 상호 의존적 성질은 하나의 컴퓨터 환경으로부터의 코드를 전환하거나 또는 이동(migrate)시키는 것을 매우 어렵게 만든다.

레거시 프로그램 파일들은 레거시 시스템 또는 레거시 플랫폼의 부분으로서 종종 지칭되는, 특정 아키텍처 및 명령 세트의 프로세서상에서만 실행되는 제약과 함께 컴파일링, 어셈블리 및 링크될 수 있다.

도 1a는 하이퍼바이저 가상화를 사용하는 레거시 플랫폼(100)의 엘리먼트들을 도시한다. 시스템 하드웨어(10)는, 예컨대, 프로그램들이 전형적으로 실행되는 자기 자신의 게스트 오퍼레이팅 시스템(OS)을 각각 갖는 완전히 격리된 가상 머신들(70)의 세트로서 제공하기 위해 종종 가상 머신 모니터(z/VM)로서 하이퍼바이저(30)를 실행하는 메인프레임 컴퓨터를 포함할 수 있다. 하이퍼바이저(30)는 레거시 시스템내에서 독립적으로 동작할 수 있는 가상 또는 게스트 머신들(70)의 세트로 호스트 머신의 자원들을 파티셔닝하는 관리 플랫폼을 제공한다. 게스트 오퍼레이팅 시스템(40) 또는 다수의 게스트 오퍼레이팅 시스템들(40)은 가상 머신들에 설치된다. 이후, 한 세트의 바이너리들 및 라이브러리 프로그램들(50) 및 하나 이상의 애플리케이션들(60)이 주어진 가상 머신상에서 실행된다. 물리적 머신과 마찬가지로, 가상 머신은 연관된 상태 정보를 가지며, 백업되거나 또는 복원될 수 있으며, 전용 시스템 자원들이 할당될 수 있다. 하이퍼바이저 시스템에서 가상 머신의 스타트-업(start-up) 및 티어-다운(tear-down)은 상당한 오버헤드를 요구하며, 이러한 이유 때문에, 설정될 때, 가상 머신들은 전형적으로 상당한 런타임들 동안 지속된다.

도 1b는 컨테이너 관리 시스템(110)의 예를 도시한다. 컨테이너 시스템의 하드웨어(15)는 물리적 서버 또는 물리적 서버의 클러스터일 수 있으며, 이는 예컨대 X86-기반 컴퓨터들일 수 있다. Linux와 같은 시스템의 호스트 오퍼레이팅 커널(25)은 플랫폼에 의해 공유되며, 한 세트의 컨테이너들(75)은 도커(Docker)와 같은 컨테이너 관리 시스템(35)을 통해 인에이블된다. 특히, Linux 커널의 이름공간 및 시그룹(cgroup) 기능성은 컨테이너화(containerization)를 위해 사용될 수 있다. 컨테이너 관리 시스템들은 커널 기능성들에 맞춘 래퍼(wrapper)들로서 제공될 수 있으며, 전개와 같은 컨테이너 관리를 가능하게 한다.

Amazon ACS, Azure Container Service, Cloud Foundry Diego, CoreOS Fleet, Docker Swarm, Google Container Engine 또는 Mesosphere Marathon 컨테이너 관리 시스템 또는 다른 컨테이너 관리 및 오케스트레이션(orchestration) 시스템과 같은 다른 컨테이너 관리 시스템들이 사용될 수 있다. 컨테이너 관리 시스템(35) 및 한 세트의 공유 오퍼레이팅 라이브러리들(85)은 한 세트의 컨테이너들(75)이 실행될 수 있는 플랫폼을 제공한다. 예컨대, 기본 파일 입력/출력(I/O) 기능들에 사용되는 것들과 같은 일부 저-레벨 오퍼레이팅 라이브러리들(35)은 개별 컨테이너들에 상주하는 것보다 오히려 오퍼레이팅 시스템 커널 또는 컨테이너 관리 시스템을 통해 모든 컨테이너들에 의해 공유될 수 있다.

가상 머신의 경우와 마찬가지로, 한 세트의 바이너리들 및 라이브러리 프로그램들(55) 및 하나 이상의 애플리케이션들(65)은 한 세트의 컨테이너들(75)에서 실행된다. 예로서, http 프로토콜과 같은 웹 액세스 서비스들을 제공하는 라이브러리는 단지 일부 애플리케이션들에서만 필요하고 다른 애플리케이션들에서는 필요하지 않을 수 있으므로, 특정 애플리케이션 서비스에 필요한 경우 라이브러리 프로그램들(55)에 포함될 수 있지만, 웹 액세스 서비스를 결코 사용하지 않는 애플리케이션들만을 갖는 컨테이너의 라이브러리 프로그램들(55)로부터 생략될 것이다.

가상 머신과 비교하여, 컨테이너는 비교적 경량 구조이며, 그 자체의 전체 오퍼레이팅 시스템의 오버헤드와 물리적 또는 가상 머신과 연관된 모든 상태 정보로 인해 부담을 지지 않는다. 결과적으로, 컨테이너의 스타트-업 및 티어-다운은 오버헤드를 거의 요구하지 않는데, 이는 컨테이너들의 전개 및 종료가 애플리케이션 업그레이드, 동적 로드 밸런싱 및 클러스터내의 자원 할당을 위한 효과적인 기술이 되게 만든다.

특히, 가상 머신들은 그들 자체의 오퍼레이팅 시스템, 파일 시스템, 프로세서(들), 네트워크 어댑터들 및 연관된 스토리지 볼륨들을 갖는다. 가상 머신들이 하이퍼바이저를 통해 게스트 오퍼레이팅 시스템을 실행한다는 사실은 애플리케이션 서비스들에 대한 변화하는 디맨드(demand)를 수용하기 위하여 2개의 오퍼레이팅 시스템들(하이퍼바이저 + 게스트 오퍼레이팅 시스템)를 서로 중첩하여 실행하는 오버헤드로 인해 가상 머신들이 중량 프로세스가 되게 하는데, 이는 용이하게 론치되어 종료될 수 없다. 다른 한편으로, 컨테이너들은 커널 직접 액세스 및 스토리지 볼륨들을 포함하는 다른 물리적 자원들을 통해 코어 오퍼레이팅 시스템 기능들을 공유한다. 스토리지 볼륨들은 전형적으로 고정 디스크 드라이브들상에 상주하지만, 플래시 드라이브들, 테이프 또는 다른 고정 또는 이동가능 저장 매체를 포함한 다른 대용량 스토리지에 또한 상주할 수 있다. 비록 상이한 컨테이너의 동작이 이들 특정 컨테이너들로 로딩된 이미지에 통합되는 바이너리 및 라이브러리 프로그램들에 기초할 때 상이할 수 있지만, 공유 오퍼레이팅 시스템을 사용하면, 컨테이너의 각각의 개별 인스턴스와 연관된 오버헤드가 현저하게 감소한다. 이러한 이유로, 컨테이너들은 가상 머신들에 비해 경량인데, 이는 애플리케이션 디맨드들이 더 실현 가능하게 되는 것에 응답하여 컨테이너들의 인스턴스화 및 종료를 만든다. 실제로, 예컨대 도커를 실행하는 쿠버네티드 컨테이너 관리 시스템의 경우에, 컨테이너는 1초의 몇 분의 1 내에 론치될 수 있다. 이 때문에, 큰 전개들은 매초 수천 개의 컨테이너들을 론치하고 종료할 수 있다.

컨테이너 관리 시스템들은 또한 포드(pod)들을 포함할 수 있다. 포드는 동일한 호스트 또는 클러스터에 함께 전개되는 하나 이상의 컨테이너들을 포함하는 컨테이너 시스템의 전개 유닛이다. 쿠버네티드와 같은 일부 컨테이너 관리 시스템들에서, 포드의 컨테이너들은 동일한 네트워크 이름공간 및 포트 공간을 공유하다. 부가적으로, 포드에 부착된 스토리지의 공유 볼륨들은 포드의 컨테이너들의 하나 이상에 장착될 수 있다.

표준 Linux 분배는 수만개 (심지어 수십만개)의 개별 파일들을 포함하며, 이러한 시스템이 사용되는 애플리케이션에 따라, 플랫폼에 기능성을 추가하는 수천개의 추가 시스템 패키지들과 결합될 수 있다. 이러한 패키지들의 예들은 Apache 웹 서버, Java 가상 머신, PostgreSQL, 또는 데이터베이스 또는 언어 지원을 제공하는 다른 패키지들 등을 포함한다. 이러한 패키지들은 패키지들, 및 패키지들과 다른 라이브러리들 간의 의존성들을 설명하는 프로그램 코드 및 메타데이터를 포함한다. 공유 라이브러리들은 동적으로 링크된 패키지들에 의해 사용될 수 있으나, 엄청난 기능성을 제공하기 위해 Linux 이미지의 풋프린트 및 시스템 관리의 복잡성을 크게 증가시킬 수 있다. 패키지들을 거의 통합하지 않는 Linux의 최소 인스턴스는 수 메가바이트의 메모리만 점유할 수 있다. 다른 한편으로, 예컨대 고급 데이터베이스 서비스들을 갖는 대규모 애플리케이션 웹-서버를 지원하기 위해 사용되는 많은 패키지들의 대규모 설치는 수백 메가바이트, 또는 심지어 그 초과의 메가바이트의 스토리지를 점유할 수 있다. Linux-기반 플랫폼들의 관리는 패키지들과 라이브러리들 간의 의존성들 및 해당 라이브러리들과 패키지들의 반복 업그레이드들을 관리하기 위해 패키지 관리자 소프트웨어를 종종 사용한다. 한 번에 다수의 타겟들을 서빙하는 큰 이미지는 단순한 이미지보다 관리하기가 더 복잡하다.

마이크로서비스들은 전형적으로, 애플리케이션의 기능성을 제공하기 위해 서로 긴밀하게 협력할 수 있는 소규모 자율 서비스들이다. 마이크로서비스들의 자율적 성질은 마이크로서비스들이 격리된 서비스들로서 서로 독립적으로 전개되는 것을 가능하며, 격리된 서비스들은 네트워크 호출들을 통해 다른 서비스들과 통신할 수 있다. 한 세트의 밀접하게 관련된 마이크로서비스들 또는 자신들의 동작시에 공통 볼륨에 대한 액세스를 공유하는 마이크로서비스들은 동일한 포드 내에 전개될 수 있다. 마이크로서비스 아키텍처는 클러스터링된 시스템들에 대해 관리성, 가용성, 확장성 및 전개성의 중요한 장점들을 제공한다. 그러나, 많은 레거시 애플리케이션들의 모놀리식 성질은 그러한 모놀로식 애플리케이션들을 최소 상호의존적인 마이크로서비스들의 세트들로 전환하는 것이 어렵고 수동 집약적인 작업이 되게 한다. 문제를 더 복잡하게 하는 것으로서, Cobol로 작성되고 독점 API들을 갖는 MVS 또는 z/OS와 같은 레거시 아키텍처들상에서 실행되도록 컴파일되는 레거시 모놀리식 애플리케이션들은, 일반적으로, 명령 세트들 및 API들의 차이로 인해, 특히 x86 서버들에 기반할 때, 레거시 아키텍처로부터 엑스포트될 수 없어 Linux 또는 다른 오퍼레이팅 시스템 또는 클러스터상에서 실행될 수 없다.

보다 일반적으로, 애플리케이션 코드를 하나의 오퍼레이팅 환경으로부터 다른 오퍼레이팅 환경으로 전환하는 시스템들은, 에뮬레이션, 크로스-컴파일링, 트랜스코딩 또는 하이브리드 접근법을 통하든 간에, 컴파일링된 레거시 프로그램을 실행함으로써, 상이한 기반 아키텍처를 사용하여 게스트 오퍼레이팅 시스템상에서 실행되도록 개발될 수 있다. 그러나, 이러한 시스템들 그 자체는 쉽게 스케일링되지 않는 큰 문제들이 되는 경향이 있으며, 이는 높은 트랜잭션 볼륨들을 수행하는 애플리케이션들을 실행하는 경우에 특히 문제가 된다. 부가적으로, 에뮬레이션 또는 트랜스코딩 시스템들은 모놀리식 애플리케이션들에 적합한데, 왜냐하면 유용하게 되도록, 에뮬레이터 또는 트랜스코더는 게스트 환경에서 레거시 환경의 가능한 명령들의 알수 없는 서브세트를 실행할 수 있어야 하기 때문이다.

본 발명은 비-일시적 매체에 저장된 컴퓨터 명령들로 구현되는 스케일러블 컨테이너-기반 시스템을 제공한다. 시스템은 복수의 트랜잭션들을 수행하기 위해 레거시 컴퓨팅 환경에서 실행 가능한 복수의 프로그램들을 포함하는 모놀리식 레거시 애플리케이션의 소스 코드를 포함하는 소스 코드 리포지토리를 포함한다. 시스템은 또한 소스 코드를 파스(parse)하고, 복수의 트랜잭션들의 각각의 트랜잭션에 대해, 트랜잭션 동안 잠재적으로 호출되는 각각의 프로그램을 식별하는 트랜잭션 정의 벡터를 식별하여 복수의 트랜잭션 정의 벡터들을 생성하도록 동작 가능한 소스 코드 분석기를 포함한다. 시스템은 또한 복수의 트랜잭션 정의 벡터들을 저장하도록 동작 가능한 트랜잭션 상태 정의 리포지토리를 포함한다. 시스템은 또한 복수의 트랜잭션들의 적어도 서브세트에서 수행할 때 어떤 프로그램이 모놀리식 레거시 애플리케이션에 의해 실제로 사용되는지를 식별하는 동적 정의 리포지토리를 생성하도록 동작 가능한 액티비티 로그 분석기를 포함한다. 시스템은 또한 복수의 트랜잭션 정의 벡터들을 동적 정의 리포지토리와 비교하고, 트랜잭션 정의 벡터들로부터 미사용 프로그램들을 제거하여 복수의 마이크로서비스들을 정의하는 복수의 마이크로서비스 정의 벡터들을 생성하도록 동작 가능한 마이크로서비스 정의 최적화기를 포함한다. 시스템은 또한 복수의 마이크로서비스 정의 벡터들의 각각의 마이크로서비스 정의 벡터에 대해, 마이크로서비스 정의 벡터들에 대응하는 복수의 마이크로서비스 이미지들을 형성하기 위해 레거시 컴퓨팅 환경에서 실행되도록 컴파일링된 컴파일링된 소스 코드 바이너리들을 마이크로서비스 정의 벡터에 의해 식별된 각각의 프로그램에 대해 로케이팅하도록 동작 가능한 마이크로서비스 이미지 빌더를 포함한다. 시스템은 또한 복수의 마이크로서비스 이미지들을 저장하도록 동작 가능한 마이크로서비스 이미지 리포지토리를 포함한다. 시스템은 또한 전체적으로 완전한 레거시 에뮬레이터가 아닌, 레거시 에뮬레이터의 에뮬레이터 엘리먼트들의 바이너리 이미지들의 세트를 저장하도록 동작 가능한 상보적 컴포넌트 리포지토리를 포함하며, 상기 이미지들은 상기 레거시 컴퓨팅 환경의 복수의 기능들 또는 기능들의 세트들에 대응하며, 그리고 상기 이미지들은 레거시 환경의 명령 세트와 완전히 다른 명령 세트에 의해 특성화되는 별개의 컴퓨터 환경에서 실행가능하다. 시스템은 또한, 복수의 컨테이너 이미지들을 생성하기 위해, 마이크로서비스 이미지 리포지토리로부터의 대응하는 마이크로서비스 이미지 또는 이미지들을 사용하여 그리고 실행될 때 마이크로서비스 또는 마이크로서비스들의 세트에 의해 사용되는 기능들 또는 기능들의 세트들에 대응하는 레거시 에뮬레이터의 레거시 엘리먼트들 ― 에뮬레이터 엘리먼트들은 마이크로서비스 또는 마이크로서비스들의 세트의 바이너리들의 호출들의 시그니처들에 의해 식별됨― 에 대한 상보적 컴포넌트 리포지토리로부터의 이미지 파일들을 사용하여 복수의 마이크로서비스들의 각각의 마이크로서비스 또는 마이크로서비스들의 세트에 대한 컨테이너 이미지를 형성하도록 동작 가능한 컨테이너 빌더를 포함한다. 시스템은 또한 별개의 컴퓨팅 환경에서 실행 가능한 복수의 컨테이너 이미지들을 저장하도록 동작 가능한 컨테이너 이미지 리포지토리를 포함한다. 시스템은 또한 별개의 컴퓨팅 환경에서 실행하기 위한 적어도 하나의 컨테이너를 생성하고 적어도 하나의 컨테이너의 컨테이너 이미지 리포지토리에 저장된 적어도 하나의 마이크로서비스를 실행하도록 동작 가능한 컨테이너 관리 시스템을 포함한다.

추가 실시예들에 따르면, 이들 모두는 명확히 상호 배타적이지 않은 경우, 앞의 시스템과 그리고 서로 결합되고 또한 앞의 시스템과 임의의 조합들로 결합될 수 있으며, 본 발명은 또한 다음을 제공한다:

i) 액티비티 로그 분석기는 복수의 트랜잭션 정의 벡터들의 적어도 일부에 대응하는 복수의 동적 트랜잭션 정의 벡터들을 생성하도록 동작 가능하고, 마이크로서비스 정의 최적화기는 각각의 동적 트랜잭션 정의 벡터를 각각의 대응하는 트랜잭션 정의 벡터와 비교하여, 복수의 마이크로서비스 정의 벡터들을 생성하며;

ii) 액티비티 로그 분석기는 레거시 컴퓨팅 환경에서 모놀리식 레거시 애플리케이션을 실행함으로써 생성된 모놀리식 레거시 애플리케이션의 레거시 액티비티 로그들을 사용하며;

iii) 액티비티 로그 분석기는 에뮬레이터를 사용하여 모놀리식 레거시 애플리케이션을 실행하여 로그 파일들을 생성하고 트랜잭션 실행 동안 모놀리식 레거시 애플리케이션에 의해 어떤 프로그램들이 사용되는지를 결정하며;

iv) 소스 코드 분석기는 액티비티 로그 분석기로부터의 정보를 사용하여 트랜잭션 정의 벡터들을 식별하도록 동작 가능하며;

v) 소스 코드 분석기는 복수의 전환 테이블들을 생성하도록 추가로 동작 가능하며;

vi) 마이크로서비스 정의 최적화기는 마이크로서비스 정의 벡터들을 추가로 최적화하도록 동작 가능하며;

vii) 마이크로서비스 정의 최적화기는 복수의 트랜잭션들의 하나 초과의 트랜잭션에 의해 공유되는 프로그램들을 포함하는 추가 마이크로서비스 정의 벡터들을 생성함으로써 마이크로서비스 정의 벡터들을 추가로 최적화하도록 동작 가능하며;

viii) 레거시 컴퓨팅 환경에서 실행되도록 컴파일링된 바이너리들을 포함하는 컴파일링된 소스 코드를 저장하도록 동작 가능한 바이너리 리포지토리를 더 포함하며;

ix) 바이너리 리포지토리의 컴파일링된 소스 코드는 소스 코드 리포지토리의 소스 코드로부터 바이너리 파일들로 컴파일링되며;

x) 레거시 컴퓨팅 환경은 MVS(Multiple Virtual Storage) 또는 z/OS 컴퓨터 시스템을 포함하며;

xi) 상보적 컴포넌트 리포지토리는 레거시 에뮬레이터에 의해 사용되는 오퍼레이팅 시스템 소프트웨어 패키지들의 복수의 이미지들을 저장하도록 추가로 동작 가능하며, 컨테이너 빌더는 또한 레거시 에뮬레이터의 특정 엘리먼트를 포함하는 특정 컨테이너 이미지에 레거시 에뮬레이터의 특정 엘리먼트에 의해 사용되는 임의의 소프트웨어 패키지들의 이미지들을 배치하며;

xii) 컨테이너 빌더는 마이크로서비스 또는 마이크로서비스들의 세트의 바이너리들의 호출들의 시그니처들을 레거시 에뮬레이터에서 동작 가능한 호출들에 대한 명령들로 대체하도록 추가로 동작가능하며;

xiii) 컨테이너 관리 시스템은 복수의 컨테이너들을 생성하도록 동작 가능하며;

xiv) 한 세트의 상보적 이미지들은 공통 포드내의 별도의 컨테이너에서 인스턴스화되며;

xv) 적어도 하나의 컨테이너 이미지의 하나 초과의 사본들은 하나 초과의 별도의 컨테이너들에서 활성화되며;

xvi) 컨테이너 관리 시스템은 복수의 컨테이너들에서 컨테이너들의 수를 변경하도록 동작 가능하며;

xvii) 컨테이너 관리 시스템은 컨테이너들을 분리하기 위해 다양한 자원들을 할당하도록 동작가능하며;

xviii) 컨테이너 관리 시스템은 액티비티 로그 분석기로부터의 정보를 사용하여, 적어도 하나의 컨테이너 이미지의 사본들의 수가 어떻게 하나 초과의 별도의 컨테이너들에 배치되어야 하는지를 결정하고, 복수의 컨테이너들에서 컨테이너들의 수를 결정하며 그리고/또는 별도의 컨테이너들에 할당할 자원들을 결정하도록 동작 가능하며;

xix) 컨테이너 관리 시스템은 스케일러블 컨테이너-기반 시스템의 사용으로부터의 정보를 사용하여, 적어도 하나의 컨테이너 이미지의 사본들의 수가 어떻게 하나 초과의 별도의 컨테이너들에 배치되어야 하는지를 결정하고, 복수의 컨테이너들에서 컨테이너들의 수를 결정하며 그리고/또는 별도의 컨테이너들에 할당할 자원들을 결정하도록 동작가능하며;

xx) 소스 코드 분석기는 모놀리식 레거시 애플리케이션의 데이터베이스로부터 하나 이상의 서브-데이터베이스들 또는 서브-데이터베이스들의 클러스터들을 생성하도록 추가로 동작 가능하며;

xxi) 컨테이너 빌더는 하나 이상의 서브-데이터베이스들 또는 서브-데이터베이스들의 클러스터들을 하나 이상의 컨테이너들에 배치하도록 동작 가능하며; 그리고

xxii) 소스 코드가 변경될 때, 컨테이너-기반 시스템은 소스 코드 변경에 기초하여 업데이트된 바이너리를 포함하도록 적어도 하나의 마이크로서비스 이미지, 적어도 하나의 컨테이너 이미지 및 적어도 하나의 컨테이너를 자동으로 업데이트하도록 동작 가능하다.

본 발명은 스케일러블 컨테이너-기반 시스템을 생성하고 동작하는 방법을 추가로 제공한다. 방법은 레거시 컴퓨팅 환경에서 실행 가능한 모놀리식 레거시 애플리케이션을 파스하고, 모놀리식 레거시 애플리케이션에 의해 수행 가능한 복수의 트랜잭션들에 대응하는 복수의 트랜잭션 정의 벡터들을 생성하기 위해 모놀리식 레거시 애플리케이션의 프로그램 파일들을 파티셔닝하는 단계, 및 각각의 트랜잭션에 대해, 그 트랜잭션에 의해 호출되는 모든 프로그램들을 식별하는 단계를 포함한다. 방법은 복수의 트랜잭션 정의 벡터들을 트랜잭션 상태 리포지토리에 저장하는 단계를 더 포함한다. 방법은, 복수의 트랜잭션들 중 적어도 일부에 대해, 트랜잭션이 모놀리식 레거시 애플리케이션에 의해 수행될 때 어떤 프로그램들이 실제로 사용되는지를 결정함으로써 동적 정의 리포지토리를 생성하는 단계를 더 포함한다. 방법은 복수의 트랜잭션 정의 벡터들을 동적 정의 리포지토리와 비교하고, 복수의 마이크로서비스 정의 벡터들을 생성하기 위해 트랜잭션에서 사용되지 않는 프로그램들을 그의 대응하는 트랜잭션 정의 벡터로부터 제거하는 단계를 더 포함한다. 방법은 복수의 마이크로서비스 벡터들의 각각의 마이크로서비스 정의 벡터에 대해, 레거시 컴퓨팅 환경에서 실행되도록 컴파일링된 바이너리를 포함하는 대응하는 컴파일링된 소스 코드를 로케이팅하며, 복수의 마이크로서비스 이미지들을 형성하기 위해 대응하는 컴파일링된 소스 코드를 포함하는 마이크로서비스 이미지를 생성하는 단계를 더 포함한다. 방법은 복수의 마이크로서비스 이미지들을 마이크로서비스 이미지 리포지토리에 저장하는 단계를 더 포함한다. 방법은 레거시 컴퓨팅 환경과 상이한 컴퓨팅 환경에서 프로그램들을 실행하도록 동작 가능한 레거시 에뮬레이터의 복수의 엘리먼트들의 이미지들을 상보적 컴포넌트 리포지토리에 저장하는 단계를 더 포함하며, 레거시 에뮬레이터의 엘리먼트들은 모놀리식 레거시 애플리케이션의 복수의 기능들 또는 기능들의 세트들에 대응한다. 방법은 복수의 컨테이너 이미지들을 생성하기 위해, 마이크로서비스 이미지 리포지토리로부터의 대응하는 마이크로서비스 이미지 또는 이미지들을 사용하여 그리고 실행될 때 마이크로서비스 또는 마이크로서비스들의 세트에 의해 사용되는 기능들 또는 기능들의 세트들에 대응하는 레거시 에뮬레이터의 레거시 엘리먼트들― 레거시 엘리먼트들은 마이크로서비스 또는 마이크로서비스들의 세트의 바이너리들의 호출들의 시그니처들에 의해 식별됨―에 대한 상보적 컴포넌트 리포지토리로부터의 이미지 파일들을 사용하여 복수의 마이크로서비스들에서 각각의 마이크로서비스 또는 마이크로서비스들의 세트에 대한 컨테이너 이미지를 형성하는 단계를 더 포함한다. 방법은 컨테이너 이미지들을 컨테이너 이미지 리포지토리에 저장하는 단계를 더 포함한다. 방법은 컨테이너 관리 시스템을 사용하여 상이한 컴퓨팅 환경에서 적어도 하나의 컨테이너를 생성하는 단계 및 상이한 컴퓨팅 환경에서 실행 가능한 형태로 컨테이너에 적어도 하나의 컨테이너 이미지를 저장하는 단계를 더 포함한다.

방법은 컨테이너에서 마이크로서비스 또는 마이크로서비스들의 세트를 실행하는 단계를 더 포함한다.

추가 실시예들에 따르면, 이들 모두는 명확히 상호 배타적이지 않은 경우, 앞의 방법과 그리고 서로 결합되고 또한 앞의 방법과 임의의 조합들로 결합될 수 있으며, 본 발명은 또한 다음을 제공한다:

i) 액티비티 로그 분석기를 사용하여 복수의 트랜잭션 정의 벡터들 중 적어도 일부에 대응하는 복수의 동적 트랜잭션 정의 벡터들을 생성하고, 마이크로서비스 정의 최적화기를 사용하여 복수의 마이크로서비스 정의 벡터들을 생성하기 위해 각각의 동적 트랜잭션 정의 벡터를 각각의 대응하는 트랜잭션 정의 벡터와 비교하는 단계;

ii) 액티비티 로그 분석기가 레거시 컴퓨팅 환경에서 모놀리식 레거시 애플리케이션을 실행함으로써 생성된 모놀리식 레거시 애플리케이션의 레거시 액티비티 로그들을 사용하는 단계;

iii) 액티비티 로그 분석기가 에뮬레이터를 사용하여 모놀리식 레거시 애플리케이션을 실행하여 로그 파일들을 생성하고 트랜잭션 실행 동안 모놀리식 레거시 애플리케이션에 의해 어떤 프로그램들이 사용되는지를 결정하는 단계;

iv) 소스 코드 분석기가 액티비티 로그 분석기로부터의 정보를 사용하여 트랜잭션 정의 벡터들을 식별하는 단계;

v) 소스 코드 분석기를 사용하여 복수의 변환 테이블들을 생성하는 단계;

vi) 마이크로서비스 정의 최적화기를 사용하여 마이크로서비스 정의 벡터들을 추가로 최적화하는 단계;

vii) 복수의 트랜잭션들에서 하나 초과의 트랜잭션에 의해 공유되는 프로그램들을 포함하는 추가적인 마이크로서비스 정의 벡터들을 생성함으로써 마이크로서비스 정의 최적화기를 사용하여 마이크로서비스 정의 벡터들을 추가로 최적화하는 단계;

viii) 레거시 컴퓨팅 환경에서 실행되도록 컴파일링된 바이너리들을 포함하는 컴파일링된 소스 코드를 바이너리 리포지토리에 저장하는 단계;

ix) 소스 코드 리포지토리의 소스 코드로부터의 바이너리 리포지토리의 소스 코드를 바이너리 파일들로 컴파일링하는 단계;

xi) 상보적 컴포넌트 리포지토리가 레거시 에뮬레이터에 의해 사용되는 오퍼레이팅 시스템 소프트웨어 패키지들의 복수의 이미지들을 저장하고, 그리고 컨테이너 빌더가 또한 레거시 에뮬레이터의 특정 엘리먼트를 포함하는 특정 컨테이너 이미지에 레거시 에뮬레이터의 특정 엘리먼트에 의해 사용되는 임의의 소프트웨어 패키지들의 이미지들을 배치하는 단계;

xii) 컨테이너 빌더가 마이크로서비스 또는 마이크로서비스들의 세트의 바이너리들의 호출들의 시그니처들을 레거시 에뮬레이터에서 동작 가능한 호출들에 대한 명령들로 대체하는 단계;

xiii) 컨테이너 관리 시스템을 사용하여 복수의 컨테이너들을 생성하는 단계;

ix) 공통 포드내의 별도의 컨테이너에서 한 세트의 상보적 이미지들을 인스턴스화하는 단계;

x) 하나 초과의 별도의 컨테이너들에서 적어도 하나의 컨테이너 이미지의 하나 초과의 사본들은 활성화하는 단계;

xi) 컨테이너 관리 시스템이 복수의 컨테이너에서 컨테이너의 수를 변경하는 단계;

xii) 컨테이너 관리 시스템이 컨테이너들을 분리하기 위해 다양한 자원을 할당하는 단계;

xiii) 컨테이너 관리 시스템은 액티비티 로그 분석기로부터의 정보를 사용하여, 적어도 하나의 컨테이너 이미지의 사본들의 수가 어떻게 하나 초과의 별도의 컨테이너들에 배치되어야 하는지를 결정하고, 복수의 컨테이너들에서 컨테이너들의 수를 결정하며 그리고/또는 별도의 컨테이너들에 할당할 자원들을 결정하는 단계;

xiv) 컨테이너 관리 시스템은 스케일러블 컨테이너-기반 시스템의 사용으로부터의 정보를 사용하여, 적어도 하나의 컨테이너 이미지의 사본들의 수가 어떻게 하나 초과의 별도의 컨테이너들에 배치되어야 하는지를 결정하고, 복수의 컨테이너들에서 컨테이너들의 수를 결정하며 그리고/또는 별도의 컨테이너들에 할당할 자원들을 결정하는 단계;

xv) 소스 코드 분석기가 모놀리식 레거시 애플리케이션의 데이터베이스로부터 하나 이상의 서브-데이터베이스들 또는 서브-데이터베이스들의 클러스터들을 생성하는 단계;

xvi) 컨테이너 빌더가 하나 이상의 컨테이너들에 하나 이상의 서브-데이터베이스들 또는 서브-데이터베이스들의 클러스터들을 배치하는 단계.

xvii) 소스 코드가 변경될 때, 소스 코드 변경에 기초하여 업데이트된 바이너리를 포함하도록 적어도 하나의 마이크로서비스 이미지, 적어도 하나의 컨테이너 이미지 및 적어도 하나의 컨테이너를 자동으로 업데이트하는 단계.

본 발명의 다양한 실시예들 및 본 발명의 특징들 및 장점들의 보다 완전한 이해를 위해, 이제 첨부 도면들과 함께 다음의 설명을 참조한다.
도 1a는 종래 기술의 하이퍼바이저-기반 가상 머신 환경의 개략도이다.
도 1b는 본 발명과 함께 수정 및 사용될 수 있는 컨테이너-기반 가상화 환경의 개략도이다.
도 2a는 애플리케이션의 트랜잭션들에 대응하는 한 세트의 프로그램 벡터들의 개략도이다.
도 2b는 애플리케이션의 트랜잭션들에 대응하는 한 세트의 최적화된 프로그램 벡터들의 개략도이다.
도 3은 모놀리식 레거시 애플리케이션의 마이크로서비스들로의 파티셔닝하기 위한 스케일러블 컨테이너-기반 시스템의 컴포넌트들을 도시한다.
도 4는 모놀리식 레거시 애플리케이션에서 2개의 트랜잭션들에 대한 호출 트리들의 컴포넌트들을 도시한다.
도 5는 스케일러블 컨테이너-기반 환경에서 마이크로서비스들로서 구현되는, 도 4의 동일한 2개의 트랜잭션들에 대한 호출 트리들을 도시한다.
도 6은 스케일러블 컨테이너-기반 환경에서 마이크로서비스들을 전개하기 위해 모놀리식 레거시 애플리케이션을 파스하기 위한 방법의 단계들을 도시하는 흐름도이다.

본 발명의 일 양상에 따르면, 모놀리식 레거시 애플리케이션을 한 세트의 마이크로서비스들로 자동으로 파티셔닝하고, 레거시 에뮬레이터의 적절한 엘리먼트들을 사용하는 그러한 마이크로서비스들을 컨테이너들에 전개하는 스케일러블 컨테이너-기반 시스템이 제안된다.

상이한 아키텍처들을 갖는 프로세서들은 상이한 바이너리 표현들을 갖는 상이한 명령 세트들을 지원하며, 그 결과 (종종 "바이너리" 또는 "바이너리 이미지"로 지칭되는) 하나의 명령 세트의 머신 명령들을 포함하는 실행가능 프로그램은 일반적으로 상이한 아키텍처 및 상이한 대응하는 명령 세트를 갖는 상이한 프로세서상에서 실행되지 않을 것이다. 따라서, 레거시 프로세서를 포함하는 레거시 메인프레임 컴퓨팅 환경과 같은 레거시 컴퓨팅 환경에서 특정 머신 명령 세트를 사용하여 특정 아키텍처를 갖는 레거시 프로세서에서 실행되도록 설계된 모놀리식 레거시 애플리케이션은 상이한 컴퓨팅 환경에서 상이한 타입의 프로세서상에서 용이하게 실행되지 않을 수 있다. 특히, 본원에서 설명된 스케일러블 컨테이너-기반 시스템들은 모놀리식 레거시 애플리케이션들이 실행되도록 설계된 레거시 컴퓨팅 환경과 별개의 프로세서, 별개의 명령 세트 및 별개의 컴퓨팅 환경을 사용하여 동작한다. 따라서, 모놀리식 레거시 애플리케이션은 본원에서 설명된 것들과 같은, 모놀리식 레거시 애플리케이션 및/또는 별개의 컴퓨팅 환경의 수정 없이 스케일러블 컨테이너-기반 시스템의 별개의 컴퓨팅 환경에서 실행되지 않을 것이다.

전형적으로, 별개의 프로세서를 포함하는 별개의 컴퓨팅 환경에서 모놀리식 레거시 애플리케이션을 실행하기 위해, 모놀리식 레거시 애플리케이션은 별개의 아키텍처를 위해 설계된 컴파일러를 사용하여 재-컴파일링되거나, 또는 해당 명령들은 별개의 아키텍처상에서 실행되도록 트랜스코딩되거나, 또는 모놀리식 레거시 애플리케이션은 레거시 아키텍처 번역기(이하, 레거시 애플리케이션 에뮬레이터)상에서 실행되며, 이 레거시 아키텍처 번역기는 별개의 아키텍처를 갖는 별개의 컴퓨팅 환경에서 레거시 컴퓨팅 환경을 위해 컴파일링되는 실행가능 프로그램을 실행할 수 있다. 이는 레거시 소스 코드를 별개의 컴퓨팅 환경으로 컴파일링할 수 있는 적합한 컴파일러가 존재하거나 또는 적합한 트랜스코더 또는 레거시 에뮬레이터가 존재할 때만 가능하다.

따라서, 본 개시내용의 스케일러블 컨테이너-기반 시스템은 적어도 하나의 레거시 에뮬레이터 엘리먼트를 포함한다. 그러나, 스케일러블 컨테이너-기반 시스템은 모놀리식 레거시 애플리케이션에 의해 수행 가능한 모든 각각의 작업을 달성하기 위해 모든 각각의 컨테이너에서 전체 레거시 에뮬레이터의 이미지를 요구하는 것보다 오히려, 마이크로서비스들이 에뮬레이터 엘리먼트들을 사용할 때만 컨테이너들에 레거시 에뮬레이터의 에뮬레이터 엘리먼트들, 이를테면 기능 컴포넌트들의 바이너리 이미지들을 배치함으로써 레거시 에뮬레이터의 사용을 최적화한다. 별도의 에뮬레이터 엘리먼트들은 모놀리식 레거시 애플리케이션 기능들의 다른 상이한 서브세트들을 지원한다.

레거시 에뮬레이터는 또한 전형적으로 입력/출력 기능성과 같이 오퍼레이팅 시스템에 의해 제공되는 다양한 기능성들을 사용한다. 모든 각각의 컨테이너에 전체 오퍼레이팅 시스템의 이미지를 배치하는 것보다 오히려, 스케일러블 컨테이너-기반 시스템은 또한 OS 엘리먼트들을 효과적으로 사용하는 에뮬레이터 엘리먼트들 및 마이크로서비스들을 갖는 컨테이너에, 오퍼레이팅 시스템의 OS 엘리먼트들, 이를테면 기본 컴포넌트들의 바이너리 이미지들을 배치함으로서 오퍼레이팅 시스템의 사용을 최적화한다. 별도의 OS 엘리먼트들은 레거시 에뮬레이터 기능들 및 관련된 모놀리식 레거시 애플리케이션 기능들의 다른 상이한 서브세트들을 지원하다.

스케일러블 컨테이너-기반 시스템은 레코드 생성, 주문, 질의 수행 등과 같이 모놀리식 레거시 애플리케이션을 사용하여 수행될 수 있는 개별 트랜잭션들을 식별할 수 있다. 이후, 스케일러블 컨테이너-기반 시스템은 각각의 개별 트랜잭션에 포함된 프로그램들을 식별한다. 마지막으로, 스케일러블 컨테이너-기반 시스템은 모놀리식 레거시 애플리케이션 외부에서 동일한 트랜잭션을 수행하기 위해 사용되거나 결합될 수 있는 마이크로서비스들을 생성한다. 일부 사례들에서, 모놀리식 레거시 애플리케이션으로부터의 트랜잭션을 구성하는 개별 프로그램들은 별개의 마이크로서비스들에 위치할 수 있다. 다른 사례들에서, 마이크로서비스는 모놀리식 레거시 애플리케이션으로부터의 하나 초과의 프로그램을 포함할 수 있다. 더욱이, 마이크로서비스들이 모놀리식 레거시 애플리케이션으로부터의 트랜잭션들을 효율적으로 달성하기 위해 임의의 방식으로 프로그램들을 그룹화할 수 있기 때문에, 모놀리식 레거시 애플리케이션으로부터의 임의의 하나의 프로그램은 스케일러블 컨테이너-기반 시스템의 단지 하나의 마이크로서비스에만 위치할 수 있거나, 또는 스케일러블 컨테이너-기반 시스템의 다수의 별개의 마이크로서비스들에 위치할 수 있다.

단일 컨테이너 이미지의 마이크로서비스는 스케일러블 컨테이너-기반 시스템을 통해 다수의 병렬 인스턴스들에, 전형적으로 별도의 컨테이너들에 전개될 수 있다. 컨테이너는 하나 초과의 마이크로서비스뿐만 아니라 마이크로서비스(들)가 실행 및 기능할 수 있도록 하는데 필요한 다른 정보를 포함할 수 있다. 마이크로서비스들은 프로그램들이 업데이트될 때 변경들을 필요로 하는 마이크로서비스들의 수를 최소화하고 그리고/또는 최소로 상호의존적이도록 바람직하게 구성될 수 있다. 마이크로서비스 컨테이너 이미지는 애플리케이션 바이너리들로 제한될 수 있고, 이후 포드를 형성하기 위한 일반 유틸리티(에러 로깅(logging), 액티비티 저널링(activity journaling), 보안 등) 컨테이너들과 연관될 수 있다.

스케일러블 컨테이너-기반 시스템은 유연성이 뛰어나, 마이크로서비스들 그 자체의 변경들뿐만아니라, 다른 팩터들 중에서, 컨테이너들의 타입 및 수, 특정 컨테이너 또는 컨테이너들에 그룹화된 마이크로서비스(들), 및 컨테이너들에 포함된 에뮬레이터 엘리먼트들 및 OS 엘리먼트들과 같은 지원 프로그램들, 및 트랜잭션들, 프로그램들, 다른 정보의 변경들 또는 트랜잭션들 또는 마이크서비스들의 사용에 기초하여 특정 컨테이너들 또는 포드들에 전용된 자원들의 변경을 가능하게 한다.

더욱이, 모놀리식 레거시 애플리케이션 또는 그 일부로부터 생성된 마이크로서비스들의 총 수는 모놀리식 레거시 애플리케이션 또는 그 일부에서의 개별 트랜잭션들의 총 수보다 클 수 있다.

도 3은 스케일러블 컨테이너-기반 시스템(300)을 예시한다. 스케일러블 컨테이너-기반 시스템은 모놀리식 레거시 애플리케이션의 소스 코드를 저장하는 소스 코드 리포지토리(305)를 포함할 수 있다. 모놀리식 레거시 애플리케이션의 소스 코드는 예컨대 수백개의 별개의 트랜잭션들(T1, T2, .... Tx)을 개별적으로 또는 그룹들로 수행하도록 설계된 수십개, 수백개 또는 심지어 무려 수만 개의 개별 프로그램 파일들을 포함할 수 있는 모놀리식 COBOL 애플리케이션일 수 있다. 이러한 트랜잭션들의 예들은 데이터베이스 2(DB2) 관계형 데이터베이스 트랜잭션들 또는 데이터 언어 인터페이스(DL/I) 계층 데이터베이스 트랜잭션들을 수행하기 위해 예컨대 고객 정보 제어 시스템(CICS:Customer Information Control System), 또는 정보 관리 시스템(IMS:Information Management System)을 사용할 수 있는 고객 레코드들의 생성, 업데이팅, 이동 또는 삭제를 포함할 수 있다. 컴파일러(310)는 소스 코드를, 바이너리 리포지토리(315)에 저장되는 하나 이상의 바이너리들의 세트로 컴파일링한다.

특정 실시예들에 따르면, 소스 코드 분석기(320)는, 전형적으로 의존성 분석기 컴포넌트를 통해, 소스 코드 리포지토리(305)에 저장된 모놀리식 레거시 애플리케이션에 소스 코드 및 연관된 파일들을 파스하고, 소스코드에서 상호의존성들(호출자 <> 피호출자)을 식별하는 코드 트리를 생성한다. 바람직하게는, 소스 코드 분석기(320)는 CICS, IMS 등과 같은, 거래 시스템의 구성 파라미터들에 정의된 바와 같이 모놀리식 레거시 애플리케이션의 각각의 트랜잭션을 반복한다. 일례에서, 소스 코드 분석기(320)는 소스 코드 리포지토리(305)로부터의 입력으로서, 모놀리식 레거시 애플리케이션과의 상호 작용들에서 사용자들에 의해 인보크될 수 있는 이용 가능한 CICS 트랜잭션 정의들을 식별하는 파일을 수신한다. 바람직하게는, 이러한 파일은 각각의 트랜잭션 및 이의 루트, 또는 트랜잭션을 수행할 때 인보크된 첫 번째 프로그램을 식별한다. 이는 트랜잭션들 중 많은 트랜잭션들에서 처럼 사용되는 EXEC CICS LINK의 피호출자로서 루트 프로그램을 포함할 수 있다. 이러한 예에서, 루트 프로그램은 인터페이스를 핸들링하는 프로그램에 의해 호출되는 첫번째 프로그램을 지칭한다(예컨대, 인터페이스가 3270일 때 SEND/RECEIVE MAP들을 수행하지만 인터페이스가 상이할 때 다른 등가 API들도 수행함). 트랜잭션들을 식별하거나 이들의 서비스들에 기여하는 다른 파일들 또는 포맷들이 사용될 수 있으며, 예컨대 추가 빌드 파일들은 메시지 큐들 및 데이터 소스들과 같이 트랜잭션에 의해 사용하는 자원들에 대한 정의 파일들을 포함할 수 있다.

부가적으로, 소스 코드 분석기(320)는 모놀리식 레거시 애플리케이션의 트랜잭션들 모두에 대한 프로그램 파일들 간의 상호의존성 관계들(카피북들과 같은 자원들에 대한 포함 또는 프로그램들에 대한 호출자 <> 피호출자)을 검출하기 위해 모놀리식 레거시 애플리케이션과 연관된 프로그램 파일들 모두를 파스할 수 있다. 소스 코드 분석기(320) 내의 의존성 분석기는 트랜잭션에 의해 사용되는 프로그램들 간의 호출자-피호출자 또는 포함 관계들을 식별한다. 정적 분석기는 특정 트랜잭션에 대한 소스 코드가 인보크하거나 또는 포함할 수 있는 프로그램들 또는 모듈들을 식별하는 벡터, 또는 벡터들의 세트 또는 그래프의 형태로 호출 또는 포함 트리를 생성할 수 있다.

모놀리식 레거시 애플리케이션의 파티셔닝은 예컨대 SOAP 또는 REST(JSON 또는 다른 데이터 포맷을 가짐)를 통해 액세스 가능한 최소 상호의존성 트랜잭션들의 세트로 애플리케이션을 분할하는 것이 바람직하다. 최소 상호의존성 트랜잭션들의 각각은 레거시 에뮬레이터(325)의 독립적인 인스턴스에서 실행하는 것이 가능할 수 있다. 소스 코드 분석기(320)의 출력은, 각각의 트랜잭션에 대해, 프로그램들의 완전한 세트를 식별하는 프로그램 호출 또는 포함 트리 또는 그래프일 수 있으며, 이는 인보크되거나 또는 사용되어, 프로그램들 간의 호출자-피호출자 또는 포함 관계들과 각각의 트랜잭션을 수행할 수 있다. 도 4는 제1 트랜잭션(T1)이 루트 프로그램 A로 시작하고, 이후 루트 프로그램 A이 프로그램 F 또는 프로그램 D를 호출할 수 있는 그러한 호출 트리의 예이다. 계속 트랜잭션 T1에서, 프로그램 D는 나중에 프로그램 E를 호출할 수 있다. 두 번째 트랜잭션 T2는 루트 프로그램 B로 시작하고, 이후 루트 프로그램 B는 프로그램 C를 호출하거나 또한 동일한 프로그램 D를 호출하며, 이후 프로그램 D는 프로그램 E를 호출할 수 있다.

호출 트리는 각각의 트랜잭션마다 하나씩 제공되거나 또는 모놀리식 레거시 애플리케이션의 가능한 트랜잭션들의 정의된 서브세트마다 하나씩 제공되는 한 세트의 벡터들로 전환되어, 트랜잭션을 수행할 때 인보크될 수 있는 프로그램들을 식별할 수 있다. 도 2a는 트랜잭션 정의 벡터들, 즉 Ta(210), Tb(220), ... Tc(230)의 세트(200)의 예를 도시한다. 이러한 예에서, Ta(210)와 같은 제1 벡터는 제1 트랜잭션을 수행할 때 잠재적으로 호출되는 프로그램들 <P1, P2, ...Px>의 세트를 포함한다. 도 4의 예를 사용할 경우에, 트랜잭션은 T1일 수 있고, 이러한 프로그램들의 세트는 프로그램들 A, F, D 및 E를 포함할 것이다. 제2 트랜잭션 및 제3 트랜잭션에 대응하는 프로그램들 <P2, P3, ...Py> 을 포함하는 제2 예시적인 벡터 Tb(220) 및 프로그램들 <P1, P6, ....Pz>을 포함하는 제3 예시적인 벡터 Tc(230)이 또한 도시된다. 프로그램들의 상이한 수들 및 조합들은 모놀리식 레거시 애플리케이션의 다른 트랜잭션들을 지정할 수 있다.

소스 코드 분석기(320)는 또한, 루트 프로그램의 인터페이스 정의에 기초하여, 데이터 타입들, 메시지들, 메시지 포맷들/바인딩들, 및 메시지 입력들 및 출력들의 세트들을 추출 또는 생성할 수 있으며, 각각의 트랜잭션의 주소들 및 엔드포인트들을 정의할 수 있으며, 그리고 메시지가 예컨대 마이크로서비스 이미지의 일부로서 컨테이너 빌더(330) 및/또는 컨테이너 관리 시스템(335)에 제공될 때 트랜잭션(들)에 대한 인터페이스를 구성하고 정의하는데 사용하기 위한 메시지 구조로 이러한 정보를 전환할 수 있다. 부가적으로, 소스 코드 분석기(320)는 또한 SOAP 프로토콜이 사용되는 경우 WSDL 메시지 인터페이스를 생성할 수 있다. WSDL 메시지 인터페이스는 정의된 데이터 타입들, 메시지들, 포트 타입들, 바인딩들, 포트들 및 서비스 정의 정보를 저장하기 위한 구조를 포함하여, W3C 표준에 정의된 포맷화된 문서일 수 있다. 소스 코드 분석기(320)는 주어진 상황에 대해 다른 프로토콜들(REST 등)과 표현들(JSON)이 바람직한 경우 또한 인터페이스 메시지들의 다른 표현들을 생성할 수 있다. 소스 코드 분석기는 또한 UTF 문자들을 8-비트 EBCDIC 문자들로(그리고 이와 반대로) (또는 ASCII를 포함한 상이한 문자 세트들 사이에서) 변환하는 양방향 데이터-인코딩 전환 테이블들 또는 절차들을 생성하도록 추가로 구성될 수 있으며, 이러한 전환은 트랜잭션들에 기초하여 그리고 요청자 쪽의 트랜잭션들의 인터페이스들에서 마이크로서비스들과 함께 사용될 스크립트/프로그램을 생성함으로써 구현될 수 있다.

스크립트를 통한 트랜잭션 정의 벡터들, 통신 인터페이스 정의 (WSDL, REST) 및 변환 지시들의 세트(200)는 트랜잭션 상태 정의 리포지토리(340)에 저장될 수 있다.

소스 코드 분석기(320)는 또한 트랜스코딩된 프로그램들의 사용을 위한 트랜스코더 경로를 스케일러블 컨테이너-기반 시스템으로 제시하기 위한 트랜스코딩 애플리케이션의 부분을 포함할 수 있다. 이러한 방식으로, 소스 코드 분석기는 또한 Cobol과 같은 자신의 원래의 언어로부터의 소스 코드를 Java와 같은 다른 언어로 전환하는 것을 지원하기 위해 사용될 수 있다. 다른 소스 코드 변환들이 수행될 수 있다. 더욱이, 소스 코드 분석기(320)는 또한 트랜스코딩 애플리케이션의 일부가 아닌 독립형 프로그램의 형태로 사용될 수 있다.

트랜잭션 상태 정의 리포지토리(340)의 각각의 트랜잭션 정의 벡터(210, 220, 230)는 모놀리식 레거시 애플리케이션을 사용하여 실제 트랜잭션들을 수행하는 과정에서 실제로 인보크되는 프로그램들의 슈퍼세트를 포함한다. 흔히, 트랜잭션 애플리케이션들은 결코 인보크되지 않는 많은 프로그램들을 포함한다. 이는 트랜잭션 애플리케이션의 초기 설계, 설계 변형들, 유스 케이스(use case)들의 변경, 트랜잭션 애플리케이션의 다른 부분들에서의 프로그램들 및 이의 피호출자들의 공유 또는 트랜잭션 애플리케이션으로의 다른 진화로 인해 발생할 수 있다. 코드에서 이러한 미사용 프로그램들을 포함하면, 영구 스토리지상에서 여기저기 이동하는데 필요한 오버헤드, 인보크되지 않는 중앙 컴퓨터 메모리 프로그램들로의 로드 및 언로드 뿐만아니라, 네트워크 업데이트들을 통해 트랜잭션 컨테이너들로 컴파일링, 빌딩 또는 이송하는데 있어서의 추가 지연들을 포함하는 다수의 이유들로 인해 컨테이너화된 애플리케이션의 효율성이 감소된다. 마이크로서비스 애플리케이션 이미지들로부터 이들 미사용 프로그램들을 제거하기 위해, 마이크로서비스 정의 최적화기(345)는 트랜잭션 상태 정의 리포지토리(340)로부터 트랜잭션 정의 벡터, 인터페이스 정의 및 전환 테이블들을 추출하고, 그리고 대응하는 마이크로서비스 정의 벡터(260) (270), (280)에 도달하도록 트랜잭션 상태 정의 리포지토리(340)의 트랜잭션 정의 벡터들 (210), (220), (230)에 포함된 미사용 프로그램들을 제거하기 위해 동적 정의 리포지토리(350)에 저장된 동적 정의 벡터를 적용하며, 마이크로서비스 정의 벡터(260) (270), (280)는, 도 2b에 도시된 바와같이, 마이크로서비스들의 추가 개선 및 정의를 펜딩하는 마이크로서비스 정의 최적화기(345)에 의해 중간 상태로 저장되거나 또는 마이크로서비스 이미지 리포지토리(355)에 저장된 마이크로서비스 이미지들을 생성하기 위해 마이크로서비스 이미지 빌더(350)에 의해 프로세싱될 수 있다. 대규모 모놀리식 시스템 레거시 애플리케이션에서, 전형적으로 이러한 방식으로 제거될 수 있는 미사용 프로그램들이 존재할 것이다. 그러나,정적 트랜잭션 상태 분석에 의해 식별된 프로그램들 모두를 사용하는 트랜잭션들의 경우, 마이크로서비스 정의 벡터는 초기 트랜잭션 정의 벡터와 동일할 것이다. 이는 도 2a의 트랜잭션 정의 벡터(220) 및 도 2b의 대응하는 마이크로서비스 정의 벡터(270)에 의해 예시된다.

동적 정의 벡터는 전형적으로 상이한 시스템상에서 실행되거나 레거시 액티비티 로그들을 사용하는 동적 정의 프로세스에 의해 트랜잭션 상태 정의 벡터와 별도로 개발된다. 동적 정의 벡터는 이미 존재할 수 있거나 또는 트랜잭션 정의 벡터들과 병행하여 개발될 수 있다.

동적 정의 프로세스에서, 모놀리식 레거시 애플리케이션이 실행되며, 각각의 트랜잭션은 분석되어 실제로 어떤 프로그램들이 호출되는지 여부를 결정한다. 시스템이 충분한 시간 기간(예컨대, 애플리케이션의 성질에 따라 주, 월, 분기, 년) 동안 실행되거나 모든 실제 유스 케이스들을 인보크하는 데이터의 세트들을 사용할 때, 동적 정의 벡터는 트랜잭션을 수행할 때 실제로 호출되는 프로그램들을 보다 정확하게 식별할 것이다.

대안적으로, 동적 정의 벡터는 프로그램을 또한 포함할 수 있는 정적 트랜잭션 상태 정의 벡터로 시작하여, 이후 실제로 인보크되는 프로그램들만을 선택함으로써 또한 생성될 수 있다. 따라서, 동적 정의 벡터는 프로그램들이 식별될 때 빌드-업될 수 있거나 또는 트랜잭션 상태 정의 벡터로부터 불필요한 프로그램들을 제거함으로써 생성될 수 있다.

일부 시스템들에서, 레거시 컴퓨팅 환경에서 실행되는 모놀리식 레거시 애플리케이션의 기존 레거시 액티비티 로그들(360)은 실세계 트랜잭션들의 실행에 의해 실제로 인보크되는 프로그램을 식별하여 각각의 트랜잭션을 위해 어떤 프로그램들이 사용되는지를 표시하는 프로그램 벡터를 생성하기 위해 액티비티 로그 분석기(365)에 의해 사용된다.

특정 시스템들에서, 모놀리식 레거시 애플리케이션은 레거시 에뮬레이터(325)상에서 실행되고, 에뮬레이터에 의해 생성된 액티비티 로그 데이터는 각각의 트랜잭션을 위해 어느 프로그램들이 사용되는지를 표시하는 프로그램 벡터를 생성하기 위해 액티비티 로그 분석기(365)에 의해 분석된다 . 일부 실시예들에서, 레거시 에뮬레이터(325)는 각각의 트랜잭션에 대한 유스 케이스들의 모든 실제 변형들에 부딪쳤을 때 신뢰를 달성하기에 충분한 시간 기간 동안 각각의 트랜잭션을 실행한다. 대안적으로, 각각의 실제 유스 케이스를 수행하도록 설계된 테스트 트랜잭션들의 정의된 세트가 수행되어, 액티비티 로그 분석기(365)가 모놀로식 레거시 애플리케이션의 트랜잭션들에 의해 어느 프로그램들이 실제로 사용되는지를 유사하게 결정하는 것을 가능하게 할 수 있다.

일부 시스템들에서, 액티비티 로그 분석기(365)는 모놀리식 레거시 애플리케이션의 트랜잭션들에 의해 어떤 프로그램들이 실제로 사용되는지를 결정하기 위하여 레거시 액티비티 로그들(360) 및 레거시 에뮬레이터(325) 둘 모두로부터의 정보를 사용할 수 있다. 예컨대, 레거시 액티비티 로그들(360)이 주어진 트랜잭션에서 사용되고 있는 프로그램의 예들을 포함하지 않는 경우, 레거시 에뮬레이터(325)로부터의 로그들은 프로그램이 해당 트랜잭션에 의해 사용되지 않는다는 결론을 내리기 전에 참조되거나 그 반대일 수 있다. 다른 예에서, 충분한 레거시 데이터가 존재하는 트랜잭션들은 레거시 에뮬레이터(325)에 의한 추가 에뮬레이션 없이 레거시 활동 로그들(360)만을 사용하여 평가될 수 있다. 또 다른 예에서, 레거시 로그 데이터는 마이크로서비스들의 정의에 대한 초기 큐(clue)로서 사용될 수 있다.

액티비티 로그 분석기의 출력은 각각의 트랜잭션에 대해, 실제로 사용된 프로그램들에 대응하는 벡터들을 저장하는 동적 정의 리포지토리(370)에 저장된다.

로드 모듈은 전형적으로 메인프레임 레거시 컴퓨팅 환경의 맥락에서 실행 가능한 프로그램의 전체 또는 일부를 지칭한다. 레거시 에뮬레이터(325)는 z/OS 또는 다른 레거시 컴퓨팅 환경으로부터의 컴파일링된 레거시 애플리케이션 또는 로드 모듈의 실행이 Linux 오퍼레이팅 시스템을 갖는 x86 플랫폼과 같은 개별 컴퓨팅 환경에서 실행될 수 있도록 개발된 에뮬레이터일 수 있다. 레거시 에뮬레이터는 원래의 실행 가능 프로그램의 각각의 네이티브 명령 또는 네이티브 오퍼레이팅 시스템 서비스 호출을 별개의 컴퓨팅 환경의 등가 명령들 및 시스템 호출들로 변환할 수 있다. 레거시 에뮬레이터(325)는 개별 레거시 명령들 또는 시스템 서비스 호출들의 에뮬레이션을 허용하는 네이티브 API들의 세트를 구현할 수 있다. 레거시 에뮬레이터(325)는 전체 에뮬레이터의 단일 이미지일 수 있거나 또는 여기에서 더 논의되는 바와 같이 파티셔닝된 이미지들을 포함할 수 있다. 레거시 에뮬레이터(325)는 레거시 에뮬레이터에 의해 실제로 사용되는 오퍼레이팅 시스템 또는 이의 컴포넌트들에 대한 동작가능한 액세스를 더 포함하거나 또는 가질 수 있다.

마이크로서비스 정의 최적화기(345)는 마이크로서비스 이미지들을 생성하기 위해 마이크로서비스 이미지 빌더(350)에 의해 사용될 수 있는 마이크로서비스 정의 벡터들에 도달하도록 동적 정의 리포지토리(370)에 저장된 동적 트랜잭션 벡터들을 트랜잭션 상태 정의 리포지토리(340)에 저장된 트랜잭션 정의 벡터들에 적용한다. 이후, 이들 이미지들은 마이크로서비스 이미지 리포지토리(355)에 저장된다.

도 2b는 마이크로서비스 정의 벡터들, 즉 MSa(260), MSb(270), ... MSc(280)의 세트(250)의 예를 도시한다. 이러한 예에서, 제1 마이크로서비스 정의 벡터 Msa(260)는 제1 트랜잭션 Ta를 수행할 때 호출되는 프로그램들 <P1b, ...Px-qb>의 세트로 만들어진 최적화된 벡터를 포함한다. 이러한 예에서, 프로그램 P2는 트랜잭션 Ta에서 실제로 사용되지 않으므로 마이크로서비스 정의 벡터로부터 제거된다. 제2 예시적인 마이크로서비스 정의 벡터 MSb(270)는 프로그램들 <P2, P3, ...Py>을 포함한다. 이러한 예에서는 트랜잭션 정의 벡터를 구성하는 모든 프로그램들이 사용되어, 마이크로서비스 정의 벡터에 보존된다. 제3 예시적인 마이크로서비스 정의 벡터 MSc(280)는 프로그램들 <P1, P6, ....Pz-y>을 포함한다. 결과적인 아키텍처는 가장 적은 수의 프로그램들에 의해 각각 정의된 Tx개의 트랜잭션들의 세트를 포함한다. 모놀리식 레거시 애플리케이션의 Tx개의 트랜잭션들 중 임의의 트랜잭션들은 이전의 모놀리식 레거시 애플리케이션의 전환된 동작 에서 그리고 정의된 마이크로서비스들 MSx를 인보크할 수 있는 강화 또는 수정된 애플리케이션들 둘 모두에서 독립적으로 호출 가능한 마이크로서비스 MSx로서 정의될 수 있다.

Tx개의 트랜잭션들의 임의의 트랜잭션은 또한 독립적으로 호출 가능한 마이크로서비스들의 세트로 정의될 수 있다. 모놀리식 레거시 애플리케이션으로부터의 Tx개의 트랜잭션들의 총 세트에 대해, 일부 서브세트는 트랜잭션 당 하나의 마이크로서비스에 의해 정의될 수 있는 반면, 다른 서브세트는 트랜잭션 당 마이크로서비스들의 세트에 의해 정의될 수 있다. 예컨대, 도 5에 예시된 바와 같이, 만일 트랜잭션들 T1 및 T2가 공통 프로그램들 D 및 E를 사용하면, 이들 트랜잭션들이 마이크로서비스 정의 최적화기(345)에 의해 마이크로서비스들로 전환될 때, 이러한 공통 프로그램들은 T1의 다른 프로그램들을 포함하는 MS1에 의해 호출되거나 또는 T2의 다른 프로그램들을 포함하는 MS2에 의해 호출될 수 있는 독립적인 마이크로서비스 MS3으로서 그룹화될 수 있다.

마이크로서비스 정의 최적화기(345)는 마이크로서비스 이미지 벡터들 또는 중간 마이크로서비스 이미지 벡터들을 저장한 다음, 추후 추가로 변경 또는 최적화할 수 있다. 예컨대, 마이크로서비스 정의 최적화기(345)는 도 4의 트랜잭션들에 대한 트랜잭션 정의 벡터들이 제시될 때, 중간 마이크로서비스 정의 벡터들 MS1 및 MS2를 먼저 생성할 수 있으며, 이들 둘 모두는 트랜잭션 정의 벡터들에 또한 위치된 프로그램들을 포함한다. 마이크로서비스 정의 최적화기(345)는 도 4의 엘리먼트들 D 및 E에 의해 표시된 바와 같이 이들 마이크로서비스 정의 벡터들 MS1 및 MS2의 공통 컴포넌트들을 인식하고, 첫 번째 2개의 마이크로서비스 정의 벡터들로부터 공통 컴포넌트를 추출할 수 있다. 도 5에 도시된 바와 같이, 제1 및 제2 마이크로서비스들 MS1 및 MS2에 부가하여, 공통 엘리먼트들 D 및 E는 이들 공통 컴포넌트를 포함하고 MS1 또는 MS2에 의해 호출될 수 있는 제3 마이크로서비스 정의 벡터 MS3를 생성하는데 사용된다. 이후, 이러한 최적화된 마이크로서비스 정의 벡터들 MS1, MS2및 MS3은 마이크로서비스 이미지 빌더(350)에 제공된다.

대안적으로, 중간 마이크로서비스 정의 벡터들은 마이크로서비스 정의 최적화기(345)가 아닌 위치에, 이를테면 중간 리포지토리(도시되지 않음)에 저장될 수 있다. 특정 실시예들에서, 중간 마이크로서비스 정의 벡터들은 마이크로서비스 이미지 빌더(350)에 저장되거나 또는 마이크로서비스 이미지 리포지토리(355)에 중간 이미지로서 저장될 수 있고, 이후 최적화된 마이크로서비스 정의 벡터들 또는 마이크로서비스 이미지들로 액세스 및/또는 대체될 수 있다.

컴파일러(310)는 소스 코드 리포지토리(305)의 소스 코드를 컴파일링하여 바이너리 리포지토리(315)에 바이너리들을 생성한다. 컴파일러(310)는 시스템(390) 또는 z/OS 메인프레임과 같은 레거시 컴퓨팅 환경에 대한 바이너리들을 생성하다. 이러한 방식으로, 본원에서 설명된 스케일러블 컨테이너-기반 시스템에서 마이크로서비스 이미지들을 구성하는데 사용되는 바이너리들은 레거시 컴퓨팅 환경에서 실행되는 바이너리들과 동일할 수 있어서, 레거시 컴퓨팅 환경으로부터 스케일러블 컨테이너-기반 시스템으로 모놀리식 레거시 애플리케이션의 점진적 이동(migration) 및 상호운용성을 용이하게 할 수 있다.

마이크로서비스 이미지 빌더(350)는 적용 가능할 경우에 마이크로서비스 정의 벡터들 또는 최적화된 마이크로서비스 정의 벡터들에서 식별된 프로그램들에 대응하는, 바이너리 바이너리 리포지토리(315)로부터의 컴파일링된 바이너리들을 리트리브하고, 마이크로서비스 정의 벡터의 각각의 프로그램에 대한 바이너리 이미지들을 포함하는 각각의 마이크로서비스에 대한 이미지를 생성하기 위해 바이너리들을 결합한다. 마이크로서비스 이미지들은 또한 마이크로서비스 이미지 빌더(350)에 의해 리트리브되는 공유 자원 정의들 등과 같은 연관된 아티팩트(artifact)들 및 정보를 포함할 수 있다. 이들 마이크로서비스 이미지들은 마이크로서비스 이미지 리포지토리(355)에 저장된다.

컨테이너 빌더(375)는 마이크로서비스 이미지 리포지토리(355)에 저장된 특정 마이크로서비스와 연관된 바이너리 이미지(들)를 상보적 컴포넌트 리포지토리(380)에 저장된 바이너리 이미지들과 결합함으로써 컨테이너 이미지들을 구성한다. 상보적 컴포넌트 리포지토리(380)는 레거시 에뮬레이터를 함께 구성하는 에뮬레이터 엘리먼트들의 이미지 파일들의 세트를 저장할 수 있으며, 이 레거시 에뮬레이터는 전형적으로 스케일러블 컨테이너-기반 시스템에 의해 달리 사용되는 레거시 에뮬레이터(325)와 동일하다.

레거시 에뮬레이터는 레거시 엘리먼트들을 형성하기 위해 기능들 또는 기능들의 서브세트들에 의해 파티셔닝될 수 있으며, 이는 본원에서 설명된 컨테이너-기반 시스템에서 레거시 에뮬레이터의 전개에 대한 장점들을 제공한다. 예컨대, 레거시 에뮬레이터에 의해 지원되는 인터페이스들에 대한 명령들의 서브세트들에 대한 지원은 분리될 수 있다. 더욱이, 배치 동작들, CICS 트랜잭션 서비스들, DB2 또는 다른 관계형 데이터베이스 서비스들, IMS 서비스들, 보안, 로깅 또는 다른 능력들에 대한 레거시 에뮬레이터의 지원이 파티셔닝될 수 있다. 이러한 방식으로, 컨테이너의 마이크로서비스들에 의해 사용되는 레거시 에뮬레이터의 개별 레거시 엘리먼트 또는 엘리먼트들의 세트만이 주어진 컨테이너 내에서 실행될 수 있다. 부가적으로, 포드의 컨테이너들에 의해 사용되는 특정 레거시 엘리먼트들은 별도의 컨테이너에 저장된 후, 포드의 다른 컨테이너들의 마이크로서비스들에 의해 액세스될 수 있다. 적합한 레거시 엘리먼트들은 에뮬레이터의 런타임 환경의 추적 및 로깅 기능들을 포함한다. 이러한 셋업은 성능 및/또는 보안을 개선시킬 수 있다.

상보적 컴포넌트 리포지토리(380)는 또한 레거시 에뮬레이터가 사용할 수 있는 오퍼레이팅 시스템으로부터의 소프트웨어 패키지들을 저장할 수 있으며, 이들은 OS 엘리먼트들로 지칭될 수 있다. 예컨대, 개별 시스템 API 컴포넌트들은 또한 별도의 이미지들로서 개별적으로 저장될 수 있다. 일부 예들에서, 개별 패키지들 및 라이브러리 파일들은 Linux 또는 다른 오퍼레이팅 시스템에 의해 제공되는 기능성을 증가시키기 위해 런타임에 결합될 수 있고, 바이너리들은 상보적 컴포넌트 리포지토리(380)에 저장될 수 있다.

컨테이너 빌더(375)는 마이크로서비스 또는 마이크로서비스들의 세트와 연관된 기능성들을 그 마이크로서비스 또는 마이크로서비스들의 세트를 포함하는 컨테이너 이미지에 제공하기 위해 에뮬레이터 엘리먼트들 및/또는 OS 엘리먼트들을 선택적으로 통합할 수 있다. 이러한 방식으로, 각각의 컨테이너에 대한 전체 이미지 크기는 전체 레거시 에뮬레이터 이미지 또는 전체 OS 이미지가 각각의 컨테이너에 포함된 경우 보다 더 작을 수 있다.

레거시 에뮬레이터의 이미지는, 일부 사례들에서, 수백 메가바이트일 수 있다. 다른 한편으로, 특정 기능, 이를테면 특정 배치 프로세스 또는 특정 데이터베이스 트랜잭션을 실행하는 에뮬레이터 엘리먼트들은 단지 수십 메가바이트일 수 있다. 유사하게, 전체 오퍼레이팅 시스템의 이미지는 에뮬레이터 엘리먼트에 의해 사용되는 실제 컴포넌트들의 이미지들보다 몇 배 더 클 수 있다.

따라서, 레거시 에뮬레이터의 에뮬레이터 엘리먼트들로의 파티셔닝, 및 컨테이너 또는 포드의 컨테이너에 전부가 아닌 이러한 엘리먼트들의 포함은 컨테이너 또는 포드의 컨테이너의 마이크로서비스들에 의해 사용되지 않는 전체 레거시 에뮬레이터 또는 에뮬레이터 엘리먼트들의 이미지를 포함하는 달리 동일한 컨테이너 또는 포드와 비교하여 5~7배 만큼 컨테이너 또는 포드를 하우징하는데 사용되는 메모리를 감소시킬 수 있다.

컨테이너 또는 포드의 컨테이너에 전부가 아닌 OS 엘리먼트들의 포함은 컨테이너 또는 포드의 마이크로서비스들 및/또는 에뮬레이터 엘리먼트들에 의해 사용되지 않는 전체 OS 또는 OS 엘리먼트들의 이미지를 포함하는 달리 동일한 컨테이너 또는 포드와 비교하여 5~7배 만큼 컨테이너 또는 포드를 하우징하는데 사용되는 메모리를 유사하게 감소시킬 수 있다.

컨테이너 또는 포드의 컨테이너에 전부가 아닌 에뮬레이터 엘리먼트들 및 전부가 아닌 OS 엘리먼트들 둘 모두를 포함시킴으로써, 컨테이너 또는 포드를 하우징하는데 사용되는 메모리는 또한 컨테이너 또는 포드의 마이크로서비스들에 의해 사용되지 않는 전체 레거시 에뮬레이터 또는 에뮬레이터 엘리먼트들의 이미지, 및 컨테이너 또는 포드의 마이크로서비스들 및/또는 에뮬레이터 엘리먼트들에 의해 사용되지 않는 전체 OS 또는 OS 엘리먼트들의 이미지를 포함하는 달리 동일한 컨테이너 또는 포드와 비교하여 5~7배 만큼 감소될 수 있다. 이러한 사례에서, 레거시 에뮬레이터 및 오퍼레이팅 시스템의 조합을 하우징하는데 필요한 메모리를 감소시키는 데 있어서 레거시 에뮬레이터 크기 및 오퍼레이팅 시스템 크기의 상대적인 감소 기여들은 레거시 에뮬레이터 및 오퍼레이팅 시스템의 상대적인 전체 크기들과 레거시 에뮬레이터 및 오퍼레이팅 시스템의 파티셔닝 정도에 따를 수 있다. 예컨대, 약 10개의 엘리먼트들로 파티셔닝된 200MB 레거시 에뮬레이터와 약 50개의 엘리먼트들로 파티셔닝된 50MB 오퍼레이팅 시스템의 경우에, 에뮬레이터 엘리먼트들을 제거하는 기여들은 전형적으로 오퍼레이팅 시스템 엘리먼트들을 제거하는 기여들 보다 중요할 것이다.

레거시 에뮬레이터는 마이크로서비스들의 가능한 요구들에 대응하는 에뮬레이터 엘리먼트들로 파티셔닝될 수 있다. 예컨대, 관리 콘솔 및 사용자 인터페이스 기능성들과 같은 특정 기능성들은 마이크로서비스들에 의해 요구될 가능성이 없거나, 또는 이러한 아키텍처(385)에 더 적합한 형태로 컨테이너 관리 시스템에 의해 기본적으로 제공될 수 있으며, 따라서 다른 에뮬레이터 엘리먼트들로부터 분리될 수 있고 심지어 상보적 컴포넌트 리포지토리(380)로부터 생략될 수 있다. 보안 엘리먼트들과 같은 다른 에뮬레이터 엘리먼트들은 특별히 파티셔닝될 수 있으며, 따라서 이들은 다른 에뮬레이터 엘리먼트들 및 마이크로서비스들로부터 별도의 컨테이너들에 배치되거나 또는 심지어 새로운 시스템에 의해 제공되는 유사한 서비스들에 의해 대체될 수 있다.

레거시 에뮬레이터는 또한 레거시 에뮬레이터의 다른 엘리먼트들에 의존하는 코어 기능성들을 코어 에뮬레이터 엘리먼트로 배치되도록 파티셔닝될 수 있다. 이러한 엘리먼트는 모든 컨테이너들 또는 포드들이 아닐지라도 대부분의 컨테이너들 또는 포드들에 포함될 수 있다. 종종, 이러한 코어 에뮬레이터 엘리먼트는 다른 에뮬레이터 엘리먼트들 보다 더 큰 총 레거시 에뮬레이터 크기의 비율일 것이다. 예컨대, 코어 에뮬레이터 엘리먼트는 총 레거시 에뮬레이터 크기의 30% 내지 40%일 수 있다.

레거시 에뮬레이터는 전체 컨테이너들이 아닌 포드의 하나의 또는 몇개의 컨테이너들에서 일반적으로 사용될 가능성이 있는 기능성들, 이를테면 보안 기능성들을 보안 에뮬레이터 엘리먼트와 같은 별도의 엘리먼트에 배치하도록 추가로 파티셔닝될 수 있다.

트랜잭션 에뮬레이터를 예로서 사용하면, 적합한 에뮬레이터 엘리먼트들은 또한 온라인/통신 에뮬레이터 엘리먼트(이를테면, 트랜잭션 서비스들에 대한 CICS 및 IMS-TM를 위한 서브프로덕트들을 포함하는 엘리먼트), 관계형 에뮬레이터 엘리먼트(이를테면, DB2를 위한 엘리먼트), 계층적 데이터베이스 에뮬레이터 엘리먼트(이를테면, IMS-DB를 위한 엘리먼트), 데이터세트들/날짜 관리 에뮬레이터 엘리먼트(이를테면, VSAM 파일들 및 순차 파일들을 위한 엘리먼트), 배치 서비스 에뮬레이터 엘리먼트, 및/또는 언어 에뮬레이터 엘리먼트(이를테면, Cobol 및 PL/1를 위한 서브프로덕트들을 갖는 엘리먼트), 보안 에뮬레이터 엘리먼트 및 사용자 인터페이스/관리 콘솔 에뮬레이터 엘리먼트를 포함할 수 있다.

서브프로덕트들은 실제로 컨테이너에 통합된 에뮬레이터 엘리먼트 이미지로부터 제외가능할 수 있다. 예컨대, 온라인/통신 에뮬레이터 엘리먼트는 IMS-TM이 아닌 CICS에 대한 바이너리 이미지들만을 포함할 수 있다.

에뮬레이터 엘리먼트들은 총 레거시 에뮬레이터와 비교하여 크기가 다양할 수 있지만, 전형적으로 비-코어 에뮬레이터 엘리먼트들은 각각 총 레거시 에뮬레이터 크기의 1% 내지 20%, 보다 특히 3% 내지 15%일 수 있다. 함께 사용할 가능성과 같은 다른 팩터들과 함께 총 레거시 에뮬레이터와 비교하여 에뮬레이터 엘리먼트의 크기는 어떤 기능성들이 상이한 에뮬레이터 엘리먼트들로 분리되는지를 결정하는데 사용될 수 있다.

OS 엘리먼트들은 PostgresSQL, LLVM, node.js 등과 같은 다양한 Linux 패키지들과 같은 이용 가능한 패키지들의 형태일 수 있다.

에뮬레이터 엘리먼트들을 동반하는 OS 엘리먼트들의 크기는 또한 어떤 레거시 에뮬레이터 기능성들이 상이한 에뮬레이터 엘리먼트들로 분리되는지를 결정하는데 사용될 수 있다.

일부 스케일러블 컨테이너-기반 시스템들에서, 컨테이너 빌더(375)는 로드 모듈 컴파일러를 포함하고, 로드 모듈 컴파일러는 마이크로서비스 이미지 리포지토리(355)에 저장된 시스템(390) 또는 z/OS 실행 가능 이미지 파일들과 같은 바이너리들을 입력으로서 수신한다. 로드 모듈 컴파일러는 어셈블러 명령들의 모음과 같은, 모놀리식 레거시 애플리케이션에 의한 레거시 컴퓨팅 환경의 프로그램들, 서비스들 또는 기능들에 대한 호출들의 바이너리들에서 모든 시그니처들을 검출한다. 로드 모듈 컴파일러는 이러한 정보를 사용하여, 마이크로서비스 또는 마이크로서비스들의 세트에 의해 사용되는 레거시 에뮬레이터 기능들을 결정할 수 있다. 이후, 컨테이너 빌더(375)는 상보적 컴포넌트 리포지토리(380)의 에뮬레이터 엘리먼트들 사이에서 이러한 기능들을 수행할 수 있는 에뮬레이터 엘리먼트들을 로케이팅할 수 있고, 마이크로서비스 이미지들 또는 마이크로서비스 이미지들의 세트를 갖는 상보적 컴포넌트 리포지토리(380)로부터의 임의의 연관된 OS 엘리먼트들과 함께 에뮬레이터 엘리먼트들을 컨테이너 이미지에 배치할 수 있다. 대안적으로, 컨테이너 빌더(375)는 마이크로서비스 이미지 또는 이미지들의 세트의 컨테이너 이미지와 연관된 컨테이너 이미지에 에뮬레이터 엘리먼트들 및 OS 엘리먼트들의 이미지들을 배치하여, 컨테이너 이미지들 둘 모두가 포드에 배치될 수 있다.

더욱이, 대신에, 로드 모듈 컴파일러는 레거시 에뮬레이터의 레거시 컴퓨팅 환경에서 호출된 동일한 기능 또는 기능들을 호출하기 위한 명령들로 바이너리들의 시그니처 또는 시그니처들을 대체하여, 컨테이너 이미지에 저장될 수 있는 레거시 에뮬레이터-최적화된 마이크로서비스 이미지를 형성할 수 있다. 모놀리식 레거시 애플리케이션 또는 레거시 컴퓨팅 환경 및 레거시 에뮬레이터 또는 스케일러블 컨테이너-기반 시스템의 별개의 컴퓨팅 환경을 위해 생성된 기존 데이터베이스를 사용하여 로케이팅된 대체 명령들 및 시그니처들이 식별될 수 있다. 더욱이, 컨테이너 빌더(375)는 식별된 레거시 기능 호출들을 레거시 에뮬레이터의 네이티브 API들에 대한 호출들로 대체하고 수정된 이미지 또는 이미지들을 구성할 수 있다.

본원에 설명된 바와같이 마이크로서비스 이미지들 또는 컨테이너 이미지들의 임의의 최적화 또는 수정 동안들 또는 이 이후에, 컨테이너 빌더(375)는 컨테이너 이미지 리포지토리(390)에 저장된다. 이어서, 컨테이너 이미지 리포지토리(390)의 컨테이너 이미지들은 컨테이너 관리 시스템(385)에 의해 관리되는 컨테이너들(395)에서 실행된다.

특정 실시예들에 따르면, 컨테이너 이미지 리포지토리(390)는 공용 도커 허브와 구조가 유사한 도커 리포지토리일 수 있다. 이후, 컨테이너 관리 시스템(385)은 바람직하게 도커 컨테이너들을 지원하고 도커 컨테이너들의 최적화된 실행을 가능하게 한다.

컨테이너 관리 시스템(385)은 컨테이너들의 인스턴스화를 스케줄링하는 기능, 컨테이너들을 실행하는 기능, 제어된 양의 컴퓨팅/저장/네트워킹 자원들을 이들에 할당하는 기능, 이들을 업그레이드하는 기능을 결합할 수 있으며 그리고/또는 추가 로깅 및 관리 기능들을 수행하여 시스템의 건강을 추적 및 관리할 수 있다. 특정 실시예들에 따르면, 컨테이너 관리 시스템(385)은 도커 컨테이너들용 쿠버네티드 컨테이너 관리 시스템일 수 있다. 그러나, Amazon ACS, Azure Container Service, Cloud Foundry Diego, CoreOS Fleet, Docker Swarm, Google Container Engine 또는 Mesosphere Marathon 컨테이너 관리 시스템 또는 다른 컨테이너 오케스트레이션 시스템들과 같은 다른 컨테이너 관리 시스템들이 사용될 수 있다. 컨테이너 관리 시스템(385)은 본원에서 설명된 것의 수정들 및 부가들과 함께 도 1b에 설명된 것과 유사할 수 있다. 컨테이너 관리 시스템(385)에 의한 자원들의 선택적인 할당은 컨테이너들이 도커에 기초할 때 그룹들의 사용에 의해 수행될 수 있다.

컨테이너 관리 시스템(385) 전방의 지능형 프록시(미도시)는 최종 사용자의 터미널 에뮬레이터 또는 영구적인 연결을 필요로 하는 임의의 다른 클라이언트 인터페이스와의 영구적인 TCP 연결을 유지할 수 있다. 이러한 프록시는 영구 연결에 대한 요청들을 검색하여, 이러한 요청들을 적절한 서비스 요청들로 변환할 수 있으며, 이들은 이후에 쿠버네티드에 의해 적절할 마이크로서비스 쪽으로 라우팅된다. 지능형 프록시 및 마이크로서비스들에서의 애드혹 래퍼들은 3270 트래픽 또는 임의의 다른 특정 트래픽의 마이크로서비스 요청들 및 응답들로의 캡슐화를 허용한다.

컨테이너들(395) 및 컨테이너 관리 시스템(385)은 서브-시스템(400)에 상주할 수 있다. 서브-시스템(400)은 스케일러블 컨테이너-기반 시스템(300)의 나머지로부터 물리적으로 분리될 수 있고, 스케일러블 컨테이너-기반 시스템(300)을 사용할 때 이용 가능한 동일한 장점들을 달성할 수 있는 독립형 시스템에서 동작할 수 있다 . 예컨대, 서브-시스템(400)은 본원에서 설명된 것과 같은 자원 할당 및 컨테이너 관리 기능들을 수행할 수 있다. 특히, 만일 서브-시스템(400)이 또한 컨테이너 이미지 리포지토리(390)를 포함하면, 컨테이너 관리 시스템(385)은 또한 컨테이너 이미지들을 사용하여 추가 또는 중복 컨테이너들을 생성할 수 있다. 서브-시스템(400)은 모놀로식 레거시 애플리케이션의 마이크로서비스들로의 파티셔닝으로부터 그리고 컨테이너 이미지들에의 단지 필요한 에뮬레이터 엘리먼트들 및 OS 엘리먼트들만의 포함으로부터 여전히 장점을 얻을 수 있다. 그러나, 서브-시스템(400)이 마이크로서비스 정의 벡터들 및 컨테이너 이미지들을 생성하는데 전용되는 스케일러블 컨테이너-기반 시스템(300)의 엘리먼트들이 없기 때문에, 서브-시스템(400)은 이의 컨테이너 이미지들 및 컨테이너들을 자동적으로 업데이트할 수 없다. 대신에, 서브-시스템(400)은 컨테이너 관리 시스템(385)이 컨테이너들(395)에 적용되거나 또는 존재하는 경우, 컨테이너 이미지 리포지토리(390)에 저장되는 업데이트된 컨테이너 이미지를 수신할 수 있다.

예시되지 않은 다른 서브-시스템은 컨테이너들(395), 컨테이너 관리 시스템(385), 컨테이너 이미지 리포지토리(390), 컨테이너 빌더(375) 및 상보적 컴포넌트 리포지토리(380)를 포함할 수 있다. 이러한 서브-시스템은 스케일러블 컨테이너-기반 시스템(300)의 나머지와 물리적으로 분리될 수 있으며, 시스템(300)과 관련하여 설명된 많은 장점들을 달성할 수 있다. 이러한 서브-시스템은 새로운 마이크로서비스 이미지가 제공될 때 컨테이너 이미지들을 업데이트하는 능력을 갖는다. 이러한 서브-시스템은 마이크로서비스 이미지 리포지토리(355) 및/또는 레거시 애플리케이션 에뮬레이터(325))를 더 포함할 수 있지만, 초기에 또는 모놀리식 소스 코드가 업데이트될 때 새로운 마이크로서비스 정의 벡터들 및/또는 마이크로서비스 이미지들을 개발하는 것을 담당하는 컴포넌트들이 부족할 수 있다. 이러한 서브-시스템은 또한 레거시 애플리케이션 에뮬레이터(325)를 포함할 수 있다.

관계형 데이터베이스들을 기초하는 많은 레거시 애플리케이션들은 논문 "A Relational Model of Data for Large Shared Data Banks” CACM 13, No. 6, June 1970”에서 초기에 발표된 Tedd Codd의 관계형 이론에 따라 구성된다. 이러한 레거시 데이터베이스들은 최소 리던던스를 염두에 두고 설계되었으며; 이들의 구조는 보통 가능한 한 정규화되었다. 실제로는 수년에 걸쳐 이러한 이상적인 형태로 변경되었을지라도, 5NF(Fifth Normal Form)는 그들 대부분에 대한 초기 설계 목표였다. 고도의 정규화의 결과는 모놀리식 레거시 애플리케이션에 의해 사용하는 데이터의 다양한 섹션들에 걸쳐 높은 상호의존성이다.

이러한 얽힌 데이터 아키텍처(entangled data architecture)는 동일한 데이터를 직접적으로 (동일한 테이블들에 액세스하는 sql 요청들) 또는 간접적으로 (프로그램 Y에 의해 업데이트된 테이블들의 기준 무결성의 제약들에 의해 수정된 프로그램 X에 의해 액세스되는 테이블들) 공유하는, 모놀리식 레거시 애플리케이션의 프로그램들의 클러스터들에 걸쳐 간접적인 상호의존성들을 생성한다.

그러나, 대부분의 경우들에서, 전형적인 대규모 모놀리식 레거시 애플리케이션은 수천개의 테이블들로 구성된 자신의 대규모 데이터베이스에서 독립적인 데이터의 클러스터들을 여전히 갖는다. 스케일러블 컨테이너-기반 시스템에서, 이러한 클러스터들은, 다양한 시스템 능력들을 개선하기 위해, 각각이 마이크로서비스들의 독립적인 세트들에 의해 사용되는 독립적인 서브-데이터베이스들로 분리되어야 한다. 이후, 이러한 서브-데이터베이스들은 예컨대 별도의 데이터베이스 서버들에서 격리될 수 있으며, 서로 독립적으로 관리될 수 있다. 이는 로컬 데이터 구조 변경들이 글로벌 구조 변경들 보다 운영상의 관점에서 볼 때 실행하기가 더 간단하기 때문에 시스템의 유연성과 민첩성을 전체적으로 증가시킨다. 서브-데이터베이스들로의 데이터베이스들의 이러한 분리는 또한 스케일러블 컨테이너-기반 시스템의 글로벌 가용성을 증가시키는데, 왜냐하면 하나의 서브-데이터베이스 또는 이의 유지의 문제가 다른 데이터베이스들 및 이들을 사용하는 마이크로서비스들에 영향을 미치지 않기 때문이다.

프로그램 의존성들을 식별하는 것과 유사하게, 데이터는 대응하는 트랜잭션들 또는 트랜잭션들의 세트들에서 사용함으로써 데이터 클러스터들을 식별하는 의존성 트리들을 생성함으로써 마이크로서비스 아키텍처에 따라 파티셔닝될 수 있다. 이러한 식별은 소스 코드 분석기(320), 특히 의존성 분석기에 의해 수행될 수 있는데, 왜냐하면 소스 코드 분석기(320)는 앞서 설명된 장점들 중 적어도 일부를 달성하기 위해 서로 분리될 수 있는 서브-데이터베이스들 및 서브-데이터베이스 클러스터들을 전형적으로 벡터들 또는 테이블들의 형태로 생성하도록 모놀리식 레거시 애플리케이션을 파스하기 때문이다.

다양한 마이크로서비스 이미지들은 동일한 서브-데이터베이스들에 대한 유사한 액세스를 공유할 수 있다. 특히, 관계형 데이터베이스 서비스 트랜잭션들은 레거시 에뮬레이터의 다른 기능성들에 대한 트랜잭션들과 별도로 패키징될 수 있으므로, 예컨대 프로세싱 서비스들 및 데이터베이스 서비스들은 궁극적으로 별도의 마이크로서비스로 정의된다.

전체 데이터베이스 또는 서브-데이터베이스들은 여러 마이크로서비스들에 걸쳐 공유될 수 있다. 전체 데이터베이스 또는 서브-데이터베이스들은 짧게 지속되는 프로세싱 컨테이너에 의해 원격으로 액세스되는 별도의 오래 지속되는 데이터베이스 컨테이너들에 위치될 수 있다. 전형적으로, 프로세싱 마이크로서비스들을 갖는 컨테이너들은 프로세싱 마이크로서비스들에 의해 사용되는 관계형 데이터베이스 서비스들 및 서브-데이터베이스들을 하우징하는 하나 이상의 컨테이너들을 갖는 포드에 있을 수 있다.

유사한 타입들의 구조들에서, 소스 코드 분석기를 사용하여 공유 객체들을 검출한 다음에 소스 코드 분석기가 알려주는 컨테이너 빌더를 사용하여 특수화된 자원 컨테이너들에서 지원 객체들을 수집함으로써, 모놀리식 레거시 애플리케이션에서 트랜잭션들에 걸쳐 공유되는 객체들에 대한 지원을 구현될 수 있다. 예컨대, 여러 마이크로서비스들에 존재하는 프로그램들 간에 공유되는 CICS TS 큐들은 이들을 호스팅하는 오래 지속되는 자원 컨테이너에 상주할 수 있다. 이들 공유 객체들 (예컨대, 메모리 세션들, 메시지 큐들, 공유 데이터 객체들)은 레거시 컴퓨팅 환경의 원격 액세스 기능들을 복제하기 위해 초기에 개발된 레거시 에뮬레이터의 원격 액세스 기능들을 통해 원격으로 그러나 투명하게 액세스될 수 있다. CICS 레거시 환경의 경우에서, 이들 기능들은 MRO, IPIC 등과 같은 레거시 기능들의 에뮬레이트된 버전들이다. 공유 메모리 존들(z/OS 시스템의 경우에 CSA, CICS CWA, CICS TCTUA 등)이 검출되고, 분산형 공유 캐시에 배치되며 그리고 다양한 마이크로서비스들에 걸쳐 공유될 때 특정 자원 컨테이너들상의 동일한 원격 액세스 기능들에 의해 원격으로 액세스될 수 있다.

다른 유사한 타입의 구조에서, 데이터 분리를 최대화하기 위해, 쿠버네티드에 대한 초기 서비스 요청 후에 캐스케이드로 서로 동기적으로 호출하는 여러 마이크로서비스들에 걸쳐 있는 트랜잭션들이 구성될 수 있다. 이러한 실시예는 분산형 2-상 커밋(distributed 2-phase commit)과 관련된 이슈들과 함께 데이터베이스 연결 공유 및 분산형 트랜잭션의 추가적인 복잡성을 소개한다.

본원에서 설명된 컨테이너-기반 시스템은 생산 환경에 유연하게 커플링되는 적응적인 통합된 빌드 프로세스를 제공함으로써 빌드 관점에서 변경된 환경을 제시한다. 소스 코드 리포지토리(305)에 저장된 소스 코드가 수정되고 컴파일러(310)에 의해 컴파일링되며 바이너리 리포지토리(315)에 저장될 때, 소스 코드 분석기(320), 트랜잭션 상태 정의 리포지토리(340), 마이크로서비스 정의 최적화기(345) 및 마이크로서비스 이미지 빌더(350)는 변경들에 의해 영향을 받는 트랜잭션들에만 대응하는 마이크로서비스 또는 마이크로서비스들에 대한 업데이트된 마이크로서비스 이미지 또는 마이크로서비스 이미지들의 세트를 구성하는데 사용될 수 있다. 이후, 컨테이너 빌더(375)는 자동적으로 그리고 선택적으로 정의된 구성 절차들을 트리거하며, 컨테이너 빌더에 의해 이전에 추출된 마이크로서비스 정의 벡터들에 기초하여, 업데이트된 마이크로서비스들에 대한 컨테이너 이미지들을 셋업할 수 있으며, 이후 이들은 컨테이너 관리 시스템(385)에 의해 전개될 수 있다. 컨테이너 이미지들은 단순히 마이크로서비스 또는 마이크로서비스들의 세트에 대한 업데이트된 이미지들을 포함할 수 있지만, 필요한 경우, 상보적 컴포넌트 리포지토리(380)로부터의 이미지들에 대한 변경들을 또한 포함할 수 있다. 소스 코드에 대한 더 극단적인 또는 다수의 변경들의 경우에, 마이크로서비스 정의 벡터들이 변경되어, 상이한 마이크로서비스 또는 마이크로서비스들의 세트가 생성될 수 있다. 예컨대, 만일 프로그램들의 공통 세트를 사용하는 상당이 많은 트랜잭션들을 제공하도록 소스 코드가 변경되면, 그 프로그램들의 공통 세트는 도 5의 MS3과 유사하게 별도의 마이크로서비스에 새롭게 배치될 수 있으며, 다른 마이크로서비스들에 대한 기존 및 새로운 마이크로서비스 정의 벡터들은 그에 따라 수정되거나 생성된다.

전체 업데이트 프로세스는 바람직하게 자동화되나, 업데이트된 마이크로서비스들의 전개는 또한 감독 관리 콘솔(administrative management console) (미도시)의 제어하에 놓일 수 있다. 유사하게, 데이터(예컨대, 카피북들, sql 파일들 등)와 같은 다른 정보에 대한 변경들이 존재하는 경우에, 변경에 대한 의존성들이 식별되고 전파되어 빌드 절차들에 자동으로 적응될 수 있다.

예시하자면, 업데이트 프로세스의 자동 단계들은 (1) 소스 코드 리포지토리(310)에 배치된 소스 코드 구조; (2) Jenkins (또는 다른 DevOps 빌드 시스템) 빌드 잡(job) 정의; (3) 메인프레임 바이너리들의 적절한 클러스터링을 통한 도커 이미지 구성; 및 (4) 쿠버네티드 관리 파라미터들을 포함할 수 있다.

스케일러블 컨테이너-기반 시스템의 마이크로서비스 구조는 또한 업데이트에 필요한 변경 횟수와 업데이트를 수행하는데 소요되는 시간 측면에서 장점들을 제공한다. 예컨대, 도 5에 예시된 바와 같이, 프로그램 D 또는 E에 대한 변경들은 트랜잭션들 T1 및 T2에 대해 2개의 별도의 마이크로서비스 빌드들 MS1 및 MS2에서 보다 오히려 마이크로서비스의 빌디 MS3에서만 이루어져야 한다. 상당히 많은 독립적인 마이크로서비스들에 의해 제시되는 고도의 입도(granularity)는 완전 자동화하에서 허용되고 바람직하게는 동작한다.

이러한 마이크로서비스들의 형성은 전체 시스템 관리성을 개선할 수 있는데, 왜냐하면 서브트리를 변경하는 애플리케이션 코드에 대한 업그레이드들 또는 변경들은 애플리케이션 코드를 인보크하는 모든 마이크로서비스들이 아니라 내부 마이크로서비스에 대한 대응 컨테이너들에 대한 업그레이드들만을 야기할 필요가 있기 때문이다.

컨테이너들이 용이하게 구성될 수 있고 컨테이너 이미지가 더 작은 경우 컨테이너 이미지를 컨테이너에 로딩하는 시간이 단축되는 것을 고려해 볼 때, 많은 스케일러블 컨테이너-기반 시스템들에서 마이크로서비스 정의 최적화기(345)는, 특히 도 4 및 도 5에 예시된 바와같이 트랜잭션들이 별도의 마이크로서비스에 배치될 수 있는 공통 프로그램들 또는 프로그램들의 세트들을 사용하는 경우에, 트랜잭션 정의 벡터 마다 다수의 마이크로서비스 정의 벡터들을 생성하기 위한 명령들을 구현할 수 있다. 예컨대, T개의 트랜잭션들은 쉽게 P개의 마이크로서비스들이 될 수 있으며, 여기서, P는 프로그램들의 수이고, T는 모놀리식 레거시 애플리케이션에 의해, 진입 지점들이 더이상 필요하지 않은 경우에 각각의 기존 트랜잭션의 루트 프로그램 그러나 애플리케이션 내에서 (예컨대, CICS 하에서 LINK를 통해) 임의의 호출가능한 프로그램에 의해 지원되는 트랜잭션들에 대한 진입 지점들의 수이다.

주어진 스케일러블 컨테이너-기반 시스템이 포드들을 사용하거나 또는 단지 컨테이너들만을 사용하여 구현될지 여부는 마이크로서비스들이 어떻게 생성되어 정의되는지를 추가로 알릴 수 있다. 예컨대, 포드들을 사용하도록 설계된 스케일러블 컨테이너-기반 시스템에서, 그렇게 설계되지 않은 시스템에서 보다는, 트랜잭션들을 마이크로서비스들로 더 크게 파스할 수 있고 더 최소의 마이크로서비스 정의 벡터들이 가능할 수 있다.

일부 사례들에서, 정의된 별도의 마이크로서비스들의 수에 대한 유일한 제한들은 모놀리식 레거시 애플리케이션의 별도의 프로그램들의 수 및/또는 마이크로서비스 이미지 리포지토리(355) 및/또는 컨테이너들(395)을 하우징하기 위한 스케일러블 컨테이너-기반 시스템에서 이용 가능한 메모리의 수일 수 있다.

더욱이, 주어진 컨테이너 이미지가 임의의 수의 액티브 컨테이너들에 배치될 수 있기 때문에, 스케일러블 컨테이너-기반 시스템은 검사 및 점진적인 업데이트 구현을 가능하게 하는데, 이 경우 일부 컨테이너들은 마이크로서비스 또는 마이크로서비스들의 세트의 구 버전들을 실행하며 더 새로운 컨테이너들은 업데이트된 마이크로서비스 또는 마이크로서비스들의 세트를 실행한다. 이는 필요한 경우 마이크로서비스 또는 마이크로서비스들의 세트의 구 버전을 사용하여 트랜잭션을 수행하는 능력을 유지하면서 업데이트들이 실패들에 대하여 검사되고 테스트될 수 있게 한다. 일단 업데이트가 충분히 검증되었으면, 마이크로서비스들의 구 버전을 실행하는 컨테이너들은 자동으로 티어-다운될 수 있다(또는 사용자 명령에 기초하여 제거될 수 있다).

더욱이, 컨테이너들이 쉽게 구축 및 티어-다운될 수 있기 때문에, 만일 일부 컨테이너들에서 트랜잭션이 실행중이면, 업데이트들을 갖는 새로운 컨테이너들은 그 트랜잭션에 대해 새로운 요청들을 수행하도록 구축될 수 있는 반면에, 트랜잭션은 업데이트가 없는 기존 컨테이너들에서 종료하며, 기존 컨테이너들은 컨테이너들이 즉시 실행중인 트랜잭션을 완료할 때 자동적으로 티어-다운될 수 있다. 따라서, 예컨대, 만일 10개의 컨테이너들 C1-C10이 트랜잭션 T1을 실행중인 경우, 대응하는 MS1에 대한 업데이트가 발생할 때, 컨테이너 관리 시스템(385)은 트랜잭션에 대한 새로운 요청이 수신될 때 자동으로 새로운 컨테이너 C11을 생성할 수 있다. 컨테이너 C11은 업데이트된 마이크로서비스 MS1'의 이미지를 포함한다. 컨테이너(C1)가 실행중인 트랜잭션을 그 컨테이너(C1)가 완료할 때, 컨테이너(C1)에 새로운 트랜잭션들이 할당되지 않고 컨테이너(C1)는 티어-다운된다. 업데이트된 마이크로서비스(MS1')를 갖는 새로운 컨테이너는 C1을 대체하도록 즉시 구축될 수 있거나, 컨테이너들을 생성 및 관리하기 위한 컨테이너 관리 시스템(385)에 의해 적용되는 파라미터들에 따라 트랜잭션(T1)에 대한 새로운 요청이 들어올 때 구축될 수 있다 .

도커 및 쿠버네티드와 같은 기술들은 웹 스케일에서 작동하여, 결과적으로 더 많은 요청들이 도착함에 따라 점점 더 많이 추가되는 x86 머신들상에 확산될 수 있는 워크로드들의 매우 빠른 성장을 가능하게 하도록 설계되었다. 이는 바로 쿠버네티드와 같은 오케스트레이터의 목적이다. 온라인 고객 트랜잭션들이 트랜잭션을 완료하기 전에 점점 더 많은 수의 질의들에 응답해야 할 요구가 더 커짐에 따라, 온라인 상거래의 요구들로 인해, 레거시 컴퓨팅 환경들이 온라인 마켓플레이스에 확장하는 확장성 문제들이 발생한다. 본원에서 설명된 것과 같은 컨테이너-기반 시스템의 확장성은 소비자-집약적 질의 애플리케이션들에 전용된 컨테이너들의 확산을 가능하게 함으로써 이러한 레거시 컴퓨팅 환경들의 확장성을 증가시키는 데 특히 유리하다. 게다가, 각각의 컨테이너 이미지 또는 일부 사례들에서 각각의 포드가 일부 OS 엘리먼트들 및 일부 에뮬레이터 엘리먼트들을 포함하기 때문에, 이는 Linux 오퍼레이팅 시스템의 사용과 같은 별개의 컴퓨팅 환경이 보존되는 한, 하드웨어의 일 피스로부터 하드웨어의 다른 피스로 쉽게 복제 또는 이동될 수 있다.

격리된 컨테이너들에 의해 제공되는 격리는 또한 서비스 레벨 관리에서 훨씬 더 정교한 접근법을 제공한다. 각각의 컨테이너에는 다른 마이크로서비스들 보다 (특정 레거시 트랜잭션들에 대응하거나 또는 특정 레거시 트랜잭션들에 의해 사용되는) 일부 마이크로서비스들을 양호하게 서빙하기 위해 상이한 양의 자원들이 할당될 수 있다. 본원에서 설명된 바와 같은 스케일러블 컨테이너-기반 시스템은 컨테이너에 의한 자원 사용량을 자동으로 검출 및 추적하고, 사용량에 기초하여 더 많거나 적은 자원들을 소비할 수 있다. 부가적으로 또는 대안적으로, 컨테이너 관리 시스템은 사용량에 기초하여 특정 마이크로서비스 또는 마이크로서비스들의 세트에 전용되는 컨테이너들의 수를 스케일링할 수 있다. 사용자 정의 우선순위들이 또한 트랜잭션 또는 마이크로서비스에 대응하는 컨테이너들의 수 또는 자원 할당을 위한 계산치들에 포함될 수 있다. 주어진 트랜잭션에게 이용 가능한 자원들의 이러한 사용자-정의 조절은 모놀리식 레거시 애플리케이션에서는 가능하지 않다.

일부 변형들에서, 마이크로서비스들 또는 마이크로서비스들의 세트들을 포함하는 컨테이너 이미지들의 컨테이너 또는 포드들로의 초기 전개는 모놀리식 레거시 애플리케이션이 레거시 컴퓨팅 환경 또는 이의 에뮬레이션에서 실행될 때 트랜잭션 액티비티에 적어도 부분적으로 기초할 수 있다. 이러한 정보는 도 3에 예시된 바와 같이 레거시 에뮬레이터(325)와 같은 레거시 에뮬레이터로부터 유도될 수 있다. 이러한 정보는 또한 레거시 액티비티 로그들(360)과 같은 레거시 액티비티 로그들 또는 액티비티 로그 분석기(365)와 같은 액티비티 로그 분석기(도 3에는 예시되지 않음)로부터 유도될 수 있다.

예컨대, 모놀리식 레거시 애플리케이션을 사용할 때 주어진 트랜잭션에 대한 자원 소비가 종종 정밀하게 모니터링된다. 자원 번호들은, 스케일러블 컨테이너-기반 시스템의 별개의 컴퓨팅 환경에서 유사한 자원 번호들로의 전송 이후에, 스케일러블 컨테이너-기반 시스템, 특히 컨테이너 관리 시스템(385)의 전개 정의 파라미터들에 대한 기초로서, 추출되어 사용될 수 있다.

게다가, 별개의 컨테이너들에서 보안 및 개별 API들 또는 트랜잭션 서비스 지원 사양들을 실행함으로써, 스케일러블 컨테이너-기반 시스템은 필요에 따라 보호된 데이터 및 자원들에 대한 액세스를 제한함으로써 보안을 증가시킨다. 부가적으로, 초기 레거시 애플리케이션의 보안 사양들은 이용 가능한 마이크로서비스들의 세트로 포팅되고, 마이크로서비스 정의 최적화기(345)에 의해 구체적으로 식별되어, 마이크로서비스들에 포함될 수 있다.

도 1b에 도시된 일반적인 타입의 스케일러블 컨테이너-기반 시스템과 같은 스케일러블 컨테이너-기반 시스템의 컨테이너들은, 하이퍼바이저 없이, 스케일러블 컨테이너-기반 시스템이 도 1a에 도시된 타입과 같은 가상 머신과 같은 시스템보다 더 효율적으로 동작할 수 있도록 동작할 수 있으며, 여기서, 하이퍼바이저 또는 다수의 OS 사본들과 같은 추가 컴포넌트들이 또한 동작해야 한다.

앞의 설명에 따른 시스템은 서버 또는 서버 클러스터, 또는 서버 클러스터들의 세트의 컴퓨터 저장 매체와 같은 비-일시적 매체에 저장된 컴퓨터 명령들로 구현될 수 있다. 컴퓨터 명령들은 그러한 시스템상에 설치되기 위해 비-휘발성 고정식 또는 이동식 저장 매체상에 저장될 수 있다. 일 실시예에서, 소스 코드 리포지토리(310), 트랜잭션 상태 정의 리포지토리(340) 및 동적 정의 리포지토리(440)는 공통 리포지토리 시스템에 저장되는 반면, 바이너리 리포지토리(330), 트랜잭션 이미지 리포지토리(360), 상보적 컴포넌트 리포지토리(450) 및 컨테이너 이미지 리포지토리(370)는 공통 바이너리 이미지 리포지토리 시스템에 저장된다. 다른 실시예에서, 컨테이너 이미지 리포지토리(370)는 별도의 플랫폼에 인스턴스화된다. 시스템의 스케일 및 요구에 따라, 상이한 수의 저장 시스템들이 사용될 수 있으며, 소스 및 바이너리 리포지토리들은 공유되거나 또는 별개의 리포지토리 시스템들로 분리될 수 있다.

명령들 및/또는 데이터는 달리 전형적인 방식으로 저장될 수 있다. 예컨대, 바이너리 이미지들은 표준 파일 시스템의 일반적인 계층 구조로 디스크상에 저장될 수 있다. 애플리케이션 데이터는 일반 파일들에 그리고/또는 구조화된 (관계형, 계층적 등) 데이터베이스에 저장될 수 있다.

본 발명의 다른 양상에 따르면, 모놀리식 레거시 애플리케이션의 동작들을 수행하는 스케일러블 컨테이너-기반 시스템을 생성 및/또는 유지하는 방법이 제공된다. 도 6은 그러한 방법의 특정 단계들의 흐름도이다. 그러나, 스케일러블 컨테이너-기반 시스템과 관련하여 앞서 설명된 임의의 기능들이 또한 방법에 포함될 수 있다. 더욱이, 본 방법이 임의의 특정 시스템과 함께 사용되는 것으로 제한되지는 않지만, 본 방법은 앞서 설명된 스케일러블 컨테이너-기반 시스템상에서 구현될 수 있다.

방법(600)은 단계(605)를 포함하며, 이 단계(605)에서 모놀리식 레거시 애플리케이션이 파스되고, 프로그램 파일들이 자동으로 파티셔닝된다. 단계(610)에서, 트랜잭션 루트 프로그램들이 식별된다. 단계(610) 이전 또는 이후에 발생할 수 있는 단계(615)에서, 프로그램 상호의존성들이 식별된다. 단계들(610 및 615)은 복수의 트랜잭션들에서 상이한 트랜잭션들에 대해 동시에 발생할 수 있다.

다음으로, 단계(620)에서, 복수의 트랜잭션 호출 트리들이 식별된다. 바람직하게, 이러한 복수의 트랜잭션 호출 트리들은 모놀리식 레거시 애플리케이션에서 가능한 모든 트랜잭션들 나타내거나 또는 모놀리식 레거시 애플리케이션의 정의된 하위-부분에서 가능한 모든 트랜잭션들을 나타낸다.

단계(625)에서, 복수의 트랜잭션 호출 트리들은 예컨대 트랜잭션 상태 정의 리포지토리에 저장된 복수의 트랜잭션 정의 벡터들을 생성하는데 사용된다.

단계(650)에서, 액티비티 로그 분석기는 모놀리식 레거시 애플리케이션에서 가능한 모든 트랜잭션들 또는 모놀리식 레거시 애플리케이션의 정의된 하위-부분에서 가능한 모든 트랜잭션들에서 실제로 어떤 프로그램들이 사용되는지를 결정한다. 만일 모놀리식 레거시 애플리케이션의 정의된 하위-부분만이 사용된다면, 이 하위-부분은 전형적으로 단계(625)의 하위-부분과 동일하거나, 이 하위-부분의 전체를 포함하거나 또는 이 하위-부분과 적어도 부분적으로 중첩할 것이다. 액티비티 로그 분석기는 자신의 원래 환경에서 실행되는 모놀리식 레거시 애플리케이션의 레거시 액티비티 로그들을 사용하여, 어떤 프로그램들이 트랜잭션들에 실제로 사용되는지를 결정할 수 있다. 대안적으로, 액티비티 로그 분석기는 어떤 프로그램들이 트랜잭션에서 실제로 사용되는지를 결정하기 위해 에뮬레이터를 사용하여 모놀리식 레거시 애플리케이션을 실행할 수 있다. 일부 방법들에서, 동일하거나 상이한 액티비티 로그 분석기들은 레거시 액티비티 로그들 및 에뮬레이터 둘 모두를 사용하여, 어떤 프로그램들이 트랜잭션에 실제로 사용되는지를 결정할 수 있다. 결과들에 기초하여, 동적 정의 리포지토리가 생성된다. 동적 정의 리포지토리는 복수의 트랜잭션들의 각각의 트랜잭션에 사용되는 프로그램들의 로그를 포함한다. 일부 실시예들에서, 이러한 로그는 복수의 동적 정의 벡터들을 포함할 수 있다. 동적 정의 리포지토리는 트랜잭션 상태 정의 리포지토리와 관련하여 정의될 수 있거나 독립적으로 생성될 수 있다.

단계(630)에서, 단계(625)로부터의 복수의 트랜잭션 정의 벡터들은 마이크로서비스 정의 최적화기에 의한 단계(650)로부터의 동적 정의 리포지토리와 비교되며, 트랜잭션에서 실제로 사용되지 않은 프로그램들은 복수의 트랜잭션들에 대응하는 복수의 마이크로서비스 정의 벡터들을 생성하기 위해 각각의 트랜잭션 정의 벡터로부터 제거된다.

단계(635)에서, 마이크로서비스 정의 최적화기는 추가 최적화가 발생할지를 결정한다. 만일 추가 최적화가 발생하면, 단계(640)에서, 복수의 마이크로서비스 정의 벡터 중 적어도 하나가 추가로 최적화되고, 이후 단계(645)에서, 복수의 마이크로서비스 정의 벡터가 마이크로서비스 이미지 빌더로 제공된다. 만일 복수의 마이크로서비스 정의 벡터들 중 임의의 것에 대해 추가 최적화가 발생하지 않으면, 단계(645)에서, 마이크로서비스 정의 벡터가 마이크로서비스 이미지 빌더에 제공된다. 마이크로서비스 정의 벡터들 중 임의의 벡터에 대해 최적화가 발생하는지 여부에 관계없이, 복수의 트랜잭션 벡터들로부터 유도된 복수의 마이크로서비스 정의 벡터들은 단계(645)에서 마이크로서비스 이미지 빌더에 제공된다.

단계(655)에서, 마이크로서비스 이미지 빌더는 복수의 마이크로서비스 정의 벡터들의 각각의 마이크로서비스 정의 벡터를 취하여, 마이크로서비스 이미지 리포지토리의 마이크로 이미지를 형성하기 위해 바이너리 리포지토리로부터 레거시 컴퓨팅 환경에서 실행되도록 컴파일링된 대응하는 컴파일링된 소스 코드를 로케이팅한다. 마이크로서비스 이미지는 또한 자신이 포함하는 프로그램에 의해 사용하는 추가 정보 및 아티팩트들을 포함할 수 있다. 단계(655)가 완료된 후, 마이크로서비스 이미지 리포지토리는 바람직하게 모놀리식 레거시 애플리케이션 또는 이의 정의된 하위-부분에서 가능한 복수의 트랜잭션들 각각에 대응하는 복수의 마이크로서비스 이미지들을 포함한다.

단계(660)에서, 레거시 에뮬레이터의 엘리먼트들의 별도의 이미지들로부터 상보적 컴포넌트 리포지토리가 생성된다. 별도의 엘리먼트들은 레거시 에뮬레이터의 다른 기능들에 대응한다. 레거시 에뮬레이터와 연관된 OS 엘리먼트들의 이미지들은 또한 상보적 컴포넌트 리포지토리에 저장될 수 있다.

단계(665)에서, 컨테이너 빌더는 마이크로서비스 또는 마이크로서비스들을 실행하는데 사용된 레거시 에뮬레이터의 에뮬레이터 엘리먼트들의 상보적 컴포넌트 리포지토리로부터의 이미지들과 함께 마이크로서비스 이미지 리포지토리로부터의 이미지(들)를 사용하여 각각의 마이크로서비스 또는 마이크로서비스들의 세트에 대한 컨테이너 이미지를 형성한다. 레거시 에뮬레이터의 엘리먼트들과 연관된 OS 엘리먼트들의 이미지들과 같은, 상보적 컴포넌트 리포지토리로부터의 다른 이미지들이 또한 컨테이너 이미지에 배치될 수 있다. 에뮬레이터 엘리먼트들은 마이크로서비스 이미지의 바이너리들에서 기능들 또는 프로그램들에 대한 호출들의 시그니처들을 식별하고, 에뮬레이터 엘리먼트들이 호출된 기능들을 수행할 수 있거나 또는 호출된 프로그램들과 동작할 수 있도록 함으로써 선택될 수 있다. 특정 실시예들에서, 각각의 컨테이너 이미지의 적어도 하나의 마이크로서비스 이미지의 적어도 하나의 바이너리는 레거시 에뮬레이터 최적화된 마이크로서비스 이미지를 형성하도록 변경될 수 있으며, 여기서 마이크로서비스 바이너리 이미지에서의 호출의 시그니처는 레거시 에뮬레이터에서 동일한 기능 또는 기능들을 호출하기 위한 명령들로 대체된다.

단계(670)에서, 복수의 컨테이너 이미지들은 컨테이너 이미지 리포지토리에 저장된다.

단계(675)에서, 컨테이너 이미지 리포지토리의 적어도 하나의 컨테이너 이미지는 컨테이너 관리 시스템에 의해 컨테이너에 저장된다. 마이크로서비스 이미지들 그 자체 뿐만 아니라 액티비티 로그 분석기로부터의 정보는 컨테이너 관리 시스템에 의해 사용될 수 있다. 바람직하게, 각각의 컨테이너 이미지는 적어도 하나의 컨테이너에서 활성화된다. 각각의 컨테이너 이미지에는 자원 할당이 배정될 수 있으며, 자원 할당은 컨테이너 이미지가 포함되는 컨테이너 또는 컨테이너들에 할당된 자원들에 반영된다.

단계(680)에서, 컨테이너 관리 시스템의 컨테이너에서 적어도 하나의 마이크로서비스가 실행된다.

많은 예들이 본원에서 제공된다. 이들 예들은 본 발명의 사상을 벗어나지 않고 수정될 수 있다. 예컨대, 다양한 예들 및 실시예들 중 임의의 것은 그들이 명확하게 상호 배타적이지 않으면 서로 조합될 수 있다. 본원에서 설명된 예들 및 실시예들은 예들로서 제공되며, 다른 컴포넌트들, 루틴들 또는 모듈들이 또한 사용될 수 있다.

Claims

비-일시적 매체에 저장된 컴퓨터 명령들로 구현되는 스케일러블 컨테이너-기반 시스템으로서,
복수의 트랜잭션들을 수행하기 위해 레거시 컴퓨팅 환경에서 실행 가능한 복수의 프로그램들을 포함하는 모놀리식 레거시 애플리케이션의 소스 코드를 포함하는 소스 코드 리포지토리;
상기 소스 코드를 파스(parse)하고, 상기 복수의 트랜잭션들의 각각의 트랜잭션에 대해, 상기 트랜잭션 동안 잠재적으로 호출되는 각각의 프로그램을 식별하는 트랜잭션 정의 벡터를 식별하여, 복수의 트랜잭션 정의 벡터들을 생성하도록 동작 가능한 소스 코드 분석기;
상기 복수의 트랜잭션 정의 벡터들을 저장하도록 동작 가능한 트랜잭션 상태 정의 리포지토리;
상기 복수의 트랜잭션들의 적어도 서브세트에서 수행할 때 어떤 프로그램들이 상기 모놀리식 레거시 애플리케이션에 의해 실제로 사용되는지를 식별하는 동적 정의 리포지토리를 생성하도록 동작 가능한 액티비티(activity) 로그 분석기;
상기 복수의 트랜잭션 정의 벡터들을 상기 동적 정의 리포지토리와 비교하고, 상기 트랜잭션 정의 벡터들로부터 미사용 프로그램들을 제거하여, 복수의 마이크로서비스들을 정의하는 복수의 마이크로서비스 정의 벡터들을 생성하도록 동작 가능한 마이크로서비스 정의 최적화기;
상기 복수의 마이크로서비스 정의 벡터들의 각각의 마이크로서비스 정의 벡터에 대해, 상기 마이크로서비스 정의 벡터들에 대응하는 복수의 마이크로서비스 이미지들을 형성하기 위해 상기 레거시 컴퓨팅 환경에서 실행되도록 컴파일링된 컴파일링된 소스 코드 바이너리들을 상기 마이크로서비스 정의 벡터에 의해 식별된 각각의 프로그램에 대해 로케이팅하도록 동작 가능한 마이크로서비스 이미지 빌더;
상기 복수의 마이크로서비스 이미지들을 저장하도록 동작 가능한 마이크로서비스 이미지 리포지토리;
전체적으로 완전한 레거시 에뮬레이터가 아닌, 레거시 에뮬레이터의 에뮬레이터 엘리먼트들의 바이너리 이미지들의 세트를 저장하도록 동작 가능한 상보적 컴포넌트 리포지토리― 상기 이미지들은 상기 레거시 컴퓨팅 환경의 복수의 기능들 또는 기능들의 세트들에 대응하며, 상기 이미지는 상기 레거시 환경의 명령 세트와 다른 명령 세트에 의해 특성화되는 별개의 컴퓨터 환경에서 실행 가능함―;
복수의 컨테이너 이미지들을 생성하기 위해, 상기 마이크로서비스 이미지 리포지토리로부터의 대응하는 마이크로서비스 이미지 또는 이미지들을 사용하여 그리고 실행될 때 상기 마이크로서비스 또는 마이크로서비스들의 세트에 의해 사용되는 기능들 또는 기능들의 세트들에 대응하는 상기 레거시 에뮬레이터의 에뮬레이터 엘리먼트들― 상기 에뮬레이터 엘리먼트들은 상기 마이크로서비스 또는 마이크로서비스들의 세트의 바이너리들의 호출들의 시그니처들에 의해 식별됨 ―에 대한 상기 상보적 컴포넌트 리포지토리로부터의 이미지 파일들을 사용하여 상기 복수의 마이크로서비스들의 각각의 마이크로서비스 또는 마이크로서비스들의 세트에 대한 컨테이너 이미지를 형성하도록 동작가능한 컨테이너 빌더;
상기 별개의 컴퓨팅 환경에서 실행 가능한 상기 복수의 컨테이너 이미지들을 저장하도록 동작 가능한 컨테이너 이미지 리포지토리; 및
상기 별개의 컴퓨팅 환경에서 실행하기 위한 적어도 하나의 컨테이너를 생성하고, 상기 적어도 하나의 컨테이너의 컨테이너 이미지 리포지토리에 저장된 적어도 하나의 마이크로서비스를 실행하도록 동작 가능한 컨테이너 관리 시스템을 포함하는, 스케일러블 컨테이너-기반 시스템.
제1 항에 있어서,
상기 액티비티 로그 분석기는 상기 복수의 트랜잭션 정의 벡터들의 적어도 일부에 대응하는 복수의 동적 트랜잭션 정의 벡터들을 생성하도록 동작 가능하며, 상기 마이크로서비스 정의 최적화기는 상기 복수의 마이크로서비스 정의 벡터들을 생성하기 위해 각각의 동적 트랜잭션 정의 벡터를 각각의 대응하는 트랜잭션 정의 벡터와 비교하는, 스케일러블 컨테이너-기반 시스템.
제1 항 또는 제2 항에 있어서,
상기 액티비티 로그 분석기는 상기 레거시 컴퓨팅 환경에서 상기 모놀리식 레거시 애플리케이션을 실행함으로써 생성되는, 상기 모놀리식 레거시 애플리케이션의 레거시 액티비티 로그들을 사용하는, 스케일러블 컨테이너-기반 시스템.
제1 항 내지 제3 항 중 어느 한 항에 있어서,
상기 액티비티 로그 분석기는 로그 파일들을 생성하기 위해 그리고 트랜잭션들의 실행 동안 어떤 프로그램들이 상기 모놀리식 레거시 애플리케이션에 의해 사용되는지를 결정하기 위해 에뮬레이터를 사용하여 상기 모놀리식 레거시 애플리케이션을 실행하는, 스케일러블 컨테이너-기반 시스템.
제1 항 내지 제 4항 중 어느 한 항에 있어서,
상기 소스 코드 분석기는 상기 트랜잭션 정의 벡터들을 식별하기 위해 상기 액티비티 로그 분석기로부터의 정보를 사용하도록 동작 가능한, 스케일러블 컨테이너-기반 시스템.
제1 항 내지 제5 항 중 어느 한 항에 있어서,
상기 소스 코드 분석기는 복수의 변환 테이블들을 생성하도록 추가로 동작 가능한, 스케일러블 컨테이너-기반 시스템.
제1 항 내지 제6 항 중 어느 한 항에 있어서,
상기 마이크로서비스 정의 최적화기는 상기 마이크로서비스 정의 벡터들을 추가로 최적화하도록 동작 가능한, 스케일러블 컨테이너-기반 시스템.
제 7 항에 있어서,
상기 마이크로서비스 정의 최적화기는 상기 복수의 트랜잭션들의 하나 초과의 트랜잭션에 의해 공유되는 프로그램들을 포함하는 추가 마이크로서비스 정의 벡터들을 생성함으로써 상기 마이크로서비스 정의 벡터들을 추가로 최적화하도록 동작 가능한, 스케일러블 컨테이너-기반 시스템.
제1 항 내지 제8 항 중 어느 한 항에 있어서,
상기 레거시 컴퓨팅 환경에서 실행되도록 컴파일링된 바이너리들을 포함하는 컴파일링된 소스 코드를 저장하도록 동작 가능한 바이너리 리포지토리를 더 포함하는, 스케일러블 컨테이너-기반 시스템.
제9 항에 있어서,
상기 바이너리 리포지토리의 상기 컴파일링된 소스 코드는 상기 소스 코드 리포지토리의 소스 코드로부터 바이너리 파일들로 컴파일링되는, 스케일러블 컨테이너-기반 시스템.
제1 항 내지 제10 항 중 어느 한 항에 있어서,
상기 레거시 컴퓨팅 환경은 MVS(Multiple Virtual Storage) 또는 z/OS 컴퓨터 시스템을 포함하는, 스케일러블 컨테이너-기반 시스템.
제1 항 내지 제11 항 중 어느 한 항에 있어서,
상기 상보적 컴포넌트 리포지토리는 상기 레거시 에뮬레이터에 의해 사용되는 오퍼레이팅 시스템 소프트웨어 패키지들의 복수의 이미지들을 저장하도록 추가로 동작 가능하며, 상기 컨테이너 빌더는 또한 상기 레거시 에뮬레이터의 특정 엘리먼트에 의해 사용되는 임의의 소프트웨어 패키지들의 이미지들을 상기 레거시 에뮬레이터의 특정 엘리먼트를 포함하는 특정 컨테이너 이미지에 배치하는, 스케일러블 컨테이너-기반 시스템.
제1 항 내지 제12 항 중 어느 한 항에 있어서,
상기 컨테이너 빌더는 상기 마이크로서비스 또는 마이크로서비스들의 세트의 바이너리들의 호출의 시그니처들을 상기 레거시 에뮬레이터에서 동작 가능한 호출들에 대한 명령들로 대체하도록 추가로 동작 가능한, 스케일러블 컨테이너-기반 시스템.
제1 항 내지 제13 항 중 어느 한 항에 있어서,
상기 컨테이너 관리 시스템은 복수의 컨테이너들을 생성하도록 동작 가능한, 스케일러블 컨테이너-기반 시스템.
제14 항에 있어서,
상보적 이미지들의 세트는 공통 포드(pod)내의 별도의 컨테이너에서 인스턴스화(instantiate)되는, 스케일러블 컨테이너-기반 시스템.
제14 항 또는 제15 항에 있어서,
적어도 하나의 컨테이너 이미지의 하나 초과의 사본(copy)들은 하나 초과의 별도의 컨테이너들에서 활성화되는, 스케일러블 컨테이너-기반 시스템.
제14 항 내지 제16 항 중 어느 한 항에 있어서,
상기 컨테이너 관리 시스템은 상기 복수의 컨테이너들의 컨테이너들의 수를 변경하도록 동작 가능한, 스케일러블 컨테이너-기반 시스템.
제14 항 내지 제17 항 중 어느 한 항에 있어서,
상기 컨테이너 관리 시스템은 다양한 자원들을 별도의 컨테이너들에 할당하도록 동작 가능한, 스케일러블 컨테이너-기반 시스템.
제14 항 내지 제18 항 중 어느 한 항에 있어서,
상기 컨테이너 관리 시스템은 적어도 하나의 컨테이너 이미지의 사본들의 수가 하나 초과의 별도의 컨테이너들에 어떻게 배치되는지를 결정하고, 상기 복수의 컨테이너들에서의 컨테이너들의 수를 결정하며 그리고/또는 별도의 컨테이너들에 할당할 자원들을 결정하기 위해 상기 액티비티 로그 분석기로부터의 정보를 사용하도록 동작 가능한, 스케일러블 컨테이너-기반 시스템.
제14 항 내지 제19 항 중 어느 한 항에 있어서,
상기 컨테이너 관리 시스템은 적어도 하나의 컨테이너 이미지의 사본들의 수가 하나 초과의 별도의 컨테이너들에 어떻게 배치되는지를 결정하고, 상기 복수의 컨테이너들에서의 컨테이너들의 수를 결정하며 그리고/또는 별도의 컨테이너들에 할당할 자원들을 결정하기 위해 상기 스케일러블 컨테이너-기반 시스템의 사용으로부터의 정보를 사용하도록 동작 가능한, 스케일러블 컨테이너-기반 시스템.
제1 항 내지 제20 항 중 어느 한 항에 있어서,
상기 소스 코드 분석기는 상기 모놀리식 레거시 애플리케이션의 데이터베이스로부터 하나 이상의 서브-데이터베이스들 또는 서브-데이터베이스들의 클러스터들을 생성하도록 추가로 동작 가능한, 스케일러블 컨테이너-기반 시스템.
제1 항 내지 제21 항 중 어느 한 항에 있어서,
상기 컨테이너 빌더는 하나 이상의 컨테이너들에 상기 하나 이상의 서브-데이터베이스들 또는 서브-데이터베이스들의 클러스터들을 배치하도록 동작 가능한, 스케일러블 컨테이너-기반 시스템.
제1 항 내지 제22 항 중 어느 한 항에 있어서,
상기 소스 코드가 변경될 때, 상기 컨테이너-기반 시스템은 상기 소스 코드 변경에 기초하여 업데이트된 바이너리를 포함하기 위해 적어도 하나의 마이크로서비스 이미지, 적어도 하나의 컨테이너 이미지 및 적어도 하나의 컨테이너를 자동으로 업데이트하도록 동작 가능한, 스케일러블 컨테이너-기반 시스템.
스케일러블 컨테이너-기반 시스템을 생성하고 동작시키는 방법으로서,
레거시 컴퓨팅 환경에서 실행 가능한 모놀리식 레거시 애플리케이션을 파스하고, 상기 모놀리식 레거시 애플리케이션에 의해 수행 가능한 복수의 트랜잭션들에 대응하는 복수의 트랜잭션 정의 벡터들을 생성하기 위해 상기 모놀리식 레거시 애플리케이션의 프로그램 파일들을 파티셔닝하며, 각각의 트랜잭션에 대해 그 트랜잭션에 의해 호출되는 모든 프로그램들을 식별하는 단계;
상기 복수의 트랜잭션 정의 벡터들을 트랜잭션 상태 리포지토리에 저장하는 단계;
상기 복수의 트랜잭션들의 적어도 일부에 대해, 상기 트랜잭션이 상기 모놀리식 레거시 애플리케이션에 의해 수행될 때 어떤 프로그램들이 실제로 사용되는지를 결정함으로써 동적 정의 리포지토리를 생성하는 단계;
상기 복수의 트랜잭션 정의 벡터들을 상기 동적 정의 리포지토리와 비교하고, 복수의 마이크로서비스 정의 벡터들을 생성하기 위해 트랜잭션에 사용되지 않는 프로그램들을 그의 대응하는 트랜잭션 정의 벡터로부터 제거하는 단계;
상기 복수의 마이크로서비스 벡터들의 각각의 마이크로서비스 정의 벡터에 대해, 상기 레거시 컴퓨팅 환경에서 실행되도록 컴파일링된 바이너리들을 포함하는 대응하는 컴파일링된 소스 코드를 로케이팅하고 복수의 마이크로서비스 이미지들을 형성하기 위해 대응하는 컴파일링된 소스 코드를 포함하는 마이크로서비스 이미지를 생성하는 단계;
상기 복수의 마이크로서비스 이미지들을 마이크로서비스 이미지 리포지토리에 저장하는 단계;
상기 레거시 컴퓨팅 환경과 상이한 컴퓨팅 환경에서 프로그램들을 실행하도록 동작 가능한 레거시 에뮬레이터의 복수의 엘리먼트들의 이미지들을 상보적 컴포넌트 리포지토리에 저장하는 단계― 상기 레거시 에뮬레이터의 엘리먼트들은 상기 모놀리식 레거시 애플리케이션의 복수의 기능들 또는 기능들의 세트에 대응함― ;
복수의 컨테이너 이미지들을 생성하기 위해, 상기 마이크로서비스 이미지 리포지토리로부터의 대응하는 마이크로서비스 이미지 또는 이미지들을 사용하여 그리고 실행될 때 상기 마이크로서비스 또는 마이크로서비스들의 세트에 의해 사용되는 기능들 또는 기능들의 세트들에 대응하는 상기 레거시 에뮬레이터의 엘리먼트들― 상기 엘리먼트들은 상기 마이크로서비스 또는 마이크로서비스들의 세트의 바이너리들의 호출들의 시그니처들에 의해 식별됨 ―,에 대한 상기 상보적 컴포넌트 리포지토리로부터의 이미지 파일들을 사용하여 상기 복수의 마이크로서비스들의 각각의 마이크로서비스 또는 마이크로서비스들의 세트에 대한 컨테이너 이미지를 형성하는 단계;
상기 컨테이너 이미지들을 컨테이너 이미지 리포지토리에 저장하는 단계;
컨테이너 관리 시스템을 사용하여 상기 상이한 컴퓨팅 환경에서 적어도 하나의 컨테이너를 생성하고, 상기 상이한 컴퓨팅 환경에서 실행 가능한 형태로 상기 컨테이너에 적어도 하나의 컨테이너 이미지를 저장하는 단계; 및
상기 컨테이너에서 상기 마이크로서비스 또는 마이크로서비스들의 세트를 실행하는 단계를 포함하는, 스케일러블 컨테이너-기반 시스템을 생성하고 동작시키는 방법.
제24 항에 있어서,
상기 액티비티 로그 분석기를 사용하여 상기 복수의 트랜잭션 정의 벡터들의 적어도 일부에 대응하는 복수의 동적 트랜잭션 정의 벡터들을 생성하는 단계; 및
상기 마이크로서비스 정의 최적화기를 사용하여 상기 복수의 마이크로서비스 정의 벡터들을 생성하기 위해 각각의 동적 트랜잭션 정의 벡터를 각각의 대응하는 트랜잭션 정의 벡터와 비교하는 단계를 포함하는, 스케일러블 컨테이너-기반 시스템을 생성하고 동작시키는 방법.
제24 항 또는 제25 항에 있어서,
상기 액티비티 로그 분석기가 상기 레거시 컴퓨팅 환경에서 상기 모놀리식 레거시 애플리케이션을 실행함으로써 생성되는, 상기 모놀리식 레거시 애플리케이션의 레거시 액티비티 로그들을 사용하는 단계를 포함하는, 스케일러블 컨테이너-기반 시스템을 생성하고 동작시키는 방법.
제1 항 내지 제26 항 중 어느 한 항에 있어서,
상기 액티비티 로그 분석기가 로그 파일들을 생성하기 위해 그리고 트랜잭션들의 실행 동안 어떤 프로그램들이 상기 모놀리식 레거시 애플리케이션에 의해 사용되는지를 결정하기 위해 에뮬레이터를 사용하여 상기 모놀리식 레거시 애플리케이션을 실행하는 단계를 포함하는, 스케일러블 컨테이너-기반 시스템을 생성하고 동작시키는 방법.
제1 항 내지 제27 항 중 어느 한 항에 있어서,
상기 소스 코드 분석기가 상기 트랜잭션 정의 벡터들을 식별하기 위해 상기 액티비티 로그 분석기로부터의 정보를 사용하는 단계를 포함하는, 스케일러블 컨테이너-기반 시스템을 생성하고 동작시키는 방법.
제1 항 내지 제28 항 중 어느 한 항에 있어서,
상기 소스 코드 분석기를 사용하여 복수의 전환 테이블들을 생성하는 단계를 포함하는, 스케일러블 컨테이너-기반 시스템을 생성하고 동작시키는 방법.
제1 항 내지 제29 항 중 어느 한 항에 있어서,
상기 마이크로서비스 정의 최적화기를 사용하여 상기 마이크로서비스 정의 벡터들을 추가로 최적화하는 단계를 포함하는, 스케일러블 컨테이너-기반 시스템을 생성하고 동작시키는 방법.
제30 항에 있어서,
상기 복수의 트랜잭션들의 하나 초과의 트랜잭션들에 의해 공유되는 프로그램들을 포함하는 추가 마이크로서비스 정의 벡터들을 생성함으로써 상기 마이크로서비스 정의 최적화기를 사용하여 상기 마이크로서비스 정의 벡터들을 추가로 최적화하는 단계를 포함하는, 스케일러블 컨테이너-기반 시스템을 생성하고 동작시키는 방법.
제1 항 내지 제31 항 중 어느 한 항에 있어서,
상기 레거시 컴퓨팅 환경에서 실행되도록 컴파일링된 바이너리들을 포함하는 컴파일링된 소스 코드를 바이너리 리포지토리에 저장하는 단계를 더 포함하는, 스케일러블 컨테이너-기반 시스템을 생성하고 동작시키는 방법.
제32 항에 있어서,
상기 바이너리 리포지토리의 소스 코드를 상기 소스 코드 리포지토리의 소스 코드로부터 바이너리 파일들로 컴파일링하는 단계를 포함하는, 스케일러블 컨테이너-기반 시스템을 생성하고 동작시키는 방법.
제1 항 내지 제33 항 중 어느 한 항에 있어서,
상기 레거시 컴퓨팅 환경은 MVS(Multiple Virtual Storage) 또는 z/OS 컴퓨터 시스템을 포함하는, 스케일러블 컨테이너-기반 시스템을 생성하고 동작시키는 방법.
제1 항 내지 제34 항 중 어느 한 항에 있어서,
상기 상보적 컴포넌트 리포지토리가 상기 레거시 에뮬레이터에 의해 사용되는 오퍼레이팅 시스템 소프트웨어 패키지들의 복수의 이미지들을 저장하는 단계를 포함하며, 상기 컨테이너 빌더는 또한 상기 레거시 에뮬레이터의 특정 엘리먼트에 의해 사용되는 임의의 소프트웨어 패키지들의 이미지들을 상기 레거시 에뮬레이터의 특정 엘리먼트를 포함하는 특정 컨테이너 이미지에 배치하는, 스케일러블 컨테이너-기반 시스템을 생성하고 동작시키는 방법.
제1 항 내지 제35 항 중 어느 한 항에 있어서,
상기 컨테이너 빌더가 상기 마이크로서비스 또는 마이크로서비스들의 세트의 상기 바이너리들의 호출들의 시그니처들을 상기 레거시 에뮬레이터에서 동작 가능한 호출들에 대한 명령들로 대체하는 단계를 포함하는, 스케일러블 컨테이너-기반 시스템을 생성하고 동작시키는 방법.
제1 항 내지 제36 항 중 어느 한 항에 있어서,
상기 컨테이너 관리 시스템을 사용하여 복수의 컨테이너들을 생성하는 단계를 포함하는, 스케일러블 컨테이너-기반 시스템을 생성하고 동작시키는 방법.
제37 항에 있어서,
공통 포드 내의 별도의 컨테이너에서 상보적인 이미지들의 세트를 인스턴스화하는 단계를 포함하는, 스케일러블 컨테이너-기반 시스템을 생성하고 동작시키는 방법.
제37 항 또는 제38 항에 있어서,
하나 초과의 별도의 컨테이너들에서 적어도 하나의 컨테이너 이미지의 하나 초과의 사본들을 활성화시키는 단계를 포함하는, 스케일러블 컨테이너-기반 시스템을 생성하고 동작시키는 방법.
제37 항 내지 제39 항 중 어느 한 항에 있어서,
상기 컨테이너 관리 시스템이 상기 복수의 컨테이너들에서의 컨테이너들의 수를 변경하는 단계를 포함하는, 스케일러블 컨테이너-기반 시스템을 생성하고 동작시키는 방법.
제37 항 내지 제40 항 중 어느 한 항에 있어서,
상기 컨테이너 관리 시스템이 다양한 자원들을 별도의 컨테이너들에 할당하는 단계를 포함하는, 스케일러블 컨테이너-기반 시스템을 생성하고 동작시키는 방법.
제37 항 내지 제41 항 중 어느 한 항에 있어서,
상기 컨테이너 관리 시스템은 적어도 하나의 컨테이너 이미지의 사본들의 수가 하나 초과의 별도의 컨테이너들에 어떻게 배치되는지를 결정하고, 상기 복수의 컨테이너들에서의 컨테이너들의 수를 결정하며 그리고/또는 별도의 컨테이너들에 할당할 자원들을 결정하기 위해 상기 액티비티 로그 분석기로부터의 정보를 사용하는 단계를 포함하는, 스케일러블 컨테이너-기반 시스템을 생성하고 동작시키는 방법.
제37 항 내지 제42 항 중 어느 한 항에 있어서,
상기 컨테이너 관리 시스템은 적어도 하나의 컨테이너 이미지의 사본들의 수가 하나 초과의 별도의 컨테이너들에 어떻게 배치되는지를 결정하고, 상기 복수의 컨테이너들에서의 컨테이너들의 수를 결정하며 그리고/또는 별도의 컨테이너들에 할당할 자원들을 결정하기 위해 상기 스케일러블 컨테이너-기반 시스템으로부터의 정보를 사용하는 단계를 포함하는, 스케일러블 컨테이너-기반 시스템을 생성하고 동작시키는 방법.
제1 항 내지 제43 항 중 어느 한 항에 있어서,
상기 소스 코드 분석기는 상기 모놀리식 레거시 애플리케이션의 데이터베이스로부터 하나 이상의 서브-데이터베이스들 또는 상기 서브-데이터베이스들의 클러스터들을 생성하는 단계를 포함하는, 스케일러블 컨테이너-기반 시스템을 생성하고 동작시키는 방법.
제1 항 내지 제44 항 중 어느 한 항에 있어서,
상기 컨테이너 빌더는 상기 하나 이상의 서브-데이터베이스들 또는 서브-데이터베이스들의 클러스터들을 하나 이상의 컨테이너들에 배치하는 단계를 포함하는, 스케일러블 컨테이너-기반 시스템을 생성하고 동작시키는 방법.
제1 항 내지 제45 항 중 어느 한 항에 있어서,
상기 소스 코드가 변경될 때, 상기 소스 코드 변경에 기초하여 업데이트된 바이너리를 포함하도록 적어도 하나의 마이크로서비스 이미지, 적어도 하나의 컨테이너 이미지 및 적어도 하나의 컨테이너를 자동으로 업데이트하는 단계를 포함하는, 스케일러블 컨테이너-기반 시스템을 생성하고 동작시키는 방법.