SW BBANG K

Lambda 함수가 Private Subnet에 있는 RDS 인스턴스에 연결되지 않는 상황은 생각보다 자주 발생한다. 'Lambda에서 Private RDS 연결'을 처음 구성할 때 가장 많이 놓치는 부분이 Lambda 자체에 VPC 설정을 붙여야 한다는 사실이다 — Lambda는 기본적으로 AWS 관리 네트워크에서 실행되기 때문에, VPC 내부 리소스에는 아예 도달할 수 없다. TL;DR — Lambda에서 Private RDS 연결 핵심 요약 항목 설명 Lambda VPC 설정 필요 여부 필수. Subnet ID와 Security Group ID를 Lambda에 지정해야 함 Lambda용 Subnet 선택 RDS와 동일한 VPC 내 Private Subnet (가용 영역 2개 이상 권장) Security Group 규칙 Lambda SG → RDS SG 인바운드 허용 (포트 3306/5432) 인터넷 액세스 필요 시 NAT Gateway 경유 라우팅 필요 (IGW 직접 연결 불가) IAM 권한 Lambda 실행 역할에 VPC ENI 생성 권한 필요 연결 진단 순서 VPC 설정 → SG 규칙 → Subnet 라우팅 → IAM → RDS 상태 Lambda가 Private RDS에 연결되는 원리 Lambda 함수는 기본 실행 환경에서 AWS 관리 네트워크에 위치한다. 이 상태에서는 퍼블릭 엔드포인트(S3, DynamoDB 등)에는 접근할 수 있지만, 고객 VPC 내부의 RDS처럼 프라이빗 리소스에는 네트워크 경로 자체가 없다. Lambda에 VPC 설정을 추가하면, AWS는 Lambda 실행 환경과 고객 VPC 사이에 Hyperplane ENI(Elastic Network Interface) 를 생성한다. 이 ENI가 지정한 Subnet에 배치되고, 지정한 Security...

RDS 인스턴스의 CPU와 커넥션 수가 치솟는데 슬로우 쿼리 로그를 열어보면 항상 같은 쿼리들이 반복해서 찍혀 있다. 상품 목록, 사용자 세션, 설정값처럼 데이터는 거의 바뀌지 않는데 매 요청마다 DB를 치고 있는 상황 — ElastiCache Redis를 캐시 레이어로 추가하는 것이 ElastiCache Redis 도입 의 가장 전형적인 시나리오다. TL;DR — ElastiCache Redis 도입 판단 기준 판단 항목 Redis 도입 적합 도입 불필요 동일 쿼리 반복 비율 전체 읽기의 30% 이상이 동일 키 대부분 유니크 쿼리 데이터 변경 주기 수 분 ~ 수 시간 단위 실시간 갱신 필수 RDS 병목 지점 읽기 쿼리 과부하 쓰기 병목, 스키마 문제 응답 지연 허용 범위 수십 ms 이내 목표 DB 직접 조회로 충분 캐시 일관성 요구 Eventually Consistent 허용 Strong Consistency 필수 ElastiCache Redis가 RDS 부하를 줄이는 원리 Redis는 인메모리 데이터 구조 저장소다. RDS가 디스크 I/O와 쿼리 파싱, 실행 계획 수립을 거쳐 결과를 반환하는 동안, Redis는 메모리에서 키-값을 직접 조회해 반환한다. 이 구조적 차이가 응답 속도 격차를 만든다. 캐시 히트 시 요청은 RDS에 도달하지 않는다. RDS 입장에서는 해당 쿼리가 존재하지 않는 것과 같다. 커넥션 풀 소모도 없고, 실행 계획 수립 비용도 없다. 트래픽이 몰리는 구간에서 RDS 커넥션 수가 안정적으로 유지되는 이유가 여기에 있다. graph LR App["애플리케이션 서버"] Redis["ElastiCache Redis"] RDS["Amazon RDS"] App -->|"① GE...

프로덕션 RDS 인스턴스를 처음 설정할 때 Multi-AZ 옵션을 보고 '이거 켜면 성능도 좋아지겠지?'라고 생각했다면, 그 가정이 장애 대응 중에 당신을 배신할 수 있다. Multi-AZ는 고가용성과 페일오버 를 위한 기능이지, 읽기 성능 향상을 위한 기능이 아니다. TL;DR: RDS Multi-AZ 핵심 요약 항목 Multi-AZ 동작 목적 고가용성 및 자동 페일오버 스탠바이 인스턴스 직접 접근 불가 (읽기/쓰기 모두 차단) 읽기 성능 향상 없음 — 읽기 스케일아웃은 Read Replica 사용 쓰기 성능 영향 동기 복제로 인한 소폭 지연 가능 페일오버 소요 시간 일반적으로 60~120초 (공식 보장 없음) 데이터 내구성 동기 복제로 RPO ≈ 0 자동 백업 스탠바이에서 수행 (프라이머리 I/O 영향 감소) RDS Multi-AZ가 실제로 하는 일 Multi-AZ를 활성화하면 AWS는 다른 가용 영역(AZ)에 스탠바이 인스턴스를 자동으로 프로비저닝한다. 프라이머리 인스턴스에 쓰기가 발생하면 Amazon RDS는 동기식 블록 수준 복제를 통해 스탠바이에 데이터를 미러링한다. 애플리케이션은 항상 프라이머리 엔드포인트 하나만 바라본다. 여기서 핵심은 동기(synchronous) 복제 라는 점이다. 프라이머리가 트랜잭션을 커밋하기 전에 스탠바이에도 기록이 완료되어야 한다. 이 구조 덕분에 페일오버 시 데이터 손실이 없지만, 반대로 스탠바이는 항상 '대기 중'이지 '서비스 중'이 아니다. graph LR App["애플리케이션"] -->|"단일 엔드포인트 (DNS)"| Primary["프라이머리 인스턴스 AZ-A"] Primary -->|"동기 ...