Kotlin과 Spring Cloud Function 기반 애플리케이션을 AWS EventBridge와 Lambda에 배포하기

Kotlin과 Spring Cloud Function 기반 애플리케이션을 AWS EventBridge와 Lambda에 배포하기개요

새롭게 B2C 서비스를 개발하며 배치 작업의 필요성이 발생했는데 기존 서비스의 배치는 SpringBatch로 작성하고 Jenkins를 트리거로 사용하고 있었습니다. 처음엔 기존 서비스와 같은 기술 스택을 고민했지만 과연 현재 요구사항에서 SpringBatch와 Jenkins를 사용할 정도의 규모일까라는 의문이 들었고 인프라 관리 부담 또한 적지 않은 고민이 되었습니다.

이와 같은 고민을 해결하기 위해 개발자가 쉽게 조작할 수 있어야 하고 트리거가 백엔드 API를 호출할 수 있는 형태를 고민했고 Kotlin과 Spring Cloud Function으로 애플리케이션을 개발하고 AWS EventBridge와 Lambda를 같이 사용하는 구조를 생각했습니다.

아키텍쳐

AWS EventBridge, Lambda를 사용해 서비스 API를 호출하는 과정

 

이번 글에서는 위와 같은 고민을 해결한 과정과 애플리케이션 배포 과정을 소개하도록 하겠습니다.

Kotlin과 Spring Cloud Function의 조합

Kotlin 적용 이유

일반적으로 Lambda를 사용하면 Python과 Node.js을 많이 사용하지만 백엔드팀이 익숙한 기술 스택이 Kotlin이고 Lambda에서 JDK 최신 버전인 JVM 21 런타임도 지원하므로 Kotlin을 사용하게 됐습니다.

Kotlin의 장점

• 간결한 문법
• 안전한 타입 시스템
• 자바와의 높은 호환성
• 코루틴과 같은 현대적 동시성 모델 지원

Spring Cloud Function 이란

Spring Cloud Function은 서버리스 아키텍처를 위한 Spring Cloud 프로젝트 중 하나로 AWS Lambda, Azure Function, GCP Function 등 클라우드 위에서 동작하는 서버리스 플랫폼과 통합을 Adapter로써 지원하며 비즈니스 로직을 간단한 함수 형태로 작성할 수 있게 해줍니다.

제가 경험해본 Spring Cloud Function의 다른 사용 예시는 주식 시세 애플리케이션을 개발하며 Spring Cloud Stream 을 사용해 Source, Processor, Sink 단계별로 비즈니스 로직을 함수 단위 애플리케이션으로 만들어주던 경험이 너무 좋았는데 Spring Cloud Stream도 각 함수 단위 애플리케이션을 개발할때 Spring Cloud Function을 사용하고 있습니다.

Spring Cloud Function의 장점

• 서버리스 환경에 최적화된 스프링 부트 모델
• 다양한 클라우드 플랫폼과의 호환성
• 함수 단위의 비즈니스 로직 구현 용이
• 특정 플랫폼에 의존성이 없는 프로그래밍 모델 지원

AWS EventBridge와 Lambda

AWS EventBridge는 서버리스 이벤트 버스 서비스로, 다양한 AWS 서비스 및 외부 애플리케이션 간 이벤트 드리븐 아키텍쳐 형태로 쉽게 구축할 수 있도록 지원합니다. AWS Lambda는 서버리스 컴퓨팅을 제공하여, 코드 실행을 위한 서버 관리 필요 없이 비즈니스 로직에 집중할 수 있게 합니다.

EventBridge의 장점

• 높은 확장성과 느슨한 결합 제공
• 실시간 데이터 처리 및 반응형 시스템 구축 가능
• cron, rate 기반의 스케쥴러 지원

Lambda의 장점

• 빠른 시작 시간과 효율적인 리소스 관리
• 다양한 프로그래밍 언어 지원
• 간편한 배포 및 관리

Spring Cloud Function 애플리케이션 개발 과정

프로젝트 구성

예제로 사용한 기술 스택

• Spring Boot 3.2.1
• Spring Cloud 2023.0.0
• Kotlin + Gradle Kotlin

Spring Initializr에 접속해서 아래와 같이 사용할 버전과 Spring Cloud Function 의존성을 추가한 뒤 초기 프로젝트 구성을 다운로드 받습니다.

다운로드한 프로젝트를 Intellij IDEA에 import 한 뒤 build.gradle.kts 를 열어 아래와 같이 설정합니다.

import org.jetbrains.kotlin.gradle.tasks.KotlinCompile

plugins {
	id("org.springframework.boot") version "3.2.1"
	id("io.spring.dependency-management") version "1.1.4"
	id("com.github.johnrengelman.shadow") version "7.1.2"
	kotlin("jvm") version "1.9.21"
	kotlin("plugin.spring") version "1.9.21"
}

group = "com.example"
version = "0.0.1-SNAPSHOT"

java {
	sourceCompatibility = JavaVersion.VERSION_21
}

repositories {
	mavenCentral()
}

extra["springCloudVersion"] = "2023.0.0"

dependencies {
	implementation("org.springframework.cloud:spring-cloud-function-web")
	implementation("org.springframework.cloud:spring-cloud-function-adapter-aws")
	implementation("com.fasterxml.jackson.module:jackson-module-kotlin")
	implementation("org.jetbrains.kotlin:kotlin-reflect")
	implementation("com.github.kittinunf.fuel:fuel:3.0.0-alpha1")

	testImplementation("org.springframework.boot:spring-boot-starter-test")
}

dependencyManagement {
	imports {
		mavenBom("org.springframework.cloud:spring-cloud-dependencies:${property("springCloudVersion")}")
	}
}

tasks.withType<KotlinCompile> {
	kotlinOptions {
		freeCompilerArgs += "-Xjsr305=strict"
		jvmTarget = "21"
	}
}

tasks.withType<Test> {
	useJUnitPlatform()
}

tasks.withType<Jar> {
	manifest {
		attributes["Start-Class"] = "com.example.function.FunctionApplicationKt"
	}
}

tasks.assemble {
	dependsOn("shadowJar")
}

tasks.withType<com.github.jengelman.gradle.plugins.shadow.tasks.ShadowJar> {
	archiveClassifier.set("aws")
	archiveFileName.set("batch.jar")
	dependencies {
		exclude("org.springframework.cloud:spring-cloud-function-web")
	}
	mergeServiceFiles()
	append("META-INF/spring.handlers")
	append("META-INF/spring.schemas")
	append("META-INF/spring.tooling")
	append("META-INF/spring/org.springframework.boot.autoconfigure.AutoConfiguration.imports")
	append("META-INF/spring/org.springframework.boot.actuate.autoconfigure.web.ManagementContextConfiguration.imports")
	transform(com.github.jengelman.gradle.plugins.shadow.transformers.PropertiesFileTransformer::class.java) {
		paths.add("META-INF/spring.factories")
		mergeStrategy = "append"
	}
}

위 설정에서 핵심적인 부분은 shadowJar 입니다. shadowJar는 프로젝트의 공통 의존성을 하나의 jar안에 모두 결합하기 위해 사용하는 Gradle 플러그인입니다. 이런 형태를 일반적으로 fat-jar라고도 부릅니다.

애플리케이션 개발

resources/application.yml 파일을 생성한 뒤 아래와 같이 작성한다. 이때 definition에 매핑되는 값은 Lambda를 통해 호출될 함수명과 일치해야합니다.

spring:
  cloud:
    function:
      definition: batchCaller

애플리케이션 코드

application.yml의 definition에 설정한대로 batchCaller 라는 이름의 함수를 Bean으로 구성한 애플리케이션입니다.

package com.example.function

import com.fasterxml.jackson.databind.ObjectMapper
import fuel.Fuel
import fuel.get
import kotlinx.coroutines.runBlocking
import org.springframework.boot.autoconfigure.SpringBootApplication
import org.springframework.boot.runApplication
import org.springframework.context.annotation.Bean

@SpringBootApplication
class FunctionApplication(
    private val objectMapper: ObjectMapper,
) {

    data class Payload(
        val url: String,
    )

    @Bean
    fun batchCaller(): (String) -> (String) {
        return { payloadAsString ->
            val payload = objectMapper.readValue(payloadAsString, Payload::class.java)

            runBlocking {
                val response = Fuel.get(payload.url)
                response.statusCode.toString()
            }

        }
    }

}

fun main(args: Array<String>) {
    runApplication<FunctionApplication>(*args)
}

예제의 batchCaller Bean은 아래와 순서로 동작합니다.

1. EventBridge로부터 넘어온 JSON payload를 함수의 인자로 전달
2. 인자로 전달받은 JSON payload를 Kotlin의 data class인 Payload로 변환
3. Fuel client를 사용해 Payload.url을 그대로 호출. 이때 호출된 url은 서비스 API의  엔드 포인트입니다.</aside>
4. <aside> 💡 Fuel client는 코루틴 기반의 경량 HTTP Client입니다. 예제는 Spring Web이나 Spring WebFlux 의존성이 없으므로 Spring에서 기본 제공하는 RestClient, WebClient등을 사용할 수 없고 서버리스 플랫폼에 올라가는 특성상 가벼운 Client가 유리하므로 Fuel을 선택했습니다.

애플리케이션 빌드

프로젝트 최상위에서 shadowJar 플러그인를 사용해 애플리케이션을 jar로 빌드합니다.

./gradlew shadowJar

빌드 완료 예시

빌드가 완료되면 프로젝트의 build/libs/ 디렉토리에 jar 파일이 생성됩니다. 예제의 경우 batch.jar 로 빌드 되게 설정된 상태입니다. batch.jar는 이후 Lambda에 코드를 업로드할 때 사용됩니다.

AWS EventBridge와 Lambda에 애플리케이션 배포하기

Lambda에 배포

AWS Lambda 콘솔에 접속해서 아래와 같이 함수를 생성합니다.

저희가 중요한 것은 런타임이므로 아키텍쳐나 함수 이름 등 기타 설정은 상황에 맞게 설정하면 됩니다.

함수가 생성되면 코드를 업로드 합니다. 이때 S3 버킷에 링크를 연결하거나 .jar 파일을 직접 업로드할 수 있습니다.

업로드가 완료되었다면 런타임 설정에서 편집을 눌러 아래와 같이 설정을 변경합니다.

핸들러 설정을 org.springframework.cloud.function.adapter.aws.FunctionInvoker::handleRequest 로 변경해주셔야 정상적으로 동작합니다.

설정이 완료되었다면 정상적으로 동작하는지 테스트해 보겠습니다. 테스트 탭에 들어가서 이벤트 JSON을 수정합니다. 이벤트 JSON은 람다 함수로 전달되는 Payload이고 앞서 Spring Cloud Function 애플리케이션을 만들 때 data class로 만들었던 Payload 형태가 되어야 합니다.

아래와 같이 함수 실행 테스트가 완료되었습니다.

이제 EventBridge의 스케쥴러와 앞서 설정한 Lambda 함수를 연결해주겠습니다.

EventBridge 스케쥴러 설정

EventBridge 콘솔에 접속해 일정 생성 버튼을 눌러 스케쥴러를 생성해보겠습니다. 예제의 경우 Rate 기반 일정을 사용해 1분 마다 Event가 발생하도록 설정했습니다. EventBridge는 Rate 기반 일정과 Cron 기반 일정을 같이 지원하므로 편리하게 스케쥴러를 설정할 수 있습니다.

다음엔 EventBridge와 Lambda를 연결합니다. 페이로드에는 Lambda 테스트시 사용했던 것과 같이 Lambda에서 호출할 서비스 API 엔드포인트를 적어줍니다.

모든 설정이 완료되었습니다.

결론

AWS EventBridge와 Lambda에 애플리케이션을 배포하는 것은 서버리스 아키텍처를 활용하는 효과적인 방법입니다. 이 과정을 통해 개발자는 인프라 관리의 부담 없이 비즈니스 로직에 집중할 수 있으며, 빠르고 유연한 클라우드 애플리케이션 개발이 가능해집니다.

일반적으로 JVM 언어만 사용해본 개발자들은 Lambda 기반의 서버리스 애플리케이션을 개발하는데 있어서 부담을 느끼는 상황을 많이 봐왔습니다. 주로 Lambda 함수를 Python과 Node.js로 만드는 경우가 많기 때문인데 Spring Cloud Function을 사용하면 Java나 Kotlin과 같은 JVM 언어에서도 빠르고 쉽게 서버리스 애플리케이션을 개발할 수 있습니다. 또한 Spring Cloud Function은 플랫폼에 상관없이 독립 실행형(Standalone) 애플리케이션을 만들어주므로 비즈니스 로직에 집중한 서비스를 만드는데 도움을 줍니다.

예제 코드

https://github.com/digimon1740/spring-cloud-function-kotlin-aws-lambda

Reference

• https://docs.spring.io/spring-cloud-function/reference/adapters/aws-intro.html
• https://docs.aws.amazon.com/eventbridge/latest/userguide/eb-what-is.html
• https://github.com/kittinunf/fuel

개요

새롭게 B2C 서비스를 개발하며 배치 작업의 필요성이 발생했는데 기존 서비스의 배치는 SpringBatch로 작성하고 Jenkins를 트리거로 사용하고 있었습니다. 처음엔 기존 서비스와 같은 기술 스택을 고민했지만 과연 현재 요구사항에서 SpringBatch와 Jenkins를 사용할 정도의 규모일까라는 의문이 들었고 인프라 관리 부담 또한 적지 않은 고민이 되었습니다.

이와 같은 고민을 해결하기 위해 개발자가 쉽게 조작할 수 있어야 하고 트리거가 백엔드 API를 호출할 수 있는 형태를 고민했고 Kotlin과 Spring Cloud Function으로 애플리케이션을 개발하고 AWS EventBridge와 Lambda를 같이 사용하는 구조를 생각했습니다.

아키텍쳐

AWS EventBridge, Lambda를 사용해 서비스 API를 호출하는 과정

이번 글에서는 위와 같은 고민을 해결한 과정과 애플리케이션 배포 과정을 소개하도록 하겠습니다.

Kotlin과 Spring Cloud Function의 조합

Kotlin 적용 이유

일반적으로 Lambda를 사용하면 Python과 Node.js을 많이 사용하지만 백엔드팀이 익숙한 기술 스택이 Kotlin이고 Lambda에서 JDK 최신 버전인 JVM 21 런타임도 지원하므로 Kotlin을 사용하게 됐습니다.

Kotlin의 장점

• 간결한 문법
• 안전한 타입 시스템
• 자바와의 높은 호환성
• 코루틴과 같은 현대적 동시성 모델 지원

Spring Cloud Function 이란

Spring Cloud Function은 서버리스 아키텍처를 위한 Spring Cloud 프로젝트 중 하나로 AWS Lambda, Azure Function, GCP Function 등 클라우드 위에서 동작하는 서버리스 플랫폼과 통합을 Adapter로써 지원하며 비즈니스 로직을 간단한 함수 형태로 작성할 수 있게 해줍니다.

제가 경험해본 Spring Cloud Function의 다른 사용 예시는 주식 시세 애플리케이션을 개발하며 Spring Cloud Stream 을 사용해 Source, Processor, Sink 단계별로 비즈니스 로직을 함수 단위 애플리케이션으로 만들어주던 경험이 너무 좋았는데 Spring Cloud Stream도 각 함수 단위 애플리케이션을 개발할때 Spring Cloud Function을 사용하고 있습니다.

Spring Cloud Function의 장점

• 서버리스 환경에 최적화된 스프링 부트 모델
• 다양한 클라우드 플랫폼과의 호환성
• 함수 단위의 비즈니스 로직 구현 용이
• 특정 플랫폼에 의존성이 없는 프로그래밍 모델 지원

AWS EventBridge와 Lambda

AWS EventBridge는 서버리스 이벤트 버스 서비스로, 다양한 AWS 서비스 및 외부 애플리케이션 간 이벤트 드리븐 아키텍쳐 형태로 쉽게 구축할 수 있도록 지원합니다. AWS Lambda는 서버리스 컴퓨팅을 제공하여, 코드 실행을 위한 서버 관리 필요 없이 비즈니스 로직에 집중할 수 있게 합니다.

EventBridge의 장점

• 높은 확장성과 느슨한 결합 제공
• 실시간 데이터 처리 및 반응형 시스템 구축 가능
• cron, rate 기반의 스케쥴러 지원

Lambda의 장점

• 빠른 시작 시간과 효율적인 리소스 관리
• 다양한 프로그래밍 언어 지원
• 간편한 배포 및 관리

Spring Cloud Function 애플리케이션 개발 과정

프로젝트 구성

예제로 사용한 기술 스택

• Spring Boot 3.2.1
• Spring Cloud 2023.0.0
• Kotlin + Gradle Kotlin

Spring Initializr에 접속해서 아래와 같이 사용할 버전과 Spring Cloud Function 의존성을 추가한 뒤 초기 프로젝트 구성을 다운로드 받습니다.

다운로드한 프로젝트를 Intellij IDEA에 import 한 뒤 build.gradle.kts 를 열어 아래와 같이 설정합니다.

import org.jetbrains.kotlin.gradle.tasks.KotlinCompile

plugins {
	id("org.springframework.boot") version "3.2.1"
	id("io.spring.dependency-management") version "1.1.4"
	id("com.github.johnrengelman.shadow") version "7.1.2"
	kotlin("jvm") version "1.9.21"
	kotlin("plugin.spring") version "1.9.21"
}

group = "com.example"
version = "0.0.1-SNAPSHOT"

java {
	sourceCompatibility = JavaVersion.VERSION_21
}

repositories {
	mavenCentral()
}

extra["springCloudVersion"] = "2023.0.0"

dependencies {
	implementation("org.springframework.cloud:spring-cloud-function-web")
	implementation("org.springframework.cloud:spring-cloud-function-adapter-aws")
	implementation("com.fasterxml.jackson.module:jackson-module-kotlin")
	implementation("org.jetbrains.kotlin:kotlin-reflect")
	implementation("com.github.kittinunf.fuel:fuel:3.0.0-alpha1")

	testImplementation("org.springframework.boot:spring-boot-starter-test")
}

dependencyManagement {
	imports {
		mavenBom("org.springframework.cloud:spring-cloud-dependencies:${property("springCloudVersion")}")
	}
}

tasks.withType<KotlinCompile> {
	kotlinOptions {
		freeCompilerArgs += "-Xjsr305=strict"
		jvmTarget = "21"
	}
}

tasks.withType<Test> {
	useJUnitPlatform()
}

tasks.withType<Jar> {
	manifest {
		attributes["Start-Class"] = "com.example.function.FunctionApplicationKt"
	}
}

tasks.assemble {
	dependsOn("shadowJar")
}

tasks.withType<com.github.jengelman.gradle.plugins.shadow.tasks.ShadowJar> {
	archiveClassifier.set("aws")
	archiveFileName.set("batch.jar")
	dependencies {
		exclude("org.springframework.cloud:spring-cloud-function-web")
	}
	mergeServiceFiles()
	append("META-INF/spring.handlers")
	append("META-INF/spring.schemas")
	append("META-INF/spring.tooling")
	append("META-INF/spring/org.springframework.boot.autoconfigure.AutoConfiguration.imports")
	append("META-INF/spring/org.springframework.boot.actuate.autoconfigure.web.ManagementContextConfiguration.imports")
	transform(com.github.jengelman.gradle.plugins.shadow.transformers.PropertiesFileTransformer::class.java) {
		paths.add("META-INF/spring.factories")
		mergeStrategy = "append"
	}
}

위 설정에서 핵심적인 부분은 shadowJar 입니다. shadowJar는 프로젝트의 공통 의존성을 하나의 jar안에 모두 결합하기 위해 사용하는 Gradle 플러그인입니다. 이런 형태를 일반적으로 fat-jar라고도 부릅니다.

애플리케이션 개발

resources/application.yml 파일을 생성한 뒤 아래와 같이 작성한다. 이때 definition에 매핑되는 값은 Lambda를 통해 호출될 함수명과 일치해야합니다.

spring:
  cloud:
    function:
      definition: batchCaller

애플리케이션 코드

application.yml의 definition에 설정한대로 batchCaller 라는 이름의 함수를 Bean으로 구성한 애플리케이션입니다.

package com.example.function

import com.fasterxml.jackson.databind.ObjectMapper
import fuel.Fuel
import fuel.get
import kotlinx.coroutines.runBlocking
import org.springframework.boot.autoconfigure.SpringBootApplication
import org.springframework.boot.runApplication
import org.springframework.context.annotation.Bean

@SpringBootApplication
class FunctionApplication(
    private val objectMapper: ObjectMapper,
) {

    data class Payload(
        val url: String,
    )

    @Bean
    fun batchCaller(): (String) -> (String) {
        return { payloadAsString ->
            val payload = objectMapper.readValue(payloadAsString, Payload::class.java)

            runBlocking {
                val response = Fuel.get(payload.url)
                response.statusCode.toString()
            }

        }
    }

}

fun main(args: Array<String>) {
    runApplication<FunctionApplication>(*args)
}

예제의 batchCaller Bean은 아래와 순서로 동작합니다.

1. EventBridge로부터 넘어온 JSON payload를 함수의 인자로 전달
2. 인자로 전달받은 JSON payload를 Kotlin의 data class인 Payload로 변환
3. Fuel client를 사용해 Payload.url을 그대로 호출. 이때 호출된 url은 서비스 API의  엔드 포인트입니다.</aside>
4. <aside> 💡 Fuel client는 코루틴 기반의 경량 HTTP Client입니다. 예제는 Spring Web이나 Spring WebFlux 의존성이 없으므로 Spring에서 기본 제공하는 RestClient, WebClient등을 사용할 수 없고 서버리스 플랫폼에 올라가는 특성상 가벼운 Client가 유리하므로 Fuel을 선택했습니다.

애플리케이션 빌드

프로젝트 최상위에서 shadowJar 플러그인를 사용해 애플리케이션을 jar로 빌드합니다.

./gradlew shadowJar

 

빌드 완료 예시

빌드가 완료되면 프로젝트의 build/libs/ 디렉토리에 jar 파일이 생성됩니다. 예제의 경우 batch.jar 로 빌드 되게 설정된 상태입니다. batch.jar는 이후 Lambda에 코드를 업로드할 때 사용됩니다.

 

AWS EventBridge와 Lambda에 애플리케이션 배포하기

Lambda에 배포

AWS Lambda 콘솔에 접속해서 아래와 같이 함수를 생성합니다.

 

저희가 중요한 것은 런타임이므로 아키텍쳐나 함수 이름 등 기타 설정은 상황에 맞게 설정하면 됩니다.

함수가 생성되면 코드를 업로드 합니다. 이때 S3 버킷에 링크를 연결하거나 .jar 파일을 직접 업로드할 수 있습니다.

 

업로드가 완료되었다면 런타임 설정에서 편집을 눌러 아래와 같이 설정을 변경합니다.

 

핸들러 설정을 org.springframework.cloud.function.adapter.aws.FunctionInvoker::handleRequest 로 변경해주셔야 정상적으로 동작합니다.

설정이 완료되었다면 정상적으로 동작하는지 테스트해 보겠습니다. 테스트 탭에 들어가서 이벤트 JSON을 수정합니다. 이벤트 JSON은 람다 함수로 전달되는 Payload이고 앞서 Spring Cloud Function 애플리케이션을 만들 때 data class로 만들었던 Payload 형태가 되어야 합니다.

 

아래와 같이 함수 실행 테스트가 완료되었습니다.

이제 EventBridge의 스케쥴러와 앞서 설정한 Lambda 함수를 연결해주겠습니다.

EventBridge 스케쥴러 설정

EventBridge 콘솔에 접속해 일정 생성 버튼을 눌러 스케쥴러를 생성해보겠습니다. 예제의 경우 Rate 기반 일정을 사용해 1분 마다 Event가 발생하도록 설정했습니다. EventBridge는 Rate 기반 일정과 Cron 기반 일정을 같이 지원하므로 편리하게 스케쥴러를 설정할 수 있습니다.

 

다음엔 EventBridge와 Lambda를 연결합니다. 페이로드에는 Lambda 테스트시 사용했던 것과 같이 Lambda에서 호출할 서비스 API 엔드포인트를 적어줍니다.

 

모든 설정이 완료되었습니다.

결론

AWS EventBridge와 Lambda에 애플리케이션을 배포하는 것은 서버리스 아키텍처를 활용하는 효과적인 방법입니다. 이 과정을 통해 개발자는 인프라 관리의 부담 없이 비즈니스 로직에 집중할 수 있으며, 빠르고 유연한 클라우드 애플리케이션 개발이 가능해집니다.

일반적으로 JVM 언어만 사용해본 개발자들은 Lambda 기반의 서버리스 애플리케이션을 개발하는데 있어서 부담을 느끼는 상황을 많이 봐왔습니다. 주로 Lambda 함수를 Python과 Node.js로 만드는 경우가 많기 때문인데 Spring Cloud Function을 사용하면 Java나 Kotlin과 같은 JVM 언어에서도 빠르고 쉽게 서버리스 애플리케이션을 개발할 수 있습니다. 또한 Spring Cloud Function은 플랫폼에 상관없이 독립 실행형(Standalone) 애플리케이션을 만들어주므로 비즈니스 로직에 집중한 서비스를 만드는데 도움을 줍니다.

예제 코드

https://github.com/digimon1740/spring-cloud-function-kotlin-aws-lambda

Reference

• https://docs.spring.io/spring-cloud-function/reference/adapters/aws-intro.html
• https://docs.aws.amazon.com/eventbridge/latest/userguide/eb-what-is.html
• https://github.com/kittinunf/fuel