![[AIX Solaris HP-UX Linux Windows]](../images/dist.gif)
![[z/OS]](../images/ngzos.gif)
애플리케이션 에디션 관리자 개념
애플리케이션 에디션 관리자 버전과 에디션의 차이점, 애플리케이션을 배치하고 업그레이드하는 방법, 에디션 유효성 검증 및 호환성을 알면 애플리케이션 배치를 관리하기 위해 애플리케이션 에디션 관리자를 충분히 사용할 수 있습니다.
비관리 웹 애플리케이션은 에디션을 사용하여 정의될 수 있습니다. 그러나 여기에서 롤아웃을 수행할 수 없으며 유효성 검증 모드에 배치할 수 없습니다. 비관리 웹 애플리케이션이 지원되며, 지원되는 라이프사이클 관리의 애플리케이션으로서의 특성으로 인해 모든 기능이 사용 가능한 것은 아니라는 점은 예외입니다.
버전 및 에디션
용어 버전과 에디션은 개발 및 빌드 환경에서 발생하는 상태와 배치 및 운영 환경에서 발생하는 상태를 구별합니다. 버전은 인터페이스, 기능, 구현 또는 전체 애플리케이션 등의 연속 생성입니다. 버전은 개발 및 빌드 개념입니다. 에디션은 예를 들어, 버전화된 특정 아티팩트 세트의 배치와 같은 연속 배치 생성입니다. 에디션은 배치 및 운영 개념입니다.
- 기본 에디션은 연관된 에디션 정보가 없는 배치된 애플리케이션을 나타냅니다.
- 에디션 활성화는 애플리케이션 에디션이 존재할 수 있는 두 상태를 구별합니다. 에디션이 처음 설치될 때 에디션은 비활성 상태에 있습니다. 에디션이 활성 상태인 경우에만 에디션을 시작할 수 있습니다. 비활성에서 활성으로의 상태 전이를 활성화라고 합니다.
- 동일한 애플리케이션의 여러 에디션이 활성 상태이고 동시에 시작된 경우 동시 활성화가 있습니다. 동시 활성 에디션은 하나의 사용자 세트에 한 에디션에 대한 액세스를 제공하고 다른 사용자에게 다른 에디션에 대한 액세스를 제공합니다. 예를 들어, 애플리케이션의 새 에디션을 도입하는 경우 선택된 사용자 그룹이 에디션을 테스트하도록 하지만 모든 사용자에게 에디션에 대한 액세스를 제공하지 않을 수 있습니다. 동시 활성화를 사용하여 에디션에 액세스할 수 있는 사용자를 구분하기 위한 라우팅 정책을 설정해야 합니다. 라우팅 정책은 애플리케이션에 대한 구성 메타데이터의 일부분으로 저장됩니다. 또한 라우팅 정책은 모호성을 방지하고 제어를 받는 에디션을 판별합니다. 다음 예는 동시 활성 에디션의 다이어그램입니다.

애플리케이션 업그레이드 및 배치
여러 비즈니스 애플리케이션에는 지속적인 가용성이 필요합니다. 애플리케이션 가용성의 표준은 애플리케이션이 애플리케이션 서버 클러스터에 배치됨을 나타냅니다. 지속적인 가용성을 제공하기 위해 여분의 클러스터가 필요합니다. 인터럽트 없는 애플리케이션 업그레이드는 지속적인 애플리케이션 가용성을 유지하면서 업그레이드가 가능함을 나타냅니다. 즉, 애플리케이션의 사용자는 애플리케이션 업그레이드 중 서비스 유실을 경험하지 않습니다.
- 새 요청 수신으로부터 서버 분리.
- 특정 서버에서 애플리케이션에 대한 요청 작업 정지.
- 현재 활성 에디션 중지.
- 새 에디션 시작.
- 에디션으로 요청 플로우 재개.
애플리케이션 서버 클러스터에서 에디션에 대한 롤아웃을 수행할 때 해당 클러스터에 있는 서버 세트에서 다음 활동을 완료하십시오.
대상 클러스터에 대한 롤아웃을 수행하려면 클러스터를 그룹으로 나누고 한 번에 처리할 노드 수를 지정하는 그룹 크기를 정의할 수 있습니다. 그룹에 대한 롤아웃을 수행하면 각 그룹의 서버가 동시에 새 에디션으로 업그레이드됩니다. 그룹의 각 서버가 작업 정지, 중지 및 재설정됩니다. 관리 콘솔에서 한 번에 하나의 그룹에서만 롤아웃을 수행할 수 있습니다. 새 에디션의 멤버가 사용 가능해지면 모든 요청이 새 에디션으로 라우팅됩니다.
에디션에 대한 롤아웃을 수행하면 클러스터의 일부 서버가 이전 에디션에서 새 에디션으로 이동하고 일부 서버는 상태 전이 중에 있으며 다른 서버는 상태 전이를 시작하지 않았습니다. 모든 애플리케이션 요청은 요청된 애플리케이션의 최신 에디션에 대한 실행 중인 활성 인스턴스가 있는 서버에 전송됩니다. 예를 들어, Edition 1.0에서 2.0으로 롤아웃을 수행할 때 Edition 2.0이 서버에서 사용 가능해지면 Edition 2.0에서 모든 애플리케이션 요청을 처리합니다. Edition 1.0을 계속 실행 중인 서버는 이 서버가 Edition 2.0으로 업데이트될 때까지 요청을 처리하지 않습니다. 다음 예는 그룹 롤아웃의 다이어그램입니다.

에디션에 대한 원자적 롤아웃을 수행하면 모든 사용자 요청을 처리하기 위해 한 번에 클러스터의 1/2에 있는 에디션을 애플리케이션의 일치하는 에디션으로 대체합니다. 모든 사용자 요청은 이전 또는 새 에디션 중 하나에서 처리합니다. 사용자 요청은 두 에디션 모두에서 처리하지 않습니다.
원자적 롤아웃을 사용하면 예를 들어, Edition 1.0 또는 2.0과 같은 일치하는 에디션에서 모든 애플리케이션 요청을 처리하지만 두 에디션에서 모두 처리하지는 않습니다. 현재 사용 가능한 에디션은 클러스터를 구성하는 서버의 1/2에서 오프라인으로 전환됩니다. 해당 서버에서 새 에디션이 활성화되고 시작되지만 해당 서버는 다음 단계가 완료될 때까지 오프라인으로 유지됩니다. 다음 단계는 나머지 서버에서 현재 활성 에디션을 오프라인으로 전환하는 것입니다. 이 때 서버에는 애플리케이션 요청을 처리할 수 있는 한 에디션의 인스턴스가 없습니다. ODR은 이 애플리케이션에 대해 도착하는 요청을 임시로 큐에 대기시킵니다. 애플리케이션이 완전히 오프라인이 되면 클러스터의 처음 1/2은 다시 온라인 상태로 전환됩니다. 클러스터의 다음 1/2은 이전 에디션에서 다음 에디션으로 상태 전이되며 다시 온라인 상태로 전환됩니다. 다음 예는 원자적 롤아웃의 다이어그램입니다.

에디션 유효성 검증 및 호환성
에디션 유효성 검증은 동시 활성화의 특별한 경우를 나타내며 이 때 에디션의 지정된 배치 대상(예: 동적 클러스터)이 복제되고 이 에디션은 복제된 배치 대상에서 시작될 준비가 됩니다. 복제된 배치 대상을 유효성 검증 대상이라고 합니다. 유효성 검증을 수행 중인 에디션으로 전송할 애플리케이션 요청을 지정하려면 라우팅 규칙을 사용해야 합니다. 에디션의 유효성을 검증 중인 경우 에디션은 유효성 검증 모드에 있습니다.
유효성 검증 모드는 애플리케이션의 새 에디션이 현재 사용 가능한 에디션을 오프라인으로 전환하지 않고도 해당 프로덕션 환경에서 기능을 수행하도록 합니다. 일반적으로 애플리케이션 환경 및 설정(예: 연결성 및 데이터베이스 액세스) 측면이 예상대로 작동하는지 확인하기 위해 유효성 검증 모드에 있는 에디션으로 테스트 로드가 전송됩니다. 에디션 유효성 검증 모드로 롤아웃을 수행할 때 에디션이 원래 설치된 배치 대상에서 조작이 발생합니다. 롤아웃을 수행하면 에디션이 유효성 검증 모드를 종료합니다. 유효성 검증이 완료되면 유효성 검증 대상이 삭제됩니다. 다음 예는 에디션 유효성 검증의 다이어그램입니다.

일부 애플리케이션 변경은 투명하지만 다른 애플리케이션 변경은 일반 사용자가 볼 수 있습니다. 애플리케이션 업그레이드가 최소한 마지막 변경과 동일한 API(Application Programming Interface)를 전달하며 필수 동작에 대한 시맨틱 변경이 없는 경우 해당 애플리케이션 에디션은 이전 버전과 호환 가능한 업그레이드입니다. 기존 사용자인 경우 사용 방법을 변경하지 않고 현재 에디션과 이전 에디션 간 차이점을 인식하지 못해도 업그레이드된 애플리케이션을 사용할 수 있습니다.
기존 사용자가 애플리케이션 사용 방법을 변경해야 하는 애플리케이션 업그레이드의 경우는 호환 불가능한 업그레이드입니다. 유지보수성 또는 기타 요인을 개선하기 위해 예를 들어, 이전 기능을 삭제하거나 인터페이스를 변경해야 할 수도 있으며 배치 환경에 호환 불가능한 변경을 도입할 수도 있습니다. 호환 불가능한 변경의 경우 기존 사용자에게 미치는 영향을 관리하는 데 세심한 계획이 필요합니다.