서버리스 아키텍처가 뭐예요?

 서버리스 아키텍처가 뭐예요?

-

가끔씩 이슈가 되어 올라오는 IT NeWs를 보는 것을 좋아하는 나는

최근 들어 회사 블로그를 관리하면서 자연스럽게 iT nEwS를 보는 시간이 늘어났습니다.

그렇게 짬시간 있을 때마다 뭔가 새롭고 재미있는 소식이 없을까 확인하다가

관심을 가지게 된 기술이 있는데 ..!! ^^

​

바로 '서버리스 아키텍처'입니다.

​

단순하게 생각하면 서버시스템이 있는데 서버는 없다는 내용인데

정말 뭘까 하는 궁금함이 생기게 되었습니다.

​

그렇게 해서 이런저런 자료를 찾아보게 되었고

이 기술이 출발한 지는 몇 년 되었는데 최근 들어 iT인들이 관심을 보이게 된 것이죠!

제가 그랬던 것처럼 ^^

​

서버리스 아키텍처에 대해서 검색을 해보면

정말 많이 나오는 내용이 바로 아마존에서 제공하는 서비스에 대한 소식과 기술에 대한 이야기입니다.

(아마존이 아마 클라우드 서비스는 최고이지 않을까..? 맞지?)

​

서버리스 아키텍처를 쉽게 설명하면 이렇습니다.

은행은 예금, 적금, 대출, 환전 등 여러 가지 업무를 담당하는 직원이 있고

우리가 은행에 들어가서 내가 원하는 업무를 요청하면

그때마다 은행 직원이 대응을 하는 것이라고 보면 됩니다.

​

이렇게 무언가 필요한 고객이 요청할 때마다 대응을 하는 것으로

서비스를 제공하기 위해서 서버와 서버를 관리하는 시스템 또한 구비하고

서비스를 개발하는 것까지 모두를 다 하는 것이 아닌

필요시에만 딱 서비스를 개발하는 것으로

어플리케이션을 제공하는 고객의 입장에서는 인프라에 대한 비용을 투자하지 않아도 되는 큰 장점이 있습니다.

​

서버리스의 구현 방식은?

-

주로 FaaS(Function as a Service)와 BaaS(Backend as a Service)를 많이 이야기합니다.

​

FaaS는 제공하려는 기능을 하나의 함수로 만들어 놓고 실행할 때마다 서버의 자원을 할당받아 사용하는데

개발자가 기능에 대해서 전체를 개발한다는 것에서 BaaS보다 기능을 구현하는데 좀 더 자유롭습니다.

대표적으로 AWS Lambda, Google Function 등이 있죠.

​

이에 비해 BaaS는 서버리ㅣ스 아키텍처 공급자가 제공하는 서비스를 활용하여 구현하는 것으로

주로 인증, 구현이 정형화된 기능(회원관리, 재고관리 등), 데이터 저장 관리 같은 곳에 많이 사용됩니다.

따라서, 개발자가 기능을 구현하는데 FaaS보다 간단하죠.

대표적으로 Google Firebase 등이 있습니다.

​

서버리스의 장점?

-

개발 업무를 하다 보면 내부적인 요인 및 고객들의 요청 등 외부적인 요인으로 인해서

많은 기능을 빠르게 만들고 테스트를 반복해야 하는 경우가 종종 발생합니다.

특히 기업의 연구소처럼 많은 아이디어를 바로바로 구현해서 파일럿 어플리케이션을 만들어야 하는 경우라면

충분히 활용해볼 수 있습니다.

이렇게 시대의 흐름에 맞게 빠르게 개발하고 고객의 반응을 확인할 수 있다면

회사의 경쟁력도 올릴 수 있지 않을까 하는 생각이 드네요 ^^.

​

정리하면, 다음과 같은 장점이 있습니다.

​

1. 개발 시간을 줄이 수 있어 개발 결과물의 출시를 단축할 수 있다.

2. 함수 단위로 개발을 하기에 요구 사항에 민감하게 대응하여 서비스 관리에 효율적이다.

3. 자주 다른 시스템과 연계하는 기능 개발 시 제공하는 것을 기반으로 개발이 가능하다.

​

서버리스의 단점?

-

그럼 서버리스는 좋은 점만 있을까요?

그렇지 않습니다.

모든 솔루션, 시스템, 서비스가 그렇듯 맞지 않는 분야나 개발에 오히려 독이 되는 경우도 있기에

자신들이 제공하려고 하는 서비스에 적합한 부분을 잘 도출해서 사용해야 합니다.

​

예를 들어 구현한 기능이 너무 자주 요청하는 경우인데 FaaS로 개발이 되었다면

FaaS는 위에 설명한 것처럼 만들어 놓은 함수를 필요 시마다 서버 리소스를 할당하여 사용하는 것인데

빠르게 많은 요청이 들어올 때마다 서버 리소스를 할당한다는 점에서 느리기에 맞지 않습니다.

​

또한, 서버리스는 말 그대로 제공하는 기능을 가지고 있는 전용 서버가 없기 때문에

기능을 사용하고 나면 서버 자원을 반납해야 합니다.

즉, 처리된 결과 및 내용을 매번 저장하는 작업이 별도로 필요합니다.

​

1. 처리시간이 긴 작업은 그만큼 리소스를 오래 사용하기에 적합하지 않다.

2. 요청된 이벤트에 따라 함수를 기동하기 위한 시간이 필요하다.

3. 함수 처리 결과를 저장해야 한다.

​

서버리스에 대해서 정리해 볼까?

-

서버리스 아키텍처를 잘 활용하면

새로운 서비스를 만든다든지, 아니면 유지 보수를 좀 더 편하게 할 수 있다는 것에서

활용가치는 있어 보입니다.

더구나 초기 투자를 확실히 줄일 수 있어 비용적으로도 많은 이점이 있습니다.

​

따라서, 개발하려는 우리의 서비스가 서버리스와 맞는지?

어떤 기능을 서버리스 방식으로 변경하면 좋을지?

​

당연하겠지만 많은 검토를 통해서 고민해야 합니다.

​

2020년 아마존에서 서버리스 아키텍처 패턴 및 모범사례에 대한 영상이 있어 소개합니다.

​

기술 개발은 시대의 흐름에 민감하게

대응하는 조직만이 살아남을 수 있다.

- 블로그지기 생각 中

​