서버리스: 무엇이고 왜 다른가

서버리스 컴퓨팅이란 무엇입니까?

개발자 커뮤니티에서 서버리스에 대한 최근 과대 광고를 모두 보았을 것입니다. 그래서 정확히 무엇입니까? 내 말은 코드가 여전히 어딘가에서 제대로 실행되어야 하므로 실제로 어떻게 서버리스입니까?

이것이 의미하는 것은 개발자와 운영 팀이 실제 서버를 감독, 관리 또는 신경 쓸 필요가 없다는 것입니다. 이는 클라우드 컴퓨팅과 매우 유사하게 들릴 수 있지만 몇 가지 주요 차이점이 있습니다. 그리고 이러한 차이점은 주로 다른 모델과 비교하여 모르는 부분에 있습니다.

알 수 없는 운영 체제!?!?

Kubernetes와 같은 일부 형태의 멋진 클라우드 오케스트레이션과 서버리스를 구별하는 쉬운 방법 중 하나는 코드를 실행하는 서버가 어떤 운영 체제를 사용하고 있는지 회사의 아무도 모른다는 것입니다. 일부 .Net 코드를 실행하고 있기 때문에 Windows라고 믿거나 Ruby이기 때문에 Linux에 있다고 믿을 수 있지만 결국에는 확실하지 않으며 개발에 영향을 미치지 않습니다.

서버리스 공급자가 지원하는 언어를 사용하여 코드를 작성할 수 있으며 그들이 제공하는 상자의 범위 내에 머무르는 한 어떤 운영 체제, 버전 등에 대한 지식이 없어도 괜찮습니다.

그리고 사실, 서버리스의 장점 중 하나는 주어진 시간에 애플리케이션이 여러 운영 체제에서 실행될 수 있다는 것입니다. 이 모든 것은 귀하를 위해 귀하의 제공자가 관리하고 운영합니다.

트래픽을 처리하려면 몇 대의 서버가 필요합니까?

이 질문에 X 서버에 대한 추측으로 답할 수 있거나 Y CPU가 필요하다면 서버리스 개발을 하고 있지 않은 것입니다.

서버리스 계약은 애플리케이션을 구동하는 데 필요한 컴퓨팅의 수와 강도가 개발자에게 아무런 문제가 되지 않는다는 것을 의미합니다. 비용이 청구되지 않는다는 의미가 아니라 귀하 또는 귀하의 팀이 관리하거나 관심을 가질 대상이 아니라는 것입니다. 우수한 공급자는 서비스가 고가용성과 응답성을 유지하도록 자동으로 서비스를 관리합니다.

컴퓨팅, 스토리지 및 네트워크를 기반으로 하는 청구 모델입니다. 서버, CPU 및 하드 드라이브 아님

애플리케이션 아래에서 실행되는 실제 하드웨어가 무엇인지 알지 못하기 때문에 청구하는 새로운 방법이 함께 제공됩니다. 서버리스 클라우드 플랫폼 제공업체는 계산, 스토리지 및 네트워크 전송의 측정된 사용량에 대해 청구합니다. 이것은 CPU, 디스크 드라이브 및 네트워크 연결에 따라 청구되는 다른 청구 모델을 대체합니다. 서버리스 세계에서 그들은 해당 부분을 제어하고 앱에 대한 정확한 사용량에 대해서만 비용이 청구됩니다.

이것은 컴퓨팅을 전기 모델에 훨씬 더 가깝게 만듭니다. 전력 회사는 측정된 전기 사용량인 KWH로 요금을 청구합니다. 전력 자체는 석탄, 원자력, 가스 등으로 만들어집니다. 그러나 청구는 출처에 관계없이 동일하게 측정됩니다.

0에서 유휴 상태

서버리스의 또 다른 주요 변경 사항은 앱이 사용되지 않을 때 자동으로 0으로 조정된다는 것입니다. CPU로 청구되지 않고 계산을 사용하여 청구되므로 사용하지 않을 때 청구서는 0입니다.

공급자는 항상 필요에 따라 계산을 측정할 준비가 되어 있지만 서버가 사용될 때 대비할 수 있도록 비용을 지불할 필요는 없습니다. 그것은 단순히 앱이 실행될 때 실제로 소비되는 계산의 초에 대해 지불하는 계산입니다.

약간 편의점이라고 생각하시면 됩니다. 가게에 우유를 비축해 두어 고객이 목이 마르면 바로 들러서 마실 우유를 사서 마신 후 떠날 수 있도록 하는 것이 그들의 일입니다. 우유가 필요하기 전에 미리 비용을 지불하지 않으며, 아무도 사지 않았기 때문에 상한 우유가 있는 경우에도 비용을 지불하지 않습니다. 식료품점의 업무는 상한 우유를 과도하게 비축하거나 낭비하지 않도록 주의하면서 사용 가능한 재고가 있는지 확인하는 것입니다. 당신이 알고 있는 것은 그들이 당신이 원할 때 당신이 원하는 것을 가지고 있다는 것이고, 나머지는 당신의 관심사에서 단순화된다는 것입니다.

서버리스를 위한 절충안

이 모든 단순화가 꽤 좋게 들립니다. 더 간단한 청구, 더 적은 운영 책임, 손쉬운 확장과 같은 모든 것을 원하는 사람이 왜 없을까요? 모든 일과 마찬가지로 여기에는 약간의 절충점이 있습니다. 이제 그들에 대해 이야기합시다.

운영 체제 잠금을 클라우드 공급자 잠금으로 대체

다른 모델에서는 코드가 실행되는 운영 체제나 서버로 인해 다양한 절충점과 제한 사항이 있었습니다. 이제 서버리스 프레임워크가 이 책임을 공급자에게 전가하므로 사용자가 따라야 하는 새로운 제약 조건이 있습니다.

현재로서는 서비스 제공자 간의 제약 및 보장을 정의하는 합의된 표준 세트가 없습니다. 이는 예를 들어 Windows에서 Linux로 애플리케이션을 이동하는 것이 과거에 얼마나 어려웠는지와 유사하다는 것을 의미합니다. 이제 서버리스 앱을 Google 클라우드에서 Amazon으로 이동하려고 할 때 이러한 문제에 직면하게 될 것입니다.

이러한 회사는 고객이 서버리스 워크로드를 쉽게 이동할 수 있는 공통 프레임워크를 아직 제공하지 않습니다. 그리고 솔직히 말해서, 그들이 가능한 한 많이 당신을 그들의 제안에 가두는 것을 선호하기 때문에 지금 당장 그렇게 하는 것이 그들의 최선의 이익이 아닙니다. 따라서 초기 서버리스 제품에는 많은 독점 문제가 있어 해당 제품에서 벗어나기 어렵게 만든다는 점을 잘 알고 있어야 합니다.

성능 및 비용에 대한 가시성 저하

코드 성능에 대해 자세히 알아보기 위한 도구는 이전 프로그래밍 모델에 대해 매우 잘 정립되어 있습니다. 주어진 프로그램이 얼마나 많은 CPU 또는 RAM을 사용하고 있는지 알아내는 것과 같은 일은 모두 일상적입니다.

서버리스 모델을 사용하면 코드에서 사용하는 계산, 네트워크 및 API 호출의 양에 따라 최적화가 변경됩니다. 공정하게 말하면 이들은 과거의 CPU 및 RAM과 관련이 있습니다. 그러나 그것들이 더 멀리 추상화되면 이러한 도구가 유용하지 않게 방해될 것입니다.

디버깅 및 성능 최적화를 위한 새로운 오픈 소스 도구가 이 시장에 서비스를 제공할 것으로 전적으로 믿습니다. 그러나 공급자가 서버리스 아키텍처를 구현하는 방법에 대한 더 나은 이해가 필요합니다. 이는 클라우드 공급업체만이 이러한 도구를 효과적으로 만들기에 충분한 깊이 있는 시각을 제공할 수 있다는 것을 의미할 수 있습니다. 리소스를 효율적으로 사용했는지 여부에 관계없이 해당 리소스에 대해 비용을 청구하기 때문에 더 적은 리소스를 사용하는 데 도움이 되는 것은 그들의 이익이 아닙니다.

장기 실행 애플리케이션은 스위트 스팟이 아닙니다.

서버리스가 제공하는 모든 유연성을 얻기 위해 일반적으로 애플리케이션 개발자를 서비스로서의 이러한 기능에 대한 시간 기반 제한으로 제한합니다. 즉, 응답하는 데 최대 1분이 걸리는 웹 요청에 코드가 응답할 수 있도록 최적화됩니다.

이러한 고정 시간 최대값은 공급자가 서버리스 약속을 이행할 수 있도록 지원합니다. 그들은 개발 팀에 장비 오류를 자동으로 확장하고 복구하는 서비스를 제공하기 위해 필요에 따라 실제 물리적 CPU와 위치 간에 워크로드를 이동할 수 있기를 기대합니다. 장기 실행 워크로드는 이러한 가정을 깨뜨립니다. 실제로 이것은 일반적으로 제품의 요구 사항 중 하나로 나열됩니다. 여기서 코드는 X 시간 내에 완료되거나 종료되어야 합니다.

웹 요청 또는 모바일 애플리케이션 API와 같은 경우 이러한 제한은 큰 문제가 아닙니다. 그러나 비디오 인코딩, 실시간 게임 서버 운영 또는 화상 회의 솔루션과 같은 다른 사용 사례에서는 이러한 제한이 실현 가능하지 않습니다. 대부분의 경우 서버리스 리소스를 창의적으로 사용하여 이러한 제한을 우회할 수 있지만 일반적으로 비용이 더 많이 들고 훨씬 느리게 작동하는 솔루션을 구사하고 있습니다. 클라우드 공급자는 사용량이 많을수록 비용이 더 많이 들기 때문에 이 작업을 수행하는 데 기꺼이 도움을 줄 것입니다. 따라서 가장 적합한 웹 애플리케이션 및 시스템에 대해 서버리스를 사용해야 합니다.