SAP BTP 환경에서 Java 마이크로서비스를 Kyma에 배포할 때 Multi-Stage Dockerfile, Helm 차트, BTP Operator를 조합해 Cloud Foundry와 다른 배포 프로세스 자동화
Deploying Java Microservices on SAP Kyma — Helm, Docker & BTP Services
AI 요약
Context
Cloud Foundry에서는 빌드팩이 자동으로 컨테이너를 생성하고 VCAP_SERVICES 환경변수로 서비스 자격증명을 주입하지만, Kyma는 개발자가 Dockerfile을 작성하고 Kubernetes Secret을 마운트해야 한다. Java 애플리케이션이 Kyma 환경에서 안정적으로 실행되려면 메모리 설정, 헬스 프로브, 서비스 바인딩, Istio 사이드카 오버헤드를 직접 관리해야 한다.
Technical Solution
- Multi-Stage Dockerfile 작성: Maven 3.9 + Eclipse Temurin 17을 빌드 스테이지에서 사용해 컴파일하고, Alpine 기반 JRE 이미지에서 최종 런타임 환경 구성 후 비루트 사용자(appuser) 생성
- JAVA_OPTS를 통한 메모리 튜닝:
-XX:MaxRAMPercentage=75.0 -XX:+UseG1GC옵션으로 Kubernetes 리소스 제한과 동기화하고, Cloud Foundry의 -Xmx 자동 설정 대신 명시적 메모리 관리 - Helm 차트 구조 정의: Chart.yaml, values.yaml, templates/ 디렉토리에 deployment.yaml, service.yaml, apirule.yaml, service-instance.yaml, service-binding.yaml, hpa.yaml을 계층적으로 배치
- BTP ServiceInstance 및 ServiceBinding 템플릿: XSUAA(인증) 및 HANA(데이터베이스) 서비스를 Kubernetes Secret으로 마운트해 /etc/secrets/sapcp/ 경로에서 자격증명 접근
- 프로덕션 안정성 설정: livenessProbe(주기 10초, 초기 지연 30초), readinessProbe(주기 5초, 초기 지연 20초), startupProbe(최대 160초 허용)를 /actuator/health 엔드포인트로 구성하고 terminationGracePeriodSeconds를 45초로 설정
- Horizontal Pod Autoscaler 구성: minReplicas 2, maxReplicas 10, targetCPUUtilization 70%로 설정해 트래픽 변화에 대응
- 리소스 요청/제한 정의: 요청(CPU 250m/메모리 512Mi), 제한(CPU 1000m/메모리 1Gi)을 설정하고 Istio Envoy 프록시 오버헤드(50-100MB) 고려
Key Takeaway
Kyma 기반 Java 배포는 Cloud Foundry의 자동화된 빌드팩 대신 명시적인 Dockerfile 작성과 Helm 템플릿화가 필요하며, Java 런타임 메모리 설정, Kubernetes 리소스 제한, 시작 시간이 긴 Spring Boot의 헬스 프로브를 정확히 구성해야 OOMKill이나 중단 없이 안정적으로 운영된다. Sealed Secrets나 External Secrets Operator로 자격증명을 암호화 관리하고, Istio 사이드카 오버헤드를 리소스 계획에 포함시키는 것이 필수 실천 사항이다.
실천 포인트
Spring Boot를 Kyma에 배포하는 팀은 Dockerfile에서 `-XX:MaxRAMPercentage=75.0`을 JAVA_OPTS에 포함시키고, Deployment 스펙의 startupProbe를 최대 160초(initialDelaySeconds 10 + periodSeconds 5 × failureThreshold 30)로 설정하며, values.yaml에 리소스 요청/제한(메모리 512Mi/1Gi)과 HPA minReplicas/maxReplicas(2/10)를 정의하면 메모리 부족으로 인한 팟 재시작과 스케일링 지연을 방지할 수 있다.