기술 영역 - AWS 권장 가이드
1. 세션 상태2. Agents3. 애플리케이션 서버4. 파일 스토어5. 빌드 및 배포 프로세스6. 데이터베이스 액세스

기계 번역으로 제공되는 번역입니다. 제공된 번역과 원본 영어의 내용이 상충하는 경우에는 영어 버전이 우선합니다.

기술 영역

이 섹션에서는 컨테이너화를 위한 주요 기술 영역을 간략히 설명합니다. 다음 다이어그램에서는 기존 Java EE 애플리케이션의 아키텍처를 보여줍니다.

리팩터링된 Java EE 애플리케이션

다음 다이어그램에서는 컨테이너식 Java EE 애플리케이션의 아키텍처를 보여줍니다.

리팩터링된 Java EE 애플리케이션

1. 세션 상태

대부분의 경우 Java EE 애플리케이션은 서블릿용 쿠키 및 Enterprise Java Beans(EJB) 상태 저장 세션과 같은 사용자 요청과 관련된 세션 데이터를 저장합니다. 컨테이너를 상태 비저장으로 유지해야 하므로 Java 가상 머신(JVM) 메모리에는 상태 정보를 저장하지 않는 것이 좋습니다. 일회성 원칙에 대한 자세한 내용은 Red Hat 설명서의 Principles of container-based application design을 참조하세요. Java EE에는 HTTP 세션 데이터와 EJB 세션 데이터라는 두 가지 유형의 세션 데이터가 있습니다. HTTP 세션 데이터와 EJB 세션 데이터는 애플리케이션 서버에서 유지할 수 있습니다. RedHat JBoss의 Infinispan과 IBM WebSphere Application Server의 Data Replication Service를 비롯한 여러 기존 애플리케이션 서버에서 메모리 복제를 지원하여 이 세션 데이터의 가용성을 높입니다.

메모리 복제 메커니즘에서는 특정 서버 세트가 항상 클러스터에 존재하거나 소수의 서버가 클러스터에 합류하거나 클러스터에서 탈퇴한다고 가정합니다. 이는 컨테이너 환경과 호환되지 않으므로 메모리 복제 메커니즘을 없애는 것이 좋습니다. 컨테이너 환경에서는 새 버전의 컨테이너 이미지가 빌드될 때 애플리케이션 서버가 재배포됩니다. 즉, 복제된 메모리 데이터도 모두 지워집니다.

2. Agents

단일 물리적 또는 가상 서버에서 일반적으로 다음과 같은 자동화 및 유틸리티 작업을 수행하는 여러 에이전트 프로세스가 실행됩니다.

  1. 모니터링 - 기존 Java EE 애플리케이션 환경에서는 모니터링을 위해 전용 에이전트를 사용하는 경우가 많습니다. 이러한 에이전트는 서버 CPU, 메모리, 디스크 사용량, JVM 내부의 메모리 사용량, 로그 메시지 등을 모니터링합니다. 그러나 컨테이너 환경에서 모니터링 에이전트를 직접 실행할 수는 없습니다. 모니터링 에이전트를 컨테이너 플랫폼에서 제공하는 Amazon CloudWatch, Amazon CloudWatch Logs 등의 모니터링 메커니즘으로 교체해야 합니다.

  2. 작업(예약된 작업) - 기존 Java EE 애플리케이션 환경에서 작업 실행 환경은 애플리케이션 서버와 동일한 서버에 상주하는 경우가 많으며 사용자 요청과는 별개로 오래 실행되는 배치 프로세스를 담당합니다. 예를 들어, 작업 컨트롤러가 제어하는 배치 프로세스는 데이터베이스에 액세스하여 데이터를 검색하고 보고서를 생성합니다. 컨테이너 환경에서 이러한 여러 워크로드가 공존할 수 없으므로 컨테이너 환경과는 별도로 작업 및 배치 실행 환경을 구축해야 합니다.

  3. 파일 전송 - 파일 전송 에이전트는 일반적으로 Java EE 애플리케이션 환경에서 흔히 사용되지 않지만 외부 애플리케이션과 파일을 주고받기 위한 독립적인 프로세스로 Java 애플리케이션과 동일한 운영 체제에서 실행되는 경우도 있습니다. 예를 들어, 다른 애플리케이션에서 사용하는 데이터는 매일 파일로 전송되어 데이터베이스에 반영됩니다. 파일 전송 에이전트는 컨테이너 옆에서 실행할 수 없지만 데이터베이스 및 파일에 액세스할 수 있는 다른 서버에서 실행되어야 합니다.

3. 애플리케이션 서버

컨테이너화의 가장 중요한 과제는 애플리케이션 서버를 변경하는 것입니다. 기존 Java EE 호환 애플리케이션 서버는 정적 컴퓨팅 환경을 가정하므로 컨테이너 환경에서 실행하기에 적합하지 않을 수 있습니다. 즉, 물리적 또는 가상 서버는 Java EE 애플리케이션의 컴퓨팅 환경 엔터티로 간주됩니다. 예를 들어, 기존의 IBM WebSphere Application Server(tWAS) 및 Oracle WebLogic Server와 같은 전용 Java EE 애플리케이션 서버에는 자체 애플리케이션 배포 메커니즘이 있습니다.

컨테이너 환경에서는 상황이 다릅니다. 이 환경에서 컨테이너는 애플리케이션 빌드 패키지(예: .war 및 .jar 파일)가 포함된 애플리케이션 서버 및 런타임을 포함하며 Amazon ECS 또는 Amazon EKS 등의 컨테이너 플랫폼에 배포됩니다. 컨테이너 플랫폼 메커니즘을 사용하여 애플리케이션을 환경에 배포하는 것이 좋습니다. 애플리케이션 서버는 컨테이너와 함께 배포되는 경우가 많으므로 500MB 미만으로 크기가 작고 빠르게 시작할 수 있어야 합니다. 이 요구 사항을 충족하려면 기존 애플리케이션 서버를 변경하고 컨테이너 친화적인 애플리케이션 서버로 마이그레이션해야 할 수 있습니다. 이를 위해 IBM WebSphere Application Server에서 IBM WebSphere Liberty로 마이그레이션하거나 JBoss Enterprise Application Platform(EAP)에서 WildFly로 마이그레이션해야 할 수 있습니다.

애플리케이션 서버 변경으로 인해 발생할 수 있는 다음과 같은 영향을 고려하는 것이 좋습니다.

  1. 환경 변수를 통한 구성 삽입(web.xml과 같은 파일에 구성을 저장하는 기존 Java EE 애플리케이션과 대조)

  2. Java EE 기능과의 호환성

  3. JVM 버전

4. 파일 스토어

기존 Java EE 애플리케이션에 가장 일반적으로 사용되는 파일 스토어는 로컬 파일 시스템입니다. 가장 일반적인 사용 사례로는 애플리케이션 로그 파일, 비즈니스 보고서와 같은 애플리케이션 생성 파일, 사용자가 업로드한 콘텐츠 등이 있습니다. 컨테이너는 상태 비저장 방식이므로 컨테이너화를 위해 파일 스토어를 외부화해야 하므로 컨테이너 내부에 파일을 저장하지 않는 것이 좋습니다.

다음 컨테이너화 옵션을 고려하세요.

  1. Amazon Elastic File System(Amazon EFS) - Amazon EFS는 컨테이너에서 액세스할 수 있는 관리형 NFS 서비스입니다. Amazon EFS는 Amazon ECS 및 Amazon EKS와 통합됩니다. Amazon EFS를 사용하는 경우 EFS 볼륨을 컨테이너에 탑재하기 위해 사용자 지정 스크립트를 작성할 필요가 없습니다. 이 옵션의 첫 번째 단계는 읽기 또는 쓰기에 사용되는 애플리케이션의 모든 파일 시스템 경로를 나열하는 것입니다. 유지할 파일 시스템 경로를 식별한 후 파일 시스템 경로를 EFS 파일 시스템 경로에 매핑할 수 있습니다. 자세한 내용은 Amazon ECS 설명서의 Tutorial: Using Amazon EFS file systems with Amazon ECS를 참조하세요. 모든 경로, 특히 애플리케이션 로그 파일을 유지할 필요는 없습니다. 대부분의 엔터프라이즈 애플리케이션은 로컬 파일 시스템에 로그 파일을 씁니다. 컨테이너화 프로세스의 일환으로 표준 출력과 표준 오류를 사용하도록 로깅 대상을 변경하는 것이 좋습니다. 이렇게 하면 로그 스토리지 크기 조정 및 성능을 관리하지 않고도 CloudWatch Logs에 모든 출력을 캡처할 수 있습니다. Amazon ECS에서 로깅에 대한 자세한 내용은 Amazon ECS 설명서의 Using the awslogs log driver를 참조하세요.

  2. Amazon Simple Storage Service(S3) - Amazon S3는 Amazon EFS보다 저렴하고 Amazon EFS보다 넓은 대역폭을 지원하지만 더 광범위한 애플리케이션 코드 변경이 필요합니다. Amazon S3는 파일 시스템이 아니기 때문입니다.

5. 빌드 및 배포 프로세스

컨테이너화 프로세스에는 애플리케이션 제공 프로세스의 변경 및 확장이 포함됩니다. 기존 환경에서 애플리케이션 제공 프로세스에는 주로 Java 아티팩트(예: .war 및 .ear 파일)가 포함됩니다. 컨테이너 환경에서는 컨테이너 이미지가 제공 단위입니다. 기존 Java 아티팩트를 빌드하는 프로세스 외에도 Docker 컨테이너를 빌드하고 제공하는 프로세스를 구축해야 합니다. 파이프라인 프로세스에 대한 자세한 내용은 AWS 권장 가이드 설명서의 CI/CD 파이프라인을 사용하여 Amazon EKS에 Java 애플리케이션 자동 빌드 및 배포를 참조하세요.

6. 데이터베이스 액세스

기존 애플리케이션 컨테이너화에는 데이터베이스 마이그레이션이 수반되는 경우가 많습니다. 마이그레이션 위험을 줄이려면 관계형 데이터베이스에 대한 마이그레이션 전략(AWS 권고 가이드)을 따르는 것이 좋습니다. 컨테이너식 환경에는 데이터베이스 연결 문자열을 포함한 외부화된 구성이 필요합니다. Spring Cloud Config(GitHub 저장소)와 같은 도구를 사용하여 분산 환경에서 Java 애플리케이션 구성을 외부화할 수 있습니다.