무시할 수 있는 서버리스에 대한 세 가지 일반적인 믿음

서버리스는 클라우드 세계의 떠오르는 인기 기술입니다 . 최소 3개 조직 중 1개(33%)가 지난 1년 동안 서버리스 앱을 배포했습니다. (원천: Digital Ocean 2018년 2분기 개발자 설문 조사 ) CNCF 2018 설문 조사 에 응답한 사람 중 38%가 현재 서버리스를 사용하고 있다고 답했습니다. 26%는 향후 12개월 내에 해당 기술을 사용할 계획입니다.

이 신생 클라우드 옵션은 빠르게 부상하고 있을 뿐만 아니라, 종종 오해를 받고 비용을 절감하고, 가치 실현 시간을 단축하고, 침대에서 아침 식사를 할 수 있게 해주는 거의 초자연적인 힘을 가진 것으로 여겨지기도 합니다. 

그리고 만약 이것만으로도 혼란스러울 수 있다면, Function as a Service(FaaS)와 Serverless가 혼동되는 경우도 있습니다. 둘은 같지 않으며, 이로 인해 일반적인 기업이 이 엄청난 신기술을 어떻게 활용할지에 대한 또 다른 오해가 발생합니다.

오늘은 지난 6개월 동안 고객과 컨퍼런스 참석자들로부터 반복적으로 들었던 세 가지 흔한 오해를 풀어보겠습니다. 기술이 무엇인지, 무엇이 아닌지 이해하는 것이 기술을 탐색하는 데 시간을 투자할 가치가 있는지 파악하는 데 필요합니다.

먼저, 서버리스와 FaaS의 차이점을 알아보겠습니다. 

신화: 서버리스 === FaaS

서버리스는 시스템입니다. 플랫폼. 프레임워크. 이는 적시(Just-in-Time) 방식의 탄력적 실행 환경으로 가장 잘 설명됩니다. 서버리스는 일종의 격리된 환경에서 주문형 작업을 실행하여 운영 오버헤드와 마찰을 없애려고 합니다. 이러한 격리된 환경은 일반적으로 컨테이너이지만 가상 머신과 웹 어셈블리를 사용하는 제품도 있습니다. 간결하게 하기 위해 "컨테이너"라는 단어를 세 가지 모두를 의미하는 넓은 의미로 사용하겠습니다.

서버리스는 이벤트 중심 입니다. 즉, 프로비저닝과 처리는 API 요청이 도착하거나 시계가 오후 2시 7분을 알리는 것과 같은 일종의 트리거에 의해 시작됩니다. 자동으로 생성된 이벤트이거나 웹 앱의 폼에서 버튼을 누르는 것과 같은 대화형 이벤트일 수 있습니다. 서버리스 모델에서 이벤트는 "컨테이너"에 있는 무언가 의 실행을 시작합니다 . 

"컨테이너"는 종종 요청 시 저장소에서 로드되거나(콜드 스타트) 이미 대기 중일 수도 있습니다(웜 스타트). 해당 "컨테이너"에 존재하는 무엇이든 실행되고, 실행을 트리거한 시스템에 대한 응답을 반환합니다.

서버리스의 비즈니스 모델은 일반적으로 "컨테이너"가 실행되는 동안 소비된 리소스에 대해서만 비용을 지불하는 데 기반합니다. 운영 모델은 환경 운영과 관련된 모든 것을 제거하고 사람들이 "뭔가"를 만드는 데 집중하도록 하는 것입니다.

그것이 서버리스입니다. 서비스로서의 기능은 "무언가"를 "함수"로 정의하는 서버리스의 특정 용도입니다. 

FaaS를 사용하면 마이크로서비스로 시작된 애플리케이션을 최종 결론인 함수로 분해할 수 있습니다.

서버리스와 서비스로서의 기능(FaaS)의 차이점을 아는 것은 다음의 오해를 해소하는 데 중요합니다.

신화: 리팩토링이 필요합니다 

FaaS와 Serverless가 혼동되기 때문에, 시장의 많은 사람들은 Serverless의 장점을 활용하려면 애플리케이션을 복합 기능으로 리팩토링해야 한다는 잘못된 생각을 가지고 있습니다.

서버리스에서는 애플리케이션을 리팩토링하거나 기능 수준에서 새로운 앱을 설계할 필요가 없습니다. 서버리스는 모든 종류의 애플리케이션, 프로세스, 데몬 또는 기능이 포함된 "컨테이너"를 쉽게 실행할 수 있습니다. "컨테이너"에 패키징되어 호출 가능한 한 Serverless 컨텍스트에서 실행할 수 있습니다.

저는 또한 Serverless를 활용하여 기존 애플리케이션 아키텍처를 확장(현대화)하는 성공적인 구현 사례도 보았습니다. 등록, 주문 이행 및 기타 비중요 경로 프로세스의 일괄 처리 및 대역 외 처리를 기존 애플리케이션을 완전히 리팩토링하지 않고도 서버리스 모델로 구현할 수 있습니다. 이미 이러한 목적으로 외부 API 기반 통합을 활용하는 애플리케이션의 경우 Serverless가 더 적합합니다. 기존 클라이언트-서버 기반 애플리케이션은 Serverless의 이점을 활용하기 위해 약간의 수정이 필요할 가능성이 높지만, 전체적인 리팩터링에 필요한 만큼 광범위한 작업은 아닙니다. 

가끔씩만 실행되는 프로세스(예상치 못하게 또는 산발적으로 발생하는 특정 이벤트에 따라)도 Serverless에 적합할 수 있습니다. 무언가를 실행하기 위해 주기적으로 "컨테이너"를 시작하는 것이 "컨테이너"를 항상 실행하는 것보다 훨씬 비용 효율적입니다. 이는 퍼블릭 및 온프레미스 Serverless 모두에 해당됩니다.

이제 세 번째 신화에 대해 이야기하겠습니다. 이는 위치에 초점을 맞춥니다.

신화: 서버리스는 온프레미스에 존재하지 않습니다

저는 멀리 있는 IT 종사자들과 전문가들 모두에서 이런 주장을 하는 것을 들어봤습니다. 이는 온프레미스에서 "클라우드"를 실행할 수 없다는 개념과 마찬가지로 명백히 거짓입니다. 물론입니다. Developer Economics State of the Developer Nation 에 따르면, 많은 기업이 그렇게 하고 있습니다.

더 크고 자주 사용되는 애플리케이션도 효율적인 확장의 이점을 얻을 수 있으며, 부하가 큰 애플리케이션의 특정 부분에 대해서만 추가 리소스 비용을 지불하고, 해당 부분을 더 쉽게 식별하여 최적화할 수 있습니다. 대규모 애플리케이션에 대한 이러한 이점은 현재 서버리스 컴퓨팅을 도입한 기업의 17%가 자체 데이터 센터에서 솔루션을 실행하는 주요 이유일 것입니다.

온프레미스 서버리스 구현으로 얻는 비용 효율성은 확장성 그 이상입니다. 동일한 리소스를 재사용하고 간헐적으로 사용되는 여러 애플리케이션에서 이를 공유할 수 있는 능력은 중요하지 않습니다. 서버리스는 핵심적인 이벤트 중심적 특성을 활용해 애플리케이션과 운영 기능 에 부가가치 기능을 추가할 수 있는 기능도 제공합니다. 개발자의 일상 생활에서 운영상의 마찰을 없애는 것 외에도 서버리스의 이점이 얼마나 큰지 이해하지 못한 채 온프레미스에서 서버리스를 사용하는 것을 가볍게 여겨서는 안 됩니다. 이는 분명 큰 도움이 되지만, 이것이 유일한 이점은 아니며 조직이 온프레미스에서 서버리스를 실험하는 유일한 이유도 아닙니다.  

따라서 현실적으로 Serverless는 온프레미스에서 구현될 수 있으며, 구현되고 있습니다. 앞서 언급한 CNCF 설문 조사는 가장 인기 있는 "설치 가능한" Serverless 플랫폼을 조사합니다.

• Kubeless (2%에서 42%로 증가)
• Apache OpenWhisk (12%에서 25%로 증가)
• OpenFaas (10%에서 20%로 증가)

이 기술이 발전함에 따라 더 많은 것들이 나올 것입니다.

서버리스와 Function as a Service는 모두 기업들이 새로운 클라우드 네이티브 애플리케이션과 현대화 노력에 사용하기 위해 기술을 시험하고 평가함에 따라 놀라운 도입률을 보이고 있습니다. 기술이 조직의 애플리케이션에 적합한지 여부를 결정하는 데 있어 일반적인 오해의 소지가 있는 부분을 인식하고 무시하는 것은 중요한 첫 번째 단계입니다.