Spring과 kubernetes를 이용한 서비스 배포(WIP)

간단하게 Google에서 Dockerfile을 찾아봐서 작성한다. 여기에는 우리가 결정해야 할 것들이 몇가지 있다.

OCI Image를 위해서는 몇가지 선택사항이 있다.

• 오라클 라이센스가 있다면, 그것을 사용하자.
• 하나의 퍼블릭 클라우드 제공 서비스 위에서 실행한다면, 해당 서비스에서 제공하는 JDK를 사용하자. (Amazon Corretto, Microsoft's build of OpenJDK)
• 커뮤니티가 주도하고 어디에서나 실행되는 프로덕션레디 배포판을 찾고 있다면 Adoptium기반 이미지를 사용하라.
• 혹은 Bellsoft Liberica와 Azul 같이 상업적 지원을 통해 이를 기반으로 하는 다양한 버전 중 하나를 선택할 수 있다. VMWare Tanzu(Spring팀이 속한 사업부)는 Tanzu Build Service 및 Tanzu Application Platform과 같은 제품에서 Bellssoft Liberia를 사용하고 있다.

정리하면 eclipse-temurin:17-jre-jammy 와 같은 Adoptium 기반 이미지 또는 지원되는 빌드 버전을 사용하자. 단일 퍼블릭 클라우드의 경우 해당 공급자의 기본 이미지를 사용하는 것이 좋다. Oracle JDK는 라이센스가 있으면 사용하자.

이건 쉽다. Java JDK 17을 사용하면 된다. Spring 6.0은 Java 17을 기반으로 한다. macos 4코어 bellsoft liberica 기반 java 11과 java17의 실행시작시간을 비교했을 때 17로 버전업 한 것만으로 1.5초가 빨라졌다.(8.9s -> 7.4s) 이것은 별거 아닌 것 같지만 쿠버네티스 환경에서 pod를 상시로 올리고 내리는 상황에서는 큰 차이가 난다.

앱을 빌드한 이후 스프링에게 앱을 어떻게 계층화할지 물어볼 수 있는 방법이 있다.

$ ls -l target
total 105992
-rw-r--r--   1 odedia  staff  53169785 Sep  5 11:10 spring-petclinic-2.7.0-SNAPSHOT.jar
-rw-r--r--   1 odedia  staff    391665 Sep  5 11:10 spring-petclinic-2.7.0-SNAPSHOT.jar.original
drwxr-xr-x  22 odedia  staff       704 Sep  5 11:10 surefire-reports
drwxr-xr-x   3 odedia  staff        96 Sep  5 11:09 test-classes

$ java -Djarmode=layertools -jar target/spring-petclinic-2.7.0-SNAPSHOT.jar list
dependencies
spring-boot-loader
snapshot-dependencies
application

이처엄, Spring Boot 애플리케이션을 실행하는 대신 Djarmode=laytertools list 명령어로 레이어들을 리스트업 할 수 있다.

• dependencies : 애플리케이션의 릴리즈 기반 종속성을 포함하는 레이어. Spring Boot버전 혹은 서드파티 프레임워크 버전이 변경되면 이 레이어가 변경된다.
• spring-boot-loader : Spring 빈 라이프사이클을 관리하기 위해 Spring Boot 앱을 JVM에 로드하는 코드. 이 레이어는 거의 변경되지 않는다.
• snapshot-dependencies : 이 종속성은 자주 변경된다. 새 빌드를 할 때마다 최신 스냅샷을 가져와야할 수 있다. 이 계층은 애플리케이션 코드와 가장 가깝다.
• application : src/main/java 코드를 말한다.

이제 스프링부트가 애플리케이션을 레이어링 하는 방법에 대한 힌트를 제공했지만, 실제로 레이어를 준비해주면 좋겠다. 이를 위해 Djarmode=layertools 명령어를 사용할 수 있다.

$ java -Djarmode=layertools -jar target/spring-petclinic-2.7.0-SNAPSHOT.jar extract --destination target/tmp
$ ls -l target/tmp
total 0
drwxr-xr-x  3 odedia  staff  96 Sep  5 11:10 application
drwxr-xr-x  3 odedia  staff  96 Sep  5 11:10 dependencies
drwxr-xr-x  3 odedia  staff  96 Sep  5 11:10 spring-boot-loader
drwxr-xr-x  3 odedia  staff  96 Sep  5 11:10 snapshot-dependencies

--destination target/tmp 인자가 없으면, 디폴트로 target/dependency 디렉토리에 레이어를 추출한다.

dependencies 폴더를 보면 Spring Boot의 종속성이 있다.

$ ls target/tmp/dependencies
BOOT-INF
$ ls target/tmp/dependencies/BOOT-INF
lib
$ ls target/tmp/dependencies/BOOT-INF/lib
HikariCP-4.0.3.jar
LatencyUtils-2.0.3.jar
...

And here is our application's compiled code:

$ ls target/tmp/application/BOOT-INF/classes
application-mysql.properties    application.properties          db                              messages                        static
application-postgres.properties banner.txt                      git.properties                  org                             templates

이처럼 uber jar를 layered OCI image에 맞게 압축을 풀어 분리할 수 있다. 저자는 폭발하는 EAR(https://docs.oracle.com/cd/E13222_01/wls/docs61/deployment/deployment.html)와 비슷한 느낌이라고 한다. 기술은 반복된다.

FROM eclipse-temurin:17-jre-jammy as builder
WORKDIR application
ARG JAR_FILE=target/*.jar
COPY ${JAR_FILE} application.jar
RUN java -Djarmode=layertools -jar application.jar extract

FROM eclipse-temurin:17-jre-jammy
WORKDIR application
COPY --from=builder application/dependencies/ ./
COPY --from=builder application/spring-boot-loader/ ./
COPY --from=builder application/snapshot-dependencies/ ./
COPY --from=builder application/application/ ./
ENTRYPOINT ["java", "org.springframework.boot.loader.JarLauncher"]

OCI image를 실제로 확인해보자.

$ docker build -t spring-petclinic:2.7.0-SNAPSHOT .
$ docker run -it --rm -p 8080:8080 spring-petclinic:2.7.0-SNAPSHOT
;; 간단하게
$ docker run -p 8080:8080 spring-petclinic:2.7.0-SNAPSHOT
2022-09-05 08:40:30.802  INFO 1 --- [           main] o.s.s.petclinic.PetClinicApplication     : Starting PetClinicApplication v2.7.0-SNAPSHOT using Java 17.0.4.1 on 93195813a338 with PID 1 (/app.jar started by root in /)
...

--rm 은 컨테이너가 종료되면 컨테이너를 삭제한다는 옵션이다. --it 는 컨테이너의 표준 입출력을 터미널에 연결한다는 옵션이다.

여튼 이렇게 하면 동작해야 한다.

Spring이 아닌 자체 릴리스 종속성 집합이 있을 수 있다. 예를 들어, 회사 내 보안, 로깅 및 감사를 위한 내부 종속성 집합이 있을 수 있다.

이러한 종속성은 Spring 종속성보다 더 자주 변경될 수 있으므로 이러한 종속성을 자체 계층으로 추출하는 것이 합리적일 수 있다. 이를 위해 사용자 정의 레이어 구성을 생성할 수 있다.

<layers xmlns="http://www.springframework.org/schema/boot/layers"
	xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
	xsi:schemaLocation="http://www.springframework.org/schema/boot/layers
			  https://www.springframework.org/schema/boot/layers/layers-2.7.xsd">
    <application>
	<into layer="spring-boot-loader">
	    <include>org/springframework/boot/loader/**</include>
	</into>
	<into layer="application" />
    </application>
    <dependencies>
	<into layer="snapshot-dependencies">
	    <include>*:*:*SNAPSHOT</include>
	</into>
	<into layer="custom-security-dependencies">
	    <include>com.mycompany.security:*</include>
	</into>
	<into layer="dependencies"/>
    </dependencies>
    <layerOrder>
	<layer>dependencies</layer>
	<layer>spring-boot-loader</layer>
	<layer>snapshot-dependencies</layer>
	<layer>custom-security-dependencies</layer>
	<layer>application</layer>
    </layerOrder>
</layers>

custom-security-dependencies 레이어를 추가했다. 이 구성을 적용하려면 스프링 부트 메이븐 플러그인(spring-boot-maven-plugin)에 layers.xml 파일을 추가해야 한다.

<project>
    <build>
	<plugins>
	    <plugin>
		<groupId>org.springframework.boot</groupId>
		<artifactId>spring-boot-maven-plugin</artifactId>
		<configuration>
		    <layers>
			<enabled>true</enabled>
			<configuration>${project.basedir}/src/layers.xml</configuration>
		    </layers>
		</configuration>
	    </plugin>
	</plugins>
    </build>
</project>

이제 도커파일을 다시 작성해보자.

FROM eclipse-temurin:17-jre-jammy as builder
WORKDIR application
ARG JAR_FILE=target/*.jar
COPY ${JAR_FILE} application.jar
RUN java -Djarmode=layertools -jar application.jar extract

FROM eclipse-temurin:17-jre-jammy
WORKDIR application
COPY --from=builder application/dependencies/ ./
COPY --from=builder application/spring-boot-loader/ ./
COPY --from=builder application/snapshot-dependencies/ ./
COPY --from=builder application/custom-security-dependencies/ ./
COPY --from=builder application/application/ ./
ENTRYPOINT ["java", "org.springframework.boot.loader.JarLauncher"]

도커파일에 uber jar를 사용하지 말자. Spring builtin layertools 로 jar를 분해하여 OCI 이미지를 보다 효율적으로 패키징하자.

위 예제에서 우리는 다음과 같은 명령을 보았다.

ENTRYPOINT ["java", "org.springframework.boot.loader.JarLauncher"]

이런 기본값은 괜찮을 수 있지만, 그렇지 않을 수도 있다. 힙 크기, 사용가능한 메모리, 가비지 수집 알고리즘 등을 결정하기 위해 JVM에서 고려해야할 변수가 너무 많다. 항상 프로덕션 전에 앱을 프로파일링하고 프로덕션과 유사한 환경에서 검증되었다고 생각되는 설정을 적용하라. 이 글의 마지막 섹션에서는 도움이 될 수 있는 몇 가지 프로파일링 팁을 소개한다.

JVM에 인수를 전달하는 방법은 여러 가지가 있다. 컨테이너화된 환경에서는 컨테이너 내부의 JVM이 읽을 수 있는 가장 안전한 선택지는 JAVA_TOOLOPTIONS 환경 변수를 사용하는 것이다. JAVA_OPTS는 shell script convention이다. JVM은 이를 제공하지 않는다.

JVM에 전달해야 할 더 중요한 인자는 메모리 관리에 관련있다. 몇가지 사항을 고려해야 한다.

• Your JVM memory is (mostly) a combination of the heap memory and the non-heap memory (Stack Memory, Direct Memory etc.).

  힙 메모리와 비 힙 메모리(스택 메모리, 디렉트 메모리 등)의 조합으로 구성된다.
  

• Most of your application's memory will be allocated to the heap. How much memory should you assign to it? It depends!

  대부분의 애플리케이션 메모리는 힙에 할당된다. 얼마나 할당해야 할까? 그것은 경우에 따라 다르다.
  

• How much memory does the container has?

  컨테이너가 얼마나 많은 메모리를 가지고 있나?
  

• How many classes are in-memory?

  메모리에 얼마나 많은 클래스가 있는가?
  

• How many threads are running at the same time (including Thread Pools)?

  동시에 실행되는 스레드 수는 얼마인가?
  

• How much memory is taken up by the Stack memory?

  스택 메모리가 얼마나 많은 메모리를 차지하고 있는가?
  

• Your application may also use a considerable amount of non-heap memory for things like NIO Direct Memory. For example, Kafka and many other socket-based frameworks make use of NIO for better performance. Without setting proper arguments, it might kill your JVM without you realizing what happened (as I learned the hard way…). Profile your application for direct memory by including the JVM arguments -XX:NativeMemoryTracking=summary-XX:+PrintNMTStatistics. Add the resulting value to the total memory footprint calculations.

  애플리케이션은 NIO 디렉트 메모리와 같은 것들을 위해 비 힙 메모리를 상당양을 사용할 수 있다.
  

  예를 들어, 카프카와 다른 많은 소켓 기반 프레임워크는 NIO를 사용하여 성능을 향상시킨다. 적절한 인수를 설정하지 않으면 JVM이 무슨 일이 일어났는지 알지 못하고 죽을 수 있다. (힘들게 경험한 것.) 애플리케이션을 프로파일링하여 다이렉트 메모리를 포함하여 JVM 인수 -XX:NativeMemoryTracking=summary-XX:+PrintNMTStatistics를 사용하라. 결과 값을 총 메모리 풋프린트(총량) 계산에 추가하라.

이런 자바 메모리를 쉽게 계산하는 도구가 있다. 바로 java-buildpack-memory-calculator이다. 이 도구는 애플리케이션의 메모리 사용량을 예측하는 데 도움이 된다. 계산하는 알고리즘은 아래 링크에 있다. 예를 들어, 애플리케이션에 750개의 클래스가 있고, 컨테이너의 총 메모리가 1G이며, 스택 크기가 1mb정도이며, 애플리케이션에서 사용하는 총 스레드가 100개 정도라고 계산 해보자.

$ ./java-buildpack-memory-calculator --loaded-class-count=750 --thread-count=100 --total-memory=1024M --jvm-options "-Xss1024k"
;; 리턴값
-XX:MaxDirectMemorySize=10M -XX:MaxMetaspaceSize=17919K -XX:ReservedCodeCacheSize=240M -Xmx672256K

결과로 max heap을 670mb로 설정하라는 메시지를 얻을 수 있다. 알고리즘은 total memory - (headroom + direct memory + metaspace + reserved code cache + (thread stack * thread count)) 로 계산한다. 이 경우에는 1024 - (128 + 10 + 17 + 240 + (1 * 100)) = 670mb가 된다.

스레드 풀의 중요성에 대해서 명확히 하기 위해 tomcat을 사용하고 웹 요청에 200개의 추가 스레드를 사용하여 총 스레드 수를 300개로 늘린다고 가정해보자.

$ ./java-buildpack-memory-calculator --loaded-class-count=750 --thread-count=300 --total-memory=1024M --jvm-options "-Xss1024k"
;; 리턴값
-XX:MaxDirectMemorySize=10M -XX:MaxMetaspaceSize=17919K -XX:ReservedCodeCacheSize=240M -Xmx467456K

이 경우에는 max heap을 465mb로 설정하라는 메시지를 얻을 수 있다. MaxDirectMomorySize는 계속 10M 기본값으로 유지된다. 이유는 애플리케이션이 프로파일링하지 않고는 실제 사용량을 알 수 없기 때문이다.

위에서 언급한 직접 메모리 사용량을 확인하는 것을 잊지말자. 힙 크기에 의미 있는 영향을 미칠 수 있다.

애플리케이션이 많은 동시 사용자와 함께 Kafka를 사용하므로 직접 메모리에 64mb가 필요하다고 가정해보자.

$ ./java-buildpack-memory-calculator --loaded-class-count=750 --thread-count=300 --total-memory=1024M --jvm-options "-Xss1024k -XX:MaxDirectMemorySize=64M"

-XX:MaxMetaspaceSize=17919K -XX:ReservedCodeCacheSize=240M -Xmx412160K

이제 힙 크기가 약 410MB로 줄었습니다. 이 시점에서 컨테이너에 1기가바이트는 충분하지 않을까?

앞에서 언급했듯이, JVM 메모리 인수는 target deployment environment와 available container memory에 의존한다. 이러한 값은 계속 변경되므로 Dockerfile에 하드코딩하고 싶지 않을 것이다. 여기에 3가지 옵션이 있다.

1. JAVA_TOOLOPTIONS 환경변수를 당신의 kubernetes deployment yaml의 부분으로 추가한다.
2. 컨테이너가 시작될 때, 인수를 계산한다. 하지만 그 전에 Spring-based application이 실제로 실행되기 전에 실행되어야 한다. (다음 섹션에서 설명)
3. 옵션 1,2를 혼합하여 사용한다. deployment manifest에서 설정할 수 있는 것을 설정하고, 나머지는 컨테이너가 시작될 때 계산한다.

거의 2023년입니다. 더 이상 리눅스 커널을 직접 컴파일하지 않으시길 바랍니다. 왜 아직도 도커파일을 작성하시나요?

Docker images (정확히 말하자면, OCI 이미지)는 훌륭하다. 어디에서나 실행할 수 있는 컨테이너 패키징의 표준이다. 하지만 Dockerfile 은 이러한 이미지를 빌드하기 위한 스크립트일 뿐이다.

OCI 이미지가 대중화될 때부터 사용되어 왔기 때문에 기본값으로 간주된다. 작동하는 OCI 이미지를 얻을 수 있는 다른 방법이 있으며, 이제 how보다는 what에 중점을 두는 방법을 모색하자. 이러한 도구 중 하나가 jib이다. Google에서 개발한 이 도구는 빌드 도구와 통합되어 완벽한 Dockerfile을 작성하는 번거로움 없이 자동으로 Java distroless container image를 생성할 수 있다.

하지만 java 이미지보다 더 범용으로 사용할 수 있는 표준이 있다.

Cloud Native Buildpacks는 사전 보안 패치라는 부가 가치도 제공한다. 플러그인을 사용할 때마다 스프링은 가장 최신 paketo 기본 빌더 이미지를 다운로드한다.

빌더는 최신 보안 패치로 지속적으로 업데이트된다. 이미지 빌드는 전적으로 이 빌더 컨테이너 내에서 이루어진다. 최신 보안 패치가 포함된 새 빌드팩이 제공될 때마다 최신 빌드에 적용된다.

이 프로세스를 대규모로 수행하려면 kpack 오픈소스 프로젝트를 이용하여 kubernetes에서 직접 빌드할 수도 있다.

여러 버전별로 등록하는 방식이 다르다는 것 같다. 새로운 프로젝트에는 그냥 Native Support를 추가하면 저절로 되지 않나? 싶다.

Spring 앱이 쿠버네티스에서 잘 실행되려면, 다양한 라이프사이클 단계에서 쿠버네티스가 애플리케이션과 상호 작용하는 방식을 이해해야 한다. 이는 스프링 애플리케이션이 실행 중이며 트래픽을 수신할 준비가 되었음을 쿠버네티스 런타임에 알리는 것으로 시작된다.

Spring Boot 2.2에는 상태 그룹이라는 개념이 도입되어 여러 액추에이터 상태 표시기(health indicator)를 그룹화할 수 있다. 특정 그룹에 대해서만 특정 속성을 정의할 수 있다. Spring Boot 2.3에서는 준비 상태 그룹과 활성 상태 그룹이라는 두 가지 상태 그룹을 기본으로 생성하여 이 개념을 더 확장시켰다. (https://spring.io/blog/2020/03/25/liveness-and-readiness-probes-with-spring-boot) 이 두 그룹을 사용하도록 설정하려면 다음 설정을 사용하도록 설정해야 한다.

management.endpoint.health.probes.enabled=true

사용자 편의를 위해 Spring 앱이 Kubernetes에서 실행되는 것을 감지하면 이 속성을 자동으로 true 로 설정한다.

이 새로운 설정을 사용하면 /actuator/health 아래의 종속 리소스와 /actuator/health/readiness 및 /actuator/health/liveness 라는 두 개의 개별 하위 그룹을 포함하여 완전하고 자세한 상태 정보를 얻을 수 있다.

1번항목(상태 엔드포인트가 오류를 반환할 때마다 정말로 파드를 다시 시작하고 싶은가?)에 대해서 설명한 이유에 따라서 Spring Boot는 기본적으로 준비 상태와 활력을 위해 외부 상태에 의존하지 않고 내부 애플리케이션 상태만 확인합니다.

이제 두 개의 별도 그룹으로 분리되었으므로, 애플리케이션에 적합한 자체적인 검사 지밥으로 각 그룹을 커스터마이즈 할 수 있다. 예를 들어, 애플리케이션이 트래픽을 수락할 준비가 되었다고 보고하기 전에 데이터베이스 연결이 되어야 하는 경우 해당 검사를 목록에 추가할 수 있다.

management.endpoint.health.group.readiness.include=readinessState,db

기본으로 제공되는 검사를 넘어서 커스터마이즈 한 검사를 작성할 수도 있다. 예를 들어, 애플리케이션이 트래픽을 수락할 준비가 되기 전에 Twillio와 같은 타사 SaaS API에 크게 의존한다고 가정하자. API 엔드포인트를 검사하는 로직을 추가할 수 있다.

management.endpoint.health.group.readiness.include=readinessState,externalTwilioVerifier

반대로 애플리케이션이 웹 트픽을 허용하지 않는 배치 또는 스트리밍 애플리케이션의 경우, 메시지 브로커와 같은 특정 외부 서비스에만 의존하는 경우도 있을 것이다.

management.endpoint.health.group.readiness.include=rabbitHealthIndicator

이제 애플리케이션에 "ready" 와 "alive" 가 무엇을 의미하는지 더 잘 제어할 수 있게 되었다.

하지만 대부분 엑추에이터 엔드포인트는 보안상의 이유로 별도의 "관리 포트(management port)"에 있어야 하는 반면, readiness 와 liveness probe(준비 빛 활성상태 확인절차)는 애플리케이션 포트에 있어야 한다는 점이 문제가 될 수 있다.

버전 2.3의 Spiring 설명서에는 이에 대한 큰 노란색 경고가 있다.

#+BEGIN_QUOTE If your Actuator endpoints are deployed on a separate management context, be aware that endpoints are then not using the same web infrastructure (port, connection pools, framework components) as the main application. In this case, a probe check could be successful even if the main application does not work properly (for example, it cannot accept new connections). #_ENDQUOTE

다행히고 Spring 2.6 부터는 주 애플리케이션 포트 또는 관리 포트에 대한 추가 경로로 상태 그룹을 설정할 수 있다.

management.endpoint.health.group.readiness.additional-path="server:/readyz"
management.endpoint.health.group.liveness.additional-path="server:/livez"

이 설정은 readiness endpoint 가 메인포트(:server)에서 readyz 라는 HTTP 패스로 접근이 가능하다는 것이다. 만약 health group을 management port로 사용하고 싶으면 menagement: prefix로 바꾼다.

Spring Boot 2.3부터 graceful shutdown이 기본으로 제공된다.

server.shutdown=graceful

위 프로퍼티를 설정하고 컨테이너가 종료 시그널(SIGTERM)을 받으면 Spring은 실제로 종료하기 전에 ㅇ녀결된 웹 서버가 새 연결을 수락하지 못하도록 차단한다.

이제 Spring 애플리케이션을 종료하기 전에 모든 요청이 완료될 때까지 기다려야 한다. 이를 위해 종료 단계에 대한 시간 초과 속성이 있으며, 기본값은 30초이다. 아래처럼 설정할 수 있다.

spring.lifecycle.timeout-per-shutdown-phase=20s

이러한 매개변수는 쿠버네티스의 컨텍스트에서 실행하는 동안만 설정하고 싶을 것이다. 다행히는 스프링은 애플리케이션이 쿠버네티스에서 실행되는 것을 감지하면 자동으로 쿠버네티스라는 프로파일을 추가하기 때문에 이 작업을 쉽게 수행할 수 있다.

spring.application.name: "SpringPetclinic"
---
spring.application.name: "SpringPetclinicKubernetes"
spring.config.activate.on-cloud-platform: "kubernetes"
spring.lifecycle.timeout-per-shutdown-phase=20s
server.shutdown=graceful

위 프로퍼티는 쿠버네티스에서 실행되는 경우에만 적용된다. 쿠버네티스 외부에서는 서버가 즉시 종료된다.

파드가 종료 수명 주기를 시작하는 동안 다른 쿠버네티스 리소스가 계속해서 트래픽을 해당 파드로 라우팅 할 수 있다. 셧다운이 프로세스가 시작될 때 파드로 들어오는 새로운 요청을 차단하기 위해, 하드 라이프사이클에서 사전 정지 단계를 구성할 수 있다.

spec:
  containers:
    image: odedia/spring-petclinic
    ...
    lifecycle:
      preStop:
	exec:
	  command: ["sh", "-c", "sleep 10"]
  terminationGracePeriodSeconds: 30

이 간단한 사례에는 종료 수명 주기가 시작되면(preStop) 10초 동안 절전 모드로 전환되도록 한다. 이 시간동안 다른 컴포넌트가 파드가 더 이상 게임에 있지 않다는 것을 파악할 수 있도록 한다. 이 시간 동안 처음에는 컨테이너에 실행 중인 메인 애플리케이션에 새 요청이 계속 들어올 수 있지만 결국에는 새 요청이 라우팅 되지 않아야 한다.