Kyma Serverless Functions를 마이크로서비스 대신 도입해 webhook 핸들러·데이터 변환·이벤트 처리를 Docker 이미지·Helm 차트 없이 구현

Context

마이크로서비스 아키텍처는 간단한 작업(webhook 핸들러, 데이터 변환, 이벤트 처리)을 위해서도 Docker 이미지 빌드, Helm 차트 작성, Spring Boot 기준 15~60초의 시작 시간 같은 과도한 오버헤드를 요구한다. 또한 최소 1개 복제본을 유지해야 해 유휴 리소스가 낭비된다.

Technical Solution

• Functions vs Microservices 선택 기준 정의: 500줄 이상의 복잡한 비즈니스 로직은 마이크로서비스로, 이하의 단순 작업은 Kyma Function으로 분류
• Kyma Function CRD 도입: serverless.kyma-project.io/v1alpha2 API를 통해 Node.js 20, Python 3.12 런타임에서 인라인 또는 Git 소스 기반 함수 정의
• 자동 스케일링 구성: minReplicas를 0으로 설정해 미사용 시 리소스 해제, maxReplicas 5로 제한해 비용 통제
• BTP 서비스 바인딩: Kubernetes Secret을 env 변수(XSUAA_URL, XSUAA_CLIENTID, XSUAA_CLIENTSECRET)로 마운트해 S/4HANA·XSUAA 연동
• CloudEvents 표준화: 외부 webhook(Stripe 등)을 cloudEvents 포맷으로 변환해 내부 NATS/Event Mesh에 발행하는 어댑터 패턴 구현
• 프로덕션 배포 패턴: 인라인 소스 대신 GitHub Git 저장소(baseDir, reference, 인증 key)에서 소스 관리

Impact

콜드 스타트 시간 1~3초(Function) vs 15~60초(Spring Boot 마이크로서비스); 스케일링 0~N(Function) vs 최소 1 복제본 유지(HPA); 리소스 요청량 CPU 50m·메모리 64Mi(Function) vs 풀 마이크로서비스 스택 필요.

Key Takeaway

Lambda처럼 단순한 작업은 Kyma Function으로, ECS 서비스 수준의 복잡성은 마이크로서비스로 명확히 분리하면, 인프라 오버헤드와 운영 복잡도를 동시에 줄일 수 있다. 특히 콜드 스타트 지연이 문제가 되면 minReplicas를 1 이상으로 고정하는 트레이드오프가 필요하다.