[ DevOps ] - (개요) 서버리스 아키텍트 소개

서버리스 아키텍트



서버리스를 음식점에 비유해 보겠습니다. 마치 음식점에 손님이 있다고 해 봅시다. 그럼 손님의 손이 들면 그때서야 직원이 주문을 받아주게 되는, 즉 항시 대기가 아니라 필요할 때만 쓰는 것이라고 보면 됩니다.

 

서버리스는 서버가 진짜로 없는것이 아니라, 추상화 시켜서 없는 것 같이 보이는 것입니다. 항상 대기하는 전용 서버가 없어서 실행을 완료하면 자원을 반납하게 되는 구조입니다. 이에 대표적으로 AWS Lambda, Google Firebase가 있습니다. 

서버리스의 장점먼저 사려보도록 하겠습니다. 우선 기존의 EC2같은 것을 보면, 어쨋든 컴퓨팅 파워는 켜져있기 때문에, 접속이 없더라도 과금이 발생하게 됩니다. 하지만 서버리스는 말 그대로 함수가 실행될 때만 서버가 있는 듯한 느낌을 주는 것이라고 했습니다. 서버는 사용된 다음에 바로 없어지니까 과금 측면에서도 좋습니다. 또한 급격한 트래픽 변화에 유연합니다. 

 

또한 단점으로는 다른 클라우드 컴퓨팅 자원보다 비쌉니다. 다른 서비스에 따른 시간에 따른 과금 요금이 비싸다는 것입니다. 만약에 1초에 1번 호출되는 함수를 서버리스 서비스에 올려놨다고 하면, 당연히 이는 EC2로 만드는 것이 좋다고 볼 수 있겠습니다. 또한 이는 느립니다. 서버가 다 셋팅되고 해야하기 때문에, 느리게 됩니다. 또한 장기적인 작업에는 적합하지 않다는 단점이 있습니다. 크롤러가 있다고 봅시다. 크롤러는 오랬동안 돌아가게 됩니다. 그럼 그 시간만큼 비싸게 과금이 된다는 것입니다. 따라서 서버리스 본연의 목적이 사라지게 됩니다. 마지막으로 함수의 처리 결과에 따라 상태를 따로 저장해야 합니다. 람다를 사용하게 되면, 모든 API들이 따러 놀게 됩니다. 모든 함수들이 따로 놉니다. 나중에 Elastic File System을 쓰게되면 모든 결과를 데이터베이스에 저장할 수는 있습니다. 따라서 유기적으로 돌아가야 하는 시스템이서는 적합하지 않다고 할 수 있게 됩니다.

 

즉 간헐적으로 어떤 트리거가 되는 애플리케이션에 적합하다고 볼 수 있습니다. 

 

서버리스의 두가지 형태

이 둘간의 차이점은 얼마나 커스터 마이징이 가능 하냐에 따른 차이 입니다. 만약에 채팅 서비스를 구현하고 싶다고 해 봅시다. Google Firebase는 통합적으로 이를 도와줍니다. 따라서 이런 통합적인 기능들을 제공하니까, 빨리 개발하고 싶은 스타트업의 입장에서는 매우 편리하지만 커스터 마이징이 불편하다는 단점이 있는 것입니다. 어떠한 백엔드 서비스가 구현되어 있는것을 우리가 사용하는 것인데, 이를 위해서는 커스터 마이징이 어렵다는 단점을 건뎌내야 한다라고 생각하면 될 것 같습니다.

 

대신 FaaS는 함수 하나하나를 서버리스 형태로 짜는 것입니다. 기능을 함수 하나로 계속 만들고, 함수가 실행 될 때마다 만약에 로그인을 하는 함수를 만들었는데, 로그인을 할 때마다 서버를 만들어서 실행하는 것이라고 보면 되겠습니다. 그리고 로직같은 것을 우리가 맘대로 작성할 수 있개 때문에 BaaS와는 다르게 커스터 마이징이 쉽다는 장점이 있습니다.

 

즉 BaaS는 스타트업에서 빠르게 개발할 때 사용하고, FaaS는 구체화 할 때 많이 사용됩니다.