일 | 월 | 화 | 수 | 목 | 금 | 토 |
---|---|---|---|---|---|---|
1 | 2 | 3 | 4 | 5 | 6 | 7 |
8 | 9 | 10 | 11 | 12 | 13 | 14 |
15 | 16 | 17 | 18 | 19 | 20 | 21 |
22 | 23 | 24 | 25 | 26 | 27 | 28 |
29 | 30 | 31 |
- 후기
- 레디스
- 부트캠프
- 멘토링
- 자바백엔드
- EC2
- 알고리즘
- 데이터구조
- nGrinder
- MySQL
- github
- 백엔드
- AWS
- backend
- Flutter
- 자바
- 에프랩
- 트러블슈팅
- 코딩테스트
- grafana
- 플러터
- java
- 성능테스트
- 도커
- Spring
- 로드밸런서
- F-Lab
- redis
- FLAB
- error
- Today
- Total
민스씨의 일취일장
TIssue | EC2 내 컨테이너에서 로컬 PC로의 요청이 전달되지 않는 이슈 (feat. Public IP vs. Private IP) 본문
TIssue | EC2 내 컨테이너에서 로컬 PC로의 요청이 전달되지 않는 이슈 (feat. Public IP vs. Private IP)
읻민스 2024. 8. 14. 19:14EC 내 컨테이너에서 로컬 PC로 보낸 요청이 전달되지 않는 이슈에 대한 글입니다.
EC2에서 로컬 PC로 요청이 전달되지 않는 이슈
상황 1
nGrinder Agent를 EC2에 도커 컨테이너로 띄웠다. Agent는 작동하기 위해선 Controller의 신호를 받아야 한다. 따라서 성능 테스트를 진행하기 전에 Agent가 보내는 신호를 Controller가 수신하는 과정을 거쳐야 한다. 하지만 EC2 컨테이너로 구동된 Agent가 로컬 PC 컨테이너로 구동중인 Controller로 보낸 신호가 도달하지 않는 이슈가 발생했다.
원인 파악 과정 1 - 로컬테스트에서는 정상 작동
로컬환경에서 nGrinder Controller와 Agent를 연결했을 때는 정상적으로 작동했다. 똑같은 설정이 EC2로 Agent를 옮긴 후 작동되지 않는 다는 건 네트워크에 문제가 있다고 밖에 판단할 수 없었다.
원인 파악 과정 2 - 네트워크 점검
네트워크에 문제가 있다는 건 2가지 원인을 생각해 볼 수 있다.
1. IP를 잘못 작성했다.
로컬 환경에서 테스트 하던 IP를 복사해 간 것이기 때문에 잘못 작성할리가 없다.
2. Firewal(방화벽) 또는 Outbound 설정
로컬의 Firewall이 요청을 막고 있거나 EC2 보안그룹의 Outbound 설정이 트래픽을 제한하고 있을 수 있다. 하지만 둘 다 완전 개방돼있었기 때문에 해당 이슈는 아니였다.
원인 - Public IP vs. Private IP
멘토님께서 외부에서 접근이 안될 대는 공유기 IP를 살펴보라고 말씀해 주셨었다. 그래서 공유기 관리자 페이지에 들어가서 트래픽관리를 해보고 있었다. 이러던 차 정말 우연히 친구에게 연락이 왔고 친구와 이야기를 하면서 해결책을 찾게 되었다. IP라는 것이 Public IP와 Private IP로 나뉘어 있다고 한다. 실제 로컬 환경에서 사용하는 IP는 Private IP이며 외부에 공개하지도 않고, 외부에서 직접 이 IP를 통해 접근도 불가능하다. 외부에서 나의 네트워크 진입점으로 먼저 접근을 하면 공유기가 이 요청을 처리할 내부 IP로 매핑(포워딩)을 해준다. 따라서 로컬 내트워크에서 테스트할 땐 Private IP로 당연히 작동이 가능했던 것이고, 로컬 내트워크 밖에 위치한 EC2에서 Private IP로 시도한 요청은 올바른 위치를 찾을 수가 없었던 것이다.
해결책 - Public IP
Agent에서 연결할 IP주소를 공유기의 IP주소 즉, Public IP로 변경해준다! 그럼 연결이 이뤄지기 시작하는 걸 볼 수 있었다.
✅ Controller의 네트워크 외부에서 Agent 실행 시 연결할 IP는 Controller의 네트워크의 Public IP이다.
상황 2
EC2에서 구동중인 Agent가 로컬 PC로 보낸 요청이 가는 것은 확인이 됐다. 하지만 올바른 값이 반환돼 오지 않았다.
원인 파악 과정 - 포트번호
nGrinder를 Controller는 Agent를 이용해서 성능 테스트를 수행하면서 동시에 수행 결과를 수신해야 한다. 이런 작업이 병목현상없이 작동하기 위해 Controller는 다양한 포트를 사용한다.
80 : Controller 콘솔제 접속할 때 사용한다. UI 환경에서 Test Script를 작성하고, Test 분석 결과를 확인할 수 있다.
16001 : Agent로 지시를 보내는 포트이다.
12000~12009: Agent가 Controller의 지시를 수행해 서비스에서 수집한 결과를 수신한다.
이와 같은 포트의 용도를 이미 알고 있다.
해결책 - 연결확인은 기본 포트로
Agent는 Controller의 지시를 16001로 받아야 하니까, 당연히 16001포트로 연결을 시도해야 한다고 생각했다. 하지만 다양한 시도를 하던 끝에 가장 기본 포트인 80 포트 시도하니 정상적으로 연결이 되었다. 그리고 내부 메시지를 확인해 보니 내부에서 알아서 16001로 Controller와 소통했다.
✅ Agent에서 Controller와 연동할 때 시도해야할 포트는 80이다.
'Projects > MetaPay' 카테고리의 다른 글
Grafana | 성능 테스트 | 모니터링 | 필요한 지표들 선정한 뒤 그라파나 대시보드 생성하기 (0) | 2024.08.16 |
---|---|
성능 테스트 | 컨테이너 메모리 제한 설정 (0) | 2024.08.16 |
TIssue | Nginx | EC2 | 도커 컨테이너로 띄운 로드밸런서가 하나의 서버만 연결하는 이슈 (0) | 2024.08.14 |
VisualVM | Java 애플리케이션의 모니터링 도구 with Docker (0) | 2024.08.07 |
프로젝트 | PaymentService 만들며 익힌 기본기 - PR, 예외처리, Test Code, SRP (0) | 2024.07.24 |