IT (9) 썸네일형 리스트형 Spring Boot 서버를 AWS ECS Fargate로 배포하기 - Route 53 + ACM으로 HTTPS 적용 (3) 들어가며이전 글에서 ALB를 도입해 고정 DNS 주소를 확보했다. 하지만 아직 두 가지가 남아있다.http://springboot-alb-xxxxxxxxx.ap-northeast-2.elb.amazonaws.com 같은 긴 주소 대신 커스텀 도메인 사용HTTP가 아닌 HTTPS로 보안 통신이번 글에서는 ACM으로 SSL 인증서를 발급하고, Route 53으로 커스텀 도메인을 ALB에 연결한 뒤 HTTPS까지 적용하는 전 과정을 다룬다.전체 구조전체 순서1. ACM에서 SSL 인증서 발급2. Route 53 호스팅 영역 생성3. 외부 도메인 네임서버를 Route 53으로 변경4. ACM CNAME 레코드 Route 53에 자동 등록5. ALB에 HTTPS 443 리스너 추가6. Route 53에서 ALB로.. Spring Boot 서버를 AWS ECS Fargate로 배포하기 - ALB로 고정 도메인 연결 (2) 들어가며이전 글에서 Spring Boot 서버를 ECR + ECS Fargate로 배포하고 GitHub Actions CI/CD까지 연동했다.그런데 한 가지 문제가 있었다. ECS Fargate는 태스크가 재시작될 때마다 퍼블릭 IP가 바뀐다. 배포할 때마다 IP를 새로 확인해야 하고, 도메인 연결도 불가능한 구조다.이를 해결하기 위해 ALB(Application Load Balancer)를 도입했다. ALB는 고정 DNS 주소를 제공하고, 내부적으로 태스크 IP를 자동으로 추적해준다.왜 ALB인가?Fargate는 EC2와 달리 Elastic IP를 직접 붙일 수 없다. 퍼블릭 IP를 고정하려면 ALB가 유일한 현실적인 선택지다.항목퍼블릭 IP 직접 사용 ALB 사용IP 고정❌ 재시작 시 변경 ✅ DNS.. Spring Boot 서버를 AWS ECS Fargate로 배포하기 - ECR + ECS + GitHub Actions CI/CD 구축 (1) 들어가며기존에는 EC2에 직접 접속해서 Docker Compose로 컨테이너를 띄우는 방식으로 서버를 운영했다. 배포할 때마다 SSH로 접속해서 docker pull → docker-compose up 을 반복하는 게 번거로웠고, 서버가 죽어도 자동으로 재시작되지 않는 구조적인 문제가 있었다.이번에 ECR + ECS Fargate로 전환하면서 이 문제를 해결했다. ECS는 컨테이너가 죽으면 자동으로 재시작해주고, GitHub Actions와 연동하면 코드 푸시만으로 자동 배포까지 된다.전체 아키텍처1. ECR 리포지토리 생성ECR(Elastic Container Registry)은 AWS의 Docker 이미지 저장소다. Docker Hub 대신 ECR을 쓰는 이유는 AWS 서비스 간 연동이 쉽고, IAM.. Nginx Rate Limiting으로 DDoS 공격 막기 문제 상황서비스를 운영하다 보면 예상치 못한 트래픽 급증이나 악의적인 공격에 직면할 수 있다.실제로 우리 서비스도 특정 API 엔드포인트에 대량의 요청이 몰리면서 서버가 불안정해지는 경험을 했다.사진을 보면 같은 API에 대해 초당 수십 건의 요청이 들어오고 있었다. 정상적인 사용 패턴이 아닌 건 명백했다.이런 상황에서 가장 먼저 떠올릴 수 있는 해결책은 Cloudflare 같은 CDN/WAF 서비스를 도입하는 것이다. 하지만 지금 당장 문제를 해결해야 하는 상황이라면? Nginx의 Rate Limiting 기능을 활용하면 빠르게 대응할 수 있다.Rate Limiting이란?Rate Limiting은 특정 시간 동안 허용되는 요청 수를 제한하는 기법이다. 예를 들어:IP당 초당 10개 요청만 허용동시 접.. Spring CQRS 패턴 적용기 서비스 레이어 구조가 복잡해지면 유지보수가 어려워진다.특히 초기에는 단순한 CRUD 서비스가 충분하지만, 애플리케이션이 커질수록 서비스 클래스는 쉽게 비대해지고, 책임이 모호해짐.기존 MemberService를 리팩토링하면서 UseCase + Facade 패턴을 적용해 서비스 레이어를 명확하게 분리했다. 2025.11.21 - [IT/BE] - Spring 애플리케이션에 UseCase + Facade 패턴 적용하기 Spring 애플리케이션에 UseCase + Facade 패턴 적용하기기존 MemberService를 리팩토링하며 구조적 개선하기Spring 애플리케이션이 커질수록 가장 먼저 무너지는 부분이 바로 Service이다.초기에는 간단해서 큰 문제는 없지만, 기능이 늘어날수록 서비스는y22jun.ti.. Spring 애플리케이션에 UseCase + Facade 패턴 적용하기 기존 MemberService를 리팩토링하며 구조적 개선하기Spring 애플리케이션이 커질수록 가장 먼저 무너지는 부분이 바로 Service이다.초기에는 간단해서 큰 문제는 없지만, 기능이 늘어날수록 서비스는 아래와 같은 문제들을 품기 시작한다.❌ 1. 기존 MemberService의 문제점아래는 기존 MemberService의 일부이다.@RequiredArgsConstructor@Servicepublic class MemberService { private final MemberRepository memberRepository; private final PasswordEncoder passwordEncoder; private final CompanyRepository companyRepositor.. Spring N + 1 문제를 해결해보자 N + 1 문제란 무엇인가JPA를 사용할 때 가장 많이 겪는 성능 이슈 중 하나가 N + 1 문제이다이 문제는 연관된 엔티티를 LAZY 로딩 할 때 흔하게 발생하며, 한 번의 쿼리로 끝날 수 있는 작업이 불필요한 추가 쿼리(N번)를 실행하게 만든다.N + 1 문제의 기본 개념'1'첫 번째 쿼리-> 부모 엔티티 리스트를 가지고 오는 쿼리select * from member where company_id = 1;이 쿼리로 멤버 N명을 가져왔다고 가정'N'두 번째 단게-> LAZY 연관 관계를 호출할 때각 멤버마다 추가 쿼리가 실행되는 상황select * from company where id = ?;멤버 1명씩 가져올 때마다 회사 정보를 따로 조회하는 쿼리가 실행됨.즉첫 번째 쿼리 1번연관된 엔티티 쿼리 N.. 스프링부트 서버 과부화 테스트(2) EC2 프리티어 t2.micro 인스턴스를 활용해 서버 과부하 테스트를 먼저 진행해봤다. 실제 서비스 운영 환경에서는 프리티어 같은 초저사양을 사용할 일은 없겠지만, 서버의 성능 한계를 직접 체감하고, 이후 인스턴스 사양을 점진적으로 업그레이드해 가며 최적의 운영 환경을 찾아보기 위해 첫 단계로 프리티어 환경부터 시작했다. 앞으로 코드 개선과 인프라 업그레이드를 병행하며, 다양한 조건에서 서버의 안정성과 한계를 체계적으로 검증해볼 계획이다. 지난 결과를 요약하자면..EC2 프리티어 t2.micro 결과 요약테스트 환경: EC2 프리티어 t2.micro 인스턴스에서 296명의 동시 사용자, 총 12,545건 요청 처리 테스트 진행주요 성능 지표평균 TPS: 217.1, 피크 TPS: 350평균 응답 시간:.. 이전 1 2 다음
