테스트 (10) 썸네일형 리스트형 TCP/IP 애플리케이션 검증하기 # TCP/IP 애플리케이션 검증 - TCP/IP 애플리케이션을 내부에서 검증할일이 생겼다. 1. EC2 인스턴스로 서버 클라이언트 생성 - t3.small 정도 사양으로 일단 2개를 생성했다. 하나는 서버이고, 하나는 클라이언트. - 서브넷은 퍼블릭에만 물렸다. 2. 검증 (ping) - ping으로 일단 해당 서버까지 트래픽이 전달되는지 테스트 - 서버에서 클라이언트로, 클라이언트에서 서버로 ping 테스트를 진행 - 여기서 주의할 점은 보안 그룹에서 ICMP를 열어줘야 한다. 3. 검증 애플리케이션 작성 - JAVA가 제일 심플하니까, 검증 애플리케이션을 작성 후 jar로 빌드 실행하여 설정한 포트로 정상 커넥션이 되는지 테스트 4. 결과 기록 및 공유 - 자 ~ 잘 됩니다. 라고 결과를 팀원에게 .. TCP IP InputStream, OutputStream 테스트 with EKS 무식하면 용감하다고, ㅋㅋㅋ 로컬 환경에서 TCP/IP 테스트 한다고 별도의 애플리케이션으로 서버 클라이언트 만들고, 별도의 포트로 찌르고 받는거 테스트한다고 총 4개의 애플리케이션을 띄웠다. 이게 하나의 프로그램으로 끝낼수 있을거 같은데 시간이 없어서 그것까지는 못하겠고, 당장 지금 해야되니까 ㅋㅋㅋ 일단 논리적으로 당연히 가능하다고 생각은한다. 일단 하려는것은 아래와 같다.(대충 그려보자. 시간이 없으니께) 3분만에 완성된 플로우 일단, 하려는것은 아래와 같다. 간단히 설명하자면 하나의 파드에서 2개의 작업이 TCP/IP로 이루어 져야한다. 하나는 5000번으로 받는 InputStream이고 하나는 6300으로 보내는 OutPutStream 이다. 일단 현재는 하나씩 단방향으로 세팅을 했지만 결국 단.. TCP/IP 소켓 연결 테스트 소켓 서버는 EKS pod로 올려놓은 상태이고, NLB DNS로 찌를수 있게 구성해 놓은 상태이다. 간단하게 소켓 통신 테스트를 보면 아래와 같다. 서버는 항상 떠있는다. 클라이언트가 연결을 끊어도 서버는 항상 등대처럼 떠있어야 한다. 클라이언트는 재 접속이 가능해야한다. 소켓 끊고 연결이 자유로워야 한다. 테스트 결과를 보면 아래와 같다. 2초에 한번씩 코드를 찍고 클라이언트에서 연결을 해제해도 서버는 항상 떠있다. 그리고 해당 클라이언트가 재 접속 했을때 바로 커넥션을 맺는다. 2개의 서로다른 포트로 통신하는 소켓 프로그램을 eks pod로올려서 tgb를 통해 서비스 구성하기 내일 추가 테스트 계속... TargetGroup Unhealthy 해결하기 # Traget 그룹 Unhealthy 해결하기 1. 상태검사 상태검사 경로 체크 근데 하나는 healthy니까 상태경로 이상은 아니라고 판단 2. 컨테이너 포트 열렸는지 확인 문제의 원인이었다. 컨테이너 포트가 막혀있어서 발생한 문제였다. 그래서 eks pod에 포트를 추가해줬다. pod의 정보를 확인하면 아래와 같다. port 부분만 보자. 3개의 포트가 오픈 되어있는것을 확인 할수 있다. Ports: 6300/TCP, 8888/TCP, 5000/TCP 근데 위에 포트가 오픈되어 있다고 해도 Unhealthy가 날것이다. 왜냐면 해당 포트로 서비스를 하고 있는게 없기 때문이다. 대상그룹은 등록된 대상의 포트를 가지고 해당 애플리케이션의 포트를 찾는다. 대상 그룹에 등록된 포트로 커넥션 연결을 시도했을.. Jmeter로 부하를 발생시켜 쿠버네티스 hpa를 활성화, Scale-Out/In 과정을 살펴보자 # 테스트 구성도 1. 구성환경 설명 # 접속 환경 - 접속 URL : Nodeport로 구성되어 있으며, 접속 url은 [node의 ip주소]:[svc 서비스 포트] - MasterNode : 192.168.137.50:31048 > php/Apache 웹서버 (부하 발생시 해당 서버에 부하를 발생 시켜야 WorkerNode1,2번으로 LB가 됨.) - WorkerNode-01 : 192.168.137.105:31048 > php/Apache 웹서버 - WorkerNdoe-02 : 192.168.137.254:31048 > php/Apache 웹서버 # 부하 발생기 - Apache Jmeter tool 활용 (TPS 등 부하 테스트) # 웹서버 - pod nginx 3개 생성 # HPA 조건 - CPU.. Jmeter를 활용한 EC2 아파치 웹서버 부하 테스트 구현 # 작업순서 1. EC2생성 및 아파치 웹서버 설치 2. 오토스케일링 구현을 위한 클라우드 와치 지표 생성 3. 오토스케일링 그룹 생성 4. Jmeter를 활용하여 부하 발생 5. 테스트 수행 1. EC2생성 및 아파치 웹서버 설치 2021.10.24 - [AWS/EC2] - EC2 생성 EC2 생성 EC2 인스턴스 생성 1. 인스턴스 시작을 클릭하여 EC2 생성을 시작합니다. 2. 설치할 OS를 확인하고 선택을 클릭합니다. 3. 원하는 스펙을 선택하고 다음으로 넘어 갑니다. 4. 네트워크를 구성 후 다음 may9noy.tistory.com 2021.08.29 - [Applications] - EC2 인스턴스에 Apache 웹서버를 띄워보자 EC2 인스턴스에 Apache 웹서버를 띄워보자 1. 해당 인스.. Jmeter를 활용한 EC2 아파치 웹서버 부하 테스트 구성도 및 시나리오 # 부하 테스트 구성도 - 테스팅 시나리오 1. 접속자(부하)에서 Jmeter를 통해 부하를 발생 시킨다. 2. 아파치 웹서버는 단일서버로 구성되어 있으며, 80번 포트로 통신을 하다. - 이 아파치 웹서버가 모든 부하를 받는다. 3. Scale-In과 Scale-Out을 위해 클라우드 와치 지표를 활용한다. (예) 네트워크 트래픽이 10,000이상일때 Scale-Out 수행) 4. 클라우드와치 지표를 생성한다. 5. 로드밸런서와 타겟 그룹을 생성하고 오토스케일링 그룹과 연동한다. 6 오토스케일링 그룹을 생성한다. 7. 부하 테스트를 진행한다. 정상적으로 오토스케일링 정책이 적용되는지 확인한다. 8. Jmeter 리포터 도구를 활용하여 최종 부하 테스팅 리포트를 작성한다. EC2 인스턴스 + Jmeter 부하테스팅 (오토 스케일링) # Jmeter를 활용하여 부하테스트를 진행해보자. - 자동 스케일링이 되게끔 설정 - 일정수준 이상의 부하가 발생 시 스케일 아웃 발생 - 일정수준 이하의 부하가 발생 시 스케일 인 수행 2021.06.10 - [AWS/EC2] - Auto-Scaling 그룹을 생성해 보자. Auto-Scaling 그룹을 생성해 보자. # 시작 템플릿을 구성 # 오토스케일링 그룹 생성 - 오토스케일링을 수행할 인스턴스를 마우스 우클릭하여 이미지 및 템플릿에서 이미지를 생성한다. - 이미지 생성에 대한 기본적인 정보를 입력 may9noy.tistory.com 1. 생성된 오토스케일링 그룹 확인하기 - 최대 4개까지 자동적으로 생성이 가능한 스케일링 그룹을 생성 하였습니다. 오토 스케일링 발생 조건은 시작 템플릿으로 설정.. 이전 1 2 다음
