[Day 27] 해시뱅 & 클라우드 컴퓨팅 모델

thru·2023년 7월 12일
1

FEDC-TIL

목록 보기
18/21

PaaS (Peeling as a Service)
CaaS (Crushing as a Service)

오늘 공부한 내용 ☁️

오늘이라고 하기엔 좀 미뤄버렸지만 아무튼 Day 27 에서는 프론트엔드가 사용할 수 있는 배포 서비스들에 대해 알아보았다.


새로 알게된 내용 🌱

해시뱅 (#!)

SPA와 pushState를 배울 때 스쳐지나갔던 내용인데 어떤 앤지 알아나보고 싶어서 정리해보았다.

이름은 해시(#)와 뱅(!)이 합쳐진 것으로 매우 직관적이다.
자바스크립트의 성능이 급격히 증가하면서 SPA의 가능성이 대두되던 시절, 브라우저들이 SPA에 관련된 기능(대표적으로 pushState)을 대부분 지원하지 않았기 때문에 SPA를 구현하기 위해서 사용되었다.

해시뱅은 기존에 없던 새로운 기술은 아니다. 원래 html에서 url에 해시를 넣으면 새로운 페이지를 로딩하지 않고 페이지 안의 특정 요소를 가리키는 기능이 존재한다. 해당 기능을 요소를 가리키는 목적으로 사용하지 않고 url만 변경하도록 사용한 것이 해시뱅이다.

생각해보니 해시는 목차(ToC)를 구현할 때 a 태그 href 속성에서 썼었다.

해시뱅 뒤에는 나타내고 싶은 하위 url을 기입하고 자바스크립트가 렌더링될 때 하위 url을 파싱받아서 사용한다. 굳이 뒤에 뱅이 추가된 이유는 원래 해시 기능과 구분하려는 목적이었다고 한다.

과도기적인 기능이다보니 오래 유지되지는 않은 것으로 보인다. 브라우저에 따라 선택적으로 pushState를 적용해주는 pjax가 나타났다가 사라지기도 했다. 요즘은 당연히 거의 모든 브라우저가 pushState를 지원하니 더더욱 사용할 이유가 없다.

pjax가 비동기 통신의 대안이라고 소개하는 글이 2017년의 글인데 벌써 쓸모가 없어졌다는게 몽가.. 몽가..


리마인드된 내용 🔨

클라우드 컴퓨팅 모델

어느 정도까지 추상화된 모델을 제공하느냐에 따라 단계적으로 나눌 수 있다.

IaaS ⛱️ (Infrastructure as a Service)

서버자원과 네트워크, 전력 등 서비스 유지를 위한 IT 장비 모음인 인프라를 제공해주는 서비스를 말한다. 서비스 제공 업체는 하드웨어적인 요소들을 관리하고 개발자들은 클라우드의 형태로 자원에 접근해서 어플리케이션을 설치하는 등의 방식으로 사용할 수 있다. 대신 개발자들은 서버 사양이나 네트워크 종류 선택 및 트래픽 몰렸을 시의 서버 관리, 모니터링 등의 책임을 가진다. 일반적으로 24시간 서버가 가동돼서 어플리케이션을 돌리고 가동 시간만큼 비용을 지불하는 방식이다. 대표적으로 AWS EC2와 Azure Virtual Machine 등이 있다.

S3는 인프라 중에 하나인 저장소지만 동적 파일이 없어도 되는 프론트엔드 특성상 배포로 사용할 수 있는 것 같다.

개발측이 직접 하드웨어를 구축해서 운영하는 것은 on-premise라고 한다.

PaaS 🛖 (Platform as a Service)

인프라에 더해서 OS, 기타 프로그램 실행에 필요한 부분인 런타임 요소들을 제공한다. 때문에 IaaS에서 하던 복잡한 환경 설정 없이 완성된 소스만 올려도 배포할 수 있다. 선택권이 줄어든 대신 신경쓸 것도 줄어들어서 편리하다. 물론 내부에서 서버는 IaaS와 마찬가지로 24시간 돌아가기에 가동 시간만큼 비용을 지불해야하고 IaaS보다 비싸다. 대표적으로 AWS Elastic Beanstalk, Azure, Heroku 등이 있다.

FaaS 🏠(Function as a Service)

프로그램이 돌아가는 게 아니라 잘게 쪼갠 함수가 실행되는 방식이다. 실행 로직은 개발자가 직접 작성해서 넣어준다. 함수 호출이 발생하면 서버는 저장소에서 함수를 꺼내서 컨테이너나 가상머신에서 실행하고 결과를 반환한다. 사용하지 않을 때는 휴기 상태에 있다가 호출이 발생한 일정 시간만 활성화상태가 된다. 덕분에 비용이 가동 시간 기준이 아닌 사용량 기준이다. 그러나 초기 깨어나는 과정이 필요하기 때문에 IaaS나 PaaS 보단 반응 속도가 느리다. 이를 Cold Start라고 한다. 또한 함수들은 맥락에 상관없이 실행되어야 하므로 상태를 가지지 않고 퓨어하게 구현되어야해서 데이터의 공유나 로컬 스토리지 등을 사용할 수 없다. AWS Lambda Function 등이 있다.

FaaS 부터는 개발자 입장에서 서버가 겉으로 보이지 않고 관리할 권한이 없기 때문에 Serverless라고 불린다.

진짜 서버가 없단 얘기는 아니다.

BaaS 🏢(Backend as a Service)

개발자가 로직도 짜지 않는다. 데이터베이스 생성/관리 및 인증 등의 이미 만들어진 기능을 API 형태로 업체가 제공하고 개발자는 이를 사용하는 방식이다. 백엔드의 역할을 대체하기 때문에 BaaS라고 불린다. 대표적으로 Firebase가 있다.

서버리스는 1회 호출에 사용할 수 있는 메모리와 시간에 제한이 있으므로 단순한 기능에 적합하다.

적다보니 백엔드와 더 관련이 있는 것도 같은데 SSR 같은 방식을 사용하면 프론트엔드도 서버가 필요하다. 그때 이런 서비스들을 이용하는 것으로 보인다.
Vercel도 기본적으론 IaaS 혹은 PaaS의 형태로 빌드를 대신 해주는 거지만 Next.js를 이용하면 FaaS의 방식으로 작동한다고 한다.


느낀점 🎬

클라우드 컴퓨팅 내용을 적을 때 사실 프론트엔드 배포 플랫폼을 중점으로 적으려고 했던 건데 이게 백엔드인가 프론트인가 헷갈리기 시작했다. 사실 SPA처럼 저장소만 있어도 되는 것만 아니면 둘 다 서버가 필요하니 구분할 필요는 없는 걸까?


출저


profile
프론트 공부 중

0개의 댓글