StudyDad

AI 장애 분석 포스트모템 시리즈 5/9Datadog에서 나온 후보를 그대로 결론으로 옮기지 않았습니다. 그래서 AWS로 반박할 수 있는지 먼저 봤습니다. 이번 사례에서 Datadog은 세 가지 큰 단서를 보여줬습니다.auth endpoint long span/heartbeat timeoutMySQL pressure이 세 가지를 AWS CLI로 ECS, ALB, CodeDeploy, RDS를 조회해서 다시 확인했습니다. 만약 AWS MCP를 붙였다면 같은 질문을 다른 도구로 던지는 문제였을 것입니다. 검증 방식은 도구와 별개였습니다.검증할 질문을 고정했습니다새 데이터를 많이 모으는 게 목적이 아니었습니다. 이번 단계에서는 Datadog 가설을 검증하는 데 집중했습니다. 그래서 질문은 다섯 가지로 좁혔습니..

AI 장애 분석 포스트모템 시리즈 1/9Datadog에서 GET /heartbeat trace 하나가 30초 timeout 경계에 붙어 있는 화면을 보고 있었습니다. 같은 시점에 JVM Old Gen이 올라와 있었습니다.초기 단서: 일부 GET /heartbeat span이 30초 timeout 경계에 붙어 있었습니다.이 스크린샷 한 장을 Claude Code에 붙여두고 원인을 물어보려고 했습니다. 그런데 프롬프트를 어떻게 써야 하나 잠깐 고민하다가 이상한 점이 보였습니다. AI가 볼 수 있는 건 이 화면 한 장뿐이었습니다.프롬프트보다 먼저 막힌 지점먼저 Datadog API Key와 Application Key를 환경변수로 붙였습니다. /api/v1/validate는 성공했습니다. metric quer..

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