EC2 to Lambda. 서버에서 서버리스로

EC2 to Lambda. 서버에서 서버리스로

사용하기 편한 클라우드 서비스

안녕하세요, 저는 AX에서 외부 판매 채널들과 연동작업을 진행하고 있는 Noah라고 합니다. 이번에는 채널과 연동하면서 AWS를 구성하면서 경험했던 내용을 갼략하게 적어보려 합니다.

처음 IaaS(Infrastructure as a Service)로서 클라우드 서비스(Cloud Computing)는 가히 획기적이었습니다. 이 때 당시에는 서버를 세팅하기 위해서 서버 용 (속성 : 물리) 컴퓨터를 세팅하던 때였습니다. 더 이상 서버가 내 옆자리를 차지하는 것이 아니라 어디 있는지 알 수 없는 가상의 어딘가에 있을 수 있다는 것을 깨닫게 되었으니까요.

그 덕분에 사람들은 유연하게 서버를 관리할 수 있게 되었습니다. 필요한 만큼의 서버를 사용료만 내면 바로 쓸 수도 있습니다. 필요하지 않은 서버는 사용하지 않도록 해두면 비용도 나가지 않습니다. 만약 서버 컴퓨터를 그 당시 필요해서 구매했다면, 서버를 사용하지 않는 것은 또 다른 기회비용의 형태로 비용이 발생하는 셈이었으니 비용을 많이 아낄 수 있었습니다.

여담으로 덕분에 학교에서 공부하던 개발자 꼬꼬마였던 필자 조차도 별도의 비용 없이 간단한 형태의 웹 사이트를 친구들에게 제공하여 성공적인 수행평가를 할 수 있었습니다. 한달에 어느 정도는 비용을 내지 않고도 사용할 수 있었던 것도 한 몫 했습니다.

이런 유연함은 중소기업, 스타트업에게는 굉장한 매력으로 다가왔습니다. 적은 비용을 투자하여 다양한 시도를 해 볼 수 있기 때문입니다. 이러한 점 덕분에 많은 IT 기반의 회사들은 특별한 이유가 있지 않는 한 (보통 법적인 이슈) 클라우드 서비스를 사용합니다. 우리 AX도 이러한 이유로 AWS라는 클라우드 서비스를 사용합니다.


사용해 볼까요

AWS는 EC2(Elastic Compute Cloud)라는 가상 컴퓨터 서비스를 제공하고 있습니다. 가상 컴퓨터의 운영체제가 리눅스라면 ssh를 통해 접속할 수 있고, 윈도우라면 원격접속 프로그램을 통해 접속할 수 있습니다. 클라우드 컴퓨터를 사용하기 위해서 AWS의 EC2 인스턴스(각각의 가상 컴퓨터 하나)에 접속하여 서비스에 필요한 프로그램들을 설치하고 서버 설정들을 해 둡니다. 그리고 세팅을 완료하면 서버에 설치된 프로그램이나 파일들을 AMI(Amazon Machine Image)를 통해 고스란히 저장할 수 있습니다. 그러면 한번 설치한 프로그램 들을 다시 설치하지 않고도 여러 개의 EC2에 AMI를 불러와서 똑같은 환경의 컴퓨터를 만들 수 있습니다.

내가 설정한 세팅대로 컴퓨터가 복사가 된다구

웹 페이지를 여러 서버에서 제공할 수 있도록 AWS에서는 ALB(Application Load Balancer)를 이용해서 트래픽을 골고루 보내줄 수 있습니다. 그래서 같은 역할을 하는 여러 대의 EC2 서버에 골고루 트래픽이 전달될 수 있도록 할 수 있습니다.

Auto Scaling을 이용하면, EC2의 갯수를 자동으로 조절할 수 있습니다. AMI 있겠다, 가져다가 EC2에 세팅하는 것도 자동으로 할 수 있었습니다. 그래픽이 언제 증가할 지 예상된다면 (프로모션을 통해 시즌 한정 상품을 판매한다거나) 미리 시간이 되었을 때 EC2의 갯수를 늘려둘 수도 있습니다.

자동으로 똑같은 환경을 세팅할 수 있어서 배포를 할 때에도 자동으로 할 수 있었습니다. 여러가지 배포 방법 중 하나가 바로 Blue Green Deployment입니다. 새로운 코드가 적용된 서버(Green)를 자동으로 만들어 줘서 기존 코드가 적용된 서버(Blue)와 동시에 실행하다가 서서히 기존 코드가 적용된 서버를 서서히 줄여나가는 식입니다. 그 외에도 다양한 바리에이션이 존재하였습니다.


클라우드 서비스가 등장하고 나서 서버 자원을 더 자유롭게 사용할 수 있게 되었고, 개발자들은 여기서 멈추지 않고 더 끊임없이 더 잘 사용하고 안정적인 클라우드 기반의 서비스를 제공하기 위해 다양한 노력을 했습니다.

또 다른 페러다임 서버리스

웹 서비스를 운영하고자 하는 개발자가 앞의 내용을 보고 나면, AWS의 인프라 세팅이 완벽하게 끝난 것 처럼 보입니다. 하지만, 불행히도 실제로는 그렇지 않습니다. 왜냐하면, 저 기능들이 다양한 변수에 의해서 생각만큼 잘 작동하지 않았기 때문입니다. 블루 그린 배포의 경우, 그린 서버를 늘이고 블루 서버를 줄어야 하는데, 블루 서버 대신 그린 서버가 생겼다가 다시 줄어드는 현상이 자주 발생했습니다. Auto Scaling의 경우에도 갑자기 요청이 늘어났을 때, 바로 EC2의 갯수가 늘어나는 것이 아니라 AMI에서 이미지를 EC2로 불러오는 초기 세팅 시간이 필요했습니다. 그래서 서비스를 제공해 주어야 하는 서버가 늘어나기 전까지는 어쩔 수 없이 다운타임이 생겼습니다.

이런 상황에서 클라우드 서비스에 등장한 것이 서버리스(Serverless) 였습니다. 서버리스는 말 그대로 서버가 없다는 뜻입니다. 사실 정확히는 개발자가 서버를 관리할 필요가 없고 추상화 되어있어서 더 이상 글의 앞 부분에서 언급했던 문제들을 고민할 필요가 없어졌습니다. 여태 개발자의 영역이었던 서버 관리가 개발자의 손을 떠나 클라우드 서비스로 옮겨가면서 개발자는 애플리케이션 개발에만 집중할 수 있게 되었습니다.

서버리스를 가능케 하는 특징으로 Event Driven하다는 것입니다. 외부의 상황에 따라 이벤트가 발생하고 그 이벤트가 서버리스를 실행하는 형태입니다. 클라우드 서비스에 있는 자원들은 거의 대부분 이벤트가 될 수 있습니다. 가장 간단한 예는 AWS S3에 파일을 새로 추가할 때가 됩니다. 그 외에도 특정 Endpoint를 통해 http request를 발생하는 경우도 있습니다.

AWS Lambda

AWS에서 서버리스 서비스로는 Lambda가 있습니다. Lambda는 그리스 문자 중 11번째 글자이며, 논리학에서 함수를 뜻 하는 기호로 알론조 처치에 의해서 처음 제시되었습니다. AWS Lambda는 이 의미를 차용하여 이름을 지었던 것으로 보입니다. 람다 기호의 뜻 그대로 AWS Lambda는 실행시킬 수 있는 함수들을 가지고 있습니다. 이러한 함수를 handler라고 합니다.

그리고 AWS Lambda를 실행시키기 위한 이벤트들로는 -과장 좀 많이 보태서- AWS의 모든 자원들이 될 수 있습니다. 앞의 예시처럼 AWS S3에 파일을 추가 & 변경했을 때가 될 수도 있으며, API Gateway에 http request를 요청했을 때도 있습니다. 덕분에 SQS나 SNS의 워커로서의 역할도 충분히 할 수 있습니다.

다양한 이벤트가 발생했을 때 handler를 통해서 실행되다 보니 Lambda를 MSA로 인프라를 구성할 때 사용합니다. 작은 기능 하나하나를 handler로 만들어서 하나의 큰 시스템을 만들기에 적당합니다.

장점

이런 서버리스의 가장 큰 장점으로는 개발자가 인프라 관리를 해주지 않아도 된다는 점에 있습니다. 클라우드 서비스에서 정해놓은 규칙대로 실행환경(콘테이너)를 구성해 두기만 하면 클라우드 서비스에서 알아서 배포해 줍니다. 이것이 주는 장점은 엄청나게 강력합니다.

먼저, 실행하고 있지 않을 때에는 아예 자원을 사용하지 않습니다. EC2의 경우에는 요청이 많든 적든 하나의 컴퓨터는 상시 대기를 하고 있어야 하는 것과 대조적입니다. 이건 비용적인 측면에서도 유리한데, 이건 클라우드 서비스의 대부분의 가격 정책이 “쓴 만큼 돈낸다”에 기반한 것이기도 합니다. EC2는 항상 내는 일정 금액이 있다면, 람다는 요청이 아예 없다면 비용을 지불할 이유가 없습니다.

다른 장점으로는 배포가 매우 빠르게 이뤄질 수 있다는 점이 있습니다. EC2의 경우에는 가상의 컴퓨터를 할당 받아서 개발한 코드, 설치된 패키지, 프로그램, 그리고 운영체제까지 포함된 AMI를 EC2에 옮겨서 배포해 주어야 하는데, 서버리스에서는 그럴 필요가 없었습니다. 서버리스인 AWS Lambda의 경우 이벤트가 발생하자마자 배포를 바로 진행하고 핸들러를 실행시켜 줍니다. 배포를 하는데 드는 지연시간은 일반 사용자(AWS를 통해 배포된 제품을 사용하는 사용자)가 느낄 수 없을 정도로 빠릅니다. 이것의 더 큰 장점은 트래픽이 갑자가 과도하게 발생했을 때 빛이 됩니다. 아무리 갑자기 트래픽이 증가해도 순식간에 대기되어있는 AWS의 자원들에 필요한 만큼 바로 할당되고 트래픽을 유연하게 처리해 줍니다. 앞의 Auto Scaling를 통해 세팅하면, EC2에 배포하느라 대기시간이 길어서 과도한 트레픽을 제대로 처리해 주지 못하던 것과 대조됩니다.

편해서 끊을 수가 없는게 단점

하지만 그만큼 단점도 있는데, 가장 큰 단점은 클라우드 서비스에 종속되어져 버린다는 점입니다.

EC2 정도만 되더라도 PC방 마냥 하나의 컴퓨터를 빌려서 쓰는 것이고, 서버에 자유롭게 세팅하여 사용할 수 있었습니다. 하지만 람다를 쓰게 된다면, 람다를 쓰기 위해서 정해진 규칙에 따라 세팅된 환경에서 사용할 수밖에 없습니다. 그래서 람다에 실행할 수 있는 프로그래밍 언어도 굉장히 제한적입니다. 물론 대부분이 사용하고 있는 메이저 언어는 지원하고 있고, 파이썬도 지원하고 있어서 이 점에서는 큰 문제가 없습니다.

자주 있지는 않지만, 만약 클라우드 서비스를 다른 서비스로 옮길 때 문제가 됩니다. 꼭 클라우드 서비스 (AWS를 다른 플랫폼으로 변경하기)가 아니더라도 서비스 내에서 다른 기능을 사용할 때에도 교체 비용이 발생할 수 있습니다. 몇몇 코드들이 람다에 의존성있는 구조로 작성되어 있을 것이기 때문입니다.

이런 단점이 있음에도 서버리스와 람다를 이용해서 구성하는 이유는 AX에서 인프라를 고민하는 개발자가 처하거나 처할 예정인 문제를 방지하기 위한 가장 효율적인 방법이기 때문입니다. 전 세계에 서비스 되고 있는 서비스이기 때문에 트래픽이 많이 발생하는 시간대가 개발자가 출근하여 즉시 대응이 가능한 시간인 경우보다 아닌 시간인 경우가 많습니다. 그렇다보니 언제나 발생할 수 있는 문제를 대비할 수 있는 환경을 만드는게 중요했습니다. 그리고, 수많은 외부 여행 오픈 마켓과도 연결되어있다보니 변수가 많았고 예측하기 어렵습니다. 여행 오픈 마켓에서 프로모션을 하면 주문이 늘어나고 이걸 모아오는 액스에도 트래픽이 증가합니다. 외부에서 프로모션을 하는 것은 예측할 수 있는 것이 아니기 때문에 항상 대비가 되어있는 것이 중요합니다.

서버리스는 이러한 문제를 막아줄 현존하는 완벽한 해결책이었습니다. 아무리 트래픽이 늘어도 전 세계 절반의 트래픽을 소화하는 든든한 AWS의 자원이 대기하고 있으니까요.

지금까지 서버리스를 구성하면서 특징들을 정리해 보았습니다. 슬슬 코로나가 끝나가고 여행 산업이 다시 폭발적으로 회복 및 성장할 예정입니다. 그 성장의 흐름에 AX가 합류할 수 있는 준비를 하기 위한 노력이 결실을 맺을 수 있을거라 생각합니다.

지금까지 Noah였습니다. 읽어주셔서 감사합니다.

액스(AX)로 다 채널 여행 상품 동시 판매 및 운영


액스는 투어 & 액티비티 판매자의 온라인 판매를 위한 최적화된 다 채널 자동 판매 서비스 입니다.
지금 무료로 시작해보세요. 써보면서 이해하는 것이 가장 빠릅니다!