서문
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 요약
험난한 세상에서 생존할 시스템을 설계하고 배치하라!
야근과 특근으로 채워진 여러분의 개발 프로젝트가 내일모레면 끝난다. 충혈된 두 눈을 커피로 자극하며 마지막 혼신을 다해 코딩을 하는 동료가 있으니, 힘든 여정이었지만 프로젝트의 끝을 볼 것 같다.
잠깐! 프로젝트를 끝내기만 하면 어딘가로 떠나 편하게 며칠 쉴 수 있다고 생각하는가?
끝이라고 생각하지만 왠지 으스스한 게, 프로젝트 골목 어디선가 프레디가 튀어나올 것 같지 않은가?
그렇다. 프로젝트가 끝났다고 모든 게 끝난 것은 아니다. 프로젝트의 끝은 새로운 시작을 의미한다는 것을 우리 모두는 잘 알고 있다. 프로젝트 기간 동안 겨울잠을 자고 있던 전화기는 긴 잠에서 깨어나 아침부터 저녁까지 배고프다고 울어댄다. 얼굴도 모르고 목소리도 처음 듣는 분노에 찬 누군가가 전화기 건너 편에서 여러분을 잡아 먹으려고 한다.
여러분이 저지른(?) 죄라고는 설계서대로 구현해 놓았다는 미필적 고의(?)밖에 없다.
아기 예수의 탄생이 기독교 역사의 이정표 역할을 하듯이, 프로젝트 완료는 프로젝트 인생의 새로운 마일스톤인 셈이다. 정규분포의 평균에서 돌아가던 여러분의 시스템은 6Sigma의 품질을 요구하는 험난한 세상으로 방출된다. 미숙한 아기가 엄마의 손길을 필요로 하듯이, 반쯤 완성된 시스템은 오랫동안 여러분의 따스한 타이핑과 클릭으로 보살펴 주어야 한다
- 갓 태어난 아기를 보살피는 부모의 삶을 두 번 다시 겪고 싶지 않다면
- 어디선가 본 듯한데 잘 기억이 나질 않는 메멘토 같은 삶이 싫다면?
- 프로젝트가 끝난 것이 진짜 끝났다는 것을 의미하는 사전을 갖고 싶다면
우리는 ‘Release it!’ 이후의 삶에 대비해야 한다.
오프라인 서점, 인터넷 서점 그리고 여러분의 책장에 있는 개발서적은 완료 이전의 삶을 다룬다. 물론 이런 서적이 있기에 험난한 프로젝트를 눈부신 완료로 탈바꿈할 수 있다. 그러나 50퍼센트가 부족하다. 항상 경험하게 되는 50퍼센트의 삶을 알려주지 않기 때문이다.
『Release it: 성공적인 출시를 위한 소프트웨어 설계와 배치』는 바로 나머지 50퍼센트의 삶을 편하게 만들기 위해서, 프로젝트 동안 무엇을 고민해야 하는지 알려준다.
중고단행본
바보 빅터
