평가

컨테이너화를 위한 애플리케이션 평가를 통해 모든 종속성과 위험을 파악할 수 있습니다. 또한 평가를 통해 애플리케이션을 현대화 및 마이그레이션을 위한 우선순위 버킷으로 분류할 수 있습니다.

평가 단계에서는 다음과 같은 주요 영역에 초점을 맞춥니다.

• 컨테이너화를 위한 운영 체제 종속성 - AWS App2Container와 같은 자동화된 컨테이너화 도구에는 컨테이너화를 위한 애플리케이션 프레임워크 및 운영 체제에 대한 몇 가지 제한이 있습니다. 지원되는 애플리케이션에 대한 자세한 내용은 App2Container 설명서를 참조하세요.

• 규정 준수 - 배포 후 사후 대응 방식으로 조치를 취하고 완화하는 대신 컨테이너식 애플리케이션이 대상 환경에 배포되기 전에 모든 규정을 준수하는지 확인하는 것이 효율적입니다. 이미지의 취약성, 컨테이너 간 무단 통신, 컨테이너 및 데이터에 대한 액세스 제어, 악의적인 활동을 방지하기 위한 자동 스캔을 확인해보세요.

• 재해 복구(DR) 솔루션 - 각 애플리케이션에는 가동 중지 시간에 대한 고유한 서비스 수준에 관한 계약(SLA)가 있습니다. 컨테이너 클러스터의 배포를 계획할 때 애플리케이션의 Recovery Point Objective(RPO)와 Recovery Time Objective(RTO)를 염두에 두어야 합니다. App2Container는 기본적으로 애플리케이션을 여러 가용 영역에 배포합니다.

• 데이터 스토리지 - 상태 비저장으로 컨테이너를 사용하는 것이 가장 좋습니다. 상태 저장 컨테이너의 경우 데이터를 컨테이너 외부에 저장해야 합니다. 컨테이너의 서비스가 중단되면 이미지와 연결된 외부 볼륨을 사용하여 데이터 손실 없이 새 컨테이너를 가동할 수 있습니다.

• 구성 및 시크릿 관리 - 대상 환경의 파라미터 스토어 또는 시크릿 스토어를 사용하여 컨테이너에서 구성과 시크릿을 저장하고 검색할 수 있습니다. 관련 컨테이너에서만 시크릿에 액세스할 수 있도록 하는 것이 중요합니다. 구성과 시크릿에 대한 모든 작업을 기록해야 합니다. 컨테이너와 시크릿 스토어 간의 통신 채널은 안전해야 합니다.

• 로그 관리 - 감사를 위해 각 컨테이너에서 생성된 로그는 컨테이너 외부에 있는 로그 관리 서비스로 전달됩니다. 애플리케이션은 각각 다른 컨테이너에 있는 여러 서비스와 프로세스로 구성되므로 각 컨테이너의 로그에는 고유한 ID가 있어야 합니다.

• 빌드 및 배포 프로세스 - 대부분의 기업은 애플리케이션과 기능을 릴리스하기 위한 일종의 빌드 및 배포 프로세스를 갖추고 있습니다. 컨테이너화를 활용하려면 CI/CD 파이프라인을 사용하여 애플리케이션 구축 및 배포를 자동화해야 합니다. 파이프라인은 원클릭 인프라 프로비저닝 및 사용 중지, 더 빠르고 오류 없는 배포, 자동화, 새 기능 출시 시간 단축 등의 이점을 제공합니다.

• 업스트림 및 다운스트림 애플리케이션 - 모든 종속 애플리케이션을 일괄적으로 컨테이너화하고 마이그레이션하는 것이 좋습니다. 이것이 불가능한 시나리오에서는 컨테이너식 애플리케이션에서 업스트림 및 다운스트림 애플리케이션으로의 통신 채널을 안전하게 개방해야 합니다. 이 채널에서 지원하는 대역폭이 애플리케이션 기능을 방해하지 않는지 확인합니다.

• 라이선스 종속성 - 애플리케이션의 여러 인스턴스가 컨테이너 내에서 실행되므로 비용이 많이 들 수 있습니다. 컨테이너에 소프트웨어를 배포하기 위한 계약 및 자격을 확인합니다. 컨테이너에서 소비되는 소프트웨어를 측정하는 데 어떤 도구가 사용되는지 파악합니다.

• 애플리케이션 서버 또는 작업자 시스템의 컨테이너화 가능성 - 컨테이너화 프로세스는 디스크 공간, 컴퓨팅 파워, 메모리와 같은 서버의 추가 리소스를 소비합니다. 애플리케이션 서버를 분석하여 컨테이너화 프로세스를 지원할 수 있는지 확인해야 합니다. 그렇지 않으면 필요한 리소스가 있고 애플리케이션 서버와 통신할 수 있는 작업자 시스템을 사용할 수 있습니다.

• 개발자 기술 및 컨테이너에 대한 생산 지원 - 현재 애플리케이션 팀은 컨테이너화 기술에 대한 숙련도를 높여야 합니다. 팀은 프로세스의 문제를 해결하고, 필요한 경우 구성을 조정하고, 컨테이너에 배포된 애플리케이션을 지원할 수 있어야 합니다.

App2Container를 사용하여 독립 실행형 JBoss, Apache Tomcat, IBM WebSphere, Oracle WebLogic과 같이 Linux에서 실행되는 Java 애플리케이션을 컨테이너화할 수 있습니다. 또한 App2Container를 사용하여 Spring Boot와 같은 일반 Java 애플리케이션을 컨테이너화할 수 있습니다. 애플리케이션 컨테이너화는 마이크로서비스 및 분산 애플리케이션과 함께 작동합니다. App2Container를 사용하여 모든 Java 애플리케이션을 현대화할 수 있지만 다음 기준을 통해 더 빠른 마이그레이션을 위해 현대화할 적합한 애플리케이션을 선택할 수 있습니다.

• 단일 바이너리로 패키징된 애플리케이션은 더 쉽게 컨테이너화할 수 있습니다. 또한 Java 런타임 환경(JRE)을 사용하여 Java 애플리케이션을 컨테이너화할 수 있습니다. 각 컨테이너는 필요한 특정 JRE를 사용할 수 있습니다.

• 상태 비저장 애플리케이션은 컨테이너로 현대화하는 데 적합합니다. 이러한 애플리케이션은 최소한의 정보를 로컬에 저장하고 대부분의 데이터를 영구 데이터 스토어에 저장합니다.

• 지속적 통합 및 지속적 배포(CI/CD) 파이프라인을 사용하여 출시되는 애플리케이션이 컨테이너화에 적합합니다. 각 애플리케이션을 컨테이너화하고 App2Container에서 자동으로 처리하는 Amazon ECS 또는 Amazon EKS와 같은 컨테이너 오케스트레이션 플랫폼을 도입합니다.

대부분의 엔터프라이즈 애플리케이션은 인증, 영구 데이터 저장, 캐싱, 비동기 통신, 로깅 및 알림을 위해 다른 다양한 서비스와 통합됩니다. 컨테이너화 성공을 촉진하려면 기존의 모든 통합 지점을 갖춘 온프레미스에서 컨테이너식 애플리케이션을 테스트해야 합니다. 마이그레이션할 준비가 되면 AWS모든 적절한 통합 지점과 데이터 스토리지를 로 마이그레이션해야 합니다 AWS. 애플리케이션 컨테이너를 AWS에 배포하기 전에 필요한 업데이트를 구성에 적용해야 합니다.

파일 시스템에 저장된 데이터는 사용 사례에 맞는 다양한 도구를 AWS 사용하여 로 마이그레이션할 수 있습니다. Redis와 같은 캐시에 저장된 데이터를 Amazon ElastiCache로 마이그레이션할 수 있습니다. 데이터베이스에 저장된 데이터는 데이터베이스의 자체 네이티브 도구를 사용하거나 AWS Database Migration Service ()를 사용하여 마이그레이션할 수 있습니다AWS DMS.는 전환 시까지 소스 데이터 스토어에서 지속적인 변경 사항을 복제하는 변경 데이터 캡처(CDC) 옵션 AWS DMS 도 제공합니다.

AWS 는 Amazon CloudWatch라는 자체 모니터링 및 운영 데이터 로깅과 시각화 서비스를 제공합니다. 이 서비스를 사용하기 위해 CloudWatch 에이전트를 애플리케이션과 함께 컨테이너에 넣을 수 있습니다.

소스 코드를 사용할 수 없거나 유지 관리할 수 없는 조직의 경우 App2Container는 애플리케이션의 런타임 환경에서 작동하고 소스 코드가 필요하지 않기 때문에 컨테이너화에 매우 적합합니다.