[도커] 도커 최적화 - 베이스 이미지 크기를 줄이면 무조건 좋을까?(alpine, musl libc, JNI)

 

프로젝트 개발에 도커를 사용하여 배포를 하며, 과정을 좀 더 최적화하고 싶은 생각이 들었다.

 

실제 서비스를 운영하게 된다면, 도커로 이미지를 빌드하고 배포하는 과정이 수 없이 반복될텐데,

이미지 용량을 줄이고 빌드시간을 단축하는 것이 시간과 컴퓨팅 자원의 낭비를 없애줄 것이라 생각한다.

 

그래서, 도커 최적화를 시작하며 첫 번째로 손대 볼 것은 JDK, JRE 이미지 경량화였다.

자바기반 프로젝트를 빌드하고 실행할때 사용하는 JDK와 JRE의 도커 이미지의 용량을 낮출 수 있는 방법을 찾았고, 이 방법을 적용하는게 합리적인지를 따져보고자 한다.

 

결론부터 말하자면, 이미지 용량을 낮추는데서 오는 장점보다 단점(성능이슈, 호환성 문제)이 크다고 생각한다.

용량의 제한이 중요한(임베디드 시스템 같은) 시스템이 아니라면 그냥 기본 이미지를 사용하는 것이 낫다고 생각한다.

 

 

1. JDK, JRE 베이스 이미지 크기를 줄여보자!

 

# 빌드 단계
# 베이스 이미지 생성. 도커 컨테이너를 특정 초기 이미지를 기반으로 세팅.
FROM eclipse-temurin:21-jdk AS builder
WORKDIR /back
COPY . .
RUN ./gradlew clean build 

# 실행 단계 
FROM eclipse-temurin:21-jre
WORKDIR /back
COPY --from=builder /back/build/libs/weddy-0.0.1-SNAPSHOT.jar /back/weddy.jar 
# 도커 컨테이너가 8080포트를 사용할 것임을 선언 
EXPOSE 8080 
# 도커 컨테이너가 시작될 때 실행될 기본 명령어
CMD ["java", "-Dspring.profiles.active=local", "-jar", "weddy.jar"]

 

위는 현재 내 도커파일 이다.

 

맨 첫째줄을 보면, eclipse-temurin:21-jdk 를 빌더로 사용하고 있음을 알 수 있다. 구체적으로는 도커허브에서 제공하는 jdk 공식 이미지를 pull받는 것이라고 볼 수 있다.

 

그런데 jdk, jre의 경량 버전의 이미지도 존재한다. 바로 alpine버전이다.

 

도커허브 공식문서 https://hub.docker.com/_/eclipse-temurin

 

도커허브에서 eclipse-temurin 이미지에서 alpine버전 대한 설명이다.

 

설명을 보면, 알파인 리눅스 이미지를 사용하여 이 eclipse-temurin이미지를 만들었다고 나온다.

 

참고로, 리눅스는 오픈소스이다. 그리고 리눅스의 핵심적인 의미는 '커널'이다. 그 커널에 이것저것(파일 시스템, 패키지 매니저 등) 추가하여 리눅스 배포판으로 만든 것이 다음과 같은 것들이다.

• Ubuntu: Canonical(회사)이 개발.
• Debian: 커뮤니티 중심.
• Red Hat Enterprise Linux (RHEL): Red Hat(회사)이 개발.
• Alpine Linux: 커뮤니티 중심, 특정 회사가 아니라 독립적인 개발자 그룹이 주도.

alpine은 커뮤니티 중심으로 만들어졌으며, 특징은 small, simple, secure이다. 공식문서 참조

 

특징 그대로, 다른 리눅스 배포판들과는 다르게 작고 가볍다. 리눅스 베이스 이미지가 5MB미만이다.

Alpine Linux	~5-8 MB	alpine:latest. musl libc, BusyBox 사용. 컨테이너에 최적화된 경량 이미지.
Ubuntu	~70-80 MB	ubuntu:latest. glibc 기반. 최소 서버 구성, 추가 패키지로 용량 증가 가능.
Debian	~50-60 MB	debian:slim. glibc 기반. Slim 버전 기준, 기본 Debian은 ~100 MB 이상.
Fedora	~150-200 MB	fedora:minimal. glibc 기반. 최소 구성이라도 상대적으로 무거움.
CentOS Stream	~200-220 MB	centos:stream9. glibc 기반. 엔터프라이즈 환경에 맞춘 기본 패키지 포함.

 

---

 

2. 작으니까 써도 될까?

 

위를 보면 jre-alpine이미지와 일반 jre-alpine이미지(우분투를 사용한)의 차이를 보면 용량이 82mb차이가 난다.

 

용량이 작고 컴파일 시간을 줄여주는 alpine버전을 쓰고 싶지만,

 

우리는 단점을 이해하고 사용할만한지 판단할 필요가 있다.

 

그러기 위해, 이 alpine버전이 다른 OS(Ubuntu, debian 등)들과의 차이점이 무엇인지 이해해보자.

 

 

---

 

 

3. alpine 버전은 다른 버전들과의 어떤 차이가 있을까?

결론: 알파인 버전은 glibc 대신 musl libc를 사용하여 보다 가볍다.

 

alpine버전과 다른 OS와의 가장 큰 차이점은

 

C 표준 라이브러리(libc, standard C library)의 구현체가 다르다는 것이다.

C 표준 라이브러리(libc, standard C library)
: C언어를 위한 표준 라이브러리. 표준 인터페이스라고 생각하자.
- 파일 입출력: 파일 읽기/쓰기(fopen, fwrite 등).
- 메모리 관리: 동적 메모리 할당(malloc, free 등).
- 시스템 호출 래퍼: 운영 체제의 시스템 호출(예: open, read)을 더 쉽게 사용할 수 있도록 제공.

 

(앞으로 C표준 라이브러리를 libc라고 하겠다.)

libc는 우리가 흔히 알고있는 stdio.h, string.h, stdlib.h 등이 포함되어있다.

 

이 libc는 ISO(국제 표준화기구)에서 채택이 되었다.

이러한 표준 덕분에, 개발자가 mac os에서 printf를 사용하든 window os에서 prinf를 사용하든 동일한 결과를 얻을 수 있다. 이식성이 좋아졌다.

 

다만, mac에서 printf를 했을 때와 window에서 printf를 했을 때 실제로 내부에서 작동되는 방식은 다를 것이다. 왜냐면, mac의 메모리 구조와 명령어 실행 구조 등 window의 그것과는 다르기 때문이다.

 

그래서 OS별로 libc의 종류가 다르며, 예를 들면

- Windows: Visual C++ Runtime

- mac :libSystem

- linux : glibc, musl libc

 

이렇다.

 

여기서 우리가 주목해야 할 리눅스용 libc 구현체는 glibc와 musl libc가 있는데,

둘의 차이점을 정말 간략하게 요약하자면,

- glibc : 무거움. / 성능 최적화. 안정적.

- musl libc: 단순하고 가벼움. 핵심 기능 위주./ 성능이 조금 느림. 호환성 이슈 있음.

glibc vs musl libc

 

오늘날 대부분의 리눅스 배포판(Ubuntu, Debian Fedora 등)이 glibc를 사용한다.

linux alpine은 바로 이 musl libc를 사용하여 적은 용량으로 배포판을 만들어냈다.

 

---

 

4. 단점이 뭐고, 사용해도 될까?

musl libc를 이용한 Linux alpine은 가볍고 좋지만, 당연하게도 단점이 있다.

크게 2가지를 꼽자면,

 

1. 성능 이슈

2. 라이브러리 이슈

 

가 있다.

 

첫 번째로, 성능 이슈와 관련해서는 어떤 특정 부분에 대해서 성능 문제가 있다고 말하기는 어렵다.

musl libc가 glibc보다 사용하는 스레드 스택크기가 작다. 그리고 런타임 성능에서 덜 최적화 되었다는 이야기가 종종 보인다. 하지만 지금까지 확인했을 시 객관적이고 명확한 프로그램 성능차이를 테스트한 자료는 확인하지 못했다. 그리고 내가 만든 프로그램의 유형에 따라서도 성능 차이가 있을 수 있기 때문에, 결국 glibc와 musl libc를 사용했을 때의 내 프로그램의 성능을 직접 테스트해보아야 정확하다.

 

두 번째로, 라이브러리 이슈이다.

기본적인 라이브러리는 문제가 되지 않지만,

우리가 사용하는 몇몇 외부 라이브러리 중, 내부에서 참조하는 네이티브 라이브러리가 libc에 의존할 수도 있는데, 만약 glibc에 의존해있다면 'UnsatisfiedLinkError (네이티브 라이브러리 로드 실패)' 오류가 발생한다.

네이티브 라이브러리(Native Library)란?

자바가 "이거 빠르게 계산해줘!"라고 부탁하면 C로 짠 네이티브 라이브러리가 OS와 직접 대화하며 빠르게 처리해줌.
특정 프로그래밍 언어(java, python)이 아닌, 운영 체제에서 직접 실행되는 기계어(바이너리)로 컴파일된 코드. 주로 C나 C++로 작성되며, 주로 C나 C++로 작성되며, OS 저수준 기능에 접근하거나 고성능 작업 수행할 때 사용.

 

여러 프레임워크와 라이브러리에서 네이티브 라이브러리를 사용한다.

 

자바 같은 경우 JNI(Java Native Interface)를 통해 .so(리눅스)나 .ddl(윈도우) 네이티브 라이브러리를 호출한다. 또는 DB 드라이버, 암호화 라이브러리, 그래픽 처리 라이브러리 등에 네이티브 라이브러리로 일부 구현 되어있다.

예를 들면, 자바에서 Thread를 생성시에 네이티브 라이브러리를 호출한다. 스레드 사용시 OS에 최적화하여 성능을 높이기 위해 사용하는 것이라고 추측된다. 참고

 

Java의 Thread같은경우,

Thread.start0 -> JNI 를 통해 JVM의 네이티브 코드(libjvm.so, libjava.so)호출

의 과정을 거치는데 JVM의 네이티브 코드는 alpine 환경에 맞게 musl libc로 컴파일되기 때문에 문제가 없다.

 

하지만, 외부 라이브러리 중 네이티브 코드가 glibc에 의존하는경우에는 문제가 된다.

예를들어 Oracle JDBC Driver는 네이티브 코드로 DB연결을 최적화한다. 이 네이티브 코드는 glibc에 의존해있다.

외부 라이브러리의 경우, 네이티브 코드가 이미 라이브러리에 포함된 상태로 배포되기 때문에, 재컴파일하지 않고 그대로 가져와서 사용한다. 이 때, 호환성 문제가 발생한다.

 

 

---

5. 그러면 쓰지말까?

용량을 줄여서 얻는 이점이

 

- 외부 라이브러리와의 호환성 이슈

- glibc를 사용하는 리눅스 배포판보다 성능이 느릴 수 있는 이슈.

 

보다 크다면, 나는 사용해도 된다고 본다.

예를 들면, 용량 제한이 매우 중요한 임베디드 시스템이라면 적용해볼 수 있겠다.

 

하지만, 실무에서는 용량 최대 몇 GB를 줄이자고 위와같은 리스크를 질 필요가 없다고 생각한다.

그냥 glibc를 사용하는 리눅스 배포한을 사용하는게 훨씬 안정적이다.

 

그러나 사이드프로젝트로서는 사용해도 좋다고 생각한다.

- 이슈가 될만한 외부라이브러리를 사용할 일이 적음.

- 프리티어 컴퓨팅 소스를 사용하기 때문에 용량이 적은게 유리.

- 성능이 느려도 크게 문제가 되지 않음.

 

 

그래서, 내 사이드 프로젝트에는 도입하기로 결심했다.

 

참조

https://jofestudio.tistory.com/138

https://bcho.tistory.com/1356

https://blog.lablup.com/en/posts/2023/09/20/diet-of-containers/

https://martinheinz.dev/blog/92

https://edu.chainguard.dev/chainguard/chainguard-images/about/images-compiled-programs/glibc-vs-musl/#high-level-differences-between-glibc-and-musl