추가 적립 안내

20년 베테랑 개발자가 공개하는 AWS 부하 테스트 기초부터 실전까지의 노하우!

이 책에서는 부하 테스트의 기본적인 정의부터 다양한 부하 테스트 도구를 설명하였습니다. 무엇보다 어렵게 느껴지는 부하 테스트의 진행 과정을 순차적으로 쉽게 설명하였습니다. 단계별로 이론과 실제 발생 상황을 자세히 정리하였고, 선배 개발자와 3년 차 개발자를 등장시켜 기업 내에서의 부하 테스트 업무 처리 과정을 대화식으로 쉽게 풀어내었습니다. 베테랑 개발자인 나카가와 타루하치와 모리시타 켄이 그들 사이에서도 생소했던 고급 노하우를 공개합니다.

클라우드와 온프레미스, 모든 환경에 적용 가능한 실제 부하 테스트의 A~Z
20년 베테랑 개발자가 공개하는 부하 테스트 기초부터 실전까지의 노하우!

이 책에서는 부하 테스트의 기본적인 정의부터 다양한 부하 테스트 도구를 설명하였다. 어렵게 느껴지는 부하 테스트의 진행 과정을 순차적으로 쉽게 설명하고 있으며, 단계별로 이론과 실제 발생 상황을 자세히 정리하였다. 또한, 선배 개발자와 3년 차 개발자의 부하 테스트 업무 처리 과정에 대한 대화식 구성은 학습 집중력을 높여준다.

부하 테스트 도구들은 정말 많다. 또한, 계속 새로운 도구들이 나오고 있다. 그러나 이런 도구를 사용한다고 해서 문제를 전부 해결할 수는 없다. 프로젝트 관리부터 운영체제 레벨까지 넓고 다양한 문제가 존재하기 때문이다.

이 책에는 웹 시스템의 서버 쪽 부하 테스트에서 발생하는 문제를 해결하기 위한 모범 사례가 잘 정리되어 있다. 또한, 클라우드 위에 시스템을 구축하는 것을 기본으로 하지만, 온프레미스 환경이 일반적이었던 시대의 운용 개발 경험을 기반으로 클라우드와 온프레미스, 그리고 클라우드와 온프레미스의 하이브리드 시스템 개발, 운용에도 적용할 수 있는 내용을 수록했다.

CHAPTER 1 부하 테스트의 문제와 웹 시스템의 실패 사례 1
1.1 잘못된 부하 테스트 2
1.1.1 사례에서의 등장 인물과 상황 3
1.1.2 잘못된 개발 일정 4
1.1.3 잘못된 테스트 전제 조건 7
1.1.4 잘못된 테스트 준비 9
1.1.5 잘못된 테스트 실행 11
1.1.6 잘못된 테스트 보고서 12
1.2 웹 시스템 실패 사례 15
1.2.1 이벤트 시스템 실패 사례 15
1.2.2 쇼핑몰 사이트 실패 사례 16
1.2.3 도서관 검색 시스템 실패 사례 17

CHAPTER 2 웹 시스템 설계 방법 19
2.1 웹 시스템 가용성 20
2.1.1 가용성이란? 20
2.1.2 여러 하위 시스템이 연결된 환경에서의 가용성 21
2.2 높은 가용성을 가진 시스템 설계 방법 22
2.2.1 시스템 이중화 23
2.2.2 시스템 확장 25
2.3 웹 시스템 설계 역사 29
2.3.1 온프레미스에서의 시스템 구축 1(저가용성/낮은 확장성) 29
2.3.2 온프레미스에서의 시스템 구축 2(중가용성/중간적 확장성) 32
2.3.3 클라우드에서의 시스템 구축(고가용성/높은 확장성) 35
2.4 요약 46

CHAPTER 3 부하 테스트 기본 지식 47
3.1 부하 테스트 목적 48
3.1.1 온프레미스에서의 부하 테스트 목적 48
3.1.2 클라우드에서의 부하 테스트 목적 51
3.2 부하 테스트에서의 시스템 성능 지표 53
3.2.1 Throughput 54
3.2.2 Latency 55
3.2.3 여러 하위 시스템으로 구성된 환경에서의 Throughput과 Latency 55
3.3 시스템 성능 개선 기본 지식 56
3.3.1 Throughput 개선 56
3.3.2 Latency 개선 58
3.4 좋은 부하 테스트에 대한 지표 59
3.4.1 좋은 부하 테스트를 나타내는 지표 59
3.4.2 나쁜 부하 테스트를 나타내는 지표 60
3.5 요약 62

CHAPTER 4 부하 테스트 도구 63
4.1 부하 테스트에서 사용하는 3가지 도구 64
4.2 부하 테스트 도구 선택 기준 65
4.2.1 부하 테스트 도구란? 65
4.2.2 부하 테스트 도구상의 부하와 실 운영환경의 차이 69
4.2.3 부하 테스트 도구 선택 기준 73
4.2.4 대상 시스템에 맞는 부하 테스트 도구 사용 74
4.3 Apache Bench 사용 방법 78
4.3.1 특징 78
4.3.2 설치 방법 78
4.3.3 주요 옵션 79
4.3.4 실행 결과 예제 80
4.4 Apache JMeter 사용 방법 81
4.4.1 특징 81
4.4.2 JMeter를 이용한 시스템 구성 예제 82
4.4.3 설치 방법 86
4.4.4 JMeter 실행 결과 예제 88
4.5 Locust 사용 방법 90
4.5.1 특징 90
4.5.2 설치 방법 91
4.5.3 시나리오 작성 91
4.5.4 Locust 기동 92
4.5.5 실행 예제 94
4.6 Tsung 사용 방법 94
4.6.1 특징 95
4.6.2 설치 방법 95
4.6.3 시나리오 작성 및 테스트 실행 97
4.6.4 실행 결과 예제 98
4.7 모니터링 도구와 프로파일링 도구 99
4.8 top 명령어와 netstat 명령어 101
4.8.1 top 명령어 101
4.8.2 netstat 명령어 103
4.9 CloudWatch 활용 106
4.9.1 CloudWatch 그래프의 주의점 108
4.10 Xhprof 사용 방법 112
4.10.1 설치 방법 112
4.10.2 Xhprof 실행 예제 113
4.11 New Relic 도입 방법 117
4.11.1 New Relic 도입 117
4.11.2 New Relic 기능 소개 120

CHAPTER 5 부하 테스트 계획 123
5.1 부하 테스트 대상 시스템 125
5.2 부하 테스트 계획 준비 126
5.2.1 일정 결정 126
5.2.2 부하 테스트 목적 설정 127
5.2.3 전제 조건 정리 128
5.2.4 목푯값 결정 129
5.2.5 사용할 부하 테스트 도구 결정 136
5.2.6 부하 테스트 환경 결정 136
5.2.7 부하 테스트 시나리오 결정 138
5.3 요약 143

CHAPTER 6 부하 테스트 준비 145
6.1 부하 테스트 대상 환경 구축 147
6.1.1 테스트 대상 환경 구축 147
6.1.2 부하 테스트 전용 엔드포인트 추가 147
6.2 부하 테스트 도구 준비 148
6.2.1 부하 테스트 도구 구축과 설치 148
6.2.2 시나리오 작성 148
6.2.3 시나리오 작성 시 주의점 148
6.3 관련 시스템 부서와의 조율 149
6.3.1 유관 부서 시스템 조정 149
6.4 클라우드 사업자 제한 사항과 해제 요청 150
6.5 요약 151

CHAPTER 7 부하 테스트 실행 1(테스트 실행과 병목 현상 확인) 153
7.1 부하 테스트 실행 단계란? 154
7.1.1 한 번에 전체 부하 테스트를 실행한 경우 154
7.1.2 단계에 따른 부하 테스트 159
7.2 단계 1: 도구와 환경 검증 161
7.2.1 대상 시스템 161
7.2.2 Plan 162
7.2.3 Do 163
7.2.4 Check 163
7.2.5 Action 164
7.3 단계 2: 웹 프레임워크 검증 165
7.3.1 대상 시스템 165
7.3.2 Plan 166
7.3.3 Do 166
7.3.4 Check 166
7.3.5 Action 167
7.4 단계 3: 조회 성능 검증 167
7.4.1 대상 시스템 167
7.4.2 Plan 168
7.4.3 Do 169
7.4.4 Check 169
7.4.5 Action 169
7.5 단계 4: 갱신 성능 검증 170
7.5.1 대상 시스템 170
7.5.2 Plan 171
7.5.3 Do 171
7.5.4 Check 171
7.5.5 Action 172
7.6 단계 5: 외부 서비스 연동 성능 검증 173
7.6.1 대상 시스템 173
7.6.2 Plan 174
7.6.3 Do 174
7.6.4 Check 174
7.6.5 Action 174
7.7 단계 6: 시나리오 테스트 175
7.7.1 Throughput 평가에 대해 175
7.7.2 대상 시스템 176
7.7.3 Plan 177
7.7.4 Do 177
7.7.5 Check 177
7.7.6 Action 178
7.8 단계 7: 스케일 아웃 테스트 준비 179
7.8.1 대상 시스템 179
7.8.2 Plan 180
7.8.3 Do 180
7.8.4 Check 180
7.8.5 Action 180
7.9 단계 8: 스케일 업/아웃 테스트(단계 1~6 회귀 테스트) 181
7.9.1 대상 시스템 181
7.9.2 스케일 업/스케일 아웃 예제 183
7.9.3 Plan 186
7.9.4 Do 187
7.9.5 Check 187
7.9.6 Action 187
7.10 단계 9: 성능 한계 테스트(단계 1~6 회귀 테스트) 189
7.10.1 대상 시스템 189
7.10.2 Plan 190
7.10.3 Do 190
7.10.4 Check 191
7.10.5 Action 191

CHAPTER 8 부하 테스트 실행 2(원인 분석과 시스템 개선 작업) 193
8.1 시스템 병목 확인 194
8.2 부하 테스트 도구 병목 원인과 대책 195
8.2.1 서버 및 테스트 도구 설정 문제 196
8.2.2 테스트 시나리오 문제 200
8.2.3 부하 테스트 서버 성능 부족 200
8.2.4 부하 테스트 서버 네트워크 문제 201
8.2.5 참고표 202
8.3 웹 서버 병목 원인과 대책 203
8.3.1 운영체제와 미들웨어 설정 문제 203
8.3.2 웹 프레임워크 문제 205
8.3.3 애플리케이션 문제 208
8.3.4 서버 리소스 성능 부족 209
8.3.5 참고표 210
8.4 캐시 서버 병목 원인과 대책 214
8.4.1 캐시 사용 방법 문제 215
8.4.2 서버 리소스 부족 215
8.4.3 참고표 215
8.5 DB 서버 병목 원인과 대책 218
8.5.1 DB 설계 문제 218
8.5.2 DB 사용 애플리케이션 문제 220
8.5.3 서버 리소스 부족 222
8.5.4 참고표 224
8.6 외부 서비스 병목 원인과 대책 231
8.6.1 외부 시스템과 연동 방법 문제 231
8.6.2 외부 시스템 성능 문제 233
8.6.3 참고표 234

CHAPTER 9 부하 테스트 보고서 작성 239
9.1 부하 테스트 최종 확인 240
9.2 목푯값에 맞춘 적정한 구성 선정 241
9.2.1 시스템 여유 리소스 확보 방안 242
9.3 부하 테스트 보고서 작성 242
9.3.1 보고서 필요 항목 242
9.3.2 부하 테스트 보고서에 시스템 모니터링 데이터를 넣으면 생기는 문제 243
9.4 요약 244

CHAPTER 10 부하 테스트에 대한 실제 사례 245
10.1 이 장에서 테스트하는 시스템 246
10.1.1 애플리케이션 기능 요건 246
10.1.2 시스템 요건 247
10.1.3 시스템 설계 247
10.1.4 부하 테스트 전제 조건 254
10.2 JMeter+Xhprof로 PHP 애플리케이션 부하 테스트 사례 257
10.2.1 부하 테스트 계획 수립 257
10.2.2 테스트 실행 1: 도구와 웹 프레임워크 검증(테스트 시작) 261
10.2.3 테스트 실행 2: 시나리오 테스트(테스트 실행) 279
10.2.4 테스트 실행 3: 스케일 업/아웃 테스트(확장에 대한 한계) 293
10.2.5 테스트 실행 4: 성능 한계 테스트(성능 한계 개선) 313
10.2.6 적정한 구성 선정과 테스트 보고서 320
10.3 Locust+New Relic으로 Node.js 애플리케이션 부하 테스트 사례 329
10.3.1 1일 차 전반: 도구와 환경 검증 332
10.3.2 1일 차 후반: 애플리케이션 시스템 전체 검증 339
10.3.3 2일 차 전반: 애플리케이션 시스템 전체 검증(1일 차에 이어 계속) 351
10.3.4 2일 차 전반: 확장성 검증(2배 확장) 355
10.3.5 2일 차 후반: 확장성 검증 - 웹 서버 확장 시 발생하는 병목 현상은? 362
10.3.6 3일 차: 최소 구성에 대한 검증 375

CHAPTER 11 부록 I(용어 설명 외) 393
11.1 용어 설명 394
11.1.1 일반 용어 394
11.1.2 AWS 용어, 아이콘 설명 396
11.2 JMeter 시나리오 설명 401
11.2.1 Thread Group 생성 402
11.2.2 Simple Controller를 사용한 그룹화 403
11.2.3 Dummy user_id 생성 404
11.2.4 사용자 정의 변수 사용 405
11.2.5 HTTP Request 실행 406
11.2.6 HTTP 응답으로부터 user_id 수집 407
11.2.7 시나리오 일부를 ○% 확률로 실행 410
11.2.8 시나리오 일부를 ○회 반복 411
11.2.9 통계 보고서 표시 412
11.3 Locust 시나리오 설명 413
11.3.1 Locust 기본 413
11.3.2 10장에서의 시나리오 417
11.4 부하 테스트의 문제 설명 423

CHAPTER 12 부록 II(AWS 로드 테스팅) 431

이중화된 시스템은 네트워크 지연(Latency)과 데이터 전송 능력(Throughput)이 허락되는 범위 내에서 지리적, 물리적으로 떨어진 장소에 설치해야 한다. 이렇게 함으로써 천재지변으로 발생하는 정전이나 네트워크 장애를 대비할 수 있다. AWS의 경우 Multi-AZ라는 형태로 데이터 센터 레벨의 독립적인 시스템을 사용하는 경우가 많다.
(/ p.23)

병목을 발견하는 작업은 예측된 각 하위 시스템 지표를 보면서 하겠지만, 숙련된 경험자도 쉽게 찾을 수 없는 어려운 작업이다. 이 부분이 병목 구간이라고 생각하고 그 구간을 개선하지만, Throughput에 영향을 주지 않을 경우 병목 확인이 잘못되었으며 다른 부분을 확인해야만 한다. 이런 과정을 반복하면서 조금씩 Throughput을 개선해 나가는 것이다.
(/ p.56)

Apache JMeter는 다양한 기능을 제공한다. 부하 테스트 서버 사양과 시나리오에 따라 다르겠지만, 수천 rps까지의 시스템이라면 충분한 부하를 줄 수 있다. 그러나 부하 테스트 서버 리소스 사용량이 비교적 많아 많은 부하를 주길 원하면 부하 테스트 서버를 많이 준비해야 한다. 또 많은 서버를 이용한 부하 테스트에서 서버 간 통신을 위해 네트워크 설정이 필요할 때도 있다.
(/ p.81)

실제 사용자 요청은 시스템과 같은 데이터 센터가 아닌 네트워크 적으로 거리가 있는 곳에서 발생한다는 것을 생각하면 부하 테스트도 실제 사용자처럼 먼 거리에서 테스트하고 싶을 것이다. 그러나 부하 테스트 서버가 네트워크 적으로 떨어져 있다면 시스템에 적당한 부하를 줄 수 없어 서버 리소스는 사용하지 않지만, 시스템의 Throughput은 나오지 않으며, Latency가 커서 타임아웃도 빈번하게 발생하는 상황이 될 수 있다.
(/ p.161)

- 시나리오가 정상적으로 실행되었는가? → 확인되었다.
- 웹 서버 리소스를 충분히 사용하는가? → CPU 사용률 100%로 병목이 발생했다.
- DB 서버 리소스를 충분히 사용하는가?
- 전 단계와 비교해 확실히 Latency가 악화했는가? → 크게 나빠지지 않았다.
- 전 단계와 비교해 확실히 Throughput 저하가 확인되었는가? → 크게 저하되지 않았다.
- DB의 데이터와 로그는 정상인가?(내용, 수) → 별도로 확인했지만 문제없었다.
(/ p.292)