StudyDad

운영 콘솔 아키텍처 시리즈 3/9React로 만든 관리자 페이지를 배포한다고 하면 자연스럽게 웹 서버를 떠올리기 쉽다. EC2 인스턴스를 만들고, Nginx를 설치하고, 빌드된 파일을 복사하고, HTTPS 인증서를 붙이는 식이다.하지만 React SPA의 빌드 결과물은 대부분 정적 파일이다. 서버가 매 요청마다 HTML을 렌더링하지 않는다면, 24시간 떠 있는 웹 서버가 꼭 필요하지 않을 수 있다.문제 상황운영 콘솔은 React SPA였다. SEO가 중요하지 않았고, 서버 사이드 렌더링도 필요하지 않았다. 브라우저가 index.html과 JavaScript 번들을 받은 뒤, 이후 화면 전환은 클라이언트 라우터가 처리했다.필요한 것은 다음 정도였다.커스텀 도메인HTTPS정적 파일 캐싱SPA 라우팅 fall..

AWS 실전 운영 시리즈 10/12운영 콘솔을 AWS에 올릴 때 배포만큼 중요한 것이 도메인 라우팅이다.React SPA를 S3에 올리고 CloudFront를 붙이면 화면은 열릴 수 있다. 하지만 실제 운영에서는 도메인이 여러 개 생긴다.프론트엔드 도메인API 도메인CloudFront origin 도메인디버깅용 직접 접근 도메인도메인은 단순 주소가 아니다.사용자가 어디로 들어오고, CloudFront가 어떤 origin을 보고, WAF가 어디에 붙고, API가 어떤 경로로 백엔드에 도달하는지 결정하는 인프라 설계 요소다.문제 상황운영 콘솔은 크게 두 종류의 트래픽을 가졌다.첫째, React SPA 정적 파일을 가져오는 프론트엔드 트래픽이다.사용자-> console.example.com-> CloudFro..

AWS 실전 운영 시리즈 2/12CloudFront를 처음 쓸 때는 캐시를 성능 기능으로만 생각하기 쉽다.사용자 가까운 엣지에서 파일을 제공하니 더 빠르다. 트래픽이 줄고, origin 부하도 줄어든다.맞는 말이다.하지만 운영 콘솔에서 CloudFront 캐시는 성능 기능이면서 동시에 운영 기능이다.캐시 정책에 따라 배포 반영 속도, 데이터 최신성, 장애 대응 방식이 달라지기 때문이다.문제 상황React SPA를 S3에 올리고 CloudFront로 서빙했다.정적 파일은 잘 캐시되었고, 화면 로딩도 빨랐다.그런데 운영 중에는 이런 질문들이 생겼다.배포했는데 왜 이전 화면이 보일까?JSON 데이터가 바뀌었는데 왜 화면에 반영되지 않을까?어떤 파일은 오래 캐시해도 되고 어떤 파일은 짧게 해야 할까?매번 inv..

AWS 실전 운영 시리즈 1/12React로 만든 관리자 페이지를 배포할 때 꼭 애플리케이션 서버가 필요한 것은 아니다.빌드가 끝난 React SPA는 결국 HTML, JavaScript, CSS, 이미지 같은 정적 파일이다. 이 파일들은 Node 서버나 Nginx가 없어도 S3와 CloudFront만으로 충분히 서빙할 수 있다.하지만 "S3에 올리면 끝"이라고 생각하면 운영 중에 여러 문제를 만난다.HTTPS, 커스텀 도메인, SPA 라우팅, 캐시 정책, 배포 후 무효화, 데이터 파일 보호 같은 것들을 미리 정해야 한다.문제 상황운영 콘솔은 React SPA로 만들었다.사용자는 많지 않았지만, 내부 업무에 매일 쓰이는 화면이었다. SEO는 중요하지 않았고, 서버 사이드 렌더링도 필요하지 않았다.이런 조..