[Serverless With Golang] 1. Serverless Architecture

 

TABLE OF CONTENTS

 

1. Which skills do DevOps engineer need? 

아래는 DevOps 엔지니어가 반드시 갖추어야 하는 세가지 역량이다. 

1. 업무 / 개발 과정에서 불편한 부분을 어떻게 하면 효율적이고 편하게할 자동화할 아이디어를 생각해내서 자동화를 구현까지 하는 능력
2. Third Party SaaS Solution과 연계를 해내는 구조를 만들어서 좀 더 효율적으로 개발할 수 있는 구조를 만드는 능력. 가령, 슬랙이나 모니터링에는 Datadoc 사용
3. DevOps 엔지니어라고 해서 단순히 인프라를 구축하고 모니터링하고 트러블 슈팅하고 배포만 하는게 아니라 자동화를 하기 위해서는 실제로 개발의 영역까지 손댈 수 있어야 한다. 즉, DevOps 엔지니어는 개발이 가장 기본적인 소양이다. 이런 개발 능력을 밑바탕으로 깔고 그 위에 올라가는 개발 자동화나 빌드 자동화나 배포 자동화를 생각해야하므로 DevOps 엔지니어는 언제나 항상 개발이 기본이어야 한다.

 

2. What is serverless architecture?

클라우드 서비스가 어떻게 발전해왔는지 봐보자.

2000년도 경에는 실제로 데이터 센터의 형태로 물리적인 서버와 스토리지 운영체제 미들웨어(런타임 등) DB를 실제로 관리자들이 IDC에 가서 Server Rack에 직접 수동으로 설치를 하고 application service를 제공하는 형태였다.

그러다가 2000년대 후반부터는 클라우드가 도입되면서 여러 클라우드 서비스가 탄생하게 되었다.

일단 IaaS는 물리적 자원을 제공하는 서비스의 형태로 고객에게 4대 리소스를 가상화해서 제공하게 되는 서비스로 기존의 Data Center에서 제공받던 물리적 서버와 같은 자산을 가상화 해서 제공하므로 예전에는 서버의 사양을 증축하려면 발주를 넣고 설치하고 졸라 오래 걸렸는데 IaaS 덕분에 이것을 즉각적으로 수행할 수 있게 됨. IaaS의 대표적인 서비스 : AWS EC2

IaaS 다음으로는 PaaS라는 형태로 서비스가 제공되었는데 SW 개발을 돕는 Platform을 제공하게 되었다. 고객에게 OS와 그 위에 동작하는 WAS나 DB와 Java Runtime이나 Node Runtime같은 Middleware(소프트웨어를 돌리기 위한 환경)을 가상화해서 제공하게 되었다. 따라서 개발자들이 개발한 서비스를 그대로 이 PaaS Platform위에다가 바로 배포를 해서 서비스를 제공할 수 있게 되었으므로 서비스 배포 속도가 빨라지게 되었다.

PaaS 다음은 Serverless로 서버가 없는 환경은 아니지만 내부적으로 서버를 띄워서 실행시켜주게 되었는데 이는 서비스를 구성하기 위해 필요한 4대 Resource만을 동적으로 할당해서 할당되는 부분만 비용을 청구하는 것으로 기능을 동작시키기 위한 모든 환경을 사용자가 직접 구성하는 것이 아니라 CSP의 내부적으로 도는 서버에 그냥 띄우기만 할 뿐이다. 따라서 지속적으로 계속 도는게 아니라 특정 이벤트가 트리거가 되었을때만 실행이 되게 된다.

가령, 어떤 URL에 트래픽이 들어왔을 때만 실행이 되거나 특정 시간에만 실행이 되도록 하고 싶을 때 트리거가 된다.

이런 서버리스는 규모가 작은 서비스에선 비용 효율적이고 계속 돌지 않기 때문에 자원 효율적이지만 서비스 규모가 점점 커져서 MSA가 되다보면 api server가 계속 많게 되는데 이 경우에는 지속적으로 api를 request하게 되어 계속 리소스를 사용해야하기 때문에 서버리스 환경으로 구축하는 것은 비용적인 측면에서 돈이 더 나와서 부적절하다. 또한 AWS의 서버리스 서비스인 Lambda는 실행 속도(몇 milli second안에 끝나는가)와 환경(메모리를 얼마나 할당할 것인가)에 따라서 비용이 달라지게 된다.

그러면 이 서버리스를 만들 수 있는 모델은 어떤게 있을까?

2개가 있다. BaaS와 FaaS이다.

BaaS는 application service를 개발할 때 복잡한 백엔드 기능(인증, 메시징 서비스)를 사용자가 직접 개발하지 않고 CSP가 제공하는 서비스를 이용하는 것으로 대표적인 예로 Firebase가 있다.

Firebase는 Cloud Messaging(메시징 기능 제공) + Realtime DB + Authentication까지 서비스의 형태로 제공하므로 application 개발시 Firebase를 사용해서 내가 필요로 하는 백엔드 서비스만 바로 바로 서비스 형태로 제공받아서 사용할 수 있게 된다.

FaaS는 아래를 보자.

 

이제 서버리스에서 FaaS에 대해서 성능을 최적화하는 방안 3가지에 대해 생각해보자.

1. FaaS의 Cold Start 줄이기 : Cold Start를 줄이게 되면 Warm Start만 지속적으로 이루어질 수 있기 때문에 Cold Start를 줄이는게 중요하다.

2. FaaS가 돌아가는 실행 환경의 메모리 증가시키기 : 메모리가 커질 수록 Fuction의 컴퓨팅 파워도 증가하는 셈인 것이다아래 표를 보면 memory가 증가할 수록 duration(함수가 실행되는 시간)이 줄어들게 된다. AWS Lambda와 같은 Function이 돌아가는 환경은 memory에 따라서 결정이 되게 된다.

 

헌데 어떤 시점으로 가면 이 차이가 점점 미미하게 되므로 이 임계점을 잘찾아서 실제로 실행되는 Function이 실행되는 환경의 memory를 적절하게 잡는게 중요하다. 메모리를 많이 쓸 수록 비용이 졸라 많이 나오므로 magic number를 잘 찾아서 사용하도록 하자

 

3. FaaS의 Provisioned Concurrency를 활성화 하자 : 아래를 보게 되면 2개의 request가 수행될때마다 cold start duration과 invocation duration이 함께 진행되게 된다.

만약 3번이 또 들어오게 되면 3번도 cold start duration과 invocation duration이 두 duration 모두 다 나타나게 되므로 너무 FaaS가 동작하는데 오래 걸리게 된다.

헌데 Provisioned Concurrency를 활성화 하게 되면(즉, 사용자가 원하는 리소스를 미리 할당하여 동시성을 제공) 아래와 같이(6개의 provisioned concurrency 활성화한 경우) 6개의 request가 들어오게 될 경우 6개가 동시에 cold start가 걸리게 되고 만약 1번 container에서 사용되고 있는 function이 안끝났으면 2번으로 가고, 여기도 안되면 3번째로 가면 되고, 쭉쭉 그렇게 진행되다 보면 6개의 request를 동시에 처리할 수 있게 된다.

헌데 provisioned concurrency도 일단 미리 내부적으로 사용되는 EC2를 대기시켜 놓는 것이므로 무조건 좋은 것은 아니다. 비용 이슈로 인해서. 따라서 적당한 수준으로 최적화 해서 사용하도록 하자.

 

따라서, 서버리스의 장점을 먼저 생각해보자면

첫째, 서비스의 규모가 작은 경우에는 Event-driven으로만 동작하므로 리소스가 지속적으로 사용되질 않아서 당연히 비용 절감의 장점이 있다.

둘째, application logic 개발 후 함수에 코드만 올리면 되므로 서비스 로직에만 집중할 수 있게 된다. 그외(os 셋업, runtime 셋업 등)는 csp에서 제공해주므로 빠른 개발과 배포가 가능하다.

셋째, 높은 확장성. csp가 자동으로 scaling을 해주므로 내가 관리하는 것보다 scalability가 더 좋아지게 된다.

서버리스의 단점은

첫째, 서버가 떳다가 어느 정도 트래픽이 없으면 다시 서버가 내려가서 자원을 반환하게 되므로 local data(서버에 있는 데이터)를 활용하는 것이 불가능하므로 외부에 state를 저장해야하므로 dynamoDB나 RDS를 꽂아줘야만 한다.

둘째, Vendor에 종속적이므로 서버리스끼리 호환이 안될 수도 있다.

셋째, 긴 시간 작업(가령, Batch 작업, 정산 작업)에는 서버리스를 사용하게되면 비용이 더 많이 나오게 됨

넷째, 어쩔 수 없이 발생하는 Cold Start의 문제가 발생한다.

서버리스 서비스 중에서 FaaS를 제공하는 Vendor는 아래와 같다.

 

 

아래는 서버리스 활용 사례이다.

 

 

[Reference]

1. https://aws.amazon.com/ko/serverless/

2. https://www.serverless.com/guides/what-is-serverless