테크 블로그 모아보기 개발 기록 (2) : Go 언어와 서버리스 프레임워크

서론

이 글은 Golang 어플리케이션을 Serverless framework 를 이용해 AWS Lambda 에 배포하는 과정을 다룬다.

현재 운영중인 사이드 프로젝트(🔗 테크 블로그 모아보기) 는 Go 언어를 기반으로 AWS Lambda(이하 람다)에 배포되어 있다. 처음 람다를 배울 땐 AWS Console 에서 일일이 API Gateway 를 설정하고 Lambda 함수의 코드를 직접 작성한 기억이 나는데, 당시만 해도 간단한 파이썬 함수를 호출하는 정도라 AWS Console 에 코드를 복붙하는 정도로 람다를 맛보기 했다.

 

하지만 실제로 운영할 애플리케이션 코드는 단순 복사 붙여넣기로 람다에 배포할 수 없었다. 파일 수도 많을 뿐더러 매번 배포할 때 마다 그런 번거로운 일을 할수도 없기 때문이다. 그리하여 람다의 배포 자동화는 어떻게 할 수 있을지를 고민하다 AWS CLI, AWS SAM, Serverless Framework 등 다양한 툴을 알게 됐다. 결론적으로 필자는 Serverless Framework (이하 서버리스 프레임워크) 를 선택했고 간단한 커맨드 입력만으로 업데이트가 있을 때마다 간단히 배포를 진행할 수 있게 됐다.
이 글에선 서버리스 프레임워크란 무엇인지, Go/Gin 웹 프레임워크로 개발된 애플리케이션을 배포하는 개략적인 방법을 알아보겠다.

 

 

Go 와 AWS Lambda 의 조합

go 언어 특성 상 람다로 배포하면 제격이라고 느낀 포인트가 몇가지 있다.

 

우선 빠른 초기 실행 시간 (Cold start time)

Go 는 컴파일 언어로 바이너리 파일로 변환되어 람다에 제공된다. 이는 런타임 시 별도의 인터프리터가 필요 없어 Python 이나 Node.js 같은 인터프리터 언어보다 람다에서 빠르게 실행될 수 있다. 쉽게 말해 실행할 준비가 완료된 상태로 제공되기 때문에 성능면에서 효율적이라 볼 수 있다.

람다는함수가 호출될 때 서버 인스턴스를 즉시 준비하여 실행하는데, 이 과정에서 람다는 새롭게 생성된 인스턴스에서 코드의 초기화를 진행한다. 이렇게 인스턴스가 새로 시작되는 것을 콜드 스타트(Cold start) 라고 한다. 이러한 콜드 스타트는 함수가 오랜 시간 동안 호출되지 않았거나 새로운 인스턴스가 생성되는 경우에 발생하며, 이 초기화 과정에서 응답 지연이 발생할 수 있다. 여기서 Go의 컴파일 언어라는 특징은 별도의 런타임을 요구하지않고 곧바로 실행할 수 있기 때문에 콜드 스타트 시간을 줄일 수 있다. 또한 Go 바이너리는 일반적으로 경량이고 메모리 사용량에 최적화 되어 있어, 초기화 시 메모리 사용량이 적어 콜드 스타트의 영향을 줄이는데 도움이 된다.

 

작은 바이너리 파일 크기

다른 컴파일 언어인 Java 를 생각해보자. Java 는 컴파일 된 후 바이트 코드로 변환된다. Java 개발자라면 잘 알다시피 이 바이트 코드를 실행하려면 JVM 이라는 가상 머신을 필요로 한다.

반면 Go  는 빌드 시 네이티브 바이너리 파일을 생성한다. 네이티브 바이너리 파일이란 특정 운영체제와 CPU 에 맞게 컴파일된 실행 파일을 의미한다. 

서버리스 프레임워크에서 Go를 빌드하는 커맨드. 빌드 시 생성될 바이너리 파일은 Linux 운영체제에서 실행하겠다는 의미다.

 

이 바이너리 파일은 시스템에서 바로 실행될 수 있어 별도의 추가 소프트웨어나 런타임 환경을 필요로 하지 않는다. 즉 Go 코드는 컴파일 되면 자체적으로 실행 가능한 독립형 바이너리를 생성하고, 이를 통해 AWS Lambda 에서 별도의 의존성 설치 없이 간단히 배포할 수 있게 된다. 또한 바이너리 파일의 크기가 작기 때문에 Lambda 의 배포 패키지 크기가 작아져 업로드 및 배포 속도에도 효율적인 영향을 줄 수 있다.

 

Go 와 Lambda

Go 애플리케이션을 위한 웹 프레임워크에는 여러 종류(Gin, Fiber, Echo etc)가 있고 필자는 Gin 을 선택했다. Gin 은 경량 웹 프레임워크로 람다에서 실행 시 Cold start 가 발생할 때도 비교적 빠르게 실행할 수 있단 장점이 있어 선택했다. 무엇보다 참고할 자료가 가장 풍부한 점도 선택에 한 몫했다.

 

import (
    "github.com/aws/aws-lambda-go/events"
    "github.com/aws/aws-lambda-go/lambda"
    "github.com/awslabs/aws-lambda-go-api-proxy/gin"
    "log"
)

var ginLambda *ginadapter.GinLambda

func main() {
    log.Println("📌 Start Lambda")
    lambda.Start(Handler)
}

func Handler(ctx context.Context, request events.APIGatewayProxyRequest) (events.APIGatewayProxyResponse, error) {
    return ginLambda.ProxyWithContext(ctx, request)
}

 

main 함수

lambda.Start 함수는 람다가 시작되면 Handler 함수가 호출되도록 설정한다. Handler 는 람다에 의해 트리거되는 이벤트를 핸들링할 함수로, 쉽게 말해 람다가 실행될 때 호출되는 함수라고 보면 된다.

 

Handler 함수

ctx : 람다가 제공하는 context.Context 객체로, 람다 실행에 관련된 타임아웃이나 종료 신호 등 여러 메타데이터를 담고 있다.

request : events.APIGatewayProxyRequest 타입으로 API Gateway 를 통해 들어온 HTTP 요청을 나타낸다.

ginLambda.ProxyWithContext(ctx, request) : ginLambda 는 람다와 연동을 돕는 헬퍼 객체로, ProxyWithContext 메서드를 사용해 request 객체를 gin 프레임워크에서 처리할 수 있는 형식으로 request 를 변환하고, response 결과도 반환해준다.

 

 

Gin 웹프레임워크를 람다에서 사용할 수 있도록 기본적인 세팅을 완료했으니, ping 을 날려 통신할 수 있도록 라우터를 설정해보자.

func init() {
    log.Println("✅ Starting initialization...")
    gin.SetMode(gin.ReleaseMode)

    config := cors.DefaultConfig()
    config.AllowOrigins = []string{"*"} // Allow all origins
    config.AllowMethods = []string{"GET", "POST", "PUT", "PATCH", "DELETE", "HEAD", "OPTIONS"}
    config.AllowHeaders = []string{"Origin", "Content-Length", "Content-Type", "Authorization"}
    config.ExposeHeaders = []string{"Content-Length"}
    config.AllowCredentials = true
    config.MaxAge = 12 * time.Hour
    r.Use(cors.New(config))


    r := gin.Default()
    r.GET("/ping", func(c *gin.Context) {
        c.JSON(200, gin.H{
            "message": "pong",
        })
    })

    ginLambda = ginadapter.New(r)
    log.Println("✅ Initialization complete")
}

 

init 함수

Go 에서 init 함수는 패키지가 로드될 때 자동으로 호출되는 특별한 함수로, 명시적으로 호출하지 않아도 패키지가 처음으로 로드되는 시점에 자동으로 호출된다. 즉 main 함수보다 먼저 호출된다고 볼 수 있다. init 이 호출되면서 Gin 서버 설정과 라우터 등록, 의존성 초기화 등의 작업을 설정한 후 main 함수로 넘어가게 된다.

 

gin.SetMode(gin.ReleaseMode) : Gin을 Release 모드로 설정한다. 이는 로그를 최소화하고 성능을 높이는 설정으로, AWS 람다처럼 리소스 제약이 있는 환경에서 효과적이다.

gin.Default() : Gin 라우터 객체를 기본 설정으로 생성한다.  Default 함수는 로깅과 리커버리 미들웨어를 기본적으로 포함한다.

ginadapter.New(r) : Gin 라우터를 람다에서 사용할 수 있는 핸들러로 변환하는 함수로, gin.Default() 가 할당된 r 변수를 인자로 넘겨 GinLambda 객체를 생성한다. Gin 으로 등록한 여러 라우터를 AWS 람다에서 사용할 수 있도록 변환하는 함수라 생각할 수 있다.

aws-lambda-go-api-proxy 라이브러리의 gin/adapter.go 의 New()

 

 

Serverless Framework 로 배포

 

람다로 어플리케이션을 배포한 경험은 많지 않지만, 🔗 Serverless Framework를 사용하면 간단히 배포할 수 있다는 것을 익히 들어온터라 이번 기회에 사용해보기로 했다.

서버리스 애플리케이션의 배포 자동화 선택지로는 AWS CLI 나 AWS SAM(Serverless Application Model) 을 활용하는 방법도 있지만, 최종적으로 서버리스 프레임워크를 선택했다. AWS SAM 도 비슷한 자동화 기능을 제공하지만 서버리스 프레임워크와 비교하면 초기 배포과정의 설정과 더 많은 선언적 방식이 필요해서 배제했다. AWS CLI 도 훌륭한 선택이지만 별도의 설정 파일 없이 명령어 기반으로 동작하기에 반복적인 작업에 비효율적일 것이라 판단했다.(사실 명령어 반복이야 shell script 로 뚝딱뚝딱 하면 될것 같기도..?)

결정적으로 Serverless Framework 는 각 언어에 맞는 프로젝트 템플릿이 잘 제공되어 있어 AWS CLI 보다 나은 선택이라 판단했다. 위에서 언급한 이미지는 serverless.yml 의 일부인데 Go 애플리케이션을 빌드하기 위한 Go 빌드 명령어도 기본 템플릿에 포함할 수 있다.

 

서버리스 프레임워크는 어떤 식으로 작동하길래 람다의 배포를 편리하게 도와주는걸까?
결론부터 말하면 서버리스 프레임워크는 AWS 의 Cloudformation 이라는 서비스를 이용한다. AWS 내에서 필요한 서비스를 JSON/YAML 파일로 형식에 맞춰 전달하면 필요한 서비스를 자동으로 생성/삭제 해주는 서비스인 셈이다.

 

아래는 필자가 서버리스 프레임워크로 애플리케이션으로 배포하기 위해 필요한 yml 파일의 전문이다.

serverless.yml

service: serverless-go

provider:
  name: aws
  runtime: provided.al2
  region: ap-northeast-2
  stage: ${opt:stage, 'dev'}

functions:
  api:
    handler: bootstrap
    timeout: 30 # Increase overall function timeout
    events:
      - http:
          path: /{proxy+}
          method: ANY
    environment:
      GO_LOG: info


package:
  patterns:
    - '!./**'
    - './bootstrap'

custom:
  golang:
    cmd: GOOS=linux GOARCH=amd64 go build -o bootstrap main.go

 

 

serverless.yml 파일과 더불어 해당 파일을 실행하는 스크립트를 자동화한 Makefile 도 작성해주자. 이를 활용하면 매번 빌드 및 배포 명령어를 일일이 입력할 필요없이 단순히 make deploy 명령만으로 Go 애플리케이션 빌드부터 Serverless Framework 로 Lambda 에 배포까지 한큐에 진행할 수 있다.

 

Makefile

build:
	GOOS=linux GOARCH=amd64 go build -o bootstrap main.go
	chmod +x bootstrap

deploy: build
	serverless deploy --stage prod

clean:
	rm -f bootstrap

 

 

이렇게 배포까지 진행하면 AWS Console 에서 서비스가 배포된 것을 확인할 수 있다.

다만 주의할 점은 해당 애플리케이션에서 외부 connection 을 맺는 과정이 제대로 이루어지지 않으면 배포에 실패한다(당연한 소리긴 함). 그래서 배포된 람다 함수가 외부 connection 과 잘 연결되는지, 포트 개방은 되어 있는지 잘 확인해봐야 한다.

 

 

 

결론

서버리스 프레임워크를 활용하여 Go 애플리케이션을 람다에 배포하는 과정을 정리했다. 생각보다 글이 짧게 끝났는데 그만큼 서버리스 프레임워크를 사용하면 간단하게 Go 어플리케이션을 배포할 수 있다. 배포 이외에도 서버리스 프레임워크를 효율적으로 사용할 수 있는 방법은 무엇이 있을지 좀 더 고민이 필요한 것 같다. 현재는 단순 배포 용도로 사용중인데 이 과정을 자동화하는, 예를 들어 Github ACtions 와 연동하여 원격 레포지토리에 푸시하거나 main 브랜치에 머지할 때마다 배포가 되도록 개선해 볼 수 있겠다.