기계 번역으로 제공되는 번역입니다. 제공된 번역과 원본 영어의 내용이 상충하는 경우에는 영어 버전이 우선합니다.
Amazon에서 Oracle에서 Apache Tomcat(TomEE) WebLogic 로 마이그레이션 ECS
작성자: Anya Epishcheva(AWS) 및 Harshad Gohil(AWS)
R 유형: 리플랫포밍 | 소스: 컨테이너 | 대상: Amazon의 Apache Tomcat(TomEE) ECS |
작성자: AWS | 환경: PoC 또는 파일럿 | 기술: 컨테이너 및 마이크로서비스, 마이그레이션 |
워크로드: Oracle | AWS 서비스: Amazon ECS |
요약
이 패턴은 Amazon Elastic Container Service(Amazon)를 사용하여 Oracle을 실행하는 온프레미스 Oracle Solaris SPARC 시스템을 Docker 컨테이너 기반 설치 runningApache TomEE
Oracle에서 WebLogic Tomcat으로 마이그레이션하는 애플리케이션과 연결된 데이터베이스 마이그레이션에 대한 자세한 내용은 이 카탈로그의 데이터베이스 마이그레이션 패턴을 참조하세요.
모범 사례
Java 및 Java Enterprise Edition(Java EE) 웹 애플리케이션을 마이그레이션하는 단계는 애플리케이션에서 사용하는 컨테이너별 리소스 수에 따라 달라집니다. Spring 기반 애플리케이션은 배포 컨테이너에 대한 종속성 수가 적기 때문에 일반적으로 마이그레이션하기가 더 쉽습니다. 반대로 엔터프라이즈 JavaBeans (EJBs)와 스레드 풀, Java 인증 및 권한 부여 서비스(JAAS) 및 컨테이너 관리형 지속성(CMP)과 같은 관리형 컨테이너 리소스를 사용하는 Java EE 애플리케이션은 더 많은 노력이 필요합니다.
Oracle 애플리케이션 서버용으로 개발된 애플리케이션은 Oracle Identity Management 제품군을 사용하는 경우가 많습니다. 오픈 소스 애플리케이션 서버로 마이그레이션하는 고객은 자주 SAML기반 페더레이션을 사용하여 자격 증명 및 액세스 관리를 다시 구현하기로 선택합니다. Oracle Identity Management 제품군에서 마이그레이션할 수 없는 경우 Oracle HTTP Server Webgate를 사용하는 경우도 있습니다.
Java 및 Java EE 웹 애플리케이션은 AWS Fargate 및 Amazon 과 같이 Docker 기반 AWS 서비스에 배포하기 좋은 후보입니다ECS. 고객은 대상 애플리케이션 서버(예: TomEE)의 최신 버전과 Java 개발 키트(JDK)가 사전 설치된 Docker 이미지를 자주 선택합니다. 기본 Docker 이미지 위에 애플리케이션을 설치하고 Amazon Elastic Container Registry(AmazonECR) 레지스트리에 게시한 다음 AWS Fargate 또는 Amazon 에 애플리케이션을 확장하여 배포하는 데 사용합니다ECS.
이상적으로는 애플리케이션 배포가 탄력적입니다. 즉, 트래픽 또는 워크로드에 따라 애플리케이션 인스턴스 수를 확장하거나 축소할 수 있습니다. 즉, 수요에 맞게 용량을 조정하려면 애플리케이션 인스턴스를 온라인 상태로 전환하거나 종료해야 합니다.
Java 애플리케이션을 로 이동할 때는 상태 비저장으로 설정하는 것이 AWS좋습니다. 이는 컨테이너화를 사용하여 수평 조정을 활성화하는 AWS Well-Architected Framework의 주요 아키텍처 원칙입니다. 예를 들어, 대부분의 Java 기반 웹 애플리케이션은 사용자 세션 정보를 로컬에 저장합니다. Amazon Elastic Compute Cloud(Amazon EC2)의 자동 조정 또는 기타 이유로 인해 애플리케이션 인스턴스가 종료되지 않도록 하려면 웹 애플리케이션 사용자가 웹 애플리케이션에 다시 연결하거나 다시 로그인하지 않고도 원활하고 투명하게 작업을 계속할 수 있도록 사용자 세션 정보를 전역에 저장해야 합니다. 이 접근 방식에는 Amazon ElastiCache for Redis 또는 글로벌 데이터베이스에 세션 상태 저장을 비롯한 몇 가지 아키텍처 옵션이 있습니다. TomEE와 같은 애플리케이션 서버에는 Redis, 데이터베이스 및 기타 글로벌 데이터 스토어를 통해 세션을 저장하고 관리할 수 있는 플러그인이 있습니다.
Amazon 및 AWS X-Ray와 쉽게 통합되는 일반적인 중앙 집중식 로깅 CloudWatch 및 디버깅 도구를 사용합니다. 마이그레이션으로 애플리케이션 수명 주기 기능을 개선할 수 있습니다. 예를 들어 지속적 통합 및 지속적 전달(CI/CD) 파이프라인을 사용하여 쉽게 변경할 수 있도록 빌드 프로세스를 자동화할 수 있습니다. 이렇게 하려면 가동 중지 시간 없이 배포할 수 있도록 애플리케이션을 변경해야 할 수 있습니다.
사전 조건 및 제한 사항
사전 조건
활성 AWS 계정
소스 Java 코드 및 JDK
Oracle로 구축된 소스 애플리케이션 WebLogic
자격 증명 및 액세스 관리를 위한 정의된 솔루션(SAML 또는 Oracle Webgate)
애플리케이션 세션 관리를 위한 정의된 솔루션(Amazon을 사용하여 또는 이동 like-for-like ElastiCache하거나 필요한 경우 애플리케이션을 상태 비저장 상태로 설정)
팀에서 Apache TomEE로의 이식성을 위해 J2EE 전용 라이브러리를 리팩토링해야 하는지 여부 이해(Apache 웹사이트의 Java EE 7 구현 상태
참조) 보안 요구 사항을 기반으로 강화된 TomEE 이미지
대상 TomEE가 사전 설치된 컨테이너 이미지
필요한 경우 애플리케이션 문제 해결 합의 및 구현(예: 디버그, 빌드 로깅 및 인증)
제품 버전
Oracle WebLogic OC4J, 9i, 10g
Tomcat 7(Java 1.6 이상)
아키텍처
소스 기술 스택
Oracle을 사용하여 구축된 웹 애플리케이션 WebLogic
Oracle Webgate 또는 SAML 인증을 사용하는 웹 애플리케이션
Oracle Database 버전 10g 이상에 연결된 웹 애플리케이션
대상 기술 스택
Amazon에서 실행되는 TomEE(컨테이너 지원이 추가된 Apache Tomcat)ECS(Amazon에서 ECS
Java 웹 애플리케이션 및 Java Microservices 배포 참조) Amazon Relational Database Service(Amazon RDS) for Oracle, Amazon에서 지원하는 Oracle 버전의 경우 OracleRDS용 Amazon
RDS참조
대상 아키텍처
도구
TomEE에서 작동하려면 Java 애플리케이션을.war 파일로 다시 빌드해야 합니다. 경우에 따라 TomEE에서 애플리케이션을 작동하기 위해 애플리케이션 변경이 필요할 수 있습니다. 필요한 구성 옵션과 환경 속성이 올바르게 정의되었는지 확인해야 합니다.
또한 Java 이름 지정 및 디렉터리 인터페이스(JNDI) 조회 및 JavaServer 페이지(JSP) 네임스페이스를 올바르게 정의해야 합니다. 내장 T 라이브러리와의 충돌 이름 지정을 방지하려면 애플리케이션에서 사용하는 파일 이름을 확인하는 것이 좋습니다. 예를 들어 persistence.xml은 구성 목적으로 Apache OpenJPA 프레임워크(TomEE에서 OpenEJB과 번들로 제공됨)에서 사용하는 파일 이름입니다. 의 persistence.xml 파일에는 Spring 프레임워크 빈 선언이 PUI 포함되어 있습니다.
TomEE 버전 7.0.3 이상(Tomcat 8.5.7 이상)은 특수 문자가 포함된 원시(암호화되지 않음)에 대해 HTTP 400 응답(잘못된 요청)URLs을 반환합니다. 서버 응답은 최종 사용자에게 빈 페이지로 표시됩니다. 이전 버전의 TomEE 및 Tomcat은 에서 특정 인코딩되지 않은 특수 문자를 사용할 수 있도록 허용URLs했지만 CVE-2016-6816 웹 사이트
.war 파일을 TomEE에 배포한 후 Linux cat의 로그 시작에서 누락된 공유 라이브러리가 있는지 확인하고 Oracle 전용 확장 프로그램을 모니터링하여 Tomcat 라이브러리에서 누락된 구성 요소를 추가합니다.
일반 절차
TomEE에서 애플리케이션을 구성합니다.
애플리케이션 서버별 구성 파일 및 리소스를 소스에서 대상 형식으로 식별하고 재구성합니다.
JNDI 리소스를 식별하고 재구성합니다.
대상 애플리케이션 서버에서 요구하는 형식으로 EJB 네임스페이스와 조회를 조정합니다(해당하는 경우).
JAAS 애플리케이션 컨테이너별 보안 역할 및 원칙 매핑을 재구성합니다(해당하는 경우).
애플리케이션 및 공유 라이브러리를 .war 파일로 패키징합니다.
제공된 Docker 컨테이너를 사용하여 .war 파일을 TomEE에 배포합니다.
로그 시작을 모니터링하여 누락된 공유 라이브러리 및 배포 설명자 확장을 식별합니다. 발견된 항목이 있으면 첫 번째 작업으로 돌아갑니다.
설치된 애플리케이션을 복원된 Amazon RDS 데이터베이스와 비교하여 테스트합니다.
Docker Containers 배포
의 지침에 따라 로드 밸런서 및 Amazon ECS 클러스터를 사용하여 전체 아키텍처를 시작합니다. 로드 밸런서를 가리키URLs도록 를 업데이트합니다.
구성 관리 데이터베이스()를 업데이트합니다CMDB.
에픽
| 작업 | 설명 | 필요한 기술 |
|---|---|---|
| 애플리케이션 검색을 수행(현재 상태가 차지하는 공간 및 성능 기준)합니다. | BA, 마이그레이션 책임자 | |
| 소스 및 대상 데이터베이스 버전과 엔진을 검증합니다. | DBA | |
| 소스 및 대상 애플리케이션 디자인(ID 및 세션 관리)을 검증합니다. | DBA, 마이그레이션 엔지니어, 앱 소유자 | |
| 대상 서버 인스턴스의 하드웨어 및 스토리지 요구 사항을 식별합니다. | DBA, SysAdmin | |
| 용량, 스토리지 기능, 네트워크 기능에 따라 적절한 인스턴스 유형을 선택합니다. | DBA, SysAdmin | |
| 소스 및 대상 데이터베이스의 네트워크 액세스 보안 요구 사항을 확인합니다. | DBA, SysAdmin | |
| 애플리케이션 마이그레이션 전략 및 도구를 식별합니다. | DBA, 마이그레이션 수석 | |
| 애플리케이션에 대한 마이그레이션 설계 및 마이그레이션 가이드를 작성합니다. | 빌드 책임자, 마이그레이션 책임자 | |
| 애플리케이션 마이그레이션 런북을 완성합니다. | 빌드 책임자, 전환 리드, 테스트 책임자, 마이그레이션 책임자 |
| 작업 | 설명 | 필요한 기술 |
|---|---|---|
| 가상 프라이빗 클라우드를 생성합니다(VPC). | SysAdmin | |
| 보안 그룹을 생성합니다. | SysAdmin | |
| Amazon RDS DB 인스턴스를 구성하고 시작합니다. | DBA, SysAdmin | |
| Amazon ECS 배포를 구성합니다. | SysAdmin | |
| 애플리케이션을 Docker 이미지로 패키징합니다. | SysAdmin | |
| 이미지를 Amazon ECR 레지스트리로 푸시합니다(또는 이 단계를 건너뛰고 Amazon ECS 클러스터로 푸시). | SysAdmin | |
| 애플리케이션 및 Amazon ECS 서비스 옵션에 대한 작업 정의를 구성합니다. | SysAdmin | |
| 클러스터를 구성하고, 보안 설정을 검토하고, AWS 자격 증명 및 액세스 관리(IAM) 역할을 설정합니다. | SysAdmin | |
| 설정을 시작하고 애플리케이션 마이그레이션 런북에 따라 테스트를 실행합니다. | SysAdmin |
| 작업 | 설명 | 필요한 기술 |
|---|---|---|
| 프로덕션 데이터를 로 이동할 수 있는 보안 보증 팀의 권한을 얻습니다AWS. | DBA, 마이그레이션 엔지니어, 앱 소유자 | |
| 데이터베이스 백업 파일을 가져오기 위한 엔드포인트를 생성하고 이에 대한 액세스 권한을 확보합니다. | DBA | |
| 네이티브 데이터베이스 엔진 또는 타사 도구를 사용하여 데이터베이스 객체 및 데이터를 마이그레이션합니다. | DBA | |
| 애플리케이션 마이그레이션 런북에서 필요한 테스트를 실행하여 성공적인 데이터 마이그레이션을 확인합니다. | DBA, 마이그레이션 엔지니어, 앱 소유자 |
| 작업 | 설명 | 필요한 기술 |
|---|---|---|
| 마이그레이션을 위한 변경 요청(CR)을 생성합니다. | 전환 리드 | |
| 마이그레이션을 위한 CR 승인을 받습니다. | 전환 리드 | |
| 애플리케이션 마이그레이션 런북의 애플리케이션 마이그레이션 전략을 따릅니다. | DBA, 마이그레이션 엔지니어, 앱 소유자 | |
| 애플리케이션을 업그레이드합니다(필요한 경우). | DBA, 마이그레이션 엔지니어, 앱 소유자 | |
| 기능, 비기능, 데이터 검증, SLA및 성능 테스트를 완료합니다. | 테스트 책임자, 앱 소유자, 앱 사용자 |
| 작업 | 설명 | 필요한 기술 |
|---|---|---|
| 애플리케이션 또는 비즈니스 소유자로부터 승인을 받습니다. | 전환 리드 | |
| 테이블 주제 연습을 실행하여 전환 런북의 모든 단계를 살펴봅니다. | DBA, 마이그레이션 엔지니어, 앱 소유자 | |
| 애플리케이션 클라이언트를 새 인프라로 전환합니다. | DBA, 마이그레이션 엔지니어, 앱 소유자 |
| 작업 | 설명 | 필요한 기술 |
|---|---|---|
| 임시 AWS 리소스를 종료합니다. | DBA, 마이그레이션 엔지니어, SysAdmin | |
| 프로젝트 문서를 검토하고 검증하세요. | 마이그레이션 책임자 | |
| 마이그레이션 시간, 수동 대비 도구 비율, 비용 절감 등에 대한 지표를 수집합니다. | 마이그레이션 책임자 | |
| 프로젝트를 마무리하고 피드백을 제공하세요. | 마이그레이션 책임자, 앱 소유자 |
관련 리소스
참조
자습서 및 동영상
Amazon에서 Oracle Databases를 실행하는 모범 사례RDS
(re:Invent 2018 프레젠테이션)
