서버 아키텍처의 새로운 패러다임 - 서버리스 아키텍처(Serverless Architecture)

Key Point.

• 서버리스 아키텍처란 무엇인가?
• 서버리스 아키텍처가 나오기까지.
• 왜 트렌드는 서버리스 아키텍처로 가는가?

서버리스 아키텍처란 무엇인가?

서버리스 아키텍처란 직접 운영하는 서버 없이, 클라우드 상의 서비스만을 활용하여 사용자의 요청에 모두 응답할 수 있는 서버 아키텍처를 말합니다. 위의 그림에서 알 수 있듯이 클라우드 상의 서비스들은 각자 다른 핵심기능들을 수행하는 마이크로서비스(MicroService)들입니다. 마치 레고 조각들을 조립해서 하나의 작품을 만드는 과정과 흡사합니다. 크기별로 있는 다양한 레고들을 목적에 맞게(예를 들어 자동차 만들기, 성 만들기) 배합하면 금방 만들 수 있습니다.

서버리스 아키텍처에서도 마찬가지입니다. 여러분이 원하는 서비스를 정의한 뒤 클라우드상에서 제공되는 여러가지 마이크로서비스들을 조합하면 훨신 빠르게 사용자의 요청에 응답하는 상용 서비스를 런칭할 수 있습니다.

서버리스 아키텍처가 나오기까지.

기존의 환경은 온프레미스 (On-premise) 환경으로, 직접 데이터 센터를 운영했습니다. 그렇기 때문에 물리 서버를 직접 준비하고 운영체제 설치 및 어플리케이션 개발 / 배포에 필요한 모든 프로그램들을 직접 설치해야 했습니다. 따라서 서비스를 실제 배포하는데까지 최소 몇 주간의 시간이 걸렸습니다.

이는 클라우드 시대가 도입되면서 점차 사라지는 추세에 있습니다. 대표적인 클라우드 서비스인 AWS(Amazon Web Service)의 경우 EC2(Elastic Compute Cloud)서비스를 제공합니다. 이는 기존의 온프레미스 환경에서 사용자가 직접 구축해야 했던 많은 부분을 대신해줍니다. 물리적 서버를 준비하고 운영체제를 설치하는 대신, 자신의 서비스에 적합한 크기의 인스턴스를 고르고 생성 명령만 내리면 몇 분안에 운영체제 설치가 완료된 서버가 만들어집니다. 이는 매우 혁신적입니다. 이로 인해 사용자는 서비스 개발에 집중할 수 있고 시간을 많이 단축할 수 있습니다. AWS에서는 사용자의 다양한 요구사항을 충족하기 위해 40여가지의 다양한 인스턴스 타입을 제공합니다.

혁신은 계속됩니다. 운영체제가 설치된 서버가 단 몇분안에 만들어진다는 것은 엄청난 발전입니다. 하지만 어플리케이션 배포를 위해 설치해야 할 프로그램과 라이브러리들을 서버 인스턴스가 바뀔 때마다 다시 설치하는 작업은 비효율을 초래했습니다. 이 문제를 해결한 것이 컨테이너 서비스입니다. 대표적인 컨테이너 서비스로는 Docker가 있습니다. 컨테이너 서비스는 어플리케이션 배포를 위해 필요한 수 많은 프로그램들이 설치된 상태를 이미지화하는 것입니다. 예를 들어, 하나의 서버 인스턴스에서 2개의 어플리케이션을 배포한다고 가정해 봅시다. 이 둘을 배포하기 위해 필요한 프로그램들은 서로 다를 것입니다. 하지만 같은 운영체제에서 돌아가는 한 운영체제에서 공통적으로 사용하는 부분이 있습니다. 따라서 예를 들어, 핵심적인 부분(커널이라고 불립니다)은 그대로 놓고 다른 부분(어플리케이션 배포를 위해 설치한 프로그램들과 다른 환경 세팅)을 이미지화시켜 어댑터처럼 갈아 끼울 수 있게하면 어떻겠냐는 아이디어가 나오게 됩니다. 바로 이 아이디어를 구현한 것이 컨테이너 서비스입니다. 이를 활용하면 새로운 서버 인스턴스를 사용하거나, 서버를 이전하게 될 때에도 이미지화 시켜놓은 컨테이너를 새로운 서버 인스턴스에 끼워 넣기만 하면 끝입니다. 바로 서비스 배포가 가능하게 되는 것입니다.

여기까지만도 엄청난 발전이라고 할 수 있습니다. 하지만 혁신은 끝나지 않습니다. 이제는 사용자가 세팅해야 하는 서버를 사용하는 것조차 거부합니다. 여기에서 서버리스 아키텍처가 탄생했습니다. AWS에서는 AWS Lambda와 AWS API Gateway라는 서비스를 통해 직접 설치 및 운영하는 서버가 없는 아키텍처를 설계할 수 있도록 지원하고 있습니다.
AWS Lamda는 Python, Javascript, Java 코드를 사용하여 사용자의 요청에 특정 응답을 할 수 있는 함수를 생성할 수 있습니다. 그리고 AWS의 클라우드 서비스 이벤트에 이 함수들이 반응하도록 하여 서버가 없이도 사용자의 요청에 응답할 수 있는 시스템을 만들 수 있게 되는 것입니다.
여기에 AWS API Gateway를 함께 사용한다면 사용자의 다양한 HTTP 요청에 모두 Lambda 함수로 대응할 수 있습니다. 이 둘만 조합해도 서버 인스턴스를 사용하거나 컨테이너 서비스를 사용하지 않고도 고객들에게 자신의 서비스를 알릴 수 있는 웹페이지를 만드는 것이 어렵지 않게 됩니다.

왜 트렌드는 서버리스 아키텍처로 가고 있는가?

기존의 온프레미스 환경에서 서비스를 개발 / 배포 / 운영할 때 최소 사용자는 다음과 같은 사항들을 고려하여야 합니다.

• 운영중인 서버에 문제가 생기면 어떡할 것인가? → 모니터링 환경이 필요합니다.
• 서버가 죽었을 때 내 서비스는 어떻게 지속할 수 있는가? → Fail Over시 대비책을 직접 구축해야 합니다.
• 내 예산에 맞는 서버의 크기는? → 직접 여러가지 서버의 스펙들을 검토해야 합니다.
• 내 서버들에 대한 접근을 어떻게 통제하는가? → 직접 해당 운영체제나 방화벽에 대한 검토가 필요합니다.
• 사용자가 늘어나면 서버를 업그레이드(Scale-Up) 해야하나 아니면 수를 늘려야(Scale-Out)하는가?
• 이외 다양한 문제 상황들.

여러분이 만약 지금 막 개발에 착수하는 스타트업이라면 위의 사항들을 모두 고려하는 것은 굉장히 힘든 일입니다. 규모가 큰 조직에서도 쉬운 작업은 아닙니다. 무엇보다 개발 일정에 맞추기 위해서는 위의 사항들에서 몇 가지를 포기하거나 많은 인재들의 노력이 필요할 것입니다. 이는 여러모로 문제가 발생할 소지가 많습니다.

반면, 클라우드 서비스인 AWS를 활용해 서버리스 아키텍처로 여러분의 서비스를 개발하게 되면 다음과 같은 장점이 있습니다.

• 서버 운영에 필요한 많은 도구들을 제공받습니다.

• 환경세팅에 들어가는 시간비용을 절감할 수 있습니다.
• 새로운 기술 도입 및 비즈니스 로직 혁신에 있어 빠른 적용이 가능합니다.
• 수 많은 서버리스 옵션을 제공합니다. (AWS의 경우)
• 서비스 확대 및 축소 시 자동으로 Scale-Up 혹은 Sclae-Down을 진행합니다.
• 높은 가용성을 제공합니다. 클라우드 환경에서는 Fail Over 상황 대처를 훨씬 유연하게 할 수 있습니다.
• 직접 데이터 센터를 운영하는 것보다 비용을 절감할 수 있습니다.
  (물론 클라우드에서 제공하는 마이크로 서비스들을 충분히 검토하고 여러분의 서비스에 적용했을 경우에 한합니다)

위와 같은 이유 때문에 빠르게 서비스를 만들고 싶은 스타트업이나, 혼자서 새로운 서비스를 개발해보고 싶은 사용자에게 클라우드 서비스와 서버리스 아키텍처는 매우 안성맞춤입니다.

예를 들어, 개인 개발자가 자신이 만든 프로그램을 홍보하는 랜딩 페이지를 구축한다고 가정합시다.

이 경우 AWS API Gateway와 AWS Lambda를 통해 사용자에게 홍보 페이지를 보여줄 수 있습니다.
이 페이지에 사람들이 얼마나 접속하는지 원한다면 모니터링 도구를 연결하면 확인할 수 있습니다.

만약 Contact에 자신의 정보를 남겨놓은 사용자들의 로그를 저장하고 싶다면 Lambda와 AWS RDS를 연동하여 데이터를 저장할 수 있습니다.
이 모든 것을 클라우드 관리 플랫폼에서 설정하고 관리할 수 있습니다.

기존의 온프레미스 환경과는 차원이 다른 생산성을 보여줍니다.

이것이 클라우드와 서버리스 아키텍처가 트렌드가 될 수 밖에 없는 이유라고 할 수 있습니다.