NC

엔씨소프트에서 론칭하는 게임이 점점 증가함에 따라 고객에게 다양한 웹 서비스를 제공하기 위해 서버가 많이 필요하게 되었습니다. 하지만 필요한 서버가 많아지면 그만큼 구매해야 하는 서버와 설치해야 하는 소프트웨어가 늘어나는 등 서버 환경을 일일이 설정해야 하는 어려움이 발생합니다. 이는 장비 구매부터 실제 서비스에 적용하기까지 많은 시간이 소요됨을 의미하기도 합니다.

이러한 환경을 개선하고자 플랫폼센터는 I&O 조직*과 협업해 2016년 클라우드 환경인 쿠버네티스(Kubernetes)를 구축하고, 플랫폼센터의 웹 서비스들을 쿠버네티스로 이전하기 시작했습니다. 쿠버네티스의 안정화로 몇 해 전부터는 서버리스(Serverless) 환경에 대한 여러 가지 테스트를 진행하고 있는데요.

본 포스팅에서는 서버리스에 대한 간단한 설명과 더불어 플랫폼센터가 서버리스 도입을 위해 어떤 다양한 기술에 관심을 갖고 살펴보고 있는지 소개하고자 합니다.

서버리스(Serverless)는 단어의 의미만으로는 ‘서버가 없다’는 뜻입니다. 하지만 실제로 서버가 존재하지 않는 것이 아니라, 마치 서버가 없는 것처럼 –서버를 고려하지 않고– 애플리케이션을 실행할 수 있는 환경을 의미합니다. 서버리스를 활용하면 이미 갖춰진 클라우드 기반의 인프라를 이용하기 때문에 서버를 직접 구축하지 않고도 자원을 효율적으로 사용할 수 있을 뿐만 아니라, 비용도 절감할 수 있습니다. 더불어 개발자로서는 서버 운영과 유지 보수 등의 인프라 작업 대신 애플리케이션 개발에 집중할 수 있다는 장점이 있습니다.

여기서 클라우드와 서버리스의 중요한 차이는 ‘on-demand’라는 핵심 개념에 있습니다. 즉, 서버리스 환경은 서비스가 항상 구동되어 있는 상태가 아니라, 요청이 있을 때만 실행되다가 더 필요하지 않은 시점에 종료됩니다.

유명한 소프트웨어 개발 전문가인 마틴 파울러(Martin Fowler)는 애플리케이션의 관점에서 서버리스를 ‘FaaS(Function as a Service)와 BaaS(Backend as a Service)를 결합한 콘셉트’라고 설명합니다. FaaS는 서비스를 작은 기능 단위(function)로 나누고 요청이 있을 때만 실행하도록 하는데, FaaS의 대표적인 구현체로는 AWS Lambda, Azure Function, Google Cloud Functions 등이 있습니다. BaaS는 Firebase나 Auth0같이 특정 기능을 하는 서비스를 API 형태로 가져다 사용할 수 있는 것을 말합니다.

FaaS는 HTTP 요청이나 cron/batch job 등 이벤트가 트리거되면 실제 동작하는 로직이 구현되는 Function을 호출합니다. Function은 보통 일회성 호출이기 때문에 상태를 저장하지 않으며(stateless), 실행의 결과는 BaaS에서 처리(DB 저장 또는 응답 전달 등)합니다. 그리고 역할을 끝낸 Function은 종료됩니다. 이처럼 요청이 있을 때만 인스턴스가 구동되기 때문에 기존의 ‘always-on’ 서버 구성보다 리소스를 절감할 수 있습니다.

우리가 잘 알고 있는 AWS Lambda나 Google Cloud Functions 그리고 Azure Functions 등의 상용 서비스를 사용하면 편리하지만 이는 특정 클라우드 플랫폼에 종속되어 있습니다. 따라서 자체 인프라 환경(On-Premise)을 구축하고자 하는 사용자들을 위해 다양한 오픈 소스 서버리스 프레임워크가 등장했습니다.

엔씨는 자체 클라우드 인프라를 구축해 사용하고 있기 때문에 사내 I&O 조직*의 도움을 받아 오픈 소스 클라우드 서버리스의 표준으로 자리 잡고 있는 Knative를 대상으로 간단한 테스트를 진행했습니다.

Knative는 Google Cloud Service에서 IBM, Red Hat, Pivotal, SAP과 협력해 개발한 오픈 소스 플랫폼으로 ‘Kubernetes+Istio’를 확장해 더 나은 서버리스 환경을 제공하고자 만든 플랫폼입니다.

Knative를 사용하면서 얻을 수 있는 이점들을 좀 더 직관적으로 알아보기 위해 쿠버네티스를 활용해 간단한 서비스를 배포한다고 가정해 보겠습니다.

가장 기본적으로 deployment, service 구성에 대한 yaml 파일을 작성하고, 외부에서 접근할 수 있도록 라우팅 설정 그리고 서비스가 잘 동작하고 있는지 확인하기 위한 모니터링과 로깅을 추가해야 합니다. 그 외에 카나리 배포(canary release)를 한다면 추가적인 설정 구성을 해야 합니다.

이처럼 쿠버네티스만을 사용할 때는 고려해야 할 사항이 많아집니다. 하지만 Knative는 auto-scaling, 빌드/배포나 라우팅 등 구성 작업에 대한 부분을 추상화해 제공하기 때문에 기본적으로 작성해야 하는 서비스 설정 파일에 단지 몇 줄 추가하는 것만으로 위에서 언급했던 것들이 가능해집니다.

그럼 지금부터 몇 가지 간단한 설정을 통해 Knative에서 제공하는 편리한 기능들을 어떻게 사용할 수 있는지 알아보겠습니다.

지금까지의 내용을 바탕으로 서버리스와 Knative를 살펴보면 비용 절감 측면과 편의성에서 긍정적인 결과를 기대할 수 있을 것으로 보입니다. 하지만 서버리스를 우리 플랫폼에 바로 도입할 수 있을까요?

요청이 있을 때마다 인스턴스를 새로 생성하는 Cold Start가 발생한다면 어떨까요? 배치와 같이 실시간성을 요구하지 않는 애플리케이션이라면 큰 문제가 없겠지만, 바로 응답을 주어야 하는 경우에는 인스턴스가 구동되어 Function을 실행하기까지 대기 시간(delay)이 발생하게 됩니다. 요청이 빈번하지 않은 애플리케이션에서 Cold Start는 피할 수 없는 이슈이기에 인스턴스를 빠르게 구동할 방법에 대한 연구가 필요합니다.

서버리스 플랫폼이 인스턴스를 초기화하는 데 소요되는 시간은 사용하는 언어, 라이브러리 수, 코드의 볼륨, 환경 설정 등 여러 요인에 따라서 몇 밀리초(ms)에서 최대 몇 초(s)에 이르기까지 다를 수 있습니다. [그림 9]는 AWS Lambda에서 언어와 메모리 크기에 따른 Cold Start 시간의 차이를 테스트한 그래프입니다. 결과에 따르면 Python이나 Node.js보다 Java와 C#의 Cold Start 시간이 100배 이상 길며, 메모리가 클수록 언어 간 격차가 줄어드는 것으로 나타났습니다. 그런데 플랫폼센터에서 서비스하고 있는 대부분의 웹 서비스는 Java 기반의 스프링 프레임워크(Spring Framework)를 사용합니다. 따라서 Cold Start 지연과 메모리 사용을 줄이는 것은 반드시 해결해야 할 아주 중요한 문제입니다.

하지만 아래 [그림 11]에서도 보듯이 이 방식은 빌드할 때마다 jar 파일 크기만큼의 도커 레이어가 생성된다는 단점이 있습니다.

애플리케이션에서 수정되는 부분은 일부분이기 때문에 매번 jar 파일 크기만큼 도커 레이어가 생기는 것은 매우 비효율적입니다. 이러한 단점을 해결하기 위해 최적화된 이미지를 만들기 시작했습니다.

스프링 부트로 개발된 애플리케이션의 경우 일반적으로 [그림 12]와 같이 fat jar라고 하는 실행 가능한 형태로 되어 있는데, 이 jar 파일의 압축을 풀어 의존성(dependency) 라이브러리와 애플리케이션 코드 부분의 레이어를 분리해 구성하는 것입니다.

이렇게 하면 거의 변경되지 않는 의존성 라이브러리에 대한 도커 레이어를 재활용할 수 있어 빌드 시간과 배포 시 다운로드 시간을 줄일 수 있습니다. 추가로 Google에서 제공하는 Jib을 이용하면 위에서 설명한 최적화 방식으로 도커 이미지를 손쉽게 생성할 수 있습니다. 물론, 이미지를 최적화하는 것도 중요하지만 우선 프레임워크나 라이브러리는 꼭 필요한 것만 경량화 버전으로 사용하고 코드의 중복을 제거하는 작업이 선행되어야 합니다. 로직을 여러 작은 함수로 세분화하고 재귀 함수 호출은 사용하지 않는 것을 권장합니다.

GraalVM은 Native Image라는 툴을 제공합니다. 이 툴을 이용하면 AOT(Ahead-Of-Time) 컴파일을 통해 Java 코드를 바이너리(binary) 파일로 만들 수 있습니다. 여러 연구 결과에 따르면 Native Image를 사용하는 경우 사전에 바이너리 파일이 만들어지기 때문에 startup 시간이 최대 100배 빠르며 런타임에 코드를 로드하고 최적화하기 위한 인프라가 불필요하여 메모리 사용량을 최대 5배까지 줄일 수 있다고 합니다.

아래 [그림 14]의 그래프는 플랫폼 센터 내부적으로 GraalVM과 Native Image에 대해 몇 가지 테스트를 진행했던 결과입니다.

동일한 애플리케이션을 OpenJDK(HotSpotVM), GraalVM 그리고 Native Image로 각각 실행했을 때의 startup 시간과 메모리 사용량을 비교한 것입니다. OpenJDK(HotSpotVM)로 실행했을 때보다 Native Image로 실행한 경우의 startup 시간이 16배 정도 빨랐으며, GraalVM보다 메모리를 2배 정도 적게 사용하는 것으로 나타났습니다.

하지만 Native Image는 아직 성숙하지 않은 기술이기 때문에 미흡한 부분이 있습니다. 특히 AOT 컴파일을 하게 되면 런타임에서 동적 클래스 로딩이 불가능하다는 점이 가장 큰 제약입니다. GraalVM에서 JNI(Java Native Interface), Java Reflection(런타임 시 클래스, 메소드, 필드 및 프로퍼티를 검사하고 수정하게 해 주는 기능) 등 동적 기능을 사용하려면 해당 요소에 대한 구성을 애플리케이션 실행 시 직접 설정해야 합니다. 그리고 Native Image로 빌드 시 많은 리소스가 요구됩니다. 간단한 스프링 부트 애플리케이션을 빌드하는 데 최소 3분 이상 소요되었고, 16GB 메모리가 필요했습니다.

서버리스가 기존의 모든 아키텍처를 대체하거나 모든 애플리케이션에 적용되기는 쉽지 않을 것입니다. 마틴 파울러의 말처럼 서버리스가 ‘No Ops’를 의미하지는 않지만 ‘No sysadmin’을 의미할 수는 있습니다. 서버리스는 분명 매력적인 기술입니다. 기술에 대한 충분한 이해와 서버리스 환경을 어떻게 구축해 어떤 애플리케이션에 적용하면 좋을지 충분히 검토가 이루어진다면 운영 및 비용 절감과 관리의 편의성 측면에서 긍정적인 결과를 기대할 수 있을 것입니다.