Serverless
March 02, 2021
Serverless
예~전에 gh-pages를 처음 접해보고, BackEnd를 운용히지 않는 웹사이트를 보며 아.. 이것이 Serverless! 라고 생각했었다.
솔직히 내잘못은 아니잖아.. Serverless라며..
ServerLess를 좀 풀어서 설명해주신 분이 있다.
Backend without Server Management- 서버 관리가 필요 없는 백엔드.
정말 잘생기신 분인데 나의 미숙한 캡쳐능력때문에 누가 될까봐 가려드렸음.
올려주신 영상의 초반부를 분석해보았다.
앱 배포의 변화
나의 서버
이전에는 자신이 혹은 기업이 개발안 앱을 배포하기위해선 개인 서버를 갖고있어야했다고 한다. 영상에 나오는것처럼 좀 물질적인? 공간을 차지하는 서버.
개인적으로 저런 기계 군대 전산실에서 본거같은데.. 어쨌든
이럴 경우, 서버가 다운되거나 콘센트가 뽑히면 앱의 서버가 닫히고 접속자 수가 늘어나면 직접 메모리를 사왔어야 했다고 한다.
AWS EC2등 대신해주는 서버 등장
AWS에서 EC2라는것이 나오게 되면서 위처럼 실제 공간을 차지하는 서버는 필요가 없게되었다.
일정 금액을 지불하면, 상시 서버가 켜져있고 사용자 수가 증가하면 알아서 메모리를 추가해주는 기능을 대신 해주고있음. 여전히
실제로 이전에
EC2로 배포를 해보면서, 특정 키를 통해AWS에 개설된 나의 서버로 들어가node.js설정 등등을 하여 배포를 했던 기억이 있음.
이처럼 EC2는 나의 앱에있어서 지속성이나 수용성?을 대신해주는 역할을 해주게 됨.
다만, 그런점들은 대신해주지만 여전히 해당 서버는 텅텅 비어있는 상태이다.
앱 기능에 필요한
node.js와 같은 것들은 다시 설정해야하고,nginx로 여러 포트로 들어오는것을 하나의 경로로 바꿔주는 등의 작업이 필요하다보니 업데이트 또한 수동으로 해줬어야 했다.
Serverless의 등장
다른 게시물에서 재미있는 예시를 발견했다.
1+2 프로그램 만들기
사실상 우리는 1+2 프로그램을 만들려고 한다.
클라이언트단에서 1과 2의 값이 서버로 넘어오면 3이라는 값을 넘겨주면된다.
물론.. 클라이언트단에서 다 해결가능하지만 그게중요한건 아니니깐
그렇다면 우리는 이런 단순한 로직 뿐만 아니라
CPU는 어떤 제품 써야 하지? AMD, Intel? RAM이나 HDD/SDD 는 어느 정도 할당해야 할까? 연결은 어떻게? 운영체제는? 윈도우? 리눅스? OSX? 어떤 언어로 작성해야 하지? 어떻게 실행시키지? 매번 터미널로 입력받아야 하나? 로컬에서 서버 돌려서 받나? 그럼 웹 서버는? 보안은 어떻게 해야하나?
이러한 고민도 함께 해야한다.
생각해보면
EC2만으로 위의 몇가지 문제는 해결이 가능할 듯 함.
위의 역할들을 대신해주는것이 ServerLess이다.
처음 노마드코더님이 말씀하신것처럼 BackEnd의 ManageMent - 관리가 필요없는 것.
ServerLess는 BasS와 FaaS로 나뉘어진다고 한다.
BaaS - Backend as a Service
DB와 같은 서버작업이 필요없을 경우, 굳이 서버를 만들 필요가 없다. 다만 그렇지 않은 경우 백엔드 개발은 필수적이다.
백엔드 서버를 사용하다보면 보안이나 확장에 대해 고려할 수밖에 없는데 이를 대신해주는것이 BaaS라고 한다.
대표적으로
Firebase
다만, 간단한 서버라면 문제 없지만 복잡한 DB로직은 수행할 수 없고 클라이언트 위주의 코드를 할 수밖에 없어 추천하는것 같지는 않다.
FaaS - Function as a Service
EC2처럼 BackEnd를 서버에 올려서 보안 등 수동으로 업데이트 하며 관리하는 것이 아닌 Function단위로 쪼개서 서버에 올리는 것이다
대표적으로
AWS Lambda.Vercel또한AWS Lambda로 만들어 졌다고 함. 오호..
서버에서만 수행되어야 하는 로직들을 AWS Lambda에 작성하여 사용하는 방식이다.
따라서 앱의 접속 요청을 받는것 때문에, 대부분
S3와 같이 쓰인다고 함. 실제로 둘이 연동도 가능하다고 함!
AWS Lambda의 경우 콘텐츠는 S3에서 호스팅, 콘텐츠의 요청에 대한 서버의 작업은 Lambda에서 수행, DB는 DynamoDB사용 등등..
가만보면
AWS내부에서 모두 수행이 됨 - 즉 이것이 단점이 되기도 함.
장점
- 기본적으로 관리 영역은
EC2처럼 대신해준다는 점. - 함수 형식으로 잘게 나뉘어져 있어, 사용자의 요청이 들어올 때만 서버가 응답하여 24시간 풀로 켜져있는 서버보다 비용이 훨씬 저렴하다고 함.
잘게 나뉘어져 있기 때문에, 필요한 함수들만 실행시킴.
단점
- 24시간 상시 서버가 운영되는것이 아닌, 특정 함수단위가 호출되면 그 부분만 실행되는것이기 때문에, 약간의 지연이 있다고 한다.
Cold Start AWS Lambda를 사용하는 순간 그 앱은AWS와 결혼을 한 것임.사실상 분리가 불가능한만큼 어려운 수준.
느낌
ServerLess 개념 확립에 가장 큰 임팩트를 준것은 확실히 이 말이였다.
Backend without Server Management 메모리, 보안 등 서버 관리가 필요없는 BackEnd
BaaS, FaaS 또한 ServerLess인지 아닌지가 아닌 방식의 차이였던 점.
실제로 S3나 EC2를 통해 배포를 해보았던 경험이 있어서 공감가는 부분도 꽤 있었다.
그리고 참고의 마지막 링크에서 쓰신 말이 있는데,
Serverless 기술이 좋고 나쁘고를 떠나서 비즈니스 전달이 목적이지 애초에 물리적 서버 자체가 목적이 아니면 필요가 없다
맞는 말씀이신것 같다. ServerLess나 EC2나 뭐가 옳다 그르다가 아니라 개발하고자 하는 앱의 특징에 따라 명확하게 선택할 수 있도록 개념을 알고있는것이 중요한 것 같다.
