최근 AWS에서 백엔드 배포를 수행하던 중, 문제가 있었다. 진짜 너무너무 싫은 오류... 확인해보니, Target Group에 연결한 인스턴스에 대한 Health Check가 실패하여, 위와 같은 오류가 발생하는 것이었다. ✅ 현재 상황보안을 위해 private subnet 내의 EC2 인스턴스에서 스프링 프로젝트를 구동 중EC2 인스턴스의 보안 그룹 (ssh, source: public subent의 IP CIDR) 현재 내가 구성한 아키텍처는 다음과 같다. ✅ 원인 분석curl http://localhost:8080/health (헬스체크 경로)로 확인하면 OK 응답이 나옴. = 프로젝트 이상 없음 따라서, ALB가 보내는 헬스체크 요청을 EC2가 받을 수 없는 상황임이 가장 유력한 이유였다. 정리..

열심히 구성을 다 하고 뿌듯한 마음으로 ALB의 엔드포인트로 연결을 했는데 안된다....... 타겟그룹도 healthy고 서비스도 제대로 다 떠있는데 처음엔 뭐가 문제인지를 몰랐다.세상이 날 억까하는줄.. 찾아보니, 로드밸런서에는 2가지 타입이 있다고 한다. Internal ALBVPC 내부에서만 접근 가능 (인터넷 안됨) ❌Internet-facing ALB외부에서 도메인/IP로 직접 접근 가능 ✅ 즉, 웹브라우저를 통해 ALB로 접속할 수 있으려면 internet-facing ALB를 사용해야한다. 로드밸런서의 엔드포인트 주소로도 보이긴하지만, 로드밸런서의 체계(schema)를 확인해보니 역시 internal로 되어있었다. 따라서 현재 ALB가 아닌 internet-facing alb로 교체해야한다...

1. Artillery란?(Aritllery 로 부하테스트를 진행한 이유 + 웹에서 리포트 및 그래프 확인 가능) 2. Artillery 설치 및 yml 작성sudo apt updatesudo apt install nodejs npm -ysudo npm install -g artillery 설치가 완료되면, 다음 명령어를 통해 설치를 확인할 수 있다.npx artiller --version artillery를 사용하기 위한 load-test.yml파일 작성한다. 테스트 환경에 따라 arrivalRate를 변경해가며 사용한다.config: target: "[부하를 보낼 ALB/인스턴스 주소]:[포트번호]" phases: - duration: 60 # 테스트 시간: 60초 ..

현재 프리티어를 사용해서 프로젝트를 진행중인데, EC2에서 자꾸 CPU 100%를 찍는 문제가 발생했었다.이렇게 되면 서비스가 아예 죽거나, 상태검사에서 통과하지 못해 ssh 접속이 아예 안된다는 문제가 있었다.문제를 해결하려 방법을 찾아보던중, SWAP 메모리를 추가해 메모리 공간을 추가해줄 수 있다는 블로그 글을 발견했다. 1. Swap 메모리?Swap 메모리는 리눅스 시스템에서 물리적 메모리(RAM)가 부족할 때를 대비한 가상 메모리 공간이다. 따라서 RAM이 부족할 때 디스크에 데이터를 임시 저장하여, 시스템이 계속 동작할 수 있도록 도와주는 보조 메모리 공간이라고 할 수 있다. 스왑의 동작 원리는 다음과 같다.사용 중인 RAM이 가득 차면,리눅스 커널은 덜 자주 쓰이는 메모리 페이지를 디스크에 ..

대용량 트래픽을 처리하기 위해서는 AutoScaling이 필요하고, 부하를 분산시켜주기 위한 로드밸런서도 필요하는 사실을 알고 있었다. 하지만 실습을 통해 이를 실제로 만들다 보니, 구현하기 위해 필요한 서비스들이 더 많았고 처음보는 개념도 있었다. 0. 전체 구조 설명 Elastic Load Balancer (ELB)외부/내부에서 들어오는 트래픽을 한 개의 엔드포인트를 통해 수신한다.트래픽을 여러 EC2 인스턴스 등에 자동으로 분산할 수 있도록 한다.로드밸런싱 알고리즘에 따라 트래픽을 Target Group으로 전달한다.Target GroupELB와 실제 EC2 인스턴스 사이를 연결하는 중간 매개체실제 트래픽을 전달할 대상(EC2 인스턴스, Lambda 함수, IP 등)의 목록을 관리하고, 상태를 감..

1. 로드밸런싱AWS에는 두가지 종류의 로드밸런서가 존재한다.1.1 ALB vs NLBALB(Application Load Balancing) ➡️ L7애플리케이션 계층에서의 요청을 분석HTTP, HTTPS 트래픽을 이해하고, URL, 쿠키, 쿼리 문자열 등을 기반으로 라우팅 가능어플리케이션 데이터 분석 필요 -> 부하 발생으로 상대적으로 느림NLB(Network Load Balancin) ➡️ L4네트워크 계층에서 패킷을 그대로 전달IP 주소와 포트 기반으로 트래픽을 분배개별 요청을 분석하지 않고, 연결(TCP/UDP) 자체를 로드밸런싱패킷을 가공하지 않고 그대로 전달 -> 속도가 빠름✅ Spring 어플리케이션을 AWS에 올려서 사용하는 것이므로, ALB가 적합하다! 1.2 로드밸런서의 구성요소리스너..