[개발PC : MacBook]
Chapter01) 코로나보드 아키텍처와 웹 서비스
학습 목표 : 코로나보드의 프론트엔드와 백엔드의 전체적인 아키텍처를 파악하고, 이러한 아키텍처로 설계된 이유를 알아봅시다.
[개발 언어 선택하기]
자바스크립트는 소규모 웹사이트를 빠르게 만들어서 출시하 데 적합합니다.
[프론트엔드 선택하기]
웹 프론트엔드는 개츠비(gatsby) 기반의 정적 웹사이트로 만들었습니다.
정적 웹사이트는 페이지를 빌드하는 시점에 필요한 데이터를 가져와서 페이지에 미리 채워넣습니다.
이렇게 빌드된 정적 웹페이지는 서버에서 동적으로 데이터를 가져올 필요가 없어서 속도가 빠른 데다 애플리케이션 서버 비용을 대폭 절감할 수 있습니다.
반면 동적 웹사이트는 페이지가 로드될 때마다 서버에서 동적으로 데이터를 가져옵니다.
데스크톱과 모바일에 동시 대응하고자 부트스트램(Bootstrap)의 그리드 시스템을 이용해 반응형 디자인으로 구현했습니다.
그 외에도 부트스트랩에서 기본 제공하는 버튼, 카드, 모달, 다이얼로그(modal dialog), 툴립(tooltip) 등의 UI 구성요소들을 CSS만 조금씩 수정해서 사용했습니다.
[백엔드 설계하기]
각 요소의 역할은 다음과 같습니다(클라이언트와 가까운 순서로).
(1) 클우드플레어 : 클라이언트의 모든 요청은 CDN 서비스인 클라우드플레어를 통해 웹 서버로 보내집니다.
이렇게 하면 클라우드플레어에서 제공하는 다양한 기능을 사용할 수 있습니다.
(2) 웹 서버 및 정적 페이지 저장소 : 클라이언트의 요청에 맞게 정적 페이지 저장소에 저장된 페이지를 보여줍니다.
(3) 정적 페이지 빌더 : 데이터 저장소의 최신 정보를 토대로 정적 페이지를 만들어 정적 페이지 저장소에 올립니다(20분 주기).
(4) API 서버 : 데이터 저장소에 필요한 통계 정보를 업데이트하고 원하는 형태로 조회할 수 있게 해줍니다.
(5) 데이터 저장소 : 코로나보드에 보여줄 다양한 정보를 저장합니다.
(6) 크롤러 : 코로나 관련 데이터를 모니터링하다가 변경 사항이 발견되면 API 서버를 통해 데이터 저장소에 반영합니다.
[크롤러]
크롤러는 자동화된 방법으로 웹페이지 전체 또는 일부를 추출하여 정보를 얻는 컴퓨터 프로그램을 지칭합니다.
노드JS(Node.js)기반으로 작성된 다수의 웹 크롤러를 이용해 여러 사이트에서 지속적으로 데이터를 수집합니다.
이 크롤러들은 AWS EC2 기반의 리눅스 서버에서 실행됩니다.
크롤러는 크론탭으로 스케줄링되어 자동으로 일정 시간마다 데이터를 수집하고 변경 사항이 발견되면 API 서버를 통해 변경된 데이터를 데이터베이스에 저장합니다.
[데이터 저장소]
데이터 저장소로는 구글 시트와 MySQL을 사용합니다.
<구글 시트>
구글이 제공하는 API를 이용해서 스프레드시트 안의 데이터를 불러오거나 업데이트하는 것이 가능해서 작은 데이터베이스처럼 활용할 수 있습니다.
또한 스프레트시트이다 보니 웹이나 구글 시트 모바일 앱으로 자유롭게 편집할 수 있다는 점도 큰 장점입니다.
다만 최대 500만 개의 셀만 담을 수 있고 100초 동안 최대 100번만 호출할 수 있습니다.
불러오는 속도도 느린편이다.
따라서 데이터양이 많다거나, 자주 불러와야 한다거나 혹은 응답 속도가 빨라야 할 때는 적합하지 않습니다.
<MySQL>
데이터양이 많아져 시트 크기 제한에 도달하면서 DB를 사용할 계기에 도달했고, 이제 오직 코드로만 데이터를 불러오고 업데이트할 수 있어 개발자 입자에서는 오히려 더 편하고 안정적인 환경을 구축할 수 있었다.
[API 서버]
노드JS로 만든 간단한 웹 애플리케이션 서버로, 크롤러가 수집한 각종 정보를 API 서버를 통해 데이터 저장소에서 저장합니다.
정적 페이지 빌더는 빌드 시점에 API 서버를 통해 페이지에 필요한 데이터를 조회합니다.
[정적 페이지 빌더]
코로나보드는 프론트엔드가 매번 백엔드 API를 호출하여 데이터를 받아오지는 않습니다.
데이터 저장소에서 데이터를 가져와서 미리 만들어둔 HTML 템플릿 파일에 주입하여 정적인 HTML 파일을 만들어주고, 클라이언트가 요청하면 이 HTML을 보내줍니다. 이런 방식을 정적 웹페이지(static web page)라고 합니다.
개츠비가 바로 이 정적 페이지 빌더 역할을 합니다.
<정적 웹페이지와 동적 웹페이지>
동적 웹페이지는 사용자 요청을 받은 애플리케이션 서버가 동적으로 사용자의 요청 내용에 맞게 콘텐츠를 생성하여 응답하는 방식이다.
이 방식은 사용자 요청에 따라 콘텐츠를 다르게 보여줄 수 있는 장점이 있지만 별도의 애플리케이션 서버가 필요합니다.
애플리케이션 서버에서는 복잡한 비즈니스 로직이 수행되고 데이터 베이스에서 원하는 데이터를 검색하는 등 작업 시간이 오래 걸리고, 요청이 많이 들어오면 처리되지 못한 요청들이 서버에 쌓여 서버 장애로 이어질 가능성이 커집니다.
그래서 동일한 요청량을 처리하는데 필요한 서버 수는 동적 웹페이지 방식이 정적 웹페이지 방식보다 더 많습니다.
반면 정적 웹페이지는 미리 만들어둔 콘텐츠를 파일로 저장해두고 웹 서버가 요청받은 내용에 해당하는 파일을 찾아 바로 응답합니다.
파일을 읽어서 응답하는 웹 서버만 있으면 되기 때문에 별도의 애플리케이션 서버가 필요 없습니다.
사용자에게 보여주고 싶은 콘텐츠가 담긴 HTML 파일들만 미리 서버에 업로드해두면 사용자 요청에 따라 해당 HTML 파일 내용을 응답으로 내려주면 되기 때문에 CPU 부담이 거의 없고 처리 속도가 매우 빨라서 적은 수의 웹 서버만으로도 동적 웹페이지 방식 대비 훨씩 더 많은 요청량을 처리할 수 있습니다.
웹사이트를 만들 때 모든 페이지가 정적 웹페이지인 정적 웹사이트를 만들 수도 있고, 모든 페이지가 동적 웹페이지인 동적 웹사이트를 만들 수도 있지만, 상황에 따라 적절하게 정적/동적 웹페이지가 혼합된 웹사이트를 만들 수도 있습니다.
[정적 페이지 저장소 및 웹 서버]
빌드가 완료된 HTML 페이지 파일들을 저장해두는 곳이 필요합니다.
'정적'이라는 말이 뜻하듯 이 파일들을 삭제해서 다시 업로드하기 전까지는 내용이 변하지 않습니다.
AWS S3(Simple Storage Service)를 사용하면 이런 파일 데이터를 저장하고, 저장된 파일을 서빙(serving)하는 웹 서버 역할까지 할 수 있기 때문에 S3를 활용했습니다.
[클라우드플레어]
사용자가 웹 서버에 직접 요청해서 웹페이지를 받아가도 되지만, 사용자와 웹 서버 사이에 CDN(content delivery network) 역할을 하는 클라우드플레어(Cloudflare) 서비스를 추가했습니다(CDN은 사용자와 가까운 위치의 분산된 캐시 서버로 부터 사진, 비디오 등의 콘텐츠를 내려받아 대기 시간을 최소화하는 콘텐츠 전송 기술입니다).
이렇게 하면 사용자는 웹 서버에 직접 접속하지 않고 클라우드플레어 서버를 통해서 웹페이지를 받아갑니다.
따라서 클라우드플레어에 이미 캐시(cache)된 웹페이지에 대한 요청은 클라우드플레어에서 바로 응답하므로 웹 서버로 직접 들어오는 트래픽을 줄어 수 있습니다.
이외에도 HTTPS와 웹사이트 운영에 필요한 여러 리디렉션 규칙을 적용할 수 있습니다.
[코로나보드 아키텍처 핵심 포인트]
<정적 웹페이지 & 빌더>
트래픽 걱정은 그만
<자동 크롤링 파이프라인>
나를 쉬게 하는 방법
<구글 시트>
저장소로 드는 돈을 아끼는 비법
<클라우드플레어 CDN>
트래픽 비용까지 무료로
<광고>
부족한 유지비를 보충하는 비법