시스템 성능 분석과 최적화: 엔터프라이즈에서 클라우드 환경까지...
Post on 24-Jul-2016
322 views
DESCRIPTION
브렌든 그레그 지음 | 오현석, 서형국 옮김 | 시스템 & 네트워크 시리즈 _ 002 | ISBN: 9791158390181 | 42,000원 | 2015년 12월 15일 발행 | 792쪽 | Dtrace, Performance, Tuning, 성능, 시스템, 엔터프라이즈, 운영체제, 최적화, 클라우드TRANSCRIPT
시스템 성능 분석과 최적화:엔터프라이즈에서 클라우드 환경까지 아우르는
서문 2
감사의 말 10
저자 소개 13
들어가며
1.1 시스템 성능 14
1.2 역할 15
1.3 활동 16
1.4 관점 17
1.5 성능은 도전적인 분야다 18
1.5.1 성능은 주관적이다 18
1.5.2 시스템은 복잡하다 18
1.5.3 여러 성능 문제가 존재할 수 있다 19
1.6 지연시간 20
1.7 동적 트레이싱 21
1.8 클라우드 컴퓨팅 22
1.9 사례 연구 23
1.9.1 느린 디스크 23
1.9.2 소프트웨어 변경 26
1.9.3 더 읽을거리 28
방법론
2.1 용어 30
2.2 모델 30
2.2.1 테스트 중인 시스템 31
2.2.2 대기열 시스템 31
2.3 개념 32
2.3.1 지연시간 32
2.3.2 시간 규모 33
01장
02장
목차|IV
2.3.3 트레이드오프 34
2.3.4 튜닝을 위한 노력 35
2.3.5 적합성의 수준 36
2.3.6 성능 개선의 한시성 37
2.3.7 부하 대 아키텍처 38
2.3.8 규모 확장성 38
2.3.9 알려진 모르는 것 40
2.3.10 지표 41
2.3.11 사용률 42
2.3.12 포화도 44
2.3.13 프로파일링 44
2.3.14 캐싱 45
2.4 관점 47
2.4.1 자원 분석 48
2.4.2 부하 분석 49
2.5 방법론 50
2.5.1 가로등 역방법론 51
2.5.2 임의 변경 역방법론 52
2.5.3 다른 사람 비난 역방법론 52
2.5.4 전용 점검 목록 방법론 53
2.5.5 문제 내역서 54
2.5.6 과학적 방법론 54
2.5.7 검사 주기 56
2.5.8 도구 방법론 56
2.5.9 USE 방법론 57
2.5.10 부하 특성 평가 63
2.5.11 드릴다운 분석 65
2.5.12 지연시간 분석 66
2.5.13 R 방법론 67
2.5.14 이벤트 트레이싱 68
2.5.15 기준 통계 70
2.5.16 정적 성능 튜닝 70
2.5.17 캐시 튜닝 71
2.5.18 마이크로 벤치마킹 72
목차 | V
2.6 모델링 72
2.6.1 기업 대 클라우드 73
2.6.2 시각적 식별 73
2.6.3 암달의 확장성 법칙 75
2.6.4 일반 확장성 법칙 76
2.6.5 대기열 이론 77
2.7 수용량 계획 81
2.7.1 자원 제약 81
2.7.2 요인 분석 83
2.7.3 확장성 해법 84
2.8 통계 85
2.8.1 성능 정량화 85
2.8.2 평균 86
2.8.3 표준 편차, 백분위, 중앙값 87
2.8.4 변동계수 88
2.8.5 다봉분포 88
2.8.6 이상치 89
2.9 감시 89
2.9.1 시간에 따른 패턴 90
2.9.2 감시 제품 91
2.9.3 부팅 시점부터의 요약 91
2.10 시각화 92
2.10.1 꺾은선 차트 92
2.10.2 산점도 93
2.10.3 열지도 94
2.10.4 표면도 95
2.10.5 시각화 도구 96
2.11 연습문제 97
2.12 참고문헌 97
목차|VI
운영체제
3.1 용어 100
3.2 배경지식 101
3.2.1 커널 101
3.2.2 스택 104
3.2.3 인터럽트와 인터럽트 스레드 105
3.2.4 인터럽트 우선순위 106
3.2.5 프로세스 107
3.2.6 시스템 콜 110
3.2.7 가상 메모리 111
3.2.8 메모리 관리 112
3.2.9 스케줄러 113
3.2.10 파일 시스템 114
3.2.11 캐싱 117
3.2.12 네트워킹 117
3.2.13 장치 드라이버 118
3.2.14 다중 프로세서 118
3.2.15 선점 119
3.2.16 자원 관리 119
3.2.17 관찰 가능 범위 120
3.3 커널 120
3.3.1 유닉스 121
3.3.2 솔라리스 기반 122
3.3.3 리눅스 기반 125
3.3.4 차이점 127
3.4 연습문제 129
3.5 참고문헌 129
03장
목차 | VII
관찰 도구
4.1 도구 유형 132
4.1.1 카운터 132
4.1.2 트레이싱 134
4.1.3 프로파일링 135
4.1.4 감시(sar) 136
4.2 관찰 소스 137
4.2.1 /proc 137
4.2.2 /sys 143
4.2.3 kstat 145
4.2.4 지연 어카운팅 148
4.2.5 미세상태 어카운팅 149
4.2.6 다른 관찰 가능 소스 149
4.3 DTrace 151
4.3.1 정적 트레이싱과 동적 트레이싱 152
4.3.2 프로브 154
4.3.3 프로바이더 154
4.3.4 인수 155
4.3.5 D 언어 155
4.3.6 내장 변수 156
4.3.7 액션 157
4.3.8 변수 타입 157
4.3.9 한 줄짜리 프로그램 160
4.3.10 스크립트 160
4.3.11 부가비용 162
4.3.12 문서와 자료 162
4.4 시스템탭 163
4.4.1 프로브 164
4.4.2 탭셋 165
4.4.3 액션과 내장 변수 165
4.4.5 부가비용 168
4.4.6 문서와 자료 169
04장
목차|VIII
4.5 리눅스 성능 이벤트(perf) 170
4.6 관찰 도구 관찰하기 170
4.7 연습문제 171
4.8 참고문헌 172
애플리케이션
5.1 애플리케이션 기초 173
5.1.1 목표 175
5.1.2 일반적인 경우 최적화하기 176
5.1.3 관찰 가능 범위 176
5.1.4 빅 오 표기법 176
5.2 애플리케이션 성능 기법 178
5.2.1 I/O 크기 변경 178
5.2.2 캐시 사용 178
5.2.3 버퍼 사용 179
5.2.4 폴링 179
5.2.5 동시성과 병렬성 180
5.2.6 비동기 I/O 183
5.2.7 프로세서 바인딩 183
5.3 프로그래밍 언어 184
5.3.1 컴파일 언어 184
5.3.2 인터프리터 언어 186
5.3.3 가상 머신 186
5.3.4 쓰레기 수집 187
5.4 방법론과 분석 187
5.4.1 스레드 상태 분석 188
5.4.2 CPU 프로파일링 192
5.4.3 시스템 콜 분석 194
5.4.4 I/O 프로파일링 203
5.4.5 부하 특성 평가 204
05장
목차 | IX
5.4.6 USE 방법론 204
5.4.7 드릴다운 분석 205
5.4.8 락 분석 206
5.4.9 정적 성능 튜닝 209
5.5 연습문제 210
5.6 참고문헌 212
CPU
6.1 용어 214
6.2 모델 214
6.2.1 CPU 아키텍처 214
6.2.2 CPU 메모리 캐시 215
6.2.3 CPU 실행 대기열 216
6.3 개념 216
6.3.1 클럭 속도 217
6.3.2 명령 217
6.3.3 명령 파이프라인 218
6.3.4 명령 너비 218
6.3.5 CPI, IPC 218
6.3.6 사용률 219
6.3.7 사용자 시간/커널 시간 비율 220
6.3.8 포화 220
6.3.9 선점 221
6.3.10 우선순위 역전 221
6.3.11 다중 프로세스, 다중 스레드 221
6.3.12 워드 크기 223
6.3.13 컴파일러 최적화 223
6.4 아키텍처 224
6.4.1 하드웨어 224
6.4.2 소프트웨어 233
06장
목차|X
6.5 방법론 238
6.5.1 도구 방법론 239
6.5.2 USE 방법론 239
6.5.3 부하 특성 평가 240
6.5.4 프로파일링 242
6.5.5 사이클 분석 243
6.5.6 성능 감시 244
6.5.7 정적 성능 튜닝 245
6.5.8 우선순위 튜닝 245
6.5.9 자원 제어 246
6.5.10 CPU 바인딩 246
6.5.11 마이크로 벤치마킹 247
6.5.12 확장하기 247
6.6 분석 248
6.6.1 uptime 249
6.6.2 vmstat 251
6.6.3 mpstat 252
6.6.4 sar 254
6.6.5 ps 255
6.6.6 top 256
6.6.7 prstat 258
6.6.8 pidstat 260
6.6.9 time, ptime 260
6.6.10 DTrace 262
6.6.11 시스템탭 270
6.6.12 perf 270
6.6.13 cpustat 278
6.6.14 기타 도구 279
6.6.15 시각화 280
6.7 실험 과정 283
6.7.1 임의 시도 284
6.7.2 시스벤치 284
목차 | XI
6.8 튜닝 285
6.8.1 컴파일러 옵션 285
6.8.2 스케줄링 우선순위와 클래스 286
6.8.3 스케줄러 옵션 286
6.8.4 프로세스 바인딩 288
6.8.5 배타적 CPU 집합 289
6.8.6 자원 제어 289
6.8.7 프로세서 옵션(BIOS 튜닝) 290
6.9 연습문제 290
6.10 참고문헌 292
메모리
7.1 용어 295
7.2 개념 295
7.2.1 가상 메모리 296
7.2.2 페이징 297
7.2.3 요구 페이징 298
7.2.4 과할당 300
7.2.5 스와핑 300
7.2.6 파일 시스템 캐시 사용 301
7.2.7 사용률과 포화도 301
7.2.8 할당자 302
7.2.9 워드 크기 302
7.3 아키텍처 302
7.3.1 하드웨어 302
7.3.2 소프트웨어 307
7.3.3 프로세스 주소 공간 314
07장
목차|XII
7.4 방법론 319
7.4.1 도구 방법론 320
7.4.2 USE 방법론 320
7.4.3 사용 특성 평가 322
7.4.4 사이클 분석 323
7.4.5 성능 감시 323
7.4.6 누수 감지 324
7.4.7 정적 성능 튜닝 324
7.4.8 자원 제어 325
7.4.9 마이크로 벤치마킹 325
7.5 분석 325
7.5.1 vmstat 326
7.5.2 sar 330
7.5.3 slabtop 333
7.5.4 ::kmastat 334
7.5.5 ps 335
7.5.6 top 337
7.5.7 prstat 338
7.5.8 pmap 339
7.5.9 DTrace 340
7.5.10 시스템탭 346
7.5.11 기타 도구 346
7.6 튜닝 348
7.6.1 변경 가능 파라미터 348
7.6.2 여러 페이지 크기 350
7.6.3 할당자 352
7.6.4 자원 제어 352
7.7 연습문제 353
7.8 참고문헌 354
목차 | XIII
파일 시스템
8.1 용어 357
8.2 모델 357
8.2.1 파일 시스템 인터페이스 357
8.2.2 파일 시스템 캐시 358
8.2.3 2단계 캐시 359
8.3 개념 359
8.3.1 파일 시스템 지연시간 359
8.3.2 캐시 360
8.3.3 임의 접근 I/O 대 순차 I/O 361
8.3.4 예비 추출 361
8.3.5 미리 읽기 362
8.3.6 라이트 백 캐시 363
8.3.7 동기적 쓰기 363
8.3.8 로우 I/O와 직접 I/O 364
8.3.9 비블로킹 I/O 365
8.3.10 메모리 맵 파일 365
8.3.11 메타데이터 366
8.3.12 논리적 I/O 대 물리적 I/O 367
8.3.13 연산들은 동일하지 않다 369
8.3.14 특별 파일 시스템 369
8.3.15 접근 타임스탬프 369
8.3.16 용량 370
8.4 아키텍처 370
8.4.1 파일 시스템 I/O 스택 370
8.4.2 VFS 371
8.4.3 파일 시스템 캐시 372
8.4.4 파일 시스템 기능 377
8.4.5 파일 시스템 유형 379
8.4.6 볼륨과 풀 385
8.5 방법론 387
8.5.1 디스크 분석 387
8.5.2 지연시간 분석 388
08장
목차|XIV
8.5.3 부하 특성 평가 390
8.5.4 성능 감시 392
8.5.5 이벤트 트레이싱 393
8.5.6 정적 성능 튜닝 393
8.5.7 캐시 튜닝 394
8.5.8 부하 분리 394
8.5.9 메모리 기반 파일 시스템 395
8.5.10 마이크로 벤치마킹 395
8.6 분석 397
8.6.1 vfsstat 397
8.6.2 fsstat 398
8.6.3 strace, truss 399
8.6.4 DTrace 399
8.6.5 시스템탭 412
8.6.6 LatencyTOP 412
8.6.7 free 412
8.6.8 top 413
8.6.9 vmstat 413
8.6.10 sar 414
8.6.11 slabtop 415
8.6.12 mdb ::kmastat 416
8.6.13 fcachestat 417
8.6.14 /proc/meminfo 418
8.6.15 mdb ::memstat 418
8.6.16 kstat 419
8.6.17 다른 도구 420
8.6.18 시각화 421
8.7 실험 422
8.7.1 임의 부하 생성 423
8.7.2 마이크로 벤치마크 도구 423
8.7.3 캐시 플러싱 426
8.8 튜닝 426
8.8.1 애플리케이션 호출 427
목차 | XV
8.8.2 ext3 428
8.8.3 ZFS 429
8.9 연습문제 431
8.10 참고문헌 432
디스크
9.1 용어 434
9.2 모델 434
9.2.1 단순한 디스크 434
9.2.2 디스크 캐시 435
9.2.3 컨트롤러 436
9.3 개념 437
9.3.1 시간 측정 437
9.3.2 시간 규모 438
9.3.3 캐시 439
9.3.4 임의 접근 I/O 대 순차 I/O 440
9.3.5 읽기/쓰기 비율 441
9.3.6 I/O 크기 441
9.3.7 IOPS는 같지 않다 442
9.3.8 데이터 전송이 아닌 디스크 명령 442
9.3.9 사용률 443
9.3.10 포화 444
9.3.11 I/O 대기 444
9.3.12 동기 대 비동기 445
9.3.13 디스크 I/O 대 애플리케이션 I/O 445
9.4 아키텍처 446
9.4.1 디스크 유형 446
9.4.2 인터페이스 453
9.4.3 저장장치 유형 454
9.4.4 OS 디스크 I/O 스택 458
09장
목차|XVI
9.5 방법론 461
9.5.1 도구 방법론 461
9.5.2 USE 방법론 462
9.5.3 성능 감시 463
9.5.4 부하 특성 평가 464
9.5.5 지연시간 분석 466
9.5.6 이벤트 트레이싱 467
9.5.7 정적 성능 튜닝 468
9.5.8 캐시 튜닝 469
9.5.9 자원 제어 469
9.5.10 마이크로 벤치마크 469
9.5.11 확장하기 471
9.6 분석 472
9.6.1 iostat 472
9.6.2 sar 482
9.6.3 pidstat 484
9.6.4 DTrace 484
9.6.5 시스템탭 495
9.6.6 perf 495
9.6.7 iotop 496
9.6.8 iosnoop 500
9.6.9 blktrace 503
9.6.10 MegaCli 505
9.6.11 smartctl 507
9.6.12 시각화 508
9.7 실험 512
9.7.1 임의 부하 생성 512
9.7.2 커스텀 부하 생성기 513
9.7.3 마이크로 벤치마크 도구 513
9.7.4 임의 위치 읽기 예제 513
목차 | XVII
9.8 튜닝 515
9.8.1 운영체제의 변경 가능 파라미터 515
9.8.2 디스크 장치의 변경 가능 파라미터 517
9.8.3 디스크 컨트롤러의 변경 가능 파라미터 517
9.9 연습문제 518
9.10 참고문헌 519
네트워크
10.1 용어 521
10.2 모델 521
10.2.1 네트워크 인터페이스 521
10.2.2 컨트롤러 522
10.2.3 프로토콜 스택 522
10.3 개념 523
10.3.1 네트워크와 라우팅 523
10.3.2 프로토콜 524
10.3.3 캡슐화 525
10.3.4 패킷 크기 525
10.3.5 지연시간 526
10.3.6 버퍼링 528
10.3.7 연결 백로그 529
10.3.8 인터페이스 교섭 529
10.3.9 사용률 530
10.3.10 지역 연결 530
10.4 아키텍처 531
10.4.1 프로토콜 531
10.4.2 하드웨어 534
10.4.3 소프트웨어 537
10장
목차|XVIII
10.5 방법론 542
10.5.1 도구 방법론 542
10.5.2 USE 방법론 543
10.5.3 부하 특성 평가 544
10.5.4 지연시간 분석 545
10.5.5 성능 감시 546
10.5.6 패킷 스니핑 547
10.5.7 TCP 분석 548
10.5.8 드릴다운 분석 549
10.5.9 정적 성능 튜닝 549
10.5.10 자원 제어 550
10.5.11 마이크로 벤치마킹 551
10.6 분석 551
10.6.1 netstat 552
10.6.2 sar 559
10.6.3 ifconfig 561
10.6.4 ip 562
10.6.5 nicstat 562
10.6.6 dladm 563
10.6.7 ping 564
10.6.8 traceroute 565
10.6.9 pathchar 566
10.6.10 tcpdump 567
10.6.11 snoop 568
10.6.12 와이어샤크 572
10.6.13 DTrace 572
10.6.14 시스템탭 587
10.6.15 perf 587
10.6.16 다른 도구 589
10.7 실험 589
10.7.1 iperf 590
목차 | XIX
10.8 튜닝 591
10.8.1 리눅스 591
10.8.2 솔라리스 595
10.8.3 설정 598
10.9 연습문제 598
10.10 참고문헌 599
클라우드 컴퓨팅
11.1 배경 602
11.1.1 가격 대 성능 비 602
11.1.2 확장 가능한 아키텍처 603
11.1.3 수용량 계획 604
11.1.4 저장장치 606
11.1.5 다중 임대 사용자 607
11.2 OS 가상화 607
11.2.1 부가비용 609
11.2.2 자원 제어 612
11.2.3 관찰 도구 616
11.3 하드웨어 가상화 621
11.3.1 부가비용 623
11.3.2 자원제어 630
11.3.3 관찰 도구 633
11.4 비교 641
11.5 연습문제 642
11.6 참고문헌 643
11장
목차|XX
벤치마킹
12.1 배경 646
12.1.1 활동 646
12.1.2 효과적인 벤치마킹 647
12.1.3 벤치마크의 죄악 649
12.2 벤치마킹 유형 657
12.2.1 마이크로 벤치마킹 657
12.2.2 시뮬레이션 659
12.2.3 리플레이 660
12.2.4 업계 표준 661
12.3 방법론 663
12.3.1 수동적 벤치마킹 663
12.3.2 능동적 벤치마킹 664
12.3.3 CPU 프로파일링 667
12.3.4 USE 방법론 668
12.3.5 부하 특성 평가 669
12.3.6 커스텀 벤치마크 669
12.3.7 연속 부하 증가 669
12.3.8 정상 여부 검사 672
12.3.9 통계적 분석 673
12.4 벤치마크 질문 674
12.5 연습문제 676
12.6 참고문헌 676
사례연구
13.1 사례 분석: 암막 커튼 679
13.1.1 문제 기술 679
13.1.2 지원 680
13.1.3 시작하기 682
12장
13장
목차 | XXI
13.1.4 어떤 모험을 택할 것인가? 684
13.1.5 USE 방법론 685
13.1.6 이제 다 끝난 것일까? 688
13.1.7 두 번째 시도 689
13.1.8 기본 690
13.1.9 암막 커튼 제치기 691
13.1.10 커널 심문하기 692
13.1.11 왜 그랬을까? 695
13.1.12 후일담 697
13.2 해설 698
13.3 추가 정보 698
13.4 참고문헌 699
USE 방법론: 리눅스
물리적 자원 700
소프트웨어 자원 703
참고문헌 704
물리적 자원 705
소프트웨어 자원 707
USE 방법론: 솔라리스
참고문헌 708
리눅스 709
sar 요약
솔라리스 710
syscall 프로바이더 711
A부록
B부록
C부록
목차|XXII
한 줄짜리 DTrace 프로그램 예제
proc 프로바이더 714
profile 프로바이더 715
sched 프로바이더 716
fbt 프로바이더 717
pid 프로바이더 718
io 프로바이더 719
sysinfo 프로바이더 720
vminfo 프로바이더 720
ip 프로바이더 721
tcp 프로바이더 721
udp 프로바이더 722
기능 723
DTrace 스크립트를 시스템탭으로 바꾸기
용어 724
프로브 724
내장 변수 725
함수 725
예제 1: 시스템콜 엔트리 프로브 나열하기 726
예제 2: read()가 반환하는 크기 요약하기 726
예제 3: 프로세스 이름별로 시스템 콜 횟수 세기 728
예제 4: 프로세스 ID 123인 프로세스에 대해 시스템콜
이름별로 횟수 세기 730
예제 5: “httpd” 프로세스에 대해 시스템콜
이름별로 시스템콜 횟수 세기 730
예제 6: 프로세스 이름과 파일 경로별로
파일 open() 횟수 세기 731
예제 7: “mysqld” 프로세스의 read()
지연시간 요약하기 731
D부록
E부록
목차 | XXIII
예제 8: 새로 시작되는 프로세스 이름과 인자를
트레이스하기 732
예제 9: 100Hz로 커널 스택 샘플링하기 733
참고문헌 733
연습문제 해답
2장 - 방법론 734
3장 - OS 734
6장 - CPU 734
7장 - 메모리 735
8장 - 파일 시스템 735
9장 - 디스크 736
11장 - 클라우드 컴퓨팅 736
시스템 성능 인명록 737
용어 740
참고문헌 745
F부록
G부록
H부록
I부록
목차|XXIV
“우리가 아는 아는 것이 있습니다. 즉, 우리가 알고 있음을 이미 알고 있는 것이 있죠.
또, 우리가 아는 모르는 것도 있습니다. 다시 말하면,
우리가 모르고 있음을 이미 알고 있는 것이 있습니다.
하지만 모르는 모르는 것도 있습니다.
이런 것은 우리가 모른다는 사실조차도 모르는 것입니다.”
- 2002년 2월 12일 미국 국방장관 도널드 럼즈펠드1(Donald Rumsfeld)
물론 위에 인용한 말은 기자 회견에 참석한 사람들의 비웃음을 사긴 했다. 하지만 이 말은 국제 관계
만큼이나 복잡한 기술 시스템에서도 중요한 원칙을 하나 알려준다. 즉, 성능 문제는 어느 곳에서나
발생할 수 있어서 아예 몰라서 검토해 볼 생각조차도 못한 시스템 분야(즉, 모르는 모르는 것들)에
서도 발생할 수 있다는 것이다. 이 책은 그러한 분야를 가능한 한 많이 드러내고, 분석할 수 있는 방
법론과 도구를 제공하고자 한다.
이 책에 대해
『시스템 성능 분석과 최적화』의 독자가 된 것을 환영한다! 이 책은 운영체제와 애플리케이션의 성능
을 운영체제의 맥락에서 살펴본 것으로, 엔터프라이즈와 클라우드 컴퓨팅 환경을 위해 쓰여졌다. 나
의 목표는 시스템이 가진 능력을 십분 활용하게 돕는 것이다.
1 (옮긴이) 미국 대통령 제럴드 포드와 아들 부시 재임 시 국방장관을 역임한 사람이다. 이 말은 이라크와 테러리스트 간의 관계에 대해 질문을 받자,
잘 모르지만 모른다고 해서 그게 꼭 관계가 없는 것은 아니라는 이야기를 빙빙 돌려 말한 것이다.
서문
3서문
지속적으로 개발 중인 애플리케이션을 다루고 있는 사람이라면 운영체제의 성능은 이미 해결된(왜
냐하면 운영체제는 수십 년간 개발 및 성능 개선이 이뤄져 왔기 때문에) 문제로 간주하고 싶은 욕구
가 있다. 하지만 그렇지 않다! 운영체제는 아주 복잡한 소프트웨어로 구성돼 있고, 매우 다양하고 계
속해서 변하는 실제 장치와 새롭게 매 순간 바뀌는 애플리케이션 부하를 관리한다. 커널(kernel) 또
한 계속 개발 중이다. 어떤 특성을 띤 부하의 성능을 향상시키기 위해 새 기능을 계속 추가하고, 시
스템이 커짐에 따라 새로 발견되는 병목지점을 제거하고 있다. 운영체제의 성능을 향상시키기 위한
분석과 작업은 지속적인 과업이며, 지속적인 성능 개선으로 이어져야만 한다. 애플리케이션 성능 또
한 운영체제의 맥락에서 분석해야만 한다. 이에 대해서도 다룰 것이다.
운영체제에 대해 다루는 내용
이 책의 주 초점은 시스템 성능 연구에 있다. 리눅스(Linux)와 솔라리스(Solaris) 운영체제를 대
상으로 도구, 예제, 그리고 변경 가능한 설정값을 제시한다. 따로 언급하지 않는다면 예제에서
운영체제 배포판의 종류는 중요하지 않다. 리눅스 기반 시스템에 대한 예제는 다양한 베어메탈
2(bare-metal)부터 가상화한 클라우드 임대(cloud tenency) 환경까지, 우분투(Ubuntu), 페도
라(Fedora), 센토스(CentOS) 등에서 가져왔다. 솔라리스 기반 시스템의 경우도 마찬가지로 베
어메탈부터 가상화한 환경, 그리고 조이언트(Joyent)의 스마트OS(SmartOS)나 OmniTI의 옴니
OS(OmniOS)에서 가져온 것들이다. 스마트OS와 옴니OS는 오픈소스 일루모스(illumos) 커널을
사용하며, 이는 오픈솔라리스(OpenSolaris) 커널을 분기해 수정한 것으로 오픈솔라리스 커널 자체
는 나중에 오라클 솔라리스 11이 된 개발 버전을 기반으로 한다.
서로 다른 두 운영체제를 다룸으로써 어느 한 운영체제를 사용하는 독자들은 다른 관점을 배울 수
있다. 각 운영체제의 설계가 서로 다른 방식을 취한 부분을 비교해 보면, 운영체제의 여러 특성을 더
잘 이해할 수 있다. 또한 이런 과정을 통해 성능에 대해 더 깊이 이해하고, 한 운영체제에만 머물지
않고 더 객관적인 시각으로 운영체제에 대해 생각해 볼 수 있다.
과거에는 솔라리스에서 성능 관련 활동이 더 많이 이뤄졌다. 그래서 일부 예제에서는 솔라리스를 선
택할 수밖에 없었다. 하지만 리눅스도 아주 많이 좋아졌다. 10년 전 리눅스와 솔라리스를 함께 다룬
“시스템 성능 튜닝(System Performance Tuning)”[Musumeci 02]이 나올 때만 해도 후자에 주로
중심을 둘 수밖에 없었다. 그 책의 저자는 다음과 같이 이유를 설명했다.
2 (옮긴이) 호스트 O/S 없이 가상 머신을 바로 물리적인 기계에서 실행하는 환경
서문4
솔라리스 장비들은 성능에 좀 더 초점을 맞추고 있다. 내 생각엔 솔라리스 시스템이 리눅스 시스템보다 평
균적으로 훨씬 더 비싸기 때문이 아닌가 싶다. 그로 인해 솔라리스 사용자들은 더 많이 성능에 집착하는 경
향이 있고, 더 많은 성능 관련 작업이 솔라리스에서 이뤄져 왔다. 리눅스가 기대에 못 미치는 성능을 보인다
면 그냥 다른 리눅스 장비를 한 대 더 사서 부하를 분산시킬 수 있다. 비용이 많이 들지 않기 때문이다. 하지
만 누군가가 보유한 수십억 원짜리 울트라 엔터프라이즈(Ultra Enterprise) 10000이 잘 동작하지 않아서 회
사에 매 순간 무시할 수 없는 손해를 끼치고 있다면 그 사람은 썬(SUN3)의 서비스를 불러서 해답을 요구할
것이다.
이는 썬이 과거에 왜 성능에 초점을 맞췄는지를 잘 설명한다. 솔라리스의 이익은 하드웨어 매출에
달려있었으며, 성능 개선이 바로 실제 매출과 직결되는 경우가 자주 있었다. 썬에는 100명이 넘는
성능 전담 엔지니어가 필요했으며, 이들을 고용할 만한 이유와 여력이 있었다(저자 본인과 무수메
치(Musumeci)도 이런 성능 엔지니어였다). 썬의 커널 엔지니어링 팀과 더불어 다양한 개발자가 시
스템 성능 분야에 있었다.
리눅스의 성능 작업과 관찰 가능성 분야에서 많은 진전이 있었다. 특히 이제는 대규모 클라우드 컴
퓨팅 환경에서도 리눅스를 사용하기 때문에 더 그렇다. 이 책에서 보여주는 것을 비롯한 여러 리눅
스 성능 관련 기능은 대부분 최근 5년 사이에 개발된 것들이다.
다른 내용
이 책에서는 성능 도구의 화면 캡처를 많이 보여준다. 이는 데이터는 물론 어떤 유형의 데이터가 사
용 가능한지를 알려주기 위해서다. 도구는 때로 아주 직관적인 방식으로 데이터를 표현하곤 한다.
이런 방식은 보기도 편하고 화면이 출력 내용을 잘 설명해준다. 초기 유닉스 도구가 이런 방식을 사
용했다. 따라서 화면 캡처는 별도의 설명 없이도 이런 도구의 목적을 보여주는 아주 좋은 방법이 될
수 있다. (어떤 도구의 결과를 해석하기 위해 많은 설명이 필요하다면 도구를 잘못 설계한 것이다!)
기술 발전의 역사를 알면 좀 더 깊게 이해하는 데 도움이 된다. 따라서 필요할 때마다 역사를 설명했
다. 또한 이 업계에서 핵심 인물이 누구인지 알아두는 것도 유용하다(어쨌든 업계가 좁으니까). 아
마도 그런 사람이 만든 결과물을 성능 분야나 다른 분야에서 마주칠 일이 자주 있을 것이다. 부록 G
에 “인명록”이 있으니 참고한다.
3 (옮긴이) 썬 마이크로시스템즈(SUN Microsystems)의 준말이다. 썬 마이크로시스템즈는 한때 워크스테이션 분야 등의 1인자 기업이었으며, 스팍
(SPARC) CPU와 솔라리스, 자바, NFS, ZFS 등을 개발하기도 한 실리콘밸리 기업이었으나, 리눅스 기반 서버가 주 사업 분야를 위협했고, 미국발 금
융위기로 인해 주요 고객이었던 금융권의 매출이 급감해서 결국 2010년 초 오라클에 합병됐다. 현재 과거 썬의 사옥 및 부지는 페이스북이 사용 중이다.
5서문
다루지 않은 내용
이 책은 성능에 초점을 맞춘다. 책에 있는 모든 작업을 수행하기 위해서는 이따금 소프트웨어를 설
치하고 컴파일(이런 부분은 이 책에서 따로 설명하지 않는다)하는 등 시스템 관리자 역할을 해야 할
것이다. 특히 리눅스의 경우 이 책에서 여러모로 쓰는 sysstat 패키지를 설치해야 한다.
본문에서 운영체제 내부를 정리할 것이다. 하지만 운영체제는 별도의 교과서가 필요할 만큼 방대하
다. 그래서 고급 성능 분석과 관련이 있는 요점만 다뤘다. 따라서 독자들은 이 책을 통해 어떤 도구
가 있는지 알아두고, 필요할 때 다른 곳을 참고해 그에 대해 더 알아볼 수 있을 것이다.
이 책의 구조
이 책의 구성은 다음과 같다.
≑ 1장, “들어가며”에서는 시스템 성능 분석과 핵심 개념을 소개하고, 성능 개선 활동 사례를 보여준다.
≑ 2장, “방법론”에서는 성능 분석과 튜닝에 대한 기반 지식을 제공한다. 이런 기반 지식에는 용어, 개념, 모델, 관찰 및
실험 방법론, 수용량 계획, 분석, 그리고 통계가 들어간다.
≑ 3장, “운영체제”에서는 성능 분석가를 대상으로 커널 내부에 대해 정리한다. 그 지식은 운영체제가 어떻게 동작하는
지를 이해하고 해석하는 데 필요한 기반이다.
≑ 4장, “관찰 도구”에서는 사용 가능한 다양한 시스템 관찰 도구를 다룬다. 또한 각 도구의 기반 인터페이스나 프레임
워크에 대해서도 다룬다.
≑ 5장, “애플리케이션”에서는 애플리케이션 성능과 관련된 주제와 애플리케이션을 운영체제에서 어떻게 관찰할 것인
가에 대해 다룬다.
≑ 6장, “CPU”에서는 프로세서, 코어, 하드웨어 스레드, CPU 캐시, CPU 상호 연결, 커널 스케줄링에 대해 다룬다.
≑ 7장, “메모리”에서는 가상 메모리, 페이징, 스와핑, 메모리 아키텍처, 버스, 주소공간, 그리고 메모리 할당자에 대해
서 다룬다.
≑ 8장, “파일 시스템”에서는 파일 시스템 I/O 성능에 대해, 관련된 여러 다른 캐시 시스템과 더불어 설명한다.
≑ 9장, “디스크”에서 다루는 범위는 저장장치, 디스크 I/O 부하, 저장장치 컨트롤러, RAID, 커널 I/O 하위 시스템 등이다.
≑ 10장, “네트워크”에서는 네트워크 프로토콜, 소켓, 인터페이스, 그리고 물리적 연결에 대해 다룬다.
≑ 11장, “클라우드 컴퓨팅”에서는 클라우드 컴퓨팅에서 자주 사용하는 운영체제와 하드웨어 기반의 가상화 방식을 다
루고, 각각의 성능 추가 비용, 임대 사용자 간 격리, 그리고 관찰 특성을 설명한다.
≑ 12장, “벤치마킹”에서는 벤치마크를 정확하게 하는 방법과 다른 사람의 벤치마크 결과를 해석하는 방법을 보여준다.
사실 이 주제는 놀랄만큼 어렵다. 이 장에서는 자주 저지르는 실수를 피하는 방법을 다루고, 그런 요소를 독자가 이
해할 수 있게 도울 것이다.
서문6
≑ 13장, “사례 연구”에서는 성능 사례 연구로, 실제 클라우드 고객의 성능 문제를 어떻게 분석했는지를 시작부터 끝까
지 보여줄 것이다.
1장부터 4장은 기본 배경지식이다. 이 네 장을 읽었다면 나머지 부분은 필요에 따라 참고할 수 있
다.
13장은 조금 다르게, 성능 엔지니어의 업무에 대해 더 큰 그림을 보여주기 위해 이야기처럼 썼다.
성능 분석 분야를 처음 접하는 독자라면 13장을 먼저 읽어서 전체 맥락을 보고, 다른 장을 보는 중
간중간 다시 13장을 들춰보는 것도 좋다.
참고자료로 활용하기
이 책은 여러 해 동안 가치 있기를 바라는 마음으로 썼다. 그래서 시스템 성능 분석가의 배경지식과
방법론에 초점을 맞췄다.
이 책을 참고자료로 쓸 수 있도록 대부분의 장은 두 부분으로 구성돼 있다. 첫 부분은 용어, 개념, 방
법론이다(보통은 그와 같은 소제목이 붙어있다). 이 같은 내용은 미래에도 여러 해 동안 계속 의미
가 있을 것이다. 두 번째 부분은 첫 부분의 내용을 어떻게 구현할 수 있는지를 다룬다. 아키텍처, 분
석 도구, 설정 가능한 값 등이 그 내용이다. 이런 정보는 시간이 지나면 낡은 정보가 될 것이다. 하지
만 여전히 예제로서의 가치는 남아있을 것이다.
트레이싱 예제
운영체제를 깊이 있게 살펴볼 필요가 있다. 그런 경우 커널 트레이싱(tracing) 도구를 활용한다. 여
러 트레이싱 도구가 개발 중이며, 각각 다른 개발 단계에 있다. 예를 들면, ftrace, perf, DTrace,
시스템탭(SystemTap), LTTng, ktap 등이 있다. 이 책에서 다룬 대부분의 트레이싱 예제는 이 중
하나인 DTrace를 사용했으며, 솔라리스나 리눅스 기반 시스템의 예제를 보여준다. DTrace는 이런
예제에 필요한 기능을 제공하며, 그에 대한 외부 자료도 풍부하다. 그런 자료 중에는 고급 트레이싱
의 예로 들 수 있는 스크립트도 여럿 있다.
독자에 따라서는 다른 트레이싱 도구를 사용하고 싶을 수도 있다. 그것도 좋다. DTrace 예제는 시
스템에 대해 어떤 질문을 던질 수 있는지를 보여준다. 때때로 이런 질문이나 그 질문을 던지기까지
의 방법론이 가장 알기 어려울 때가 있다.
7서문
대상 독자
이 책은 엔터프라이즈나 클라우드 컴퓨팅 환경의 관리자와 운영자를 1차 대상으로 한다. 또한 이 책
은 개발자, 데이터베이스 관리자, 웹 서버 관리자 등 운영체제와 애플리케이션 성능에 대해 이해할
필요가 있는 사람들을 위한 참고서 역할을 할 수 있다.
클라우드 컴퓨팅 회사의 책임 성능 엔지니어로서, 나는 여러 성능 문제를 풀어야 하는 긴박감에 시
달리는 지원 부서 직원이나 고객들과 함께 자주 일하곤 한다. 많은 경우 성능 문제는 그들의 주요 업
무가 아니다. 그런 사람들은 자신이 접한 문제를 해결하기에 충분한 지식만 있으면 된다. 이런 이유
로 나는 이 책을 가능한 한 짧게 만들려고 노력했다. 독자 여러분의 시간이 한정돼 있음을 알기 때문
이다. 하지만 너무 짧게 만들 수는 없었다. 여러분을 확실히 준비시키기 위해 꼭 다뤄야만 할 내용이
많기 때문이다.
다른 대상 독자로는 학생을 들 수 있다. 이 책은 시스템 성능 과목의 부교재로 사용하기에도 좋다.
이 책을 쓰는 동안(그리고 이 책이 쓰여지기 전 수년간), 나 자신이 그런 과목을 가르쳐 왔다. 나는
수업을 진행하면서 시뮬레이션으로 만들어서 학생들이 풀어야 하는 성능 문제를 내곤 했다(물론 미
리 답을 가르쳐주지 않고 말이다!). 이런 경험을 통해 어떤 종류의 자료가 성능 문제를 푸는 데 가장
잘 도움을 줄 수 있는지 알 수 있었다. 그런 경험을 바탕으로 이 책의 내용을 선택했다.
여러분이 학생이건 아니건, 각 장의 연습문제는 본문의 내용을 다시 살펴보고 응용해 볼 기회를 준
다. 이런 연습문제에는 (리뷰를 해준 사람들의 의견에 따라) 꼭 풀어볼 필요는 없는 아주 어려운 연
습문제도 몇 가지 들어 있다(어쩌면 아예 풀 수 없을 수도 있다. 적어도 그런 문제는 독자 여러분이
생각의 틀을 깨는 데 도움될 것이다).
기업 규모에 대해 말하자면 이 책에는 작은 환경부터 십여 명의 성능 전담 직원까지 있는 대규모 환
경까지 모두 만족시킬 만큼 상세한 내용이 들어 있다. 소규모 기업의 경우, 이 책의 일부 내용을 채
택해 매일 사용하면서, 필요에 따라 다른 부분을 참고할 수 있을 것이다.
이 책에서 사용한 표기법
다음은 이 책에서 사용한 표기법이다.
netif_receive_skb() 함수 이름
iostat(1) 온라인 매뉴얼(man) 페이지
서문8
Documentation/ . . . 리눅스 문서 경로
CONFIG_ . . . 리눅스 설정 선택 사항
kernel/ . . . 리눅스 커널 소스 코드
fs/ 리눅스 커널 소스 코드, 파일 시스템
usr/src/uts/ . . . 솔라리스 기반 커널 소스 코드
# 수퍼유저(루트) 셀 프롬프트
$ 일반사용자(비-루트) 셀 프롬프트
^C 키 입력에 따른 실행 중단(Ctrl-C)
[...] 일부 생략
mpstat 1 사용자가 입력한 명령어 또는 내용 강조
보충 자료 및 참고 도서
다음은 운영체제와 성능 분석의 배경지식을 얻기 위해 참고할 수 있는 일부 참고 도서 목록이다(전
체 목록은 참고문헌에 있다).
[Jain 91] Jain, R. The Art of Computer Systems Performance Analysis: Techniques for Experimental
Design, Measurement, Simulation, and Modeling, Wiley, 1991.
[Vahalia 96] Vahalia, U. UNIX Internals: The New Frontiers, Prentice Hall, 1996.
ㆍ한국어판: UNIX의 내부: 새로운 미개척 영역, 조유근 역, 홍릉과학출판사, 2001년 9월.
[Cockcroft 98] Cockcroft, A., and R. Pettit. Sun Performance and Tuning: Java and the Internet, Prentice
Hall, 1998.
[Musumeci 02] Musumeci, G. D., and M. Loukidas. System Performance Tuning, 2nd Edition, O’Reilly, 2002.
[Bovet 05] Bovet, D., and M. Cesati. Understanding the Linux Kernel, 3rd Edition, O’Reilly, 2005.
ㆍ한국어판: 리눅스 커널의 이해(개정판), 심마로, 이호 공역, 한빛미디어, 2003년 9월.
[McDougall 06a] McDougall, R., and J. Mauro. Solaris Internals: Solaris 10 and OpenSolaris Kernel
Architecture, Prentice Hall, 2006.
[McDougall 06b] McDougall, R., J. Mauro, and B. Gregg. Solaris Performance and Tools: DTrace and MDB
Techniques for Solaris 10 and OpenSolaris, Prentice Hall, 2006.
[Gove 07] Gove, D. Solaris Application Programming, Prentice Hall, 2007.
성능은 흥미진진하고, 다양하며, 도전적인 분야다. 1장에서는 성능 분야, 그중에서도 시스템 성능에
대해 설명하며, 역할, 활동, 관점, 그리고 도전 과제에 대해 알려줄 것이다. 또한 지연시간(latency)
이라는 필수적인 성능 지표와 새로운 분야인 동적 트레이싱(dynamic tracing)과 클라우드 컴퓨팅
(cloud computing)에 대해 다룰 것이다. 또한 성능 개선 활동 사례를 통해 관련 맥락을 설명할 것
이다.
1.1 시스템 성능
시스템 성능은 전체 시스템에 대한 연구로, 모든 물리적 구성 요소와 전체 소프트웨어 스택을 모두
아우른다. 데이터 경로에 있다면 하드웨어건 소프트웨어건 성능에 영향을 끼칠 수 있기 때문에 모두
성능 개선 활동의 대상이다. 분산 시스템의 경우 이는 여러 서버와 애플리케이션 모두를 의미한다.
만약 대상 환경의 데이터 경로를 보여주는 도식이 없다면 찾아보거나 직접 그리자. 그 그림은 각 구
성 요소 간의 관계를 이해하고 전체 영역에서 간과하는 부분이 없게끔 도와줄 것이다.
그림 1.1은 단일 서버 상의 일반적인 시스템의 소프트웨어 스택이다. 여기에는 운영체제 커널과 예
제 데이터베이스와 애플리케이션 계층이 포함돼 있다. 이따금 전체 스택이라는 말은 데이터베이스,
애플리케이션, 웹 서버를 포함하는 애플리케이션 환경만을 의미하기도 한다. 하지만 시스템 성능에
대해 말할 때 전체 스택은 시스템 라이브러리나 커널까지 포함한다.
들어가며
01장
151장. 들어가며
애플리케이션
데이터베이스
시스템 라이브러리
커널
사용자 수준
커널 수준
장치 드라이버
장치
스레드
스케줄러
파일
시스템
네트워크
스택
가상
메모리
시스템 콜
그림 1.1 일반적인 시스템 소프트웨어 스택
이 스택에 대해서는 3장 “운영체제”에서 다룰 것이고, 그다음에 오는 여러 장에서 더 자세히 설명할
것이다. 이어지는 절에서는 시스템 성능이나 일반적인 성능에 대해 설명한다.
1.2 역할
시스템 성능은 다양한 역할을 통해 이뤄지는 활동이다. 여기에는 시스템 관리자, 지원 인력, 애플리
케이션 개발자, 데이터베이스 관리자, 웹 관리자 등이 포함된다. 이들 중 대부분은 성능이 주 업무가
아니기 때문에 자신의 책임 분야(네트워크 팀은 네트워크만, 데이터베이스 팀은 데이터베이스만 점
검하는 등) 내에서만 성능에 신경 쓰는 경향이 있다. 하지만 어떤 성능 문제의 근본 원인을 찾기 위
해 여러 팀이 협력해야만 하는 경우도 있다.
성능 엔지니어를 고용하는 회사도 있다. 성능 엔지니어의 주 업무는 시스템 성능이다. 이들은 여러
팀과 더불어 전체 환경에 대한 성능 평가 및 개선을 수행하며, 이는 복잡한 성능 문제를 해결하려는
경우 필수적이다. 이런 사람들은 전체 시스템에 걸친 분석을 위한 더 나은 도구와 지표를 개발할 기
회를 판별하고, 전체 환경에 걸쳐 수용량(capacity)을 계획한다.
시스템 성능 분석과 최적화: 엔터프라이즈에서 클라우드 환경까지 아우르는16
예를 들어, 자바 성능이나 MySQL 성능 등 애플리케이션에 따라 특화된 성능 개선 활동도 있다. 이
런 활동은 보통 애플리케이션에 대한 분석 도구로 가기 전에 해당 시스템의 성능을 제한적으로 검사
하는 목적으로 이뤄진다.
1.3 활동
성능 분야는 다음과 같은 활동을 포함하며, 각 활동을 이상적인 실행 순서에 따라 정리했다.
1. 성능 목표와 모델 설정
2. 프로토타입 소프트웨어나 하드웨어의 성능 특성 파악
3. 개발한 코드의 성능을 통합하기 전에 분석
4. 출시 전이나 후에 빌드한 소프트웨어에 대해 비-퇴행 테스트1(non-regression test)를 수행
5. 소프트웨어 릴리즈에 대한 벤치마킹이나 벤치마케팅2(benchmarketing)
6. 목표 환경에서의 개념 증명(proof-of-concept) 테스트
7. 프로덕션 배포를 위해 최적화 설정
8. 실행 중인 프로덕션 소프트웨어 감시
9. 문제 발생 시 성능 분석
1단계에서 5단계까지는 전통적인 소프트웨어 제품 개발의 일부분이다. 그 후 제품이 나오고, 개념
증명을 위한 테스트를 고객 환경에서 수행하거나 배포 및 설정하게 된다. 고객 환경에서 문제가 발
생하는 경우(6단계에서 9단계), 이는 개발 단계에서 해당 문제를 발견하지 못했다는 뜻이다.
이상적인 경우 성능 엔지니어링은 하드웨어를 선택하거나 소프트웨어를 작성하기 전에 시작해야 한
다. 첫 단계는 목표를 설정하고 성능 모델을 만드는 것을 포함한다. 이 단계 없이 나중에 문제가 보
일 때까지 성능 엔지니어링을 연기한 채로 제품을 개발하는 일도 많다. 하지만 각 개발 단계를 거칠
때마다 앞 단계에서 내린 아키텍처 결정으로 인해 성능 문제를 수정하는 것은 점차 더 어려워진다.
1 (옮긴이) 보통 regression test를 회귀 테스트라고 번역하는 경우가 많지만, 실제로 이 경우 regression을 번역한 말에는 회기(어떤 기준 통계 분포
로 돌아간다는 뜻)보다는 퇴행(소프트웨어 변경의 결과 문제가 발생한다는 뜻)이 더 바람직한 것 같다.
2 (옮긴이) 벤치마케팅은 마케팅에 활용하기 위해 벤치마킹을 최대한 자사에 유리하게 진행하고 활용하는 것이다.
171장. 들어가며
수용량 계획은 이러한 활동 중 일부를 가리키는 용어다. 설계 시 개발 중인 소프트웨어의 자원 사용
량(footprint)을 파악하는 것이 필요하다. 이를 통해 설계가 목표에 맞게 진행 중인지 알 수 있다.
배포 후에는 성능 개선 활동에 자원 사용 감시가 들어간다. 자원 사용을 감시하는 이유는 문제가 발
생하기 전에 가능한 한 이를 예측하기 위해서다.
이러한 활동을 수행하는 데 도움되는 방법론과 도구를 이 책에서 다룰 것이다.
환경과 활동은 회사나 제품에 따라 달라질 것이다. 대부분의 경우 앞에서 나열한 9가지 단계를 모두
실행하지는 않을 것이다. 여러분이 해야 할 일은 아마도 이 중 여럿 또는 단 하나의 활동에 집중하는
것일 수도 있다.
1.4 관점
여러 가지 다른 활동에 집중하는 것과 별도로, 성능 역할을 다른 관점에서 볼 수도 있다. 그림 1.2에
는 두 가지 관점의 성능 분석이 표시돼 있다. 이는 부하(workload) 분석과 자원(resource) 분석이
다. 각 접근법은 소프트웨어 스택을 서로 다른 방향에서 접근해 간다.
운영체제
소프트웨어
스택
부하 분석
부하
애플리케이션
시스템 콜
시스템 라이브러리
커널
장치 자원 분석
그림 1.2 분석 관점
자원 분석 관점은 시스템 자원에 대한 책임이 있는 시스템 관리자들이 보통 취하는 관점이다. 부하
가 걸린 상황에서 성능에 대한 책임이 있는 애플리케이션 개발자는 보통 부하 관점을 취한다. 각 관
점은 각기 장점이 있으며, 이에 대해서는 2장 “방법론”에서 더 자세히 다룰 것이다. 어려운 문제에
도전하는 경우 두 관점에서 모두 분석을 시도해 보는 것이 도움될 수도 있다.
시스템 성능 분석과 최적화: 엔터프라이즈에서 클라우드 환경까지 아우르는18
1.5 성능은 도전적인 분야다
시스템 성능 엔지니어링은 도전적인 분야다. 주관적이며 복잡한 데다가 여러 문제를 함께 다뤄야 하
기 때문이다.
1.5.1 성능은 주관적이다
기술 분야는 객관적인 경향이 있다. 그래서 기술 산업에 종사하는 사람들은 보통 흑백 논리를 사용
한다고 알려져 있다. 소프트웨어 문제 해결의 경우 이런 경향이 사실이다. 왜냐하면 버그는 존재하
거나 존재하지 않거나 둘 중 하나이고, 이를 고치거나 고치지 못하거나 둘 중 하나이기 때문이다. 쉽
게 이해하고 해석할 수 있는 오류 메시지를 통해 버그의 존재를 입증할 수 있는 경우가 많다.
반면 성능은 주관적인 경우가 자주 있다. 성능 문제가 정말 존재하는지 명확히 알 수 없는 경우도 많
고, 문제가 있다고 인정하더라도 그 문제가 해결된 것인지 판단하기 어려운 경우도 많다. 어떤 사용
자는 시스템 성능을 “나쁜” 것으로 여겨서 문제가 된다고 했는데, 다른 사용자는 “좋은” 성능으로 생
각하는 경우도 있다.
다음 정보를 보자.
이 디스크의 I/O 응답시간은 1ms다.
이것은 “좋은” 것일까 아니면 “나쁜” 것일까? 응답시간 또는 지연시간은 현존하는 가장 좋은 지표
중 하나지만, 그 정보를 해석하는 것은 어렵다. 어떤 지표가 “좋은” 것인지 “나쁜” 것인지는 어느
정도 애플리케이션 개발자나 실 사용자의 성능 기대치에 달려 있다.
주관성은 명확한 목표를 설정하는 방식으로 객관화할 수 있다. 예를 들어, 목표 평균 응답시간을 정
하거나, 요청 중에서 특정 지연시간 안에 해결되는 것의 최소 비율을 정할 수도 있다. 2장 “방법론”
에서 주관성을 다루는 다른 방법도 설명한다. 그런 방법에는 문제를 연산 지연시간의 비율로 기술하
는 지연시간 분석 등이 있다.
1.5.2 시스템은 복잡하다
주관성과 더불어 시스템이 복잡하고 어디서부터 분석을 시작할지가 불명확하다는 점도 성능을 도전
적인 분야로 만든다. 때로 네트워크를 비난하는 식의 추측에서 시작할 수도 있지만 성능 분석가는
그런 추측이 맞는지 확인해야만 한다.
191장. 들어가며
때때로 별도로 분석하면 잘 동작하는 개별적인 하위 시스템의 복잡한 상호작용에 의해 성능 문제가
생겨날 수도 있다. 이런 일은 한 구성 요소의 오류가 다른 구성 요소에 성능 문제를 일으키는 경우인
실패의 전파(cascading failure)로 인해 생길 수 있다. 최종적으로 생겨나는 문제를 이해하기 위해
서는 구성 요소 간의 복잡한 관계를 풀고, 어떻게 각 요소가 문제를 야기했는지 이해해야 한다.
병목 또한 복잡하고 여러 예상하지 못한 방식으로 연관돼 있기 마련이다. 병목을 하나 해결하는 것
이 우리의 바램과 달리 단지 병목지점을 시스템의 다른 위치로 옮기는 것에 불과해서 전체 성능에는
큰 변화가 없는 경우도 있다.
시스템의 복잡성과는 별도로 프로덕션 부하의 복잡한 특성이 성능 이슈를 야기했을 수도 있다. 이런
경우는 결코 실험실 환경에서 재현할 수 없거나, 어쩌다 한 번만 재현할 수 있는 경우도 많다.
복잡한 성능 이슈를 해결하기 위해 전체적인 접근법이 필요할 때도 있다. 전체 시스템(시스템 내부
는 물론 외부와의 상호작용까지)을 조사해 봐야 할 수도 있다. 이를 위해서는 한 사람만으로는 불
가능한 다양한 범위의 기술이 필요하다. 따라서 성능 엔지니어링은 폭넓고, 지적으로 도전적인 분
야다.
2장에서 설명할 내용과 같이 이러한 복잡성을 다룰 때 여러 방법론이 도움될 수 있다. 6장부터 10장
까지는 CPU, 메모리, 파일 시스템, 디스크, 네트워크 등 시스템 자원에 대한 구체적인 방법론을 다
룬다.
1.5.3 여러 성능 문제가 존재할 수 있다
성능 문제를 찾는 것은 보통 어렵지 않다. 복잡한 시스템이라면 문제가 많이 있는 경우도 흔하다. 이
런 예를 보고 싶다면 여러분이 사용 중인 운영체제나 애플리케이션의 버그 데이터베이스를 열어서
“성능”이란 단어를 찾아보라. 아마도 놀라게 될 것이다! 대부분의 경우 알려져 있지만 수정이 안 된
성능 문제가 많이 있을 것이다. 심지어 고성능으로 알려진 성숙한 소프트웨어의 경우에도 그렇다.
이는 성능을 분석할 때 마주칠 수 있는 또 다른 어려움이라 할 수 있다. 따라서 성능상 문제가 있다
는 것을 알아내는 것이 아니라 가장 문제가 되는 것(들)이 어떤 것인지 알아내는 것이 성능 분석 시
해야 할 일이다.
이를 위해 성능 분석가는 각 문제의 규모를 정량화할 수 있어야 한다. 어떤 성능 문제는 여러분이 당
면한 부하에 적용할 수 없을 것이고, 어떤 문제는 아주 작은 부분에서만 적용 가능할 것이다. 이상
적인 경우라면 각 문제를 정량화할 뿐 아니라 각각을 해결하면 얼마나 속도 향상을 가져올 수 있는
지도 추산해야 한다. 이런 정보는 의사 결정권자들이 엔지니어링이나 운영 자원을 사용할 수 있도록
시스템 성능 분석과 최적화: 엔터프라이즈에서 클라우드 환경까지 아우르는20
정당화해야 할 때 가치가 있다. 성능을 정량화할 때 잘 들어맞는 (물론 사용 가능한 경우에만) 지표
로는 지연시간이 있다.
1.6 지연시간
지연시간(latency)은 기다리느라 소모한 시간을 재는 척도로 널리 사용된다. 이 용어는 어떤 연산이
완료될 때까지 걸리는 시간을 의미할 수도 있다. 이런 연산으로는 애플리케이션 요청, 데이터베이스
질의, 파일 시스템 연산 등이 있다. 예를 들어, 링크를 클릭해서 화면에 사이트가 그려지고 웹사이트
를 완전히 로딩할 때까지 걸리는 시간을 지연시간이라 할 수 있다. 이는 고객이나 웹사이트를 제공
하는 회사에 중요한 지표다. 지연시간이 크면 불만이 커지고, 고객들은 다른 사이트에서 업무를 볼
것이다.
지표로써의 지연시간은 최대 속도 향상 값을 예측할 수 있게 해준다. 예를 들어, 그림 1.3은 100ms
걸리는 데이터베이스 질의를 보여준다. 전체 지연시간 중 80ms는 디스크 읽기를 기다리느라 블록
된 것이다. 따라서 디스크 읽기를 완전히 없앨 수 있다면(캐시 등을 사용) 최대로 얻을 수 있는 성능
향상은 5배다. 이는 예상치다. 또한 이 계산은 성능 문제를 정량화한다. 디스크 읽기는 질의를 5배
더 느리게 만든다고 말할 수 있기 때문이다.
데이터베이스 질의: 100ms
디스크 읽기: 80ms
CPU 대기
스레드
CPU 실행
그림 1.3 디스크 I/O 지연시간 예제
이런 계산은 다른 지표로는 불가능하다. 일례로 초당 I/O 횟수(IOPS, IO operation per second)
는 I/O의 종류에 따라 달라지며, 서로 다른 두 IOPS를 직접적으로 비교할 수 없다. 어떤 변경에 의
해 IOPS가 80% 줄어든다고 해도 성능에 끼치는 영향이 얼마나 될지 예측하기란 쉽지 않다. 만약
IOPS는 5배 줄었지만 각 I/O의 데이터 크기(바이트 단위)는 10배로 늘어났다면 어떻게 될까?
네트워크 상황에서 지연시간은 연결 설정에 걸리는 시간을 의미하며, 데이터 송수신 시간을 의미하
지 않는다. 이 책에서는 각 장의 앞부분에서 용어를 명확히 정리해서 상황이나 맥락에 따라 달라지
는 의미를 구분할 것이다.
211장. 들어가며
지연시간이 유용한 지표이긴 하지만 언제 어디서나 사용 가능하지는 않다. 어떤 시스템은 평균 지연
시간만을 제공할 수도 있고, 어떤 시스템은 전혀 지연시간을 제공하지 않을 수도 있다. 동적 트레이
싱이 출현하면서 지연시간을 원하는 어느 시점에서든 측정할 수 있게 됐고, 전체 지연시간 분포 데
이터를 제공할 수 있게 됐다.
1.7 동적 트레이싱
동적 트레이싱(dynamic tracing)을 이용하면 실행 중인 프로덕션 환경에서 모든 소프트웨어에 계
측도구를 심을 수 있다. 이는 메모리에 존재하는 CPU 명령어 위에 동적으로 계측 도구를 구축하는
기법이다. 이를 통해 실행 중인 어떤 소프트웨어든지 원하는 성능 통계를 만들 수 있으며, 소프트웨
어에 원래부터 들어있던 통계가 제공하는 범위를 훨씬 벗어나는 관찰이 가능하다. 관찰 능력의 미비
로 예전에는 해결할 수 없었던 문제를 이제 풀 수 있게 됐다. 예전에도 풀 수 있긴 했지만 실질적으로
는 풀 수 없는 것이나 다름없이 어렵던 문제를 동적 트레이싱으로 쉽게 풀 수 있는 경우도 자주 있다.
동적 트레이싱은 전통적인 관찰 방법과는 아주 다르다. 그래서 처음에는 어떤 역할을 하는지 알아채
기 어렵다. 운영체제 커널을 생각해 보자. 커널 내부를 분석하는 것은 캄캄한 방을 커널 엔지니어가
미리 예상해서 박아 둔 촛불(시스템 통계)을 사용해 탐험하는 것과 같다. 반면 동적 트레이싱은 아
무데나 비출 수 있는 손전등 불빛과 같다.
맨 처음에 동적 트레이싱은 DTrace로 만든 프로덕션용 도구였다. DTrace는 자체 프로그래밍 언어
인 D3를 포함해 여러 다른 기능도 제공한다. DTrace는 썬 마이크로시스템즈에 의해 개발되어 솔라
리스 10 운영체제에 2005년에 탑재됐다. 이것이 바로 솔라리스에서 가장 먼저 오픈소스화된 구성
요소이기도 했다. 그 후 맥 OS X과 FreeBSD에 포팅됐고, 이제는 리눅스까지 포팅됐다.
DTrace 이전에는 커널과 다른 소프트웨어에 미리 심어둔 관찰 지점인 정적 프로브(probe)를 사용
해 시스템 트레이싱이 이뤄졌다. 이런 프로브는 탐지 범위가 제한적이고 사용하기에 시간이 많이 필
요했고, 설정, 트레이싱, 데이터 저장, 분석 과정을 반복해야 했다.
DTrace는 사용자와 커널 수준의 소프트웨어를 정적으로나 동적으로 트레이싱할 수 있고 실시간으
로 데이터를 제공한다. 다음은 간단한 예로, ssh 로그인 시 프로세스 실행을 트레이싱한다. 트레이
싱은 시스템 전체에 걸쳐 진행된다(특정 프로세스 ID와 연관돼 있지 않다).
3 (옮긴이) 범용 언어 D와는 다른 언어다.
시스템 성능 분석과 최적화: 엔터프라이즈에서 클라우드 환경까지 아우르는22
# dtrace -n 'exec-success { printf("%d %s", timestamp, curpsinfo->pr_psargs); }'
dtrace: description 'exec-success ' matched 1 probe
CPU ID FUNCTION:NAME
2 1425 exec_common:exec-success 732006240859060 sh -c /usr/bin/locale -a
2 1425 exec_common:exec-success 732006246584043 /usr/bin/locale -a
5 1425 exec_common:exec-success 732006197695333 sh -c /usr/bin/locale -a
5 1425 exec_common:exec-success 732006202832470 /usr/bin/locale -a
0 1425 exec_common:exec-success 732007379191163 uname -r
0 1425 exec_common:exec-success 732007449358980 sed -ne /^# START exclude/,/^#
FINISH exclude/p /etc/bash/bah_completion
1 1425 exec_common:exec-success 732007353365711 -bash
1 1425 exec_common:exec-success 732007358427035 /usr/sbin/quota
2 1425 exec_common:exec-success 732007368823865 /bin/mail -E
12 1425 exec_common:exec-success 732007374821450 uname -s
15 1425 exec_common:exec-success 732007365906770 /bin/cat -s /etc/motd
이 예에서 DTrace는 타임스탬프(단위: ns), 프로세스 이름, 그리고 인자를 출력한다. D 언어로 더
복잡한 스크립트를 만들 수도 있다. 이를 사용하면 원하는 특화된 지연시간 지표를 만들고 계산할
수 있다.
DTrace와 동적 트레이싱에 대해서는 4장 “관찰 도구”에서 설명할 것이다. 이 책에서는 리눅스와 솔
라리스 기반 시스템에서 사용하는 더 많은 한 줄짜리 DTrace 코드 및 스크립트를 볼 수 있다. 고급
사용법을 알고 싶은 독자라면 DTrace에 대한 별도의 책[Gregg 11]을 참고한다.
1.8 클라우드 컴퓨팅
시스템 성능에 가장 큰 영향을 끼친 최근의 발전은 클라우드 컴퓨팅과 그 바탕이 되는 가상화 기술
의 대두다.
클라우드 컴퓨팅을 이용하면 작은 시스템의 개수를 늘려가면서 애플리케이션의 균형을 유지할 수
있는 아키텍처를 통해 빠르게 규모를 확장할 수 있다. 이런 방법을 이용하면 필요에 따라 금방 클라
우드로부터 용량을 추가할 수 있기 때문에 엄밀한 수용량 계획의 필요성이 줄어든다. 반면 클라우드
컴퓨팅이 성능 분석의 필요를 증가시키는 측면도 있다. 클라우드 사용량은 보통 시간 단위로 청구
되기 때문에 더 적은 시스템을 사용하도록 성능이 향상됐다는 것은 직접적인 비용 절감을 의미할 수
있는데, 성능 분석을 통해 더 적은 자원을 사용하면 시스템을 덜 사용해 비용을 절감할 수 있다. 이
