StudyDad

AWS 실전 운영 시리즈 5/12브라우저에서 API를 호출할 때 CORS 오류를 만나면 당황스럽다.서버는 멀쩡한 것 같은데 브라우저가 요청을 막는다. Postman에서는 되는데 화면에서는 안 된다.운영 콘솔처럼 React SPA와 API 도메인이 분리된 구조에서는 CORS가 설계 요소다.특히 JSON 요청이 많다면 preflight OPTIONS 요청을 어떻게 처리할지 정해야 한다.CORS preflight란 무엇인가브라우저는 다른 origin으로 특정 요청을 보내기 전에 OPTIONS 요청을 먼저 보낼 수 있다.이 요청을 preflight라고 한다.예를 들어 다음 조건에서는 preflight가 발생한다.Content-Type: application/jsonAuthorization 헤더 사용PUT, DE..

AWS 실전 운영 시리즈 4/12AWS API Gateway에는 크게 REST API와 HTTP API가 있다.HTTP API는 더 가볍고 저렴하고 빠르다. 그래서 새로 만들 때는 HTTP API가 먼저 떠오를 수 있다.하지만 항상 HTTP API가 정답은 아니다.운영 콘솔처럼 브라우저 기반 SPA, 여러 endpoint, CORS preflight, API Key, 요청 검증, MOCK 응답 같은 요소가 중요하다면 REST API가 더 나을 수 있다.문제 상황운영 콘솔의 프론트엔드는 별도 도메인에서 동작했다.API는 Lambda를 통해 제공되었고, 여러 path와 method가 있었다.필요한 것은 단순히 Lambda를 HTTP로 호출하는 것만이 아니었다.path별 라우팅CORS preflight 처리O..

AWS 실전 운영 시리즈 3/12Lambda는 배포가 단순하다.코드를 zip으로 묶고 update-function-code를 실행하면 된다.하지만 Python Lambda에서 엑셀 생성 라이브러리나 데이터베이스 드라이버를 함께 넣기 시작하면 배포 파일이 금방 무거워진다.작은 코드 하나를 고쳤을 뿐인데 매번 큰 zip 파일을 만들고 올려야 한다면 배포가 느려지고 실수 가능성도 커진다.그래서 Lambda Layer를 사용해 함수 코드와 의존성을 분리했다.문제 상황운영 콘솔에는 리포트 파일을 생성하는 Lambda가 있었다.이 함수는 단순 API 응답만 하는 것이 아니라 다음 작업을 했다.데이터베이스 조회엑셀 파일 생성object storage 업로드작업 상태 갱신Python 코드 자체는 크지 않았다.하지만 엑..

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는 중요하지 않았고, 서버 사이드 렌더링도 필요하지 않았다.이런 조..

자동화 워크플로우 시리즈 1/8운영 자동화를 시작할 때 가장 먼저 떠올리는 것은 도구다.폼을 만들까, 스프레드시트를 쓸까, 관리자 페이지를 만들까, 자동화 스크립트를 붙일까, 아니면 처음부터 데이터베이스와 백엔드를 갖춘 시스템을 만들까.하지만 자동화는 도구에서 시작하면 자주 실패한다.먼저 봐야 할 것은 업무 흐름이다.누가 입력하고, 누가 확인하고, 어떤 기준으로 상태가 바뀌고, 결과가 누구에게 공개되는지부터 정리해야 한다. 그다음에야 어떤 도구가 충분한지 판단할 수 있다.문제 상황신청을 받고, 내부에서 확인하고, 일정이나 결과를 공개하는 업무가 있었다.처음부터 완전한 백오피스 시스템을 만들 수도 있었다. 로그인, 신청 화면, 관리자 화면, 상태 관리, 데이터베이스, 알림, 공개 페이지를 모두 직접 구현하..

데이터와 리포트 설계 시리즈 8/8작은 운영 콘솔의 리포트 시스템은 단순하게 시작할 수 있다.job table을 만들고, worker를 비동기로 실행하고, 결과 파일을 object storage에 저장한다.이 정도면 많은 내부 도구에는 충분하다.하지만 시간이 지나면 다시 검토할 지점들이 생긴다.좋은 설계는 처음부터 모든 것을 넣는 것이 아니라, 나중에 무엇을 볼지 알고 시작하는 것이다.현재 구조기본 구조는 다음과 같다.POST /api/reports-> job 생성-> worker 비동기 실행-> 파일 생성-> object storage 업로드-> job 완료-> polling으로 상태 확인이 구조는 단순하고 이해하기 쉽다.하지만 작업량이 늘거나 실패 대응이 중요해지면 개선 후보가 생긴다.1. 전용 Qu..

데이터와 리포트 설계 시리즈 7/8운영 콘솔에서 데이터베이스를 쓴다고 해서 모든 쿼리가 같은 성격은 아니다.화면 조회를 위한 쿼리와 리포트 생성을 위한 쿼리는 다르다.운영 데이터와 리포트 데이터도 다르다.이 차이를 무시하면 대시보드가 느려지거나, 리포트 생성이 운영 DB에 부담을 주거나, 정산성 데이터의 기준이 흔들릴 수 있다.운영 화면의 데이터운영 화면의 데이터는 빠르게 보여주는 것이 중요하다.예를 들어:오늘의 요약최근 주문상태별 건수점포 또는 사용자 목록간단한 필터 조회이런 데이터는 사용자가 화면에서 반복적으로 본다.응답 시간이 중요하고, 쿼리는 자주 실행된다.따라서 connection pool, index, pagination, cache 같은 요소가 중요하다.리포트 데이터리포트 데이터는 성격이 다..

데이터와 리포트 설계 시리즈 6/8운영 콘솔에는 통계 화면이 자주 등장한다.월별 매출, 주문 수, 사용자 수, 처리 건수, 리포트 합계 같은 지표를 보여준다.처음에는 화면이 열릴 때마다 원천 데이터를 조회해서 실시간 집계하면 된다고 생각할 수 있다.하지만 운영 통계는 매번 실시간으로 계산하는 것이 항상 좋은 선택은 아니다.반복 조회되는 통계는 미리 계산해두는 편이 더 안정적일 수 있다.문제 상황운영자는 대시보드에서 월별 통계를 자주 확인한다.통계는 여러 원천 데이터를 조합해서 계산해야 한다.데이터 범위가 넓거나 쿼리가 복잡하면 매번 화면 조회 시 집계하는 방식은 부담이 된다.특히 다음 문제가 생길 수 있다.대시보드 로딩이 느려진다.DB에 반복적인 집계 부하가 생긴다.같은 월 통계를 여러 사용자가 반복 조..

데이터와 리포트 설계 시리즈 5/8비동기 리포트 생성에서는 사용자가 작업 상태를 알아야 한다.가장 단순한 방법은 polling이다.프론트엔드가 일정 간격으로 상태 API를 호출한다.GET /api/jobs/{jobId}완료되면 다운로드 URL을 보여준다.Polling은 오래된 방식처럼 보일 수 있다. WebSocket이나 Server-Sent Events가 더 세련되어 보일 수도 있다.하지만 내부 운영 도구에서는 polling이 충분히 좋은 선택일 때가 많다.polling이란 무엇인가Polling은 클라이언트가 주기적으로 서버에 상태를 묻는 방식이다.예를 들어 2초마다 job 상태를 확인한다.0초: IN_PROGRESS2초: IN_PROGRESS4초: IN_PROGRESS6초: COMPLETE구현은 단순..