Serverless Computing(서버리스 컴퓨팅)!

서버리스 컴퓨팅이란 단어를 보면 서버가 없는 컴퓨팅이란 느낌을 받으실 수 있다고 생각합니다.

왜냐하면 단어 자체가 ‘Server(서버) + Less(가 없는)’이라는 의미를 가지고 있으니까요.

하지만, 사실은 서버를 사용합니다.

일반적인 서버의 경우 하루 종일 서버가 켜져 있어야 합니다. 즉, 필요가 없을 때도 계속 서버의 자원이 할당되고 구동되어 있어야 한다는 것이죠.

이에 반해 서버리스 컴퓨팅은 서버가 필요할 때만 해당 처리에 필요한 자원을 할당받는 것입니다.

예를 들어, 편의점에서 24시간 내내 계산대에 사람이 서 있는 것이 기존 서버 사용 방식이라고 보시면 되고, 편의점에 고객이 들어와서 계산할 때만 사람을 호출해서 계산을 하게 하는 것이 서버리스라고 생각하시면 됩니다.

사실 클라우드 업계로 이직하고 이 분야에 대해 배우면서 가장 생소하면서도 재밌다고 생각했던 것이 바로 이 서버리스 컴퓨팅입니다.

이런 서버리스 컴퓨팅 기능을 주요 CSP들에서도 제공하고 있습니다.

AWS의 AWS Lambda, Azure의 Azure Functions, Google의 Cloud Functions 등이 이에 해당하죠.

그럼, 서버리스의 장점은 어떤 것이 있을까요?

서버의 관리가 필요하지 않습니다.
서두에서 언급해 드렸듯이 실제로 서버리스에도 서버가 있기는 하지만 서버를 다룰 필요는 없습니다. 필요할 때만 할당을 받아서 쓰기 때문에 말이죠. 이 서버 관리는 서버리스 기능을 제공하는 CSP에서 관리를 하게 되는 것이죠. 이를 통해 DevOps에 필요한 투자를 줄일 수 있고 서버 용량을 신경쓰지 않고 확장이 가능합니다.

필요한 만큼만 서버를 사용하기에 비용을 절감할 수 있습니다.
서버리스는 필요할 때만 실행되기에 비용을 절감할 수 있습니다. 기존 서버 아키텍처에서는 필요한 서버 용량을 미리 예측한 다음 해당 용량을 구매해야 하기에 실제 사용 여부와는 상관없이 비용이 들지만, 서버리스의 경우는 그렇지 않기에 비용의 절감이 가능해 지는 것이죠.

서버리스 아키텍처는 기본적으로 확장이 용이합니다.
사무실에서 직원의 자리를 원하는대로 추가하거나 줄일 수 있는 것을 생각해 보시면 됩니다. 서버리스로 구축되면 사용자나 사용량이 증가함에 따라 자동으로 확장됩니다. 그리고 사용하지 않으면 아예 리소스를 불러 오지 않게 되는 것이죠.

빠른 배포 및 업데이트가 가능합니다.
서버리스 기능을 사용하면 코드를 CSP 기능 내에서 직접 작업할 수도 있고 각 기능별로 바로 작업해서 적용할 수 있기에 빠른 작업이 가능합니다. 예를 들어 블로그 에디터에서 블로그 글을 수정하고 저장하면 바로 반영이 되는 것과 같은 기능을 제공합니다.

코드가 엔드 유저에게 가까운 곳에서 실행될 수 있어 지연 시간이 줄어듭니다.
코드가 특정 서버에 속하는 것이 아니라 어디에서도 실행될 수 있기 때문에 엔드 유저에게 가까운 서버에서 실행될 수 있습니다. 이를 통해서 지연 시간(레이턴시; Latency)이 줄어들 수 있습니다.

하지만, 서버리스에 장점만 있는 것이 아닙니다.

위에 말씀드린 서버리스의 장점을 보면서 바로 단점을 파악하실 분들도 있으실 것이라 생각합니다. 장점이 있으면 단점이 있는 것이죠. 그럼 어떤 단점들이 있을까요?

테스팅과 디버깅이 어려워질 수 있습니다.
코드가 배포된 후 실제로 어떻게 수행되는지 테스트하기 위한 서버리스 환경의 복제가 어렵습니다. 그리고 백엔드에 대한 가시성이 부족하고 작은 기능으로 분할되어 있기에 디버깅도 복잡해 집니다.

보안에 대한 새로운 고민이 필요합니다.
서버리스 기능을 제공하는 업체가 보안을 완전히 검증하지 못할 수 있으며, 이는 특히 개인 데이터나 민감한 데이터를 처리하는 애플리케이션의 경우 문제가 될 수 있습니다. 기능 자체가 작게 구분되어 있기에 기능 사이의 데이터 연결 시 문제가 생길 수도 있습니다.

오래 실행되는 프로세스에는 적합하지 않습니다.
서버리스는 사용되는 양에 따라 비용이 발생합니다. 그렇기에 오래 계속 실행되는 프로세스에 적용하면 오히려 기존보다 비용이 더 증가할 수 있습니다. 왜냐하면 서버리스는 필요할 때만 제공하기에 일반 리소스보다 가격이 더 높을 수 있기 때문입니다.

성능 관련 문제가 발생할 수 있습니다.
지속적으로 실행되지 않기 때문에 서버리스를 사용할 때마다 부팅을 해야 할 수 있습니다. 이 부팅 시간으로 인해 성능이 저하될 수 있는 것이죠. 물론 정기적으로 사용되는 기능의 경우는 활성화된 상태로 유지할 수도 있다고는 합니다.

특정 CSP(클라우드 공급 업체)에 종속될 수 있습니다.
일반적으로 Lock-in이라고 부르는 상황이 발생할 수 있습니다. 특정 CSP에서 모든 백엔드 서비스를 제공받으면 필연적으로 그 CSP에 대한 의존도가 높아지게 되는 것이죠. 그리고 각 CSP마다 다른 기능과 워크플로우를 제공하기에 필요한 경우 CSP의 전환이 어려울 수 있는 것입니다.

MSA(마이크로 서비스 아키텍처), Micro SaaS, 서버리스에 대해서 생각하다 보니 뭔가 유사한 점들이 많다는 생각이 들었습니다. 그리고 이런 것들의 핵심에는 빠르게 적용하고 빠르게 고객들의 반응을 보고 빠르게 개선해 나간다는 애자일의 의미가 포함되어 있는 것이 아닌가 하는 생각도 듭니다.

저희에게는 클라우드에 대한 다양한 정보와 경험, 그리고 도구가 있습니다.

 OpsNow에 문의하기