Chapter2 - CPU Bound 애플리케이션

• 안녕하세요~ 이전에 운영하던 블로그 및 GitHub, 공부 내용을 정리하는 Study-GitHub 가 있습니다!

• 네이버 블로그

• GitHub

• Study-GitHub

• 🐔

---

✔ CLASS101 백엔드 시스템 실무 - Chapter2 CPU Bound 애플리케이션

안녕하세요, 클래스101 백엔드 시스템 실무 강의를 듣고, 복습 차원으로 정리하여 남기려고 합니다! 혹시 문제가 된다면 글을 삭제하겠습니다 !!

 

class101.net/products/5fc4a3b4fc231b000d85661b

현직 대기업 개발자 푸와 함께하는 진짜 백엔드 시스템 실무!

---

 

 

✔ CPU를 극단적으로 사용하는 애플리케이션

프로그램과 프로세스의 차이 ?

• 애플리케이션은 일반적으로 하드디스크에 저장되어 있는데, 이것을 프로그램이라고 합니다.

• 하드디스크에 있는 프로그램을 실행시키면, 이 프로그램의 내용은 메모리 위에 올라가고 이것을 프로세스라고 합니다.

• I/O 연산을 적게하고, CPU 연산을 많이 사용하는 애플리케이션 => CPU를 특별히 많이 사용하는 애플리케이션

    • Hash(MD5 Hash)를 통해 CPU 연산을 높이도록 합니다.

 

 

아래의 사이트에서 Spring Boot 프로젝트를 Clone 합니다.

github.com/lleellee0/cpu-bound-application

 

 

* DataTypeConverter 클래스를 찾을 수 없는 오류가 나와서 pom.xml에 의존성을 추가했습니다.

		<dependency>
			<groupId>javax.xml.bind</groupId>
			<artifactId>jaxb-api</artifactId>
			<version>2.3.1</version>
		</dependency>

 

 

 

스프링 부트를 실행하고, localhost:80/hash/123 URL로 접근했을 때, 문자열이 출력되면 정상 결과입니다.

 

✔ Spring Boot 프로젝트를 GCP에 배포하기

Spring Boot 프로젝트를 jar 파일로 생성합니다.

Maven > Lifecycle > deploy 더블 클릭

 

 

 

Maven 빌드는 실패하지만, jar 파일은 생성이 됩니다.

* jar 파일을 GitHub에 올리고, GCP가 GitHub의 파일을 받아가도록 하는 방식을 사용합니다.

 

 

 

 

GCP에서 새로운 인스턴스를 생성합니다.

이름, 리전(서울), 머신 유형(e2-micro), 부팅 디스크(CentOS 7), 방화벽(HTTP, HTTPS허용) 으로 수정하고 생성합니다.

 

 

인스턴스 생성이 완성되면 SSH로 연결해서 아래 명령어를 통해 wget과 Java를 설치합니다.(중간에 y를 입력합니다)

$ sudo yum install wget

$ sudo yum install java

 

 

설치가 끝나면 wget으로 GitHub에 올린 jar 파일을 다운 받습니다.

github.com/lleellee0/class101-files/blob/main/cpu-0.0.1-SNAPSHOT.jar

위 사이트에서 Download 버튼 우클릭 > 링크 주소 복사를 합니다.

 

 

그 후 SSH에서 wget을 통해 jar 파일을 다운 받습니다.

$ wget 링크 주소(URL)

 

 

 

 

그 후 Java로 jar 파일을 실행합니다.

$ sudo java -jar cpu-0.0.1-SNAPSHOT.jar

위와 같은 화면이 나타나면 스프링 부트가 정상적으로 실행이 된건데요,

GCP에서 인스턴스의 외부 IP/hash/{input} 으로 접근을 해봅니다.

 

 

 

정상적으로 접근이 됩니다. 😁

 

 

 

개발자 도구(F12) > Network > 새로고침 (HashController)

    • Time: 193 ms

 

 

개발자 도구(F12) > Network > 새로고침 (CpuApplication)

    • Time: 51 ms

 

 

대략 위의 결과를 봤을때, HashController의 시간(193ms) - CpuApplication의 시간(51ms) 의 결과인

140ms 정도가, MD5 Hash 를 100,000번 정도 수행하는 시간이라고 생각 할 수 있습니다.

---

 

 

 

 

✔ 스트레스 테스트 툴로 성능 측정하기(by Artillery)

• NodeJS 설치하기

nodejs.org/ko/

Node.js

NodeJS 설치 결과

 

 

 

• Visual Studio Code 실행

artillery-scripts 라는 폴더를 생성하고, 이 폴더를 열어줍니다.

(소문자로 생성했는데, 대문자로 나옵니다.)

 

 

 

•Artillery 실행

artillery.io/docs/guides/getting-started/installing-artillery.html#System-requirements

Installing Artillery | Artillery.io Documentation

 

 

 

 

Visual Studio Code에서 화면 상단 Terminal > New Terminal을 클릭합니다.

(단축키: Ctrl + Shift + `(숫자 1 좌측))

 

 

Terminal이 열리면 artillerty 을 실행합니다.

npm install -g artillery

 

 

Artillery 사이트에서 Core Concepts로 들어갑니다.

화면에서 내려가다보면 위와 같이 코드가 존재하는데요, 위 코드를 모두 복사 한 후

Visual Studio Code에서 yaml 파일을 만들고, 코드를 붙여넣기 합니다.

 

 

 

 

 

GCP cpu-instance-1 인스턴스에서 Spring Boot 애플리케이션을 다시 실행합니다.

 

 

 

 

Visual Studio Code에 작성한 yaml 파일을 위와 같이 수정합니다.

필요없는 부분은 모두 제거하고 target, phases, scenarios 부분만 수정합니다.

    • target: GCP의 외부 IP

    • phases: 테스트 성능 설정

    • scenarios: name 및 get방식의 url 설정

 

 

 

Visual Studio Code의 Terminal에서 artillery을 실행합니다.

 

 

위 과정이 끝나면 report.json 이라는 파일이 생성 됩니다.

 

 

위 json 파일을 html로 보기 위해 위 명령어를 실행합니다.

 

그럼 위와 같은 artillery의 report 화면이 실행이 됩니다.

 

 

Scenario counts에서 현재 yaml파일에 설정한 duration은 60, arrivalRate은 1이므로

60 번의 Request가 이루어진 걸 볼 수 있습니다.

 

 

chart에서 가장 중요한 그래프 중 하나인데요, yaml에 설정한 arrivalRate의 값을 증가시키면서 테스트를 하고,

처리할 수 없을때까지 실행하며 확인합니다.

---

 

✔ 고 사양의 CPU로 Scale-up 하기

고 사양의 CPU로 Scale-up을 통해 부하 테스트를 진행하겠습니다.

GCP에서 기존의 cpu-instance-1 인스턴스는 삭제하고 새로운 인스턴스를 생성합니다.

 

 

기존과 모두 동일하게 설정하고, 머신 유형은 e2-highcpu-8 로 설정하고 인스턴스를 생성합니다.

    • 이름: cpu-instance-1

    • 리전: asia-northeast3(서울)

    • 머신 유형: e2-highcpu-8

    • 부팅 디스크: CentOS 7

    •방화벽: HTTP, HTTPS 트래픽 허용

 

 

인스턴스가 생성되면 위에서 진행한 wget, Java 설치 및 jar 파일 실행을 동일하게 진행합니다.

 $ sudo yum install wget

 $ sudo yum install java

 

 

인스턴스의 외부 IP가 변경되었다면 cpu-test.yaml 파일에도 외부 IP를 수정합니다.

 

 

 

수정 후 artillery를 통해 스크립트를 실행합니다.

 

 

 

차트 페이지를 보기 위해서는 다음 명령어를 실행하시면 됩니다.

 

 

결과를 보면 확실히 고성능 CPU(highcpu-8) 이 latency time(지연 시간)이 짧은 걸 확인할 수 있습니다.

 

 

 

 

위 테스트 과정이 모두 끝나면 좀전에 생성한 GCP 인스턴스는 반드시 삭제를 하셔야 합니다.

(고성능 CPU 이므로 비용을 많이 차지합니다 !)

 

 

 

※ 예상 TPS보다 여유롭게 잡습니다.

※ API에 기대 Latency를 만족할 때까지 성능 테스트를 해야 합니다.

※ Scale-out을 해도 성능이 향상되지 않으면, 병목을 의심해봐야 합니다.(코드, I/O 등등)