추가 고려 사항

이 섹션에서는 Java EE 애플리케이션에만 국한되지 않는 Java 컨테이너화에 대한 일반적인 고려 사항을 다룹니다.

작은 기본 이미지 사용

500MB 미만의 작고 잘 관리된 기본 이미지를 생성하는 것이 좋습니다. 기본 이미지 크기를 줄이면 네트워크 및 운영 비용이 감소합니다. 기본 이미지가 작을수록 악용될 수 있는 구성 요소 수가 감소하여 보안도 향상될 수 있습니다. Debian 기반의 Distroless 이미지 중 하나를 사용할 수 있습니다. 이미지에는 최소한의 도구가 설치되어 있으며 패키지 관리자나 쉘이 포함되어 있지 않습니다. 이러한 Distroless 이미지는 전체적인 공격 표면을 감소시키기도 합니다. Distroless 이미지는 150MB 미만일 수 있습니다. 자세한 내용은 "Distroless" Container Images GitHub 리포지토리를 참조하세요.

일회성 원칙을 따르고 컨테이너 이미지의 시작 시간을 단축하는 것이 가장 좋습니다. ahead-of-time-compilation(OpenJDK 설명서) 또는 애플리케이션 클래스 데이터 공유(OpenJDK 설명서)와 같은 기법을 사용하면 가상 머신을 시작하기 전에 Java 클래스를 네이티브 코드로 컴파일하고 클래스 세트를 공유 아카이브 파일로 사전 처리하여 전체 시작 시간을 향상시킬 수 있습니다. 또한 GraalVM을 사용하여 Java 애플리케이션을 위한 최소한의 도커 이미지를 빌드할 수 있습니다. 자세한 내용은 AWS 블로그 게시물 Using GraalVM to Build Minimal Docker Images for Java Applications를 참조하세요.

컨테이너 인식 JDK 버전으로 업그레이드

JDK 8u131 이전에는 JVM이 플래그를 사용하여 도커 엔진에서 설정한 메모리 또는 CPU 제한을 인식하지 못했습니다. 즉, 컨테이너에서 애플리케이션을 실행할 때마다 JVM은 시스템 또는 가상 시스템(가상 시스템의 경우)에서 사용 가능한 총 프로세서 수를 '인식'합니다. 기본 메모리 제한도 마찬가지입니다. JVM은 호스트의 전체 메모리를 살펴보고 이를 기본값 설정에 사용합니다. 따라서 JVM은 컨테이너 플랫폼에서 허용하는 것보다 더 많은 메모리를 할당할 수 있으며, 이로 인해 컨테이너 플랫폼(도커)에서 Java 프로세스를 종료하게 됩니다. 이 문제를 해결할 수 있는 한 가지 방법은 컨테이너화하기 전에 Java 애플리케이션을 Java 9 또는 8u131+로 마이그레이션하는 것입니다. Java 10 이상 버전은 완전한 컨테이너 인식 및 지원을 제공합니다.