StudyDad

기술 실무 설계 시리즈 1/8관리자 페이지는 종종 작게 시작한다.목록 하나, 상세 화면 하나, 상태 변경 버튼 하나. 처음에는 단순 CRUD처럼 보인다.그래서 "이 정도는 그냥 만들면 되지 않을까?"라고 생각하기 쉽다.하지만 실제 운영에 쓰이는 관리자 페이지는 생각보다 빨리 복잡해진다. 인증, 권한, 배포, 캐시, API, 파일 다운로드, 장애 대응, 데이터 원천 같은 문제가 화면 뒤에 붙기 시작한다.작은 관리자 페이지에도 아키텍처가 필요한 이유는 규모 때문이 아니다.업무가 그 도구에 의존하기 때문이다.사용자 수보다 업무 중요도가 중요하다운영 도구는 사용자가 많지 않을 수 있다.하루에 몇 명만 쓰는 화면일 수도 있다.하지만 그 몇 명이 매일 중요한 업무를 처리한다면 시스템의 중요도는 낮지 않다.예를 들어..

AWS 실전 운영 시리즈 12/12WAF를 붙였다고 해서 시스템 전체가 자동으로 보호되는 것은 아니다.WAF는 어디에 연결되어 있는지에 따라 보호 범위가 달라진다.CloudFront에 WAF를 붙이면 CloudFront를 통과하는 요청은 검사할 수 있다. 하지만 CloudFront를 우회하는 API Gateway나 origin 직접 접근 경로는 별도 보안 정책이 필요하다.이 차이를 이해하지 못하면 "WAF가 있으니 안전하다"고 착각할 수 있다.문제 상황운영 콘솔 앞단에는 CloudFront가 있었다.프론트엔드 SPA는 CloudFront를 통해 S3에서 제공되었다.API 일부도 CloudFront를 거쳐 origin API 서버로 전달되었다.여기에 사무실 IP만 허용하는 WAF 정책을 붙일 수 있다.구조..

AWS 실전 운영 시리즈 11/12CloudFront를 S3 앞에 붙이는 구성은 익숙하다.하지만 CloudFront를 EC2나 API 서버 앞에 둘 때는 조금 다른 문제가 생긴다.CloudFront의 Custom Origin에는 origin domain name이 필요하다. 운영 중인 API 서버가 EC2 IP로만 접근 가능하다면, CloudFront origin으로 쓰기 위해 별도의 도메인을 만들어야 할 수 있다.이 글은 API용 CloudFront 앞뒤에 왜 도메인을 두 개 만들었는지 정리한 것이다.문제 상황운영 콘솔에는 상주 API 서버가 있었다.이 서버는 대시보드와 분석 API처럼 짧고 잦은 요청을 처리했다.사용자는 다음 도메인으로 API를 호출하게 하고 싶었다.api.example.com그리고 ..

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

AWS 실전 운영 시리즈 9/12작은 운영 콘솔을 만들 때 처음부터 모든 AWS 기능을 켤 필요는 없다.RDS Proxy, WAF, X-Ray, ECS Fargate, Reserved Concurrency, Request Validation, DLQ 같은 것들은 모두 유용하다.하지만 처음부터 다 넣으면 시스템이 과해진다.중요한 것은 지금 쓰지 않더라도, 어떤 조건이 되면 검토할지 적어두는 것이다.현재 구조에서 출발하기작은 운영 콘솔은 다음 정도로 시작할 수 있다.React SPA-> S3 + CloudFront-> API Gateway-> Lambda-> S3 / RDS일부 잦은 API-> EC2 + Docker-> RDS이 구조는 충분히 현실적이다.하지만 규모나 요구사항이 바뀌면 추가할 후보들이 생긴다..

AWS 실전 운영 시리즈 8/12AWS 콘솔에는 리소스가 많다.Lambda, API Gateway, S3 bucket, CloudFront distribution, IAM role, EC2 instance, ECR repository, CloudWatch log group.처음 만든 사람은 어디에 무엇이 있는지 안다.하지만 시간이 지나거나 담당자가 바뀌면 리소스 이름을 찾는 것부터 일이 된다.그래서 AWS 리소스 이름과 배포 정보는 반드시 문서화해야 한다.문제 상황운영 콘솔은 여러 AWS 리소스를 사용했다.정적 파일을 저장하는 S3 bucket데이터를 저장하는 S3 bucketCloudFront distributionAPI Gateway REST APILambda functionLambda LayerIA..

AWS 실전 운영 시리즈 7/12컨테이너를 운영한다고 하면 ECS나 EKS를 먼저 떠올릴 수 있다.AWS에서 컨테이너를 운영하는 표준적인 방법이고, 오토스케일링과 배포 관리에도 강하다.하지만 모든 컨테이너 워크로드에 처음부터 오케스트레이션이 필요한 것은 아니다.작은 운영 콘솔의 상주 API 서버라면 EC2 한 대에 Docker로 운영하는 방식이 더 단순할 수 있다.문제 상황운영 콘솔 일부 API는 Lambda보다 상주 서버가 더 적합했다.이 API들은 다음 특성이 있었다.대시보드 조회처럼 짧고 잦은 요청DB connection pool 유지 필요내부 인증 쿠키 처리낮은 지연 시간 필요무거운 배치 작업과 분리 필요Lambda만으로 처리하면 cold start와 DB connection storm이 걱정되었..

AWS 실전 운영 시리즈 6/12운영 중 문제가 생기면 가장 먼저 보는 것은 로그다.하지만 로그가 있다고 해서 바로 원인을 알 수 있는 것은 아니다.중요한 것은 어떤 순서로 볼 것인가다.React SPA, CloudFront, API Gateway, Lambda, 애플리케이션 서버, 데이터베이스가 이어진 구조에서는 증상을 계층별로 나눠 봐야 한다.문제 상황운영 콘솔에서 사용자가 이렇게 말할 수 있다.화면이 안 떠요.데이터가 안 바뀌어요.다운로드가 계속 기다려요.버튼을 눌렀는데 아무 일도 안 일어나요.어제는 됐는데 오늘은 안 돼요.이 말만 듣고 원인을 알 수는 없다.브라우저 문제일 수도 있고, CloudFront 캐시 문제일 수도 있고, API Gateway 설정 문제일 수도 있고, Lambda 오류일 수..

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..