분류 전체보기 77

DBeaver에서 MySQL Dump 시 소켓 연결 오류 해결

DBeaver에서 MySQL Dump 시 소켓 연결 오류 해결DBeaver에서 SSH 터널링으로 Docker 위에서 동작하는 MySQL에 접속해 쿼리는 정상 작동하는데, Dump(Data Transfer/Export)만 실행하면 Can't connect to local MySQL server through socket 오류가 발생하는 경우의 해결 방법을 정리합니다. 원인DBeaver가 AWS EC2에 있는 MySQL에 접속할 때, 직접 접속(3306 포트 개방)이 막혀 있다면 SSH 터널링을 사용합니다.이때 데이터의 흐름은 다음과 같습니다.DBeaver가 SSH 접속을 통해 EC2와 연결을 맺습니다.DBeaver는 로컬 Mac의 특정 포트(예: 37492)를 리스닝(Listening) 상태로 엽니다.사용..

DB 2026.01.29

bluegreen-배포-환경에서-prometheus-메트릭이-끊겨-보이던-이유와-해결-방법

Blue/Green 배포 환경에서 Prometheus 메트릭이 끊겨 보이던 이유와 해결 방법Blue/Green 배포 환경에서 Prometheus의 target을 인스턴스 기준으로 설정한 상태에서 모니터링을 하다 보니, Grafana 그래프가 배포 시점마다 끊겨 보이는 문제가 발생했습니다.현재 Spring Boot + Actuator를 사용해 메트릭을 노출하고, Prometheus와 Grafana를 통해 이를 모니터링하고 있습니다.서비스는 Blue/Green 배포 방식으로 운영 중이며, 배포 시점에 따라 Spring Boot 인스턴스가 blue 또는 green으로 전환되는 구조입니다. 문제는 Prometheus가 특정 시점에는 dev-blue 인스턴스를 바라보다가, 배포 이후에는 dev-green 인스턴스..

인프라 2026.01.02

Grafana 및 prometheus 활용 #2

Grafana 및 prometheus 활용 #2본 글에서는 Grafana와 Prometheus를 연결하는 방법과, 실제 모니터링에 바로 사용할 수 있는 대시보드 템플릿 적용 방법에 대해 다뤄보겠습니다. 1. Prometheus 데이터 소스 추가Grafana에서 Prometheus 메트릭을 조회하려면, 먼저 Prometheus를 Data Source로 등록해야 합니다.Grafana에 접속한 후 아래 메뉴로 이동합니다.Connections → Data sources 1.1 Prometheus 컨테이너 이름 확인현재 docker-compose를 통해 실행 중인 컨테이너는 다음과 같습니다.docker-compose를 사용하는 경우, 같은 네트워크에 속한 컨테이너들은 서비스 이름을 hostname으로 사용할 수 ..

인프라 2025.12.31

Grafana 및 prometheus 활용 #1

Grafana 및 prometheus 활용 #1본 글에서는 Spring Boot 애플리케이션에서 Actuator와 Micrometer를 활용해 메트릭을 노출하고Prometheus로 이를 수집한 뒤 Grafana를 통해 시각화하는 전체 흐름을 구성하는 방법을 설명합니다. Spring Actuator + Prometheus + GrafanaSpring BootActuator와 Micrometer를 통해 애플리케이션 내부 메트릭을 생성합니다.생성된 메트릭은 HTTP 엔드포인트 를 통해 외부에 노출됩니다.Prometheus노출된 메트릭 엔드포인트를 주기적으로 pull 방식으로 scrape합니다.GrafanaPrometheus를 데이터 소스로 사용합니다.수집된 메트릭을 대시보드 형태로 시각화하여, 시스템 상태를 ..

인프라 2025.12.31

cross-origin 환경에서 쿠키 전송이 실패하는 이유

cross-origin 환경에서 쿠키 전송이 실패하는 이유웹에서 쿠키 기반 인증을 구현하다 보면, 분명 서버에서는 쿠키를 내려주고 있는데 클라이언트 요청에는 쿠키가 포함되지 않는 상황을 종종 마주하게 됩니다.이 문서는 이러한 문제를 겪으면서 정리한 내용으로, same-site, same-origin, withCredentials 개념을 쿠키 전송 관점에서 정리해보겠습니다. 1. Same-Site 란 무엇인가1.1 정의Same-Site는 현재 요청을 보내는 origin을 기준으로, 해당 요청이 같은 사이트(site) 에서 발생했는지를 판단하기 위한 개념입니다.여기서 site는 Schemeful Same-Site 기준에 따라 다음 요소로 판단합니다.scheme + registrable domain 기준 Or..

네트워크 2025.12.29

CloudWatch Logs 를 통해 로그 수집하기

CloudWatch Logs개요기존 프로젝트에서는 ELK(Stack) 기반으로 로그를 수집·분석했습니다. 하지만 새로운 프로젝트에서는 운영 복잡도 증가와 비용 부담을 고려하여 CloudWatch Logs + Log Insights 기반으로 로그 시스템을 구성했습니다.CloudWatch Logs는 AWS 네이티브 서비스로, 인프라 관리 부담을 줄이면서도 충분한 로그 수집 및 분석 기능을 제공합니다.CloudWatch 로그 흐름Application Log (file) ↓CloudWatch Agent (tail) ↓CloudWatch Logs (Log Group / Log Stream) ↓CloudWatch Log Insights장점AWS 네이티브 환경으로 권한, 보안, 비용 관리가 일원화됩니다.단..

AWS 2025.12.26

CloudFormation을 활용한 이미지 변환 및 리사이징

CloudFormation 을 사용한 이미지 변환 및 리사이징기존엔 프론트 단에서 이미지를 압축한후 S3 로 이미지를 업로드그후 CloudFront 를 통하여 캐싱된 이미지를 가져오는 방식을 사용했습니다.해당 방식을 사용하다 발생한 문제는 프론트 단에서 이미지를 압축하는데 리소스가 든다는 것이었고, 그렇다고 서버측에서 이미지를 바이너리 형태로 받아, 압축하는것또한 서버측 부담이 커져 AWS 에서 제공하는 CloudFormation 을 통해 해당 문제를 해결했습니다. CloudFormation을 이용하면 AWS에서 제공하는 Serverless Image Handler 스택을 한 번에 배포할 수 있습니다.이 스택은 다음과 같은 주요 기능을 제공합니다.온디맨드(On-demand) 이미지 리사이징이미지를 “업로..

AWS 2025.11.18

Flyway 사용법 (#2)

Flyway 사용법 (#2)Flyway 사용법 (#1) 에서 대략적인 Flyway 사용방법을 다뤄 봤습니다.이번 글에서는 Flyway 사용 중 자주 발생하는 문제와 해결 방법을 정리합니다. SQL 파일과 Entity 의 불일치 문제Flyway SQL 파일이 무한히 늘어나는 문제 1. SQL 파일과 Entity 의 불일치 문제1.1 문제 개요Flyway는 SQL 기반으로 DB 스키마를 관리합니다.하지만 JPA Entity는 코드 기반으로 스키마를 정의하기 때문에, 두 구조가 항상 일치한다는 보장이 없습니다. 1.2 ddl-auto: validate 설정Entity 구조가 DB 스키마와 일치하는지 자동으로 확인할 수 있습니다.spring: jpa: hibernate: ddl-auto: val..

Spring 2025.11.15

Spring WebSocket(STOMP) 통합 테스트 정리

Spring WebSocket(STOMP) 통합 테스트 정리 1. 통합 테스트를 결정한 이유WebSocket의 전반적인 흐름을 실제와 동일하게 검증하기 위해 통합 테스트 방식을 선택하였습니다.현재 STOMP 구조는 다음과 같습니다.StompDispatcher → 각 command에 맞는 handler → SEND의 경우 @MessageMapping이 선언된 단에서 처리이 흐름에서 최초 handshake 단계에서 사용자의 인증 및 인가 상태를 확인하며, 필요한 인가 정보는 session에 저장합니다.이후 각 command에 해당하는 handler는 handshake 과정에서 설정된 session 값을 활용하여 비즈니스 로직을 수행합니다.이러한 일련의 흐름은 단위 테스트로는 충분히 검증하기 어렵기 때문에, ..

Spring 2025.10.17

Flyway 사용법 (#1)

Flyway 사용법 (#1)지금까진 ERDCloud로 전체적인 DB 구조와 컬럼을 관리하고, 변경사항이 생기면 세 가지 단계를 거쳤습니다. 먼저 ERDCloud를 수정하고, 그다음 Spring Boot 코드(Entity)를 수정한 뒤, 마지막으로 DB에 직접 쿼리를 실행해 반영하는 방식이었습니다. 하지만 이 과정에는 몇 가지 문제가 있었습니다. 가장 큰 문제는 DB에 직접 쿼리를 날리는 시점과 실제 서비스 배포 시점이 정확히 맞아야 한다는 점이었습니다. 시점이 어긋나면 서비스가 정상적으로 동작하지 않을 위험이 있었습니다. 또한, Entity와 ERDCloud 간 불일치 문제가 자주 발생했습니다. 원래는 ERDCloud에서 DDL을 추출한 뒤, 그중에서 수정되거나 추가된 부분만 직접 쿼리로 DB에 적용하는..

Spring 2025.09.25