[2018-05-08] 결제 시스템 성능, 부하, 스트레스 테스트

안녕하세요. 우아한형제들에서 결제시스템을 개발하고 있는 권용근입니다. 입사한 지 4개월 만에, 드디어 우아한형제들 기술 블로그에 글을 남기게 되어 감회가 새롭습니다.

저는 최근 결제 시스템의 개비를 진행하며 경험한 성능, 부하, 스트레스 테스트 경험을 작성해보려고 합니다.

시스템 개비

입사하고 보니 저에게는 결제 API 단순화, 결제 시스템 데이터베이스 분리 및 파티션 도입, 비동기 결제 시스템 개발 이라는 굵직굵직한 작업들이 기다리고 있었습니다.

Java, Spring Framework, ORM 등의 기술 지식은 그간 해온 게 있기 때문에 (구글링이 있기 때문에) 파악하는데 어렵지 않았지만, 이미 구축되어 있는 시스템을 손대는 것은 쉬운 일이 아니었습니다.

"거대 규모 프로젝트에서 내가 수정한 코드가 어떤 사이드 이펙트를 발생시킬지.."

이래서 존재하는 것이 바로 테스트 코드 !! 다행히 테스트 코드를 지향하는 프로젝트였기에 작성된 테스트의 보호 아래 신나게 개발을 할 수 있었습니다.

결국 테스트를 모두 통과시키며, 개발이 완료되었습니다!

그리고 이때부터 본격적인 미지의 영역에 대한 공포가 시작되었습니다.

공포의 시작

내가 만든 이 시스템은 실제 장비에서

• 어느 정도의 부하 를 견딜 수 있는가?
• 시스템(데이터베이스, 서버), 자원(cpu, disk, memory 등)에서 병목 이 생기진 않는가?
• 자원을 효율적 으로 사용하는가?
• 메모리 누수, 오류, 오버플로우 는 발생하지 않는가?
• 최악의 상황 에선 어떤 동작을 하는가? (예측하고 대비하기 위하여)
• 장애 조치와 복구 가 잘 동작을 하는가?

전혀 감이 안 잡혔습니다. 이것은 흔히 말하는 localhost:8080 레벨에서는 확인할 수 없는 문제였습니다.

위의 수많은 공포에 대하여, '내가 예상하는 데로', '내가 정의해놓은 데로, 작성해놓은 데로 잘 동작하겠지' 라고 믿을 수는 없었습니다. 호되게 당한 적도 있기도 하고, 실제 사용자의 돈이 움직이는 결제 시스템에서 전혀 보이지 않는 불안요소를 가지고 가기에는 너무나 두렵고 무서웠습니다.

그래서 테스트 코드가 두려움을 해소해줬듯, 이번에도 두려움을 해소해줄 성능 테스트 환경을 만들게 되었습니다.

---

테스트 환경

1. 외부 인터페이스 Mock 처리

결제 시스템은 사용자의 주문 비용을 각종 결제수단(PG사, 포인트, 쿠폰) 등의 시스템과 통신하여 지불처리하는 시스템입니다. 많은 부분을 생략하고 간단하게만 표현하면, 하나의 결제는 결제수단 시스템이란 외부 인터페이스를 거치게 됩니다.

그래서 저는 결제수단 시스템을 Mock 처리해야 했습니다. 온전히 테스트 대상 시스템의 성능을 측정하기 위해서 외부 시스템은 항상 기대한 결과만을 반환하는 환경이 필요하기 때문입니다.

성능 테스트시 하지 말아야 할 Mocking 방식

1. 객체 Mocking

객체 Mocking은 테스트 코드를 작성할 때 가장 많이 사용하는 방식이라 친숙할 것 입니다. 그러나 로직에 대해 검증을 하는 테스트와 달리, 성능 테스트는 어플리케이션 동작과 자원의 사용을 모두 보아야만 하는 테스트입니다.

객체 Mocking 은 해당 객체의 행위 뒤로 들어가야 할 동작들을 무시해버리게 됩니다. 예를 들어 Spring Profile 을 사용하여 RestOpertation 을 객체를 Mock 처리하였을 때

• http connection Pool 미사용
• connection thread 미사용
• io가 발생하지 않음

등등 성능 테스트에서 중요한 관점인 Thread 사용, 리소스 사용을 전부 무시하게 됩니다.

외부 인터페이스를 Mocking 하는 것처럼 보이지만, 내부 인터페이스도 Mocking 해버리는 객체 Mocking 은 성능 테스트에서 피해야 합니다.

2. 같은 어플리케이션에 Dummy Controller 생성

이 방식도 아주 간혹 테스트 코드를 작성할 때 사용하는 방식입니다. 이 방식이 1번 방식과 다른 것은 실제로 요청을 보내고 받으며 자원을 사용한다는 것 입니다.

그러나 Dummy Controller 의 로직은 테스트 시스템의 자원과 리소스를 같이 사용해버리게 됩니다. 테스트 대상 시스템이 더 늘어나 버리는 신뢰성이 굉장히 떨어지는 의미없는 성능 테스트를 하게 됩니다. 테스트를 위한 요소는 대상 시스템에 절대로 영향을 미쳐서는 안 됩니다.

Mock Server 만들고 띄우기

그래서 우리는 테스트 대상 시스템과 완벽히 분리된 Mock Server 를 띄워야 합니다.

외부 인터페이스 Mock이 갖추어야 할 조건을 아래와 같이 정의했습니다.

• 모든 요청에 기대한 결과만을 반환한다.
• 모든 요청에 기대한 퍼포먼스만 낸다.
• 병목이 되지 않아야 한다.

제가 만든 것은 가짜 PG사인 Gazua PAY 입니다. 요청 인터페이스는 기대한 결과와 퍼포먼스로 응답을 하도록 하는 값을 받도록 하였습니다.

(개발 당시에는 코인 시장이 엄청 핫할 때 였습니다. 승인 결과의 message는 차트의 상승을 표현했는데 아무도 눈치채지 못했습니다.)

저는 Spring 쟁이라 Spring Boot 로 아주 간단히 모든 요청에 기대한 결과, 퍼포먼스를 내는 Mock Application을 만들었습니다.

이제 Mock Application 을 배포해야 합니다. 이럴 때 정말 유용했던 것은 AWS Elastic Beanstalk 입니다. (우아한형제들은 AWS 사용을 적극 지원해주기 때문에 마음껏 쓸 수 있었습니다.)

(Elastic Beanstalk 홍보 영상 중..)

Elastic Beanstalk 은 애플리케이션을 업로드하기만 하면 용량 프로비저닝, 로드 밸런싱, Auto Scaling, 애플리케이션 상태 모니터링에 대한 배포 정보를 자동으로 처리해줍니다.

배포를 위한 스크립트를 작성하거나, 서버 설정을 해줄 필요 없이 클릭만으로 간단하게 하나의 환경을 만들 수 있고, Mock Server 에 병목이 생겨도 클릭만으로 Scale Out 하여 병목을 해소할 수 있습니다.

이로써 병목이 되지 않는, 기대한 결과와 퍼포먼스를 반환하는 Mock Server 가 완성되었습니다.

2. 사용한 도구들

nGrinder

nGrinder 는 성능 측정 목적으로 개발된 오픈소스 프로젝트로

• 테스트 프로세스를 제공
• 부하를 줄 수 있는 웹 인터페이스를 제공
• 테스트 결과를 수집하여 통계로 제공

등의 기능을 제공합니다.

성능 측정 도구로 nGrinder 가 가장 좋았던 것은 groovy 스크립트로 테스트 시나리오를 작성할 수 있다는 것 입니다.

groovy는 gradle, jenkins file, spock 등에서 자주 다루었던 친숙한 언어였기에 내가 원하는 테스트 시나리오를 쉽고 자유롭게 작성할 수 있었습니다.

pinpoint

pinpoint 는 Java로 작성된 대규모 분산 시스템용 APM 도구입니다.

사내에서 사용하고 있는 모니터링툴이기도 하며, Transaction 의 추적을 제공하는 APM 중 하나입니다.

단일 Transaction의 Stack Trace 를 기록하여 직접적인 병목이나 문제를 빠르게 추적할 수 있고,

Transaction 이 DOT 로 그려지는 응답시간/요청시간 그래프 Transaction View 는 테스트의 상태를 실시간으로 확인하여, 가장 빠르게 이상을 감지하도록 도와줍니다.

Transaction View 는 패턴에 따른 어플리케이션 상태 예측에도 큰 몫을 하였습니다. A 구간의 병목을 보였을 때 보이는 패턴, 외부 인터페이스가 병목을 보였을 때 등등 예상 패턴을 통해 더 빠른 조치가 가능하기도 했습니다.

실제로 테스트를 하며 수많은 이상 패턴들이 탄생하기도 하였습니다.

(기영이 패턴)

(L타워 패턴)

그리고 노력 끝에 얻어진..

(백설기 패턴)

jstack

pinpoint 로 어플리케이션의 전반적인 상황을 파악할 수 있었지만, pinpoint 의 Trace 기능으로 모든 패키지와 클래스를 탐색 하는 것은 너무 과하며, Thread 간의 경합 으로 발생되는 예기치 않은 현상들을 탐지하기는 어렵습니다.

이럴 때 우리는 Thread Dump 를 분석해야 합니다.

저는 JVM 의 내장 명령 도구인 jstack 을 사용하여 쉽게 Thread Dump 를 획득할 수 있었습니다.

이제 Tread Dump 를 분석하여 병목의 원인을 파악할 수 있습니다.

(Tread Dump 를 보기 편하게 가공)

dstat

우리가 만드는 시스템은 결국 하드웨어 위에서 동작하게 되고, 시스템의 리소스 자원 사용은 Scale Up, Scale Out, Scale Down 의 중요한 지표가 됩니다.

그러므로 우리는 테스트를 통해 이 시스템은 리소스 자원을 최대한으로 사용하고 있다 라는 결론으로 도달해야 합니다.

리소스 자원을 실시간으로 모니터링하기 위해 dstat 을 사용하였습니다.

dstat 은 vmstat, iostat, ifstat, netstat 정보 등을 결합한 내용을 보여주고, 실시간성 통계를 제공해주어 성능 테스트 중 모니터링하기에 매우 적합했습니다.

dstat 하나의 명령어로 대부분의 리소스를 모니터링할 수 있었습니다.

dstat으로 모니터링 가능한 자원 : aio, cpu, cpu24, disk, disk24, disk24old, epoch, fs, int, int24, io, ipc, load, lock,
mem, net, page, page24, proc, raw, socket, swap, swapold, sys, tcp, time, udp, unix,
vm

kingpoint

kingpoint 라는 도구를 아시나요? 제가 만든 것이라 당연히 모를 것 입니다. 비동기 어플리케이션의 완벽한 모니터링이 아직은 어렵기도 하며, 어플리케이션의 특성을 반영한 모니터링을 하기에도 쉽지 않았습니다.

정말 보아야 하는 것이 있는데 그것을 지원하는 도구가 없다면, 테스트를 위한 요소가 실제 어플리케이션의 성능에 절대 영향을 주지 않는다는 것을 꼭 지키는 선에서 만들어보는 것도 나쁘지 않을 것 같습니다.

비동기 대한 모니터링을 위해 요청과 완료 시점에 특정 key 값으로 통계를 전송하도록 하여, 분석한 지표를 chart.js 로 그려주는 간단한 모니터링 툴 입니다. 저는 이로인해 많은 두려움을 해소할 수 있었습니다.

---

테스트 진행

그래서 저는 아래와 같은 테스트들을 진행했습니다.

성능 테스트

• 실제 트래픽 상황에서의 정상 동작
• 기존 시스템 대비 BenchMarking

부하 테스트

• 리소스 병목 탐색, 어플리케이션 버그 탐색
• 이벤트 상황과 같은 순간 트래픽 최대치, 한계치를 탐색
• 신규 스펙 장비에서 MYSQL 설정 최적화 탐색

스트레스 테스트

• 장기간 부하 발생에 대한 한계치를 탐색, 예외 동작 상황 확인
• Graceful Shutdown 정상 동작 확인
• 데이터베이스 failover 상황, 자동 복구, 예외 동작 상황 확인
• 외부 요인(PG사)의 밀릴, 예외 상황 동작 확인

Mock Server 를 올리고, 위의 도구들을 사용하여 수백 번의 테스트를 해본 것 같습니다. 점차 원하는 패턴, 안정적인 수치와 지표를 찾을 수 있었습니다.

• 어느 정도의 부하 를 견딜 수 있는지 알고 있다.
• 한계치에서 병목 이 생기는 지점을 알고 있다.
• 자원을 효율적 으로 사용한다.
• 메모리 누수, 오류, 오버플로우 는 발생하지 않는다.
• 최악의 상황 에서 어떤 동작을 하는지 직접 확인하였다.
• 장애 조치와 복구 의 동작을 직접 확인하였다.

라는 미지의 영역을 개척할 수 있었습니다.

---

마무리

지금까지 결제 시스템 개비를 진행하며 경험했던 성능, 부하, 스트레스 테스트 환경 구축 및 진행에 대한 내용이습니다.

테스트를 했다고해서 이상적으로 동작하는 어플리케이션을 만든 것은 아닐 것 입니다. 많은 상황을 예방할 수 있겠지만, 언제나 전혀 예상치 못했던 상황들이 생깁니다.

그러나 적어도 확인한 것, 확보한 지표 를 기반으로 장래의 부하, 장애를 최소한의 비용과 시간으로 합리적으로 대응할 수 있을 것 입니다.

보았어야 했는데 보지 않았던 것, 더 쉽게 볼 수 있었는데 어렵게 보았던 것 등 많은 시행 착오가 있었지만, 환경을 만들고 테스트를 하면서 많은 자신감을 얻을 수 있었습니다.

그래도 배포할 땐..

긴 글 읽어주셔서 감사합니다.

참고

• 성능, 부하, 스트레스 테스트
• Elastic Beanstalk 소개
• pinpoint 소개
• dstat 소개