추가 적립 안내

성공적인 출시 이후를 위한 소프트웨어의 설계와 배치를 다루는 전문서. '엔터프라이즈급'의 소프트웨어 시스템 개발자를 대상으로, 소프트웨어가 출시 이후, 혹독한 현실에 맞설 수 있도록 설계하고 배치하는 방법을 안내한다.

작동시간을 지속시키는 방법을 가르쳐주면서, 용량을 최적화하는 방법에 대해 중점적으로 다루고 있다. 또한 데이터 센터에서 사용하는 소프트웨어를 만들 때 아키텍트가 고려해야 하는 일반적인 디자인 쟁점에 대해 살펴본다. '사례 연구'를 수록하여 이해를 도와주고 있다.

누가 이 책을 읽어야 하는가?

이 책은 아키텍트, 설계자, 엔터프라이즈 급(enterprise-class, 여기에는 웹사이트, 웹 서비스, EAI 프로젝트 등이 포함된다) 소프트웨어 시스템 개발자를 대상으로 한다. 간단하게 ‘엔터프라이즈 급’이라는 것은 소프트웨어가 항상 가용(available)해야 하고, 그렇지 않다면 회사가 손해를 보는 것을 뜻한다. ‘엔터프라이즈 급’ 소프트웨어는 판매를 통해서 직접적으로 수익을 창출하는 상거래 시스템이나 직원들이 업무를 수행하기 위해 사용하는 핵심적인 내부 시스템일 수 있다. 시스템이 작동을 멈췄기 때문에 직원 중 한 사람이라도 일찍 퇴근해야 했다면, 이 책은 바로 여러분의 것이다.


이 책은 어떻게 구성되어 있나?

1부는 시스템을 생존시키는 방법을 보여준다. 즉, 시스템 가동시간을 유지하는 방법이다. 이중화(redundancy)를 이용한 신뢰성의 보장에도 불구하고, 분산 시스템은 기대하는 ‘99.999퍼센트’ 대신 고작 ‘88퍼센트’에 해당하는 가용성(availability)을 보여준다. 안정성(stability)은 다른 어떤 것보다 중요한 필수조건이다. 시스템이 날마다 멈추고 죽는다면, 어떤 사람도 시스템의 먼 미래에 대해서 관심을 두지 않는다. 이러한 환경에서는 단기적인 수정과 단기적인 사고가 지배한다. 안정성이 없이 생존할 수 있는 미래는 없기 때문에, 안정적으로 동작하는 기초 시스템을 어떻게 마련할지 살펴본다.

2부에서는 용량에 대해서 살펴본다. 시스템의 용량을 어떻게 측정하는지 살펴보며, 용량이란 실제로 무엇이고, 시간이 흐르면서 용량을 어떻게 최적화하는지 배운다. 좋은 디자인과 나쁜 디자인 그리고 이러한 디자인이 시스템의 용량에 주는 극적인 효과를 보여주기 위해 몇 가지 패턴과 안티패턴(antipattern)을 보여준다.

3부에서는 데이터 센터에서 사용하는 소프트웨어를 만들 때 아키텍트가 고려해야 하는 일반적인 디자인 이슈를 살펴본다.

4부에서는 전체 정보 생태계의 일부로서 시스템의 지속적인 삶을 살펴본다. 상자 안에 갇힌 슈뢰딩거의 고양이와 비슷한 실전 시스템이 너무나 많다. 즉, 시스템의 실제 상태를 관찰할 방법이 없다. 이렇게 해서는 건강한 생태계를 꾸미지 못한다. 정보가 없다면, 계획적인 개선을 하기란 불가능하다. 시스템의 건강 상태, 성능, 특징이 드러나면, 이 정보들을 기초로 작업할 수 있다. 사실 이러한 정보는 선택이 아닌 필수다. 때때로 말은 쉬워도 행동으로 옮기기는 어렵다. 따라서 변화를 막는 장애물을 살펴보고 이러한 장애물들을 줄이고 극복하는 방법도 함께 배울 것이다.


사례연구에 대해서

이 책의 주요한 주제를 설명하기 위해서 폭넓은 사례연구 몇 가지를 실었다. 이러한 사례연구는 저자가 관찰한 실제 사건과 실제 시스템의 고장(failure)에서 뽑아서 설명한다.

서문

1장 소개
1.1 올바른 목표를 향해서
1.2 힘을 사용하라
1.3 삶의 질
1.4 도전의 범위
1.5 여기도 백만달러, 저기도 백만달러
1.6 실용주의 아키텍처

1부 안정성(Stability)

2장 사례연구 : 항공사를 정지시킨 예외(Exception) 사건
2.1 정지 사태
2.2 결과
2.3 사후검토
2.4 확실한 증거
2.5 약간의 예방?

3장 안정성 소개
3.1 안정성이란?
3.2 고장 유형
3.3 크랙 전파
3.4 고장의 연쇄
3.5 패턴과 안티패턴

4장 안정성 안티패턴
4.1 통합지점
4.2 연쇄 반응
4.3 연속적인 고장
4.4 사용자들
4.5 블록된 스레드
4.6 자기부정 공격
4.7 확장 효과
4.8 불균형 용량
4.9 느린 응답
4.10 SLA 역전
4.11 끝이 없는 쿼리 결과

5장 안정성 패턴
5.1 제한시간을 사용하라
5.2 차단기
5.3 칸막이
5.4 정상 상태
5.5 빠른 고장
5.6 핸드셰이킹
5.7 테스트 하니스
5.8 분리하는 미들웨어

6장 안정성 요약

2부 용량(Capacity)

7장 사례연구 : 고객에게 짓밟히다
7.1 카운트다운과 런칭
7.2 QA를 향해
7.3 부하 테스트
7.4 군중에 의한 살인
7.5 테스트와의 차이
7.6 사고 여파

8장 용량 소개하기
8.1 용량 정의하기
8.2 제한조건
8.3 상관관계
8.4 확장성
8.5 용량에 대한 미신
8.6 요약

9장 용량 안티패턴
9.1 리소스 풀 경쟁
9.2 지나친 JSP 프라그먼트
9.3 AJAX 대량살상
9.4 너무 오래 머무는 세션
9.5 HTML 안에 낭비된 공간
9.6 새로고침 버튼
9.7 손으로 만든 SQL
9.8 데이터베이스 부영양화
9.9 통합지점 지연
9.10 쿠키 괴물
9.11 요약

10장 용량 패턴
10.1 풀 연결
10.2 캐싱을 신중하게 사용하자
10.3 콘텐트를 미리 계산해두자
10.4 가비지 콜렉터를 튜닝하자
10.5 요약

3부 일반적인 디자인 이슈

11장 네트워킹
11.1 멀티홈드 서버
11.2 라우팅
11.3 가상IP 주소

12장 보안
12.1 최소 권한의 원칙
12.2 설정된 비밀번호

13장 가용성
13.1 가용성 요구사항 모으기
13.2 가용성 요구사항 문서화
13.3 로드 밸런싱
13.4 클러스터링

14장 관리
14.1 QA가 실전과 일치하나?
14.2 설정 파일
14.3 시작과 종료
14.4 관리자 인터페이스

15장 디자인 요약

4부 운영(Operation)

16장 사례연구 : 경이적인 우주의 힘, 하찮은 삶의 터전
16.1 피크 시즌
16.2 아기의 첫 번째 크리스마스
16.3 맥박을 짚다
16.4 추수감사절
16.5 검은 금요일
16.6 바이탈 사인
16.7 진단 테스트
16.8 전문가에게서 호출
16.9 해결책 선택사항을 비교하다
16.10 해결책은 효과가 있었을까?
16.11 진정국면

17장 투명성
17.1 관점
17.2 투명성을 위한 설계
17.3 권능을 부여하는 기술
17.4 로깅
17.5 모니터링 시스템
17.6 법률적이며 사실상의 표준
17.7 운영 데이터베이스
17.8 지원 프로세스
17.9 요약

18장 적응
18.1 시간이 흐르면서 적응하기
18.2 적응 가능한 소프트웨어 설계
18.3 적응 가능한 엔터프라이즈 아키텍처
18.4 릴리스가 고통을 줘서는 안 된다
18.5 요약


부록
- 참고문헌
- 베타리더 리뷰 후기
- 찾아보기