추가 적립 안내

오픈소스 소프트웨어의 최적화 과정을 추적하다!

『오픈소스 소프트웨어 성능 최적화 보고서』는 오픈소스의 느린 코드, 메모리 누수, 제어할 수 없는 잠복지연과 싸웠던 개발자들이 오픈소스 소프트웨어의 성능을 주제로 다양한 사례와 이야기를 담은 책이다. 저자들은 응용 프로그램 안에서 실제로 어떤 일이 일어나는지, 커다란 응용 프로그램을 구성하는 서로 다른 부분들이 어떻게 연동되는지를 상세히 파악해 문제 해결과정을 들려준다. 이처럼 생물정보학 연구 코드에서 웹 브라우저에 이르기까지 다양한 사례의 문제들이 등장하고 그만큼 다양한 해법들을 제시하고 있다.

크롬은 브라우저 전쟁에서 어떻게 살아남았을까?
크롬뿐만이 아니다. 여러 오픈소스 소프트웨어가 지금의 성능 최적화를 이루기까지
수많은 시행착오 속에 그 비밀이 들어있다!

1974년에 커누스(Donald Knuth)가 쓴 “이를테면 약 97%의 경우에서 작은 효율성들은 무시해야 마땅하다. 때 이른(premature) 최적화는 만악의 근원이다.”라는 유명한 문구를 기억할 것이다. 컴퓨터들이 당시보다 수백만 배는 빨라진 지금, 프로그래머들은 CPU 주기를 줄이고 바이트들을 아끼는 데 한 세대 전의 프로그래머들보다는 신경을 훨씬 덜 써도 된다. 그러나 “덜 쓴다”가 “안 쓴다”는 아니다. 가끔은 컴퓨터의 성능을 마지막 한 방울까지 짜내는 것이 정말로 중요할 때가 있다.

이 책은 오픈소스 소프트웨어의 느린 코드, 메모리 누수, 제어할 수 없는 잠복지연과 싸워야 했던 십여 명의 개발자들이 저술했다. 이 책을 통해 그들은 자신의 실수와 성공담을 공유하고, 주어진 도전과제에 자신이 어떻게 접근했는지를 독자가 어깨 너머로 볼 수 있게 한다. 생물정보학 연구 코드에서 웹 브라우저에 이르기까지 다양한 사례의 문제들이 등장하며, 그만큼이나 다양한 해법들이 제시된다.

독자가 신입 개발자이든 고참 개발자이든, 성능에 대한 동료 개발자들의 관점과 접근방식을 독자가 이해하는 데 이 책이 도움이 될 것이다.

이 책에서 논의하는 오픈소스 소프트웨어:
● 파이어폭스
● Pugixml
● 크롬
● Ninja
● EtherCalc
● Talos
● Warp
● Khmer
● Zotonic
● DAnCE
● Infinispan
● 또한 이동통신망의 성능에 대해서도 논의한다.

제1장 크롬의 고성능 네트워킹
1.1 구글 크롬의 역사와 기본 지침 1
1.2 성능의 여러 측면 2
1.3 현대적인 웹 응용 프로그램의 특징 4
1.4 네트워크 자원 요청 하나의 일생 5
1.5 “충분히 빠르다”의 의미 8
1.6 3천 미터 상공에서 본 크롬의 네트워크 스택 10
1.7 브라우저 세션의 일생 19
1.8 크롬은 사용하면 할수록 빨라진다 33
제2장 SocialCalc에서 EtherCalc로
2.1 초기 원형 38
2.2 첫 번째 병목 39
2.3 Node.js로 이식 41
2.4 서버 쪽 SocialCalc 42
2.5 Node.js 프로파일링 43
2.6 다중 코어 규모 확장 46
2.7 교훈 48
제3장 Ninja
3.1 크롬의 간단한 역사 54
3.2 Ninja의 설계 56
3.3 Ninja가 하는 일 58
3.4 Ninja의 최적화 60
3.5 결론 및 설계 대안 67
3.6 감사의 글 68
제4장 빛의 속도로 XML 파싱하기
4.1 소개 69
4.2 XML 파싱 모형들 70
4.3 pugixml 설계상의 선택들 71
4.4 파싱 72
4.5 DOM 자료구조 85
4.6 스택 기반 메모리 할당 89
4.7 스택 기반 할당자의 메모리 해제 지원 93
4.8 결론 95
제5장 MemShrink
5.1 소개 97
5.2 기반구조의 개요 98
5.3 잰 만큼 얻는다 101
5.4 달성하기 쉬운 과제들 105
5.5 내 잘못은 아니지만 내 문제 108
5.6 영속성은 탁월함의 대가 110
5.7 공동체 112
5.8 결론 113
제6장 최적화 원리 패턴들을 구성요소 배치와 구성 도구들에 적용하기
6.1 소개 115
6.2 DAnCE의 개요 119
6.3 최적화 원리 패턴들을 DAnCE에 적용하기 123
6.4 결론 140
제7장 Infinispan
7.1 소개 145
7.2 개요 146
7.3 Infinispan의 벤치마킹 149
7.4 Radar Gun 150
7.5 성능 문제의 잠재적 근원 153
7.6 결론 159
제8장 Talos
8.1 개요 162
8.2 측정 대상의 이해 164
8.3 재작성 대 리팩터링 167
8.4 성능 문화 만들기 168
8.5 결론 171
제9장 Zotonic
9.1 Zotonic 소개 173
9.2 왜 Zotonic인가? 왜 Erlang인가? 174
9.3 Zotonic의 구조 177
9.4 문제 해결: 슬래시닷 효과에 맞서기 180
9.5 캐싱 계층들 183
9.6 Erlang의 가상 기계 190
9.7 Webmachine 라이브러리 변경 사항 194
9.8 자료 모형: SQL 기반 문서 데이터베이스 196
9.9 벤치마크, 통계치, 최적화 197
9.10 결론 199
9.11 감사의 글 200
제10장 이동통신망 성능의 비밀
10.1 소개 201
10.2 잠복지연의 근원들 202
10.3 셀 방식 이동통신망의 특성 203
10.4 네트워크 프로토콜 성능 208
10.5 TCP(전송 제어 프로토콜) 209
10.6 HTTP(하이퍼텍스트 전송 프로토콜) 213
10.7 TLS(전송층 보안) 216
10.8 DNS(도메인 이름 시스템) 219
10.9 결론 221
제11장 Warp
11.1 Haskell의 네트워크 프로그래밍 224
11.2 Warp의 구조 229
11.3 Warp의 성능 231
11.4 핵심 착안 233
11.5 HTTP 요청 파서 235
11.6 HTTP 응답 조합기 242
11.7 타이머를 이용한 정리 245
11.8 향후 작업 249
11.9 결론 251
제12장 생물정보학의 거대 자료 다루기
12.1 소개 253
12.2 khmer의 구조와 성능상의 고려사항 257
12.3 프로파일링과 측정 261
12.4 조율 265
12.5 전반적인 조율 266
12.6 병렬화 271
12.7 결론 275
12.8 향후 개선안 275
12.9 감사의 글 276
참고문헌 277
찾아보기 282

소프트웨어에서 단순함은 하나의 미덕이다. 항상 문제는 단순함을 얼마나 오래 유지할 수 있는가이다. Ninja는 특정한 값비싼 과제들을 다른 도구(GYP나 CMake)에 위임함으로써 빌드 시스템의 복잡성을 상당 부분 잘라 냈다. 그리고 그 덕분에 애초에 Ninja를 염두에 두고 만든 프로젝트가 아닌 다른 프로젝트들에서도 Ninja를 유용하게 사용할 수 있다. 나는 Ninja의 단순한 코드가 기여자들을 격려했으리라고 믿는다.
_67

소프트웨어를 최적화하기란 어렵다. 성공적인 최적화를 위해서는 거의 항상 저수준 미시적 최적화와 고수준 성능 지향적 설계 결정, 세심한 알고리즘 선택과 조율, 메모리와 성능, 구현 복잡도 사이의 절충 등 다양한 노력이 필요하다. pugixml은 아주 빠른 현업 수준 XML 파서를 제공하기 위해(그러한 목표를 위해 몇 가지 희생한 것들도 있긴 하지만) 이 모든 접근방식이 필요한 라이브러리의 예이다. 구현 세부사항의 상당 부분은 다른 프로젝트나 과제에 맞게 개조가 가능하다. 다른 프로젝트는 또 다른 파싱 라이브러리일 수도 있고, 아예 다른 뭔가일 수도 있겠다. 이 글에서 제시한 요령들이 독자의 흥미를 끌어당겼다면, 그리고 다른 프로젝트들에 유용하게 쓰인다면 좋겠다.
_95

파이어폭스 4는 웹 브라우저의 개방적 동영상 지원, JavaScript 성능, 그래픽 가속 같은 영역에서 커다란 진전을 이룩했지만, 안타깝게도 메모리 사용량 면에서는 크게 후퇴했다. (중략) 그로부터 약 1년 반이 지난 지금, 그들의 일치된 노력은 파이어폭스의 메모리 소비량과 평판을 급속도로 바꾸었다. 대부분의 사용자들의 머리에서 ‘메모리 누수(memory leak)’는 과거의 일이 되었으며, 이제는 파이어폭스가 다른 브라우저들과 비교할 때 가장 가벼운 브라우저들 중 하나로 간주되는 경우가 많다. 이번 장에서는 파이어폭스의 메모리 사용량을 개선하기 위한 노력들을 살펴보고 그 과정에서 배운 교훈들을 소개하고자 한다.
_97

내용 관리 시스템이나 프레임워크를 만들 때에는 웹 서버에서 시작해서 요청 처리 시스템, 캐싱 시스템을 거쳐 데이터베이스 시스템에 이르는 응용 프로그램의 전체 스택을 고려하는 것이 중요하다. 그 모든 구성요소가 잘 연동되어야 좋은 성능이 나온다. 자료를 미리 처리함으로써 성능을 크게 높일 수 있다. 텍스트 자료를 데이터베이스에 저장하기 전에 미리 특수 문자들을 탈출시키고 문제가 될 만한 부분을 소독하는 것이 그러한 전처리의 예이다. (중략) 급격한 방문자 증가를 처리하기 위한 또 다른 최적화는 서로 비슷한 요청들을 동적으로 부합시키고 그것들을 한 번에 처리해서 동일한 결과를 산출하는 것이다. 이를 잘 구현한다면 대리(proxy) 서버를 사용하지 않아도 되며, 모든 HTML 페이지를 동적으로 생성할 수 있다.
_199

이동통신망의 증폭된 잠복지연이 미치는 영향을 완화하려면 잠복지연을 악화시키는 네트워크 왕복운행을 줄여야 한다. 그러한 벅찬 성능 문제를 극복하는 데에는 왕복운행 프로토콜 메시지 교환을 최소화하거나 제거하는 데 전적으로 초점을 둔 소프트웨어 최적화 기법들을 도입하는 것이 꼭 필요하다.
_221

서열 해독 기술이 개선됨에 따라 산출되는 서열 자료의 양이 너무 커져서, 그런 자료를 기존의 방법으로 처리하는 컴퓨터 하드웨어의 능력을 넘어설 정도가 되었다. (최신 서열 해독 기술은 수백만에서 수십억에 이르는 엄청난 수의 유전체 판독 단편[50에서 100개의 뉴클레오티드들로 이루어진 서열]들을 산출한다.) 이러한 경향은 앞으로도 지속될 예상이며, 이는 곧 고성능 컴퓨팅(high performance computing, HPC) 및 분석, 정보과학 공동체에서 거대 자료(big data; 소위 빅데이터)[Varc]라고 부르는 문제에 속한다. 하드웨어가 제한 요소가 됨에 따라, 이 문제를 소프트웨어 해법을 통해서 완화하는 방법을 고민하는 사람들이 많아졌다. 이번 장은 그런 소프트웨어 해법 하나를 제시하고, 그 해법을 수 테라바이트의 자료를 처리할 수 있도록 조율, 확장한 방법을 설명한다.
_254