민프

배포 회고모바일 앱과 백엔드를 동시에 갱신하는 건 불가능하다. 그 틈에서 뭘 지켜야 안 터지나.2026 · DevOps › [CI-CD]#VersionSkew#버전스큐#BackwardCompatibility#하위호환#ParallelChange#ExpandContract#DBMigration#마이그레이션#무중단배포#CICD모바일 앱을 출시하려고 백엔드를 먼저 prod에 올렸다. 앱은 앱스토어 심사를 거쳐 며칠 뒤에나 나간다. “서버는 최신인데 앱은 옛날 버전인 그 구간에 에러 나면 어쩌지?”에서 시작해, version skew를 정면으로 마주친 하루의 기록.01배경 — 서버는 오늘 올리는데, 앱은 며칠 뒤모바일 앱 출시를 앞두고 있었다.앱이 쓸 API를 담은 백엔드를 prod에 올려야 했다.문제는 순서..

개념 정리EC2는 "이 서버 살아있어"라고 하고, ECS는 "아직 일 못 받아"라고 한다. 같은 서버를 두고 두 시스템이 다르게 말하는 이유.2026 · AWS 개념 · 약 5분#ECS#AutoScaling#EC2인스턴스가 InService인데 태스크가 ECS Agent is not connected로 실패했다. "켜졌으면 됐잖아?" 싶었는데, 알고 보니 InService와 agentConnected는 서로 다른 시스템의 서로 다른 "준비" 신호였다.01ECS Agent가 뭐길래ECS Agent는 EC2 인스턴스 안에서 도는 작은 프로그램이다. 하는 일은 둘.하나, 그 서버를 ECS 관제탑에 "저 여기 있어요, 컨테이너 받을 수 있어요"라고 등록/연결한다.둘, 관제탑이 준 태스크를 받아 그 서버에..

트러블슈팅 일지동시 요청이 몰리면 Step Functions 실행이 아주 가끔 죽었다. 하나의 버그인 줄 알았는데, 뜯어보니 서로 다른 세 가지 실패가 섞여 있었다.2026 · 인프라/트러블슈팅 #StepFunctions#ECS#AutoScaling#warmpoolGPU 태스크를 warm pool로 미리 켜두고 병렬 처리하는 파이프라인. 평소엔 잘 도는데 동시 요청이 겹치면 간헐적으로 실패했다. "재시도하면 되잖아"로 넘길 수도 있었지만, 실제 로그를 끝까지 판 결과 독립적인 실패 모드 3개가 나왔다. 그 추적기다.01배경 — 미리 켜두는 구조파이프라인은 GPU 인스턴스를 warm pool에 준비시켜 두고, 요청이 오면 꺼내 쓰는 구조다. 각 실행은 시작할 때 필요한 만큼 인스턴스를 켜고(scale..

트러블슈팅 일지미리 켜뒀다고 믿은 인스턴스가, 정작 깨우는 순간 용량이 없어서 못 떴다.2026 · AWS · 인프라 · 약 5분#AWS#ECS#AutoScaling#워밍풀#회고GPU 워커를 warm pool로 미리 준비해두면 "용량 걱정은 끝"인 줄 알았다. 그런데 워밍풀에 인스턴스가 멀쩡히 대기 중인데도 Insufficient capacity로 못 뜨는 걸 만났다.워밍풀에 대한 내 오해를 정정한 기록.01워밍풀을 믿었다GPU 인스턴스는 부팅이 느리다. 그래서 Auto Scaling Group의 warm pool에 인스턴스를 미리 만들어 Stopped(정지) 상태로 대기시켜 뒀다.작업이 오면 이 정지된 인스턴스를 깨우기만(start) 하면 되니 빠르다. 그리고 나는 여기서 한 가지를 당연하게 믿..

트러블슈팅 일지속도를 위해 병렬로 바꾼 새 아키텍처. 그런데 그 "미리 켜두기"가 두 오토스케일러의 영역 다툼을 불렀다.2026 · AWS · 인프라 · 약 8분#AWS#StepFunctions#ECS#오토스케일링#회고요즘 팀에서 ML 파이프라인을 새 아키텍처로 마이그레이션하고 있었다. 그러다 실행 하나가 8시간 넘게 안 끝나는 걸 발견했고, 원인을 파고들었더니 결국 "오토스케일러 두 개가 같은 손잡이를 반대로 당기고 있던" 문제였다. 이 삽질기를 공유한다.01왜 "병렬"로 바꿨나배경을 먼저 깔면 이번 에러가 왜 났는지가 훨씬 잘 보인다. 우리는 파이프라인을 새 아키텍처로 옮기는 중이었다.이전 → 새 아키텍처이전 — 필요한 인프라(CPU/GPU 인스턴스)를 보수적으로, 비교적 순차적으로 준비했다...

AI 채팅 서비스의 dev 환경을 새로 구축하면서, 내부 서비스(ai, AI 엔진)를 어떻게 노출할지 정해야 했다. 이 서비스는 백엔드만 서버-서버로 내부 호출하는, 외부에 공개되지 않는 서비스다.선택지는 둘이었다.내부 전용 ALB (Application Load Balancer)AWS Cloud Map (ECS 서비스 디스커버리, ai.dev.local 같은 내부 DNS)처음엔 Cloud Map이 매력적으로 보였다. 그런데 결국 ALB로 돌아왔다. 이유는 딱 하나, SSE(Server-Sent Events) 때문이었다.Cloud Map이 끌렸던 이유내부 서비스끼리만 통신하는데 ALB를 두는 건 좀 과해 보였다.비용: 내부 ALB도 시간당 요금(~$16/월) + LCU 요금이 붙는다. Cloud Map은..

이전 글: [AWS] Bastion Host란 (feat. Private VPC, RDS) | ECS, EKS, EC2 VPC 보안을 지키는 관문 서버의 모든 것 [AWS] Bastion Host란 (feat. Private VPC, RDS) | ECS, EKS, EC2 VPC 보안을 지키는 관문 서버의 모든 것Bastion Host에 대해서 알아보도록 하겠습니다.1. Bastion Host란?Bastion [ˈbæstiən]. "요새", "보루"를 뜻하는 영어 단어이다. 특히 성형 요새를 의미하는 모양이다. 그러나 자주 사용되지는 않고 이러한minf.tistory.com이전 글에서 Private Subnet 안의 RDS·Redis에 접근할 때 Bastion Host를 관문으로 쓰는 방법을 소개했습니다...

상황DEV 환경을 새로 구축하던 중이었다. 백엔드가 결제 등등.. 다른 서비스들과 연동해야 해서, 그 연동용 KEY 값들을 ECS task definition에 넣어야 했다.귀찮은 마음에 SSM을 거치지 않고 CICD에 사용될 dev-task-definition의 secrets에 값을 직접 박아봤다."secrets": [ { "name": "SERVICE_RANDOM_KEY", "value": "pay_secret_5678" }]그리고 배포는 보기 좋게 깨졌다. 왜 깨졌나 — secrets는 valueFrom만 받는다ECS의 secrets 필드는 스키마가 엄격하다. 각 항목은 반드시 { "name": ..., "valueFrom": ... } 형태여야 하고, 직접 값(value)은 허용되지 않는다./..

보호되어 있는 글입니다.

저번 편에서는 CICD 자동배포를 제외한 나머지를 구축하였고,이번에는 아래에서 CICD 자동배포를 구현해보겠습니다.사용자/클라이언트 ↓ (HTTPS, 도메인)AWS Route53 (사전준비) ↓NCP L7 LoadBalancer (Public Subnet, SSL 종단) ↓Github Actions CICD 자동배포 ↓애플리케이션 서버 (Private Subnet, Docker Compose) 이번에 제가 구축할 CI/CD흐름은 아래와 같습니다.로컬 개발개발자가 로컬에서 코드를 수정하고 GitHub main 브랜치에 PUSHGitHub Actions (CI/CD)main 브랜치에 PUSH 이벤트 감지 → GitHub Actions 실행.GitHub Actions Runner가 Bastion..