[eks, fargate, sagemaker] 2. Microservices 파트 구축 - Microservices구축시 EKS 와 Serverless 비교 및 Machine Learning Service 확장 프로젝트

2.4 구축

 

2.4.1 개발

[개발 환경]

Microservices, Web

Language	Java
Framework	Spring Boot
IDE	Intelli J
Tools	Postman, VMware
VCS	Git

 

App

Language	Java
Framework	Android
IDE	Android Studio
Tools	Postman
VCS	Git

 

[개발 내용]

APP

안드로이드 프레임워크 기반 APP으로 예약 서비스를 위해 microservices와 REST 통신

WEB

Spring Boot 프레임워크 기반 WEB Front로 설문 서비스를 위해 microservices와 REST 통신

Microservices

Spring Boot 프레임워크 기반 backend로 app과 web에 REST URL endpoint를 제공

 

 

 

2.4.2 On-premise 테스트

On-premise 테스트는 kubernetes의 아키텍처를 이해하고 개발된 microservices의 운영 테스트 를 하는데 목적을 두었고 총 3단계로 진행했다.

1. kubeadm으로 centos7 환경에서 kubernetes의 마스터 노드와 작업 노드 클러스터를 구축.

2. 각 microservices의 kubernetes구성에 따라 yaml파일 만들고 kubectl을 통해 배포.

3. 각 microservices의 서비스가 정상 작동하는지 확인.

[kubeadm을 통한 클러스터 생성]

kubeadm을 통해 클러스터 구축을 했으며, [그림 2.4-1]과 같이 마스터 노드에서 클러스터를 초 기화하는 단계, 작업 노드에서 마스터 노드에 가입하는 단계를 거쳤다. 정상적으로 클러스터가 구 축되어 kubectl 명령을 통해 가입된 노드가 확인되었다.

[그림 2.4-1]

[kubectl을 통한 배포]

kubernetes 아키텍처와 운영 계획에 따라 yaml파일을 만들고 kubectl을 통해 각 microservices 를 생성하였고 각 서비스가 배포되는 것을 [그림 2.4-2]와 같이 확인하였다.

[그림 2.4-2]

외부 접속 테스트를 위해 각 microservices는 nodeport로 서비스되도록 구성했고 API 요청을 통해 [그림 2.4-3]과 같이 서비스가 정상 작동하는 것을 확인했다.

[그림 2.4-3]

[서비스 동작 확인]

모든 microservice가 kubernetes에 구축된 후 각 서비스가 유기적으로 동작하는 지 확인하기 위해 클라이언트를 통해 서비스 동작 테스트를 진행했다. [그림 2.4-4]는 안드로이드 app에서 레 스토랑을 선택하여 예약을 진행하는 부분이고, [그림 2.4-5]는 설문조사를 위한 push 메시지가 왔 을 때 web browser를 통해 설문조사를 진행하는 부분이다.

[그림 2.4-4]

[그림 2.4-5]

2.4.3 AWS EKS 구축

EKS 구축은 총 3단계로 구축과 운영의 방법을 파악하는 것을 목적으로 진행했다.

1. AWS Console을 통해 EKS 클러스터를 생성.

2. awscli로 EKS 클러스터에 접근할 수 있도록 설정 및 kubectl을 통해 microservices를 배포.

3. 서비스가 제대로 동작하는지 확인.

 

EKS 클러스터가 정상적으로 만들어진 후 Amazon Container Services에서 [Amazon EKS] – [Clusters] 부분에서 [그림 2.4-6]과 같이 생성된 클러스터를 확인한다.

[그림 2.4-7]처럼 aws cli, kubectl, aws-iam-authenticator가 작동가능한 환경에서 이미 만들어진 yaml 파일을 kubectl을 적용하여 각종 kubernetes 오브젝트들을 생성하였다.

[서비스 동작 확인]

4개의 다른 NLB의 endpoint에 8080 port로 요청하여 확인한 결과 모든 서비스들이 정상 작동 하는 것을 볼 수 있다.

[그림 2.4-8 Information Service]

 

[그림 2.4-9 Book Service]

 

[그림 2.4-10 Survey Service]

 

[그림 2.4-11 Push Service]

 

2.4.4 AWS Fargate 구축

Fargate는 ECS 클러스터 생성, 작업 정의 생성, 서비스 생성의 단계로 구축과 운영의 방법을 파악하는 것을 목적 진행하였다.

[그림 2.4-6]은 생성한 클러스터의 상세 현황이고 [그림 2.4-7]은 작업 정의 리스트이다.

서비스가 정상적으로 생성되어 [그림 2.4-8]처럼 상태가 ACTIVE인 것을 볼 수 있다.

[그림 2.4-8 서비스]

[서비스 동작 확인]

ELB의 endpoint에 mapping된 각 port로 요청하여 확인한 결과 모든 서비스들이 정상 작동하는 것을 볼 수 있다.

[그림 2.4-9 Information Service]

 

[그림 2.4-10 Book Service]

 

[그림 2.4-11 Survey Service]

 

[그림 2.4-12 Push Service]

 

 

2.4.5 부하테스트

[시나리오]

전체 사용자	1만
점심과 저녁 제외 평균	100명
점심(동시접속자)	3000명
저녁(동시접속자)	4000명
일 평균 예약자	7000명

[표 2.4-1]

최대 동시 접속자 수인 4000명에 대한 부하를 견딜 수 있는 resource를 선택하기 위해 낮은 resource 부터 점차 늘려가며 부하테스트를 통해 최적의 resource를 찾는다

 

[목표]

resource에 따른 부하 내성을 파악하고 AWS 설계 시 적절한 Instance의 size를 선택하는 것.

 

[부하 테스트 환경 구축]

요청수 설정

Jmeter를 사용하여 부하를 테스트한다. 한 PC에서 Thread를 1000개를 초과하여 발생시키는 경우 성능의 문제로 원활하게 진행되지 않아 4개의 PC에서 각각 1000개의 Thread를 발생시켰 다. Thread의 자세한 설정은 [그림 2.4.4-1]과 같다.

[그림 2.4.4-1]

요청 경로 설정

가장 많은 Traffic이 발생되는 지점에 부하를 발생시켜 병목 현상이 발생하는지 여부 파악. 부하 발생 대상 설정은 [그림 2.3.4-2]와 같다.

[그림 2.4.4-2]

응답 모니터링 설정

[그림 2.3.4-3]과 같이 Summary Report를 이용하여 평균 사용자 경험시간과 Error 확률을 파악한다.

[그림 2.4.4-3]

 

[단일 서버에 대한 부하 테스트]

 AWS ECS서비스의 Fargate에 배포한 service를 대상으로 위에서 설정한 부하테스트 환경을 이 용해 테스트를 진행한다.

 

1차 부하 테스트 결과는 [그림 2.4.4-4]와 [그림 2.4.4-5] 및 [표 2.4-2]를 통해 볼 수 있다.

 

차수	Cpu	Ram	CPU / Ram 사용량(%)
1차	0.5	1GB	100 / 88

[표 2.4-2]

 

2차 부하 테스트 결과는 [그림 2.4.4-6]와 [그림 2.4.4-7] 및 [표 2.4-3]를 통해 볼 수 있다.

 

 

차수	Cpu	Ram	CPU / Ram 사용량(%)
2차	0.5	2GB	100 / 45

[표 2.4-3]

 

3차 부하 테스트 결과는 [그림 2.4.4-8]와 [그림 2.4.4-9] 및 [표 2.4-4]를 통해 볼 수 있다.

 

차수	Cpu	Ram	CPU / Ram 사용량(%)
3차	1	2GB	80 / 45

[표 2.4-4]

 

4차 부하 테스트 결과는 [그림 2.4.4-10]와 [그림 2.4.4-11] 및 [표 2.4-5]를 통해 볼 수 있다.

차수	Cpu	Ram	CPU / Ram 사용량(%)
4차	2	4GB	60 / 15

[표 2.4-5]

 

 

 

[테스트 결과]

0.5 CPU, 1GB Memory 사용시 두 Resource의 사용률이 모두 매우 높았다. 2차 테스트시 Ram 을 2배로 늘려 테스트한 결과 Ram 사용률이 45%정도로 안정되었음을 알 수 있다. 3차 테스트시 CPU를 2배로 늘려 테스트한 결과 CPU사용률이 80%정도로 안정되었다. 마지막 4차 테스트로 2 CPU, 4GB로 테스트한 결과 두 Resource의 사용량이 매우 낮아졌다. 테스트 결과는 [표 2.4-2] 과 같다.

 

차수	Cpu	Ram	CPU / Ram 사용량(%)
1차	0.5	1GB	100 / 88
2차	0.5	2GB	100 / 45
3차	1	2GB	80 / 45
4차	2	4GB	60 / 15

[표 2.4-2]