전체 글

배포 장애에서 배운 것 롤백은 성공했지만, 서비스는 멈췄다커넥션 풀과 스레드 풀, 그리고 롤백만으로 회복되지 않았던 이유 배포가 정상적으로 끝났다는 알림을 받았다. 그런데 곧바로 서비스에서 DB 연결 관련 오류가 발생하기 시작했다. 이상을 확인하고 롤백 요청을 받아 이전 버전으로 롤백했다. 익숙한 대응이었고 곧 회복될 것이라고 생각했다. 하지만 장애가 전이되면서 점점 더 큰 문제를 일으켰다. 이 경험을 통해 배포를 되돌리는 것과 서비스를 회복하는 것은 서로 다른 작업이라는 것을 뼈저리게 느꼈다. 보안과 기밀 보호를 위해 조직명, 내부 도구명, 서비스명 및 구체적인 운영 수치는 생략했다. 당시 관찰한 현상과, 이를 이해하기 위한 기술적 설명을 구분해 정리했다.빠른 롤백을 위해 남겨 둔 이전 파드 장애..

ALB 생명주기 관리 · Terraform state 이전 · 동적 DNS 조회 · CodeDeploy 검증 · AWS 비용 절감이번 작업의 결론테스트 환경을 올릴 때 ALB를 만들고, 내릴 때 ALB를 삭제하도록 변경했다.새로 만든 ALB의 DNS가 매번 달라져도 부하 테스트와 모니터링 코드가 현재 주소를 조회하도록 수정했다.실제 환경에서 env-up → env-down → env-up 왕복, 머지 후 CodeDeploy, 마지막 env-down까지 확인했다.1. 시작은 단순한 비용 문제였다내 프로젝트는 대량의 캠페인 참여 요청을 처리하는 테스트 환경을 AWS에 구성해 두었다.애플리케이션은 Auto Scaling Group(ASG)에서 실행되고, 앞에는 Application Load Balancer(A..

Kubernetes · Operator · Kafka · StatefulSet · kind · 코드 리뷰 Kafka MQ Reconciler는 브로커가 뜰 때까지 상태를 계속 다시 확인한다. 문제는 이미지 pull이 실패하거나 노드가 부족한 경우였다. 이때 MQ는 영원히 PROVISIONING에 머문다. 코드 리뷰에서 이 부분을 지적받고 실패 기한과 재시도 간격을 넣었다.그런데 kind 클러스터에서 검증하다 보니 하나가 더 있었다. 설정을 고쳐도 이전 설정으로 만들어진 Pending Pod가 그대로 남아서 복구를 막고 있었다.이번 글은 PerfStack PR #30에서 받은 리뷰부터 kind 통합 테스트, 추가 수정과 재검증까지의 기록이다. 1. MQ Operator가 관리하는 것사용자가 MQ Custo..

EC2 · AMI · Docker · CodeDeploy · Redis · 장애 분석 이 글의 핵심새 EC2 인스턴스에 최신 앱이 배포되기 전, AMI에 남아 있던 5개월 전 Docker 컨테이너가 먼저 실행됐다. 구버전 앱은 운영 Redis의 캠페인 상태를 변경했고, 그 결과 202로 접수된 메시지 20만 6천 건이 Redis 큐에 고립됐다. 150만 건의 캠페인 참여 요청을 처리하는 시스템을 부하 테스트하던 중 이상한 현상을 만났다. API는 참여 요청 60만 건에 202 Accepted를 반환했는데, 최종 DB에는 39만 4천 건만 기록됐다. 나머지 20만 6천 건은 Redis 큐에 그대로 남아 있었다. 처음에는 Kafka Consumer나 Bridge의 처리량 문제라고 생각했다. 하지만 Kafka..

Spring Boot로 새 애플리케이션 서버를 만들 땐 구조를 어떤 식으로 설계해야 할지가 제일 먼저 드는 고민이다. 요즘 전부 msa 쓴다고 해서 전부 마이크로서비스로 나누면 서비스 간 호출, 배포 순서, 장애 전파, 데이터 정합성 같은 운영의 문제들이 따라온다. 반대로 일반적인 모놀리스로 시작하면 개발 속도 자체는 초반에 빠르지만 시간이 지나면서 패키지 경계가 흐려지고 서비스가 서로 강한 결합을 하게 되는 경우가 생긴다. 모듈러 모놀리스는 이 둘 사이의 현실적인 선택지이다. 배포 단위는 하나로 유지하되, 코드 내부는 비즈니스 모듈 단위로 나누고, 모듈 사이의 접근 규칙들을 테스트로 검증한다. Spring Modulith는 이 접근을 Spring Boot 프로젝트 안에서 적용할 수 있게 도와준다. 내..

요즘 정말 많은 벽을 넘고 있다. 일도 하고 숙제도 많고 공부할 것도 많고.. 몰려오는 지식의 양이 너무 많아서 한달 정도 블로그 글을 쓸 엄두도 내지 못했다. 써야 할 글이 넘쳐나지만 이럴 수록 더 정제를 잘 하고 내걸로 만들어서 좋은 글을 올려야겠다. 오늘은 쿠버네티스를 처음 다룰 때 가장 헷갈리는 부분 중 하나인 외부 사용자의 요청이 어떻게 클러스터 안의 Pod까지 도달하는지에 대해 알아볼 것이다. Pod는 기본적으로 클러스터 내부 네트워크에 존재한다. 사용자가 브라우저에서 https://hskhsmm.com으로 요청을 보냈다고 해서 그 요청이 곧바로 Pod로 들어가는 것은 아니다. 중간에 DNS, 로드밸런서, 쿠버네티스 Service, Ingress 또는 Gateway 같은 여러 계층이 관여한..

기존에 수행중인 프로젝트의 배포는 Github Actions와 CodeDeploy를 기반으로 동작한다. Github Actions는 Docker 이미지를 빌드해서 ECR에 push하고 배포에 사용할 이미지 주소를 SSM Parameter Store에 저장한 뒤, appspec.yml과 배포 스크립트를 S3 bundle로 묶어 CodeDeploy 배포를 생성한다. CodeDeploy는 Auto Scaling Group에 속한 애플리케이션 EC2 인스턴스에 배포 bundle을 전달하고, appspec.yml에 정의된 lifecycle hook을 순서대로 실행한다. appspec.yml BeforeInstall -> deploy/scripts/beforeInstall.sh AfterInstall ..

이 프로젝트는 단순한 CRUD 서비스가 아니라, 대규모 이벤트성 트래픽을 처리하는 캠페인 오케스트레이션 시스템이다. Kafka 3 broker, Redis/Valkey Cluster, RDS MySQL, Auto Scaling Group, ALB, CodeDeploy, Prometheus/Grafana 기반 모니터링까지 포함해 실제 운영 환경에 가까운 구조로 AWS 인프라를 구성했다. 문제는 비용이었다. 개인 프로젝트에서 운영형 인프라를 계속 켜두면 비용 부담이 꽤 커진다. 특히 다음 리소스들은 테스트하지 않는 시간에도 계속 비용이 발생한다. - RDS MySQL- ElastiCache Redis/Valkey Cluster- Kafka EC2 3대- monitoring 및 terraform-mcp EC2..