이러한 변화를 가장 극적으로 보여준 것이 바로 지난 5월말 뉴욕에서 있었던 서버리스컨퍼런스(Serverless Conference)다. 일반적으로, 회자되는 기술의 유행 방식은 선두 주자가 혁신적인 서비스를 내면, 경쟁적으로 유사한 서비스가 만들어지고, 오픈 소스로 된 관련 도구가 증가하면서 개발자들이 여기에 동조하고, 콘퍼런스에서 다 같이 만나는 패턴인데,이는과거에도 종종 있었다.
2014년 AWS람다(Lambda)가 이러한 개념을 처음 선 보인 이후로, 많은 클라우드 업체들이 이를 벤치마킹한 서비스를 줄줄이 내놓고 있다. 많은 개발자들은 관련된 코드 예제들을 오픈 소스로 공개하고, 급기야는 Serverless FRAMEwork, CloudiaJS 같은 서버리스 오픈 소스 개발 프레임워크가 계속 나오고 있다. AWS에서 Lambda와 API Gateway 서비스 개발을 총괄하고 있는 팀 와그너(Tim Wagner)는 서버리스 콘퍼런스키노트 발표에 앞서 물리 서버를 부숴버리는 상징적인 퍼포먼스를 보여 주기도 했다.
물론 서버리스(Serverless)라는 말 자체가 서버가 필요 없다는 뜻은 아니다. 클라우드에서도 서버는 존재하고 있고, 다만 고객이 스스로 관리해야 하는 서버 혹은 콘테이너가제로(0)에 수렴한다는 의미다. 따라서, 서버리스란 오로지 이벤트에 따라 동작하는 클라우드 기반의 나노 수준 (최근 회자되는 마이크로서비스가 가진 크기를 생각해서) 서비스 단위의프로그램 코드만을 개발하고 배포에 집중한다는 의미이다. 기존의 PaaS(Platform as a Service)는 복잡한 모놀리식(Monolithic) 애플리케이션을 지원했다는 점에서, 무상태(Stateless)는 서버리스의특징과 대비된다.
이유는 간단하다. 더 빠르게 움직이기 위해서다. 이러한 특징은 인프라 설치, 운용, 확장성 고려, 복잡한 배포 및 모니터링 등 많은 관리 업무를 줄이고, 민첩하게 만들고 배포하려는 회사 혹은 팀에게 적합하다.
예를 들어, AWS Lambda는 가장 선두에 있는 서비스로서 Node.js, Java, Python 코드를 올리기만 하면, 코드가 실행될 때 마다 5분 안에 실행하면서 100ms 단위로 과금한다. 다른 AWS 서비스의 이벤트를 처리(예를 들면, Amazon S3에 이미지가 올라오면 썸네일을 만드는 기능을 동작)하거나, Amazon API Gateway로 들어오는 HTTP 요청에 대해서도 실행할 수 있다. 올려진 코드에 대한 버전 기능, 배치 작업을 위한 Cron 기능등을 제공하고, 매월 100만 밀리세컨드에 대해 무료로 제공하기에 테스트 개발에도 적합하다.
모바일 앱을 위한 서버없는백엔드 아키텍처 사례(출처: AWS 한국 공식 블로그) 모바일 앱을 위한 서버없는백엔드 아키텍처 사례(출처: AWS 한국 공식 블로그)
■ 진화하는 서버리스 개발 생태계
서버리스 아키텍처나 프레임워크는아직 초기 단계다. 해결해야 할 사항도 적지 않다. 예를 들어, 기존 서버 기반 SW 플랫폼 개발 프레임워크만큼, 통합 개발 환경(IDE)나 테스팅, 디버깅이 편리하지 않다. 개별 클라우드 함수의 크기나 성능에 따른 메모리 사이징(그에 따른 CPU 및 네트워크 사용량) 및 함수 기능을 어디까지 세분화 할 것인가에 대한 기준도 명확하지 않다.
이런 부분은 서버리스 아키텍처에 대한 다양한 논의가 진행되고, 개발자 생태계가 커지면서 각종 지원 개발 도구가 나온다면 자연스럽게 해결될문제라고 생각한다.
하지만, 가장우선적으로서버리스에 대한 개념과 목적을 명확하게 하는 것이 중요하다. 못을 박기 위한 도구인 망치를 가지고, 음식을 만들려는 우를 범하지 않기 위해서다. 팀 와그너는서버리스 콘퍼런스키노트 중 아래와 같이서버리스선언문(Serverless Manifesto)을 소개하였다.
함수(Function)가 서비스의 기본 배포 및 확장 단위이다.
프로그래밍 모델에서 물리 서버, 가상 서버 및 콘테이너에 대한 의존성을 제거하라
데이터 스토리지는 어딘가 무제한으로 있다고(사용한다고) 가정하라
사용자가 아닌 오로지 요청(Request)에 대해서만 확장하라
요청이 없는데 돈을 낼 필요가 없다(가상 서버나 콘테이너도 여전히 비효율적이다).
함수의 실행은 어디서나 가능하므로, 장애 복원력을 가지도록 만들어라
BYOC(Bring your own code) ?나만의 서비스를 책임지고 만들 수 있다!
통계 수집 및 로그 취득은 보편적인 필수 사항이다.
이와 함께 Flourish라는 오프 소스 서버리스 프레임워크를 곧 공개할 것이라고 밝혔다. 이 프레임워크는 마이크로 서비스의 형식을 정의하고, 기존 IDE와 통합하여 빌드 및 ZIP 파일 기반 배포를 할 뿐만 아니라 하나의 대시보드에서 모니터링 및 요금 집계가 가능한 현실적인 서비스 기능을 통합 할 예정이다. 또한 프로그램 코드와 버전 설정을 조합에 의한 일관된 롤백 기능도 제공한다. 벤더 중립적인 API 서비스 참조 역할도 하면서, 코드 작성 및 배포에만 집중되어 있는 기존 프레임워크의 대안이 될 수 있을 것이다.
Flourish가 중립적인 프레임워크로 자리잡더라도 다른 클라우드 업체들도 비슷한 수준의 서버리스 프레임워크를 내놓을 가능성이 높다. 기존의 개발자 커뮤니티에서 만들어지는 프레임워크 역시 생태계 확대에 이바지할 것으로 예상된다.
■ 서버리스의 대중화의 필수 조건은?
서버리스 개발 생태계 확대를 위해서는 기존 벤더 기반 서버리스 컴퓨팅 환경과 스토리지 서비스에서 개발자 생태계 기반 프레임워크와 개발 도구의 제공이 확대되는 단계도 중요하다.하지만 궁극적으로 서버리스 킬러 응용 프로그램(Killer Application)이 나와야 한다.
최근에 Slack을 기반으로 하는 채팅봇애플리케이션이나 Amazon Echo와 Alexa 그리고 AWS Lambda를이용한음성인식서버리스 애플리케이션이 늘어나는 것은 고무적인 현상이다. 테크크런치기사에서 언급한, Amazon Echo의 음성 인식 API인 Alexa Skills과 AWS Lambda를 이용한 앱(Skills)이 연초 135여개에서 1,000여개로 늘어났다는 것이 바로 그러한 예이다.
AWS Lambda의 이용 사례도 극적으로 늘고 있다. 여성 패션 사이트인 Bustie는 수백만의 사용자가 방문하는 웹 사이트를 Amazon S3 기반으로 만들고 필요시 동적 데이터를 Lambda로 처리한다. 광고 리타게팅 플랫폼인 AdRoll 역시 매달 300TB의 압축 데이터를 S3에 저장하는데, 호출 데이터 저장 시 Lambda를 사용한다. 실시간 동영상 인코딩 업체로 유명해진 스타트업인 Periscope는 포르노 같은 유해 영상인지 여부를 3초 단위로 파악해서 차단하는 기능에 Lambda를 이용한다.
특히, 데이터 분석 영역에서 Lambda 사용도 두드러진다. FireEye는 Lambda를 이용하여 침입 탐지 시스템을 만들었는데, 기존에 맵리듀스(MapReduce) 기능을 Lambda 함수로 바꾸고, S3에 저장하는 새로운 아이디어를 내기도 했다.국내에서도 비트패킹컴퍼니가 음악 재생 시 광고 노출 데이터를 실시간으로 처리하기 위해 Lambda를 통해 Amazon Kinesis로 보내고, 이를 S3에 저장하거나Amazon Elasticsearch Service와 Kibana를 통해 분석 대시 보드를 만드는 서버가전혀없는원스톱분석서비스를 만들어 발표하기도 했다.
향후서버리스 아키텍처를 위한 생태계에서 필요한 것은 매우 많다. 클라우드 함수에 대한 지속적인 통합 및 배포(CI/CD) 지원, IDE 플러그인, 테스트 프레임워크는 가장 필수적이다. React 같은 현대적 웹 앱 프레임워크와의 연동 및 원활한 동영상 및 파일 처리, 사물 인터넷과의 연동, 이를 엔터프라이즈급 업무에서도 활용할 수 있는 다양한 사례를 발굴하는 것 역시 중요한 과제다.
마지막으로 무엇 보다 중요한 것은 개발자들의호기심이다. 항상 성공하는 기술은 낮은 진입 장벽에서, 호기심을 가진 기술 관심자들의참여로 이루어진다. 과거 모바일앱생태계 초기를 돌아보면, 개발자가 부업으로 만든 앱들이 대박을 친 경우가 많았다. 서버리스 아키텍처도 과거 수많은 고민을 해야했던 많은 장벽을 없애 줌으로써새로운아이디어를 시작해 볼 수 있고, 성공도 예측해 볼 수 있다. 누가 아는가? 내가 만든 작은 API가 유료로도 서비스할 수 있는 대박 서비스가 될지…
기업에서도 복잡한 문제 해결에 대한 가장 단순한 해법을 찾고, 기존 레거시를 혁신하기 위해 이를 직접 만들어 보는 개발자와 기업에게 미래가 있다. 만약 이를적용 하면 회사의 기존 사업이 망할 것 같고, 나의 일이 없어지는 내부적인 파괴(Disruption)를 일으킬 것 같은 기술처럼 보이는가? 서버리스 아키텍처를 바라보는 IT개발자의 우려와 벤더의 시각도 이와 다르지 않다.그렇다면 지금 당장 시도해야 한다.“미래는 이미 가까이에 와 있다. 다만 널리 퍼지지 않았을 뿐(The future is already here-it's just not very evenly distributed.-윌리암 깁슨)”이라는 말을 다시 새겨볼 때다.
원문보기:
http://www.zdnet.co.kr/column/column_view.asp?artice_id=20160614172904#csidx8c46e4e1087c35f8e14c0b57e8295cf
