목차
Chaos Monkey 소개
JUnit 챕터에서 프로젝트의 단위및 인수테스트를 위한 라이브러리의 사용법과 각각의 메서드들이 의도한대로동작하는지를 테스트하는 방법을 익혔고, Testcontainer를 통해 가상화 컨테이너환경구성, 그리고 JMeter 도구를 사용해서 성능테스트 방법을 학습했다.
다양한 성능 테스트중 HTTP API 성능 테스트 위주로 진행을하며 API요청을 해보았는데, 이번 챕터에서는 운영 이슈 테스트를 학습할 것이다. HTTP API 요청을 할 때 늘 같은 인터넷 속도와 환경, 그리고 서버의 메모리상태와 동시 접속하는 사용자는 늘 달라진다. 그렇게 다음과 같은 운영 환경 문제가 발생할 수 있다.
•
네트워크 지연
•
서버 장애
•
디스크 오작동
•
메모리 누수
이러한 이슈들은 아주 자주 발생하지는 않고 간혹가다 한 번씩 발생을하지만, 발생했을 때의 여파는 매우 크다.
이렇게 생기는 문제들을 카오스(Chaos)라 하는데, 이런 이슈를 핸들링하는 방법을 카오스 엔지니어링이라 한다.
그리고 이런 카오스 엔지니어링을 도와주는 툴들이 있는데, 대표적으로 넷플릭스에서 만든 Chaos Monkey라는 툴이 있다.
참고: 카오스 엔지니어링 툴넷플릭스의 카오스 엔지니어링을 설명하기 위한 기본 원칙을 담고 있는 책의 번역본
이번 포스팅에서는 Chaos Monkey for Spring Boot를 사용해서 카오스 엔지니어링을 해 볼 것인데, 다음과 같은 애노테이션이 붙어있는 빈(bean)들에 접근제어자가 public인 경우 다음과 같은 공격을 할 수 있으며, Chaos Monkey를 사용해 공격을 해서 카오스 엔지니어링을 진행해볼 것이다.
공격 대상(Watcher)
•
@RestController
•
@Controller
•
@Service
•
@Repository
•
@Component
공격 유형(Assaults)
•
응답 지연(Latency Assault)
•
예외 발생(Exception Assault)
•
애플리케이션 종료(AppKiller Assault)
•
메모리 누수(Memory Assault)
왜 이런 운영이슈 테스트를 해야할까?
테스트 대상 프로젝트에서 특정 레파지토리가 응답 지연이 발생한다면 해당 레파지토리를 사용하는 서비스나 컨트롤러도 같이 응답이 지연된다. 이런 상황들을 재연할 수 있다면, 우리는 개발단계에서 임의의 응답지연이나 문제가 이슈가 발생하는 대상을 찾을 수 있고, 문제가 없는 리포지토리로 바꾸거나 성능개선을 추구할 수 있다.
Chaos Monkey 설치
스프링부트 환경에서 Chaos Monkey 라이브러리 설치는 기타 다른 의존성을 추가하듯이 (메이븐 기준)pom.xml에 코드를 추가해주면 된다.
의존성 추가
<dependency>
<groupId>de.codecentric</groupId>
<artifactId>chaos-monkey-spring-boot</artifactId>
<version>2.1.1</version>
</dependency>
<dependency>
<groupId>org.springframework.boot</groupId>
<artifactId>spring-boot-starter-actuator</artifactId>
</dependency>
XML
복사
Chaos Monkey 활성화
의존성만 추가한다고 동작하지는 않고 설정파일(ex: application.properties)에 옵션을 넣어줘야 한다.
(vm 옵션으로 줄 수도 있다.)
spring.profiles.active=chaos-monkey
Groovy
복사
스프링 Actuator 엔드 포인트 활성화
management.endpoint.chaosmonkey.enabled=true
management.endpoints.web.exposure.include=health,info,chaosmonkey
Groovy
복사
참고: 스프링 부트 Actuator란?•
스프링 부트 운영 툴로, 런타임 중에 Chaos Monkey 설정을 변경할 수 있다.
•
그 밖에도 헬스 체크, 로그 레벨 변경, 매트릭스 데이터 조회 등 다양한 운영 툴로 사용이 가능하다
•
/actuator
CM4SB 응답 지연
CM4SB(Chaos Monkey For Spring Boot) 라이브러리를 이용해 응답지연 이슈를 재현시켜 확인해보자.
1. Repository Wathcer 활성화
우선 프로젝트 설정파일에서 @Repository 애노테이션에 대해 Watcher를 활성화시켜준다.
chaos.monkey.watcher.repository=true
Groovy
복사
⇒ 프로젝트에 repository를 응답지연 공격대상으로 지정해준다는 애노테이션이다.
2. Chaos Monkey 활성화
서버를 구동했다면 Chaos Monkey를 설치한 지금 기존의 study api를 제외하고 다음과 같은 api들이 추가되었을 것이다.
우선 status로 현재 Chaos Monkey의 공격상태유무를 확인해보면 다음과 같다.
•
localhost:8080/actuator/chaosmonkey/status → GET
⇒ 프로젝트 구동시에는 Chaos Monkey가 비활성화 되어있다. 이를 API 요청으로 활성화가 가능하다.
•
localhost:8080/actuator/chaosmonkey/enable → POST
이제 위와같이 활성화가 되었다면 제대로 활성화가 되었는지 확인을 해보자.
•
localhost:8080/actuator/chaosmonkey/status → GET
→ Chaos Monkey가 나쁜짓을 할 준비가 되었다고 알려준다. 즉 활성화가 되었다.
→ 이제 Chaos Monkey 지연 공격 설정 API를 보내서 아까 활성화한 레파지토리에 대해 응답이 지연되도록 한다.
•
localhost:8080/actuator/chaosmonkey/assaults level=3 latencyRangeStart=2000 latencyRangeEnd=5000 latencyActive=true → POST
→프로젝트에 레파지토리가 API 요청 3회마다 한 번씩 2~5초 응답지연이 되도록 공격설정을 해주는 API다.
→ 이를 GET 방식으로 보내면 현재 Chaos Monkey 공격 설정이 어떻게 구성되있는지 확인 가능하다.
⇒ 아까 보낸 API 요청대로 level, latencyRangeStart, latencyRangeEnd, latencyActive가 설정되어 있다.
이제 이전챕터에서 만든 JMeter 의 Study.jmx 파일을 이용해 정말 지연공격 설정이 적용됐는지 확인해보자.
공격 전 API 요청 결과
⇒ 평균 속도가 0.xxx초 정도로 요청/응답이 되고 있다.
공격 중 API 요청 결과
⇒ 평균 속도 1초 정도로 요청/응답이 되고있다.
⇒ 응답 지연이 제대로 되고 있다는걸 확인할 수 있다.
참고: watchers는 메서드 레벨단위로도 적용이 가능하다.
위 예제에서는 Repository의 모든 메서드에 대해 지연 설정을했는데, 커스타미이징을 통해 특정 메서드 레벨로 지연설정을 할 수 있다.
API or Properties 두 방법 모두 제공한다.
CM4SB 에러 발생시켜보기
CM4SB를 이용해 응답지연뿐아니라 예외도 발생시켜볼 수 있는데, 방법은 모두 지연방법과 동일한데, assaults 패스에서 exceptionsActive 옵션과, exception.type을 제공하면 된다.
에러 발생 재현 API
http POST localhost:8080/actuator/chaosmonkey/assaults level=3 latencyActive=false exceptionsActive=true exception.type=java.lang.RuntimeException
Bash
복사
⇒ 지연공격은 이제 필요없기에 latencyActive는 false로 설정한다.
⇒ exceptionsActive를 true로 하여 예외발생 공격을 하도록 한다.
⇒ exception.type 속성으로 내가 발생시킬 예외의 FQCN(Full Qualified Class Name)을 작성해서 보내준다.
JMeter 실행 결과
⇒ 요청/응답의 평균 속도는 다시 빨라졌지만 예외(Err)가 33%정도로 발생하고 있다.
위 이미지를 보면 8515번 시도해서 2889번 예외가 발생했다고 하고 있다.
