brunch

You can make anything
by writing

C.S.Lewis

by 배울장 Aug 23. 2018

아마존웹서비스를 활용한 서버리스 웹페이지 구축

서버리스아닌 서버리스 아키텍쳐

처음 클라우드 서버를 이용할 때 이제 더 이상 서버를 관리하지 않아도 된다는 사실이 희소식이었다. 사실 서버를 대신 관리해주는 서비스는 매우 많았다. 대규모로 서버를 대신 관리해주는 곳에 내 서버가 입주하면 되는 것이었다. 문제는 바로 비용. 임대를 해주는 형태, 월 사용료만 내는 형태, 형태는 다양했지만 모두 비용이 문제였다. 12개월 사용료만 모아도 새 서버를 살 수있는 돈이 나와 이용을 포기하고 직접 서버를 구매해서 관리하는 형태를 주로 사용했다.

하지만 관리도 만만치 않다. 나는 대규모서버를 구축해보지도 운영해보지도 않았지만 소규모도 관리하는데 은근히 손이 많이 갔다. 서버가 있는 곳에 비가 많이와서 침수를 당해 갑자기 서버가 꺼져버린다거나 정전이 난다거나하는 문제들이 발생했다. 문제는 서버중단은 바로 서비스중단으로 이어지고 이용자들에게 신뢰를 잃어버린다는 것이다. 서비스가 유니크하지 않다면 이용자들은 바로 다른 서비스를 찾아가고 리뷰에 이렇게 남길 것이다. '맨날 끊겨요'

지금 나는 내 개인 용도로만 서버를 이용하고 있고 제공하는 서비스들은 모두 웹 호스팅을 이용하거나 아마존웹서비스를 이용한다. 왜 구글은 사용하지 않냐고 물으신다면 아마존을 먼저 썼기때문이라고 말씀드리겠다.

제목을 서버리스라고 지어놓고 서론이 길었다. 서버리스는 서버를 사용하지 않는다는 것인데 서버를 안쓰고 웹페이지를 만드는 것은 사실 홍철없는 홍철팀이다. 웹페이지에서 서버의 역할은 이용자가 웹페이지에 접속했을 때 원하는 페이지의 데이터들을 전송해주고 이용자가 일련의 활동들을 하고 서버로 요청을 했을 때, 예컨대 로그인을 하기위해 아이디와 비밀번호를 입력하고 엔터를 누르면 서버로 이 아이디와 비밀번호 맞아? 하고 서버로 요청을 보낸다. 서버는 맞으면 로그인을 허가하여 로그인을 한 이용자만 볼 수 있는 데이터를 전송한다.

여기까지만 살펴보자. 서버의 역할은 데이터 전송, 유저의 요청 처리 이 두가지다. 서버가 없으면 데이터를 전송할 수 없다. 그렇다면 서버리스는 뭘까? 단순히 데이터를 전송하는 서비스를 이용하는 비즈니스 고객들은 많다. 그 고객들에게 데이터를 전송하기 위해 서버를 구축하는 수고로움을 대신 처리하고 자료만 올리면 권한이 있는지 없는지 판단하여 자료에 접근을 하게해주는 아마존의 S3(Simple Storage Service)가 있다.

서버가 처리할 요청이 없는 페이지라면 여기서 완료

웹페이지가 특별한 동작을 하지 않고 단순히 정보를 보여주기만 한다면 여기서 멈춘다. 웹페이지를 디자인하고 S3에 업로드 후 정적 웹사이트 호스팅을 활성화하면 웹페이지 구축완료다. 아주 쉽다. 물론 페이지를 만드는건 다루지 않았다.

정적의 반대인 동적 웹 사이트는 그럼 뭘까? 아까 언급했던 유저의 요청을 처리해야한다면 동적 웹 사이트이다. 페이지가 정적이라고 정적 웹 사이트가 아니다. Javascript와 CSS로 움직이게 할 수 있다. HTML + Javascript + CSS 만으로 웹 사이트가 이루어졌다면 정적 웹 사이트이다.

그렇다면 유저의 요청 처리가 필요한 경우 어떻게 서버리스로 대처를 할 수 있을까? 그것은 바로 아마존 웹서비스의 Lambda 서비스를 이용하면 된다. 자, 웹사이트에서 서버는 주로 PHP, Python, Node 등을 사용하는데 Lambda는 Python과 Node js를 지원한다. 무슨 이야기인고 하니, 서버를 따로 구축하지 않아도 Python 코드와 Node js 코드를 실행시킬 수 있다는 것이다. 처리할 정보는 어디서 가져올까? 더 쉽게 말해 로그인 버튼을 눌렀을 때 아이디와 비밀번호를 받아야하는데 어떤 통로로 그 정보를 받는 것일까? 서버가 없는데 정보를 어떻게 받을까? 그 해답은 API Gateway 에 있다. 아마존웹서비스의 서비스 중 하나인데 REST API를 구축할 때 도움을 준다. REST API는 또 뭘까? 쉽게말해 brunch.co.kr 이라는 도메인에 로그인 정보를 보낼 때는 brunch.co.kr/login 으로 보낸다고 약속을 하고 데이터를 보내는 방식에 차이를 두어 어떤 요청인지 알아내고 데이터를 처리한 후 응답을 보내는 방법이다. 천천히 하나씩 풀어 이야기하면 당신이 아이디와 비밀번호를 누르고 엔터를 치면 아이디와 비밀번호가 POST 라는 방식으로 brunch.co.kr/login 으로 전송되고 서버는 해당 정보가 POST로 왔기 때문에 로그인을 시도하는 것이구나! 를 알아차리고 아이디와 비밀번호가 맞는지 확인하고 로그인 성공 / 실패 여부를 다시 이용자에게 보내는 것이다. 만약 POST 방식이 아니고 GET 방식으로 보낸다면 현재 내 로그인 정보를 얻어오려고 하는구나! 라는 것을 알 수 있을 것이다. 중요한 것은 어떤 방식으로 보내느냐에 따라 어떤 요청인지 구분할 수 있다는 것이다. 이런 로직을 간단하게 구현할 수 있는 서비스가 바로 API Gateway 이다.

API Gateway로 정보가 도달 했을 때 그 정보를 바로 Lambda 서비스로 전송한다. 그러면 서버가 잠깐 실행이 되고 요청을 처리한 후 Lambda에서 API Gateway로 정보가 전송되고 API Gateway에서 다시 유저에게 응답을 보낸다. 복잡하지만 이용자가 요청을 보낼때만 간헐적으로 서버 코드가 실행되기 때문에 비용면에서 유리하고 트래픽이 폭주할 때 대응하기 좋다. 비용은 매우 저렴하다. 아무도 안쓰면 돈이 안나가고 많이 쓰면 그 만큼 많이 나가지만 결제할 때는 기쁘지 않을까?

로그인 / 카드결제 등을 언급하고 싶었는데 이미 글이 너무 길어졌다. 여튼 중요한 것은 저렴한 비용으로 트래픽 걱정없이 로그인 / 카드결제 등 많은 기능을 구현할 수 있는 서버리스 아키텍쳐를 소개하고 싶었다. 상당히 많은 서비스들을 융합해서 써야하지만 Django나 Flask, Express 들이 하는 역할들을 나누어서 구현한 서비스라고 생각하면 편하겠다.

Lambda 코드를 실행할 때 결국 서버를 쓰는데 서버리스라는 이름이 맞나 하는 의문이 든다면 좋은 생각이다. 해외에도 많은 사람들이 공감한다.

keyword