요점

• 몇 년 동안 우리는 서버리스 컴퓨팅(serverless)이 애플리케이션을 실행하는 특정 OS 없이 새로운 시대를 열 것이라고 약속했습니다. 우리는 그러한 구조가 많은 확장성 문제를 해결할 것이라고 들었습니다. 사실 모든 것이 다릅니다.
• 많은 사람들이 서버리스 기술을 새로운 아이디어로 보고 있지만 그 뿌리는 서버리스 아키텍처를 사용하는 Zimki PaaS와 Google App Engine으로 2006년으로 거슬러 올라갑니다.
• 제한된 프로그래밍 언어 지원에서 성능 문제에 이르기까지 서버리스 혁명이 정체된 이유는 네 가지입니다.
• 서버리스 컴퓨팅은 그다지 쓸모가 없습니다. 그것과는 거리가 멀다. 그러나 서버를 직접 대체하는 것으로 보아서는 안 됩니다. 일부 응용 프로그램의 경우 편리한 도구가 될 수 있습니다.

서버가 죽었습니다, 서버 만세!

이것은 서버리스 혁명 지지자들의 외침입니다. 지난 몇 년간 업계 언론을 훑어보는 것만으로도 전통적인 서버 모델이 죽었고 몇 년 안에 우리 모두가 서버리스 아키텍처를 사용하게 될 것이라는 결론을 내리기에 충분합니다.

업계의 모든 사람이 알고 있고 우리가 기사에서 지적했듯이 서버리스 컴퓨팅의 상태, 이것은 잘못된 것입니다. 장점에 대한 많은 기사에도 불구하고 서버리스 혁명, 그것은 결코 일어나지 않았습니다. 사실은, 최근 연구에 따르면이 혁명이 막다른 골목에 이르렀을지도 모른다는 것.

서버리스 모델에 대한 약속 중 일부는 확실히 실현되었지만 전부는 아닙니다. 모두는 아니다.

이 기사에서 나는 이 상태에 대한 이유를 고려하고 싶습니다. 서버리스 모델의 유연성 부족이 특정하고 잘 정의된 환경에서는 여전히 유용하지만 더 폭넓은 채택에 걸림돌이 되는 이유는 무엇입니까?

서버리스 컴퓨팅 전문가들이 약속한 것

서버리스 컴퓨팅의 문제로 이동하기 전에 서버리스 컴퓨팅이 무엇을 제공해야 하는지 살펴보겠습니다. 서버리스 혁명의 약속 수가 많았고 때로는 매우 야심적이었습니다.

용어에 익숙하지 않은 분들을 위해 간략한 정의가 있습니다. 서버리스 컴퓨팅은 애플리케이션(또는 애플리케이션의 일부)이 일반적으로 원격으로 호스팅되는 런타임 환경에서 요청 시 실행되는 아키텍처를 정의합니다. 또한 서버리스 시스템을 호스팅할 수 있습니다. 강력한 서버리스 시스템을 구축하는 것은 지난 몇 년 동안 시스템 관리자와 SaaS 회사의 주요 관심사였습니다. 이 아키텍처는 "전통적인" 클라이언트/서버 모델에 비해 몇 가지 주요 이점을 제공하기 때문입니다.

1. 서버리스 모델은 사용자가 자신의 운영 체제를 유지 관리하거나 특정 운영 체제와 호환되는 애플리케이션을 구축할 필요가 없습니다. 대신 개발자는 공유 코드를 만들어 서버리스 플랫폼에 업로드하고 실행을 지켜봅니다.
2. 서버리스 프레임워크의 리소스는 일반적으로 분(또는 초) 단위로 청구됩니다. 즉, 클라이언트는 실제로 코드를 실행한 시간에 대해서만 비용을 지불합니다. 이것은 기계가 대부분의 시간 동안 유휴 상태이지만 비용을 지불해야 하는 기존 클라우드 VM과 유리하게 비교됩니다.
3. 확장성 문제도 해결되었습니다. 서버리스 프레임워크의 리소스는 시스템이 갑작스러운 수요 급증에 쉽게 대처할 수 있도록 동적으로 할당됩니다.

즉, 서버리스 모델은 유연하고 저렴하며 확장 가능한 솔루션을 제공합니다. 나는 우리가 이 아이디어를 더 일찍 생각하지 않았다는 것에 놀랐습니다.

정말 새로운 아이디어인가요?

사실 아이디어는 새로운 것이 아닙니다. 사용자가 코드가 실제로 실행되는 시간에 대해서만 비용을 지불하도록 허용하는 개념은 짐키 PaaS 2006년과 거의 같은 시기에 Google App Engine은 매우 유사한 솔루션을 내놓았습니다.

실제로 현재 "서버리스" 모델이라고 부르는 것은 거의 동일한 기능을 제공하는 현재 "클라우드 네이티브"라고 하는 많은 기술보다 오래되었습니다. 언급했듯이 서버리스 모델은 본질적으로 수십 년 동안 존재해 온 SaaS 비즈니스 모델의 확장일 뿐입니다.

또한 서버리스 모델이 FaaS 아키텍처가 아니라는 점을 인식할 가치가 있습니다. 비록 둘 사이에 연결이 있지만 말입니다. FaaS는 본질적으로 서버리스 아키텍처의 컴퓨팅 중심 부분이지만 전체 시스템을 나타내지는 않습니다.

왜 이 모든 과대 광고? 개발도상국의 인터넷 보급률이 계속해서 치솟고 있기 때문에 컴퓨팅 리소스에 대한 수요도 급증하고 있습니다. 예를 들어, 전자 상거래 부문이 빠르게 성장하고 있는 많은 국가에는 이러한 플랫폼의 애플리케이션을 위한 컴퓨팅 인프라가 없습니다. 유료 서버리스 플랫폼이 등장하는 곳입니다.

서버리스 모델의 문제

문제는 서버리스 모델에 문제가 있다는 것입니다. 오해하지 마십시오. 나는 그들이 그 자체로 나쁘다거나 어떤 상황에서 일부 회사에 상당한 가치를 제공하지 않는다고 말하는 것이 아닙니다. 그러나 서버리스 아키텍처가 기존 아키텍처를 빠르게 대체할 것이라는 "혁명"의 주요 주장은 결코 실현되지 않습니다.

그 이유입니다.

프로그래밍 언어에 대한 제한된 지원

대부분의 서버리스 플랫폼은 특정 언어로 작성된 애플리케이션만 실행하도록 허용합니다. 이는 이러한 시스템의 유연성과 적응성을 심각하게 제한합니다.

서버리스 플랫폼은 대부분의 주요 언어를 지원하는 것으로 간주됩니다. AWS Lambda 및 Azure Functions는 또한 지원되지 않는 언어로 애플리케이션 및 기능을 실행하기 위한 래퍼를 제공하지만 종종 성능 비용이 발생합니다. 따라서 대부분의 조직에서 이 제한은 일반적으로 큰 문제가 아닙니다. 하지만 여기에 문제가 있습니다. 서버리스 모델의 이점 중 하나는 모호하고 자주 사용되지 않는 프로그램을 실행한 시간에 대해서만 비용을 지불하기 때문에 더 저렴하게 사용할 수 있다는 것입니다. 모호하고 거의 사용되지 않는 프로그램은 종종 모호하고 거의 사용되지 않는 프로그래밍 언어로 작성됩니다.

이것은 서버리스 모델의 주요 이점 중 하나를 약화시킵니다.

벤더에 바인딩

서버리스 플랫폼 또는 적어도 현재 구현되는 방식의 두 번째 문제는 일반적으로 운영 수준에서 비슷해 보이지 않는다는 것입니다. 작성 기능, 배포 및 관리 측면에서 표준화가 거의 없습니다. 즉, 한 플랫폼에서 다른 플랫폼으로 기능을 마이그레이션하는 데 시간이 많이 걸립니다.

서버리스 모델로 전환할 때 가장 어려운 부분은 일반적으로 코드 조각에 불과한 컴퓨팅 기능이 아니라 애플리케이션이 객체 스토리지, ID 관리 및 대기열과 같은 연결된 시스템과 통신하는 방법입니다. 기능은 이동할 수 있지만 애플리케이션의 나머지 부분은 이동할 수 없습니다. 이것은 약속된 저렴하고 유연한 플랫폼의 정반대입니다.

일부에서는 서버리스 모델이 새롭고 작동 방식을 표준화할 시간이 없다고 주장합니다. 그러나 위에서 언급했듯이 그것들은 그렇게 새로운 것이 아니며 컨테이너와 같은 다른 많은 클라우드 기술은 좋은 표준의 개발과 광범위한 채택으로 인해 이미 훨씬 더 편리해졌습니다.

Производительность

서버리스 플랫폼의 컴퓨팅 성능은 부분적으로 공급업체가 정보를 비밀로 유지하는 경향이 있기 때문에 측정하기 어렵습니다. 대부분의 사람들은 원격 서버리스 플랫폼의 기능이 내부 서버에서와 마찬가지로 빠르게 실행되며 몇 가지 피할 수 없는 대기 시간 문제를 제외한다고 주장합니다.

그러나 일부 증거는 그렇지 않음을 시사합니다. 이전에 특정 플랫폼에서 실행되지 않았거나 한동안 실행되지 않은 기능은 초기화하는 데 시간이 걸립니다. 벤치마크와 마찬가지로 대부분의 벤더가 데이터 포팅에 대해 알려주지 않더라도 코드가 쉽게 사용할 수 없는 저장 매체로 포팅되었기 때문일 수 있습니다.

물론 이 문제를 해결하는 방법에는 여러 가지가 있습니다. 하나는 서버리스 플랫폼이 실행되는 모든 클라우드 언어에 대해 기능을 최적화하는 것이지만, 이는 이러한 플랫폼이 "민첩"하다는 주장을 다소 약화시킵니다.

또 다른 접근 방식은 성능에 중요한 프로그램을 정기적으로 실행하여 "최신" 상태로 유지하는 것입니다. 물론 이 두 번째 접근 방식은 프로그램 실행 시간에 대해서만 비용을 지불하기 때문에 서버리스 플랫폼이 더 비용 효율적이라는 주장에 약간 반박합니다. 클라우드 제공업체는 콜드 스타트를 줄이기 위한 새로운 방법을 도입했지만, 이들 중 다수는 FaaS의 원래 가치를 훼손하는 "스케일 투 원(scale to one)"을 요구합니다.

콜드 스타트 ​​문제는 서버리스 시스템을 사내에서 실행하여 부분적으로 해결할 수 있지만 자체 비용이 발생하며 자원이 풍부한 팀을 위한 틈새 옵션으로 남아 있습니다.

전체 애플리케이션을 실행할 수 없습니다.

마지막으로 서버리스 아키텍처가 기존 모델을 곧 대체하지 못하는 가장 중요한 이유는 일반적으로 전체 애플리케이션을 실행할 수 없기 때문입니다.

더 정확하게는 비용 측면에서 비실용적입니다. 성공적인 모놀리스를 XNUMX개의 게이트웨이, XNUMX개의 대기열 및 XNUMX개의 데이터베이스 인스턴스로 함께 묶인 XNUMX개의 기능 세트로 전환해서는 안 됩니다. 이러한 이유로 서버리스는 새로운 개발에 더 적합합니다. 사실상 기존 애플리케이션(아키텍처)을 포팅할 수 없습니다. 마이그레이션할 수 있지만 처음부터 시작해야 합니다.

즉, 대부분의 경우 서버리스 플랫폼은 컴퓨팅 집약적인 작업을 수행하기 위해 백엔드 서버를 보완하는 수단으로 사용됩니다. 이것은 원격 컴퓨팅을 수행하는 전체적인 방법을 제공하는 다른 두 가지 형태의 클라우드 컴퓨팅인 컨테이너 및 가상 머신과 매우 다릅니다. 이는 마이크로서비스에서 서버리스 시스템으로 마이그레이션할 때의 과제 중 하나를 보여줍니다.

물론 이것이 항상 문제가 되는 것은 아닙니다. 자체 하드웨어를 구입하지 않고도 거대한 컴퓨팅 리소스를 주기적으로 사용할 수 있는 기능은 많은 조직에 실질적이고 지속적인 이점을 가져올 수 있습니다. 그러나 일부 애플리케이션이 내부 서버에 있고 다른 애플리케이션이 서버리스 클라우드 아키텍처에 있는 경우 관리가 새로운 수준의 복잡성에 들어갑니다.

혁명 만세?

이러한 모든 불만에도 불구하고 저는 서버리스 솔루션 자체에 반대하지 않습니다. 솔직히. 개발자는 특히 처음으로 서버리스 모델을 탐색하는 경우 이 기술이 서버를 직접 대체할 수 없다는 점을 이해해야 합니다. 대신에 대한 팁과 리소스를 확인하십시오. 서버리스 애플리케이션 구축 이 모델을 적용하는 최선의 방법을 결정합니다.

출처 : habr.com