개발 끄적임 노트

RDS 인스턴스 업그레이드 후 Firebase Functions 연결 장애 — HAProxy DNS 캐싱 트러블슈팅 상황RDS 인스턴스를 t4g.xlarge에서 m7g.2xlarge로 업그레이드했다. 업그레이드 직후부터 Firebase Functions에서 다음 에러가 발생하기 시작했다.Unhandled error Error: Connection lost: The server closed the connection. at Object.createConnection (mysql2/promise.js:253:31) ... code: 'PROTOCOL_CONNECTION_LOST'증상 정리항목상태EKS 서비스 → RDS (Spring Boot, Ruby)✅ 정상Bastion → RDS 직접 ..

배경자사 서비스의 핵심 백엔드는 EKS(Kubernetes) 위에서 운영되며, EKS 애플리케이션들은 프라이빗 서브넷 내에서 RDS에 직접 연결한다.그런데 일부 기능은 Firebase Functions로 운영되고 있다. Firebase Functions는 Google Cloud 위에서 실행되기 때문에 AWS VPC 안에 있는 RDS에 직접 접근할 수 없다.이 글은 Firebase Functions에서 AWS RDS로 접근하기 위해 HAProxy + NLB 구조를 설계한 과정을 다룬다.왜 직접 연결이 안 되는가RDS는 프라이빗 서브넷에 위치해 있다. 외부 인터넷에서 직접 접근할 수 없도록 의도적으로 격리된 구조다.Firebase Functions는 Google Cloud의 서버리스 환경에서 실행되며, 고정..

AWS 인프라 전체 구조 — Terraform으로 관리하는 VPC 설계개요AWS 인프라는 Terraform으로 관리되며, 총 13개의 모듈로 구성되어 있다.cloudfront / ec2-bastion / eks / eks_node_alarm / eks-addonirsa / network / nodegroup / notifications / rdsrds_alarm / rds-proxy-server / s3서비스의 핵심 트래픽은 EKS Cluster에서 처리되며, 모든 애플리케이션은 프라이빗 DB 서브넷의 RDS MySQL에 직접 연결된다. Firebase Functions는 별도의 HAProxy 경유 경로를 사용한다.VPC 네트워크 구조리전: ap-northeast-2 (서울)서브넷 구성서브넷종류용도SBN..

📌 문제 상황테스트 서버에서 특정 Deployment의 Pod가 ImagePullBackOff 상태로 Pending, kubectl describe pod에서 반복적인 Back-off pulling image 이벤트를 확인하였다. ImagePullBackOff는 원인이 다양하기 때문에 먼저 아래 항목을 확인했다.Deployment에 imagePullSecrets가 설정되어 있는가?spec.template.spec.imagePullSecrets에 regcred가 있어야 함.Secret(regcred)이 올바른 네임스페이스에 있는가?Pod와 Secret은 동일 namespace여야 함.Secret 내부 .dockerconfigjson 구조가 정확한가?auths에 레지스트리 도메인이 정확히 들어가 있어야 ..

잘 동작중이던 GitHub Action이 오늘 갑자기 아래와 같은이유로 실패를 하였다.#0 building with "default" instance using docker driver#1 [internal] load build definition from Dockerfile#1 transferring dockerfile: 188B done#1 DONE 0.0s#2 [internal] load metadata for docker.io/library/openjdk:17-jdk#2 ...#3 [auth] library/openjdk:pull token for registry-1.docker.io#3 DONE 0.0s#2 [internal] load metadata for docker.io/library/op..

📌 문제 상황RDS에서 slow_query_log를 켜둔 상태였는데, 로그가 수만 건 이상 쌓여 관리가 어려워짐로그를 직접 보면 조건값이 조금씩 달라서 전부 다른 쿼리처럼 보임실제로는 같은 쿼리 패턴인데 단순 값 차이 때문에 중복 로그처럼 쌓이고 있었음즉, 비슷한 쿼리를 묶어서 패턴화하지 않으면 개선 포인트를 찾기 어려운 상황 📌 해결 방법저는 크게 두 가지 단계를 거쳐 문제를 해결했습니다.로그 파일 다운로드AWS Console에서 RDS 인스턴스를 선택하고 '로그 및 이벤트' 탭으로 이동slowquery/mysql-slowquery.log 파일을 다운로드로그 분석Percona Toolkit의 pt-query-digest를 이용해 쿼리를 패턴화 & 집계상위 몇 개의 문제 쿼리만 집중적으로 튜닝 📌 ..

📌 문제 상황우리 서비스에서는 메인 배너, 서브 배너, 카테고리 등과 같이 자주 변하지 않는 데이터를 계속해서 조회하는 문제가 있었습니다.예를 들어, 메인 페이지에 들어올 때마다 DB에서 배너 정보를 매번 조회한다면,불필요하게 DB 부하가 커지고,트래픽이 많을 경우 성능 저하로 이어질 수 있습니다.특히 배너나 카테고리처럼 한 번 가져오면 크게 변하지 않는 데이터를 매번 불러오는 건 낭비에 가까웠습니다. 📌 해결 방법: 스프링부트 캐시 도입이 문제를 해결하기 위해 선택한 방법은 Spring Boot의 캐시(Cache) 기능이었습니다.스프링 캐시는 단순히 @Cacheable, @CacheEvict 등의 어노테이션만으로 손쉽게 적용할 수 있습니다.@Cacheable → 캐시에 값이 없을 경우 메서드를 실행..

Firebase를 이용한 서비스에서 데이터베이스를 MySQL로 마이그레이션하는 과정은 효율적인 데이터 동기화가 핵심입니다. 특히 Firebase Functions의 onWrite 트리거를 사용하여 Firestore 데이터를 MySQL로 실시간 동기화할 때, 대규모 데이터 업데이트는 예상치 못한 Too Many Connections 오류를 유발할 수 있었습니다. 본 글에서는 마이그레이션 과정에서 겪었던 이러한 문제 상황과 그 해결 과정을 공유합니다.문제 상황: 베스트 리뷰 선정과 대규모 onWrite 트리거저희 서비스에는 특정 리뷰를 '베스트 리뷰'로 설정하는 기능이 있습니다. 이 기능은 다음과 같은 로직으로 작동하도록 설계되었습니다.특정 리뷰를 베스트 리뷰로 설정하게되면 해당 리뷰의 today_index..

제가 운영 중인 AWS EC2 인스턴스는 메모리와 디스크 상황이 다음과 같습니다.df -h/dev/root 30G 25G 4.8G 84% /free -h total used free shared buff/cache availableMem: 3.8Gi 3.0Gi 127Mi 9.0Mi 705Mi 557MiSwap: 2.0Gi 2.0Gi 40Mi 디스크 사용량: 30GB 중 25GB 사용 (84%) → 여유가 크진 않음메모리: 3.8GiB 중 3.0GiB 사용, swap 2GiB 거의 다 사용 중사용 가능한 메모리: 557..

1️⃣ JMeter 설치JMeter 최신 버전 다운로드https://jmeter.apache.org/download_jmeter.cgi Apache JMeter - Download Apache JMeterDownload Apache JMeter We recommend you use a mirror to download our release builds, but you must verify the integrity of the downloaded files using signatures downloaded from our main distribution directories. Recent releases (48 hours) may not yet be avajmeter.apache.org 압축 해제 후 bi..