- 본 도서의 개정판이 출간되었습니다.
이미 소장하고 있다면 판매해 보세요.
- 해외배송 가능?
- 문화비소득공제 가능
이 분야의 이벤트
위키북스 IT Leaders 시리즈
책소개
목차
|
서문
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 요약 |
저자 소개 1
고려대학교 기계공학과를 졸업하였으며 동대학원에서 석사를 마쳤다. 소프트웨어 개발, 프로젝트 관리, 컨설팅의 업무를 수행하고 있다. 관심 분야로는 더 나은 개발 환경 및 직장생활이고, 이에 대한 저작 작업에 주력하고 있다. 현재는 차량용 임베디드 소프트웨어 개발, 컨설팅을 하고 있다. 읽은 것과 생각한 것을 블로그(http://talk-with-hani.com)와 트위터(http://twitter.com/talkwithhani)에 꾸준히 남기려고 노력한다. 저서로는 『시지프스를 다시 생각하다』『겸손한 개발자가 만든 거만한 소프트웨어』『도와주세요! 팀장이 됐어요』 등이 있으며 역서로
고려대학교 기계공학과를 졸업하였으며 동대학원에서 석사를 마쳤다. 소프트웨어 개발, 프로젝트 관리, 컨설팅의 업무를 수행하고 있다. 관심 분야로는 더 나은 개발 환경 및 직장생활이고, 이에 대한 저작 작업에 주력하고 있다. 현재는 차량용 임베디드 소프트웨어 개발, 컨설팅을 하고 있다. 읽은 것과 생각한 것을 블로그(http://talk-with-hani.com)와 트위터(http://twitter.com/talkwithhani)에 꾸준히 남기려고 노력한다. 저서로는 『시지프스를 다시 생각하다』『겸손한 개발자가 만든 거만한 소프트웨어』『도와주세요! 팀장이 됐어요』 등이 있으며 역서로는 『뽀모도로 테크닉』『고약한 문제, 합당한 해결』『Manage it!』『Release it』『애자일 프랙티스』『실천가를 위한 실용주의 프로젝트 관리』『레일스와 함께하는 애자일 웹개발』등이 있다.
신승환의 다른 상품
저자 : 마이클 나이가드
마이클 나이가드(Michael Nygard)는 15년이 넘는 경력의 전문 프로그래머이자 아키텍트다. 그는 미국 정부, 군대를 포함하여 은행, 재정, 농업 그리고 유통업에 시스템을 인도하였다. 마이클은 수많은 기사와 사설을 기고했고 컴덱스에서 연설을 했으며 초창기 자바서적을 공동으로 집필하기도 했다.
역자 : 정태중
고려대학교 기계공학과와 동대학원을 졸업하였고, 현재 LG전자 생산연구원에 근무하면서 자동화 장비 프로그램과 비전 알고리즘 개발 업무를 수행하고 있다. 공역한 책으로 『실천가를 위한 실용주의 프로젝트 관리』(위키북스), 『애자일 프랙티스』(인사이트)가 있다
품목정보
- 발행일
- 2007년 11월 28일
- 쪽수, 무게, 크기
- 442쪽 | 865g | 175*225*30mm
- ISBN13
- 9788992939102
책 속으로
|
여러분이 프로젝트에 공을 들인 지 1년이 넘었다. 드디어, 모든 기능들이 실제로 완성된 것처럼 보이고, 대부분의 기능들을 위한 단위 테스트도 있다. 안도의 한숨을 쉬어도 좋다. 일은 끝났다. 정말 그럴까?
‘기능이 완성되었다는 것’이 ‘제품을 출시할 준비가 되었음’을 뜻할까? 여러분의 시스템은 정말로 배치될 준비가 됐는가? 여러분이 없더라도, 시스템은 운영요원에 의해 잘 돌아가고 실제 사용자들과 부딪히는데 문제가 없겠는가? 한밤중에 비상 전화나 호출기가 울린다면 수렁에 빠지는 기분이 들지 않을까? 결국 지금까지 구현된 모든 기능보다 앞으로 개발할 것이 훨씬 많다는 사실을 알게 된다. 너무나 자주, 프로젝트 팀은 실전에서 (정말로 원활한) 운영을 목표로 삼는 대신, QA 테스트 통과를 목표로 삼는다. 즉, 여러분이 하는 많은 일들은 십중팔구 테스트 통과에 초점을 맞춘다. 그러나 테스트만으로(애자일 테스트, 실용주의 테스트, 자동화된 테스트일지라도) 소프트웨어가 실제 세상에 나갈 준비가 되었다는 것을 증명하는 데는 충분하지 않다. 유별난 실제 사용자, 엄청난 트래픽, 들어보지도 못한 나라의 바이러스를 만드는 일당으로 가득한 실제 세상의 스트레스와 스트레인(strain)은, 우리가 테스트의 대상으로 삼았던 것들을 훌쩍 뛰어넘는다. 여러분의 소프트웨어가 실제 세상의 가혹한 현실에 맞설 준비가 되었는지 확인해야 한다. 이 책의 목적은 이러한 문제들이 어디에 있는지, 문제들을 극복하려면 무엇이 필요한지 보여주는 데 있다. 그러나 시작하기 전에, 널리 알려진 몇 가지 오해에 대해 얘기해 보자. 우선, 온갖 노력을 다해 계획했어도, 나쁜 일들은 여전히 생긴다는 사실을 받아들여야 한다. 물론 가능하다면 나쁜 일을 예방하는 것이 현명하다. 그러나 가능한 모든 나쁜 사건들을 예측하여 제거했다고 가정하는 것은 너무나 치명적이다. 대신에, 여러분은 가능한 조치를 취하고 예방할 수 있기를 바라야 하지만, 예상치 못한 심각한 트라우마가 시스템에 생기더라도 전체 시스템이 복구될 수 있다고 확신해야 한다. 둘째로, ‘릴리스 1.0(Release 1.0)’은 개발 프로젝트의 끝이 아니라 시스템의 삶이 시작되는 것임을 깨달아야 한다. 이런 상황은 부모가 다 자란 자녀를 처음으로 떠나 보내는 것과 비슷하다. 여러분은 성인 자녀가 돌아와 여러분과 함께 지내길 바라지 않을 것이다. 더구나 배우자, 손자 네 명, 개 두 마리 그리고 애완용 앵무새와 함께라면 말이다. 이처럼, 개발하는 동안 여러분이 내리는 설계 결정은 릴리스 1.0 이후에 펼쳐질 여러분 삶의 질에 큰 영향을 미칠 것이다. 실전 환경에 맞도록 시스템을 설계하는 데 실패한다면, 릴리스 이후 여러분의 삶은 ‘흥분’으로 채워질 것이다. 물론 좋은 의미의 흥분이 아니다. 이 책에서, 중요한 설계 트레이드오프(trade-off)를 살펴보고, 어떻게 영리하게 설계 트레이드오프를 결정하는지 알게 될 것이다. 그리고 마지막으로, 기술에 대한 우리들의 공동체적인 애착과 멋진 신기술, 근사한 시스템에도 불구하고, 여러분은 결국 이러한 기술들이 전혀 중요하지 않다는 사실과 마주쳐야 한다. 우리에게 일용할 양식을 주는 세계, 즉 비즈니스 세상에서 모든 것은 돈으로 귀착되기 때문이다. 시스템은 비용을 지출한다. 이 비용을 만회하기 위해 시스템은 직접적인 수익이나 비용을 절약하는 방법으로 돈을 벌어야 한다. 추가 작업은 비용을 지출하며 서비스 중단을 일으킨다. 자금과 운영 비용을 높이기 때문에 비효율적인 코드는 많은 돈을 지출케 한다. 여러분은 운영되고 있는 시스템을 이해하기 위해 이런 비용을 추적해야 한다. 그리고 여러분은 사업을 유지하기 위해 돈을 벌어야 한다. 아니면 적어도 잃지는 말아야 한다. 나는 이 책이 변화를 만들어서 여러분과 여러분의 조직이 거대한 손실과 일반적으로 엔터프라이즈 소프트웨어의 특성으로 표현되는 돈 낭비를 피하는 것을 도울 수 있기를 바란다 - 서문 중에서 |
출판사 리뷰
|
험난한 세상에서 생존할 시스템을 설계하고 배치하라!
험난한 세상에서 생존할 시스템을 설계하고 배치하라!야근과 특근으로 채워진 여러분의 개발 프로젝트가 내일모레면 끝난다. 충혈된 두 눈을 커피로 자극하며 마지막 혼신을 다해 코딩을 하는 동료가 있으니, 힘든 여정이었지만 프로젝트의 끝을 볼 것 같다. 잠깐! 프로젝트를 끝내기만 하면 어딘가로 떠나 편하게 며칠 쉴 수 있다고 생각하는가? 끝이라고 생각하지만 왠지 으스스한 게, 프로젝트 골목 어디선가 프레디가 튀어나올 것 같지 않은가? 그렇다. 프로젝트가 끝났다고 모든 게 끝난 것은 아니다. 프로젝트의 끝은 새로운 시작을 의미한다는 것을 우리 모두는 잘 알고 있다. 프로젝트 기간 동안 겨울잠을 자고 있던 전화기는 긴 잠에서 깨어나 아침부터 저녁까지 배고프다고 울어댄다. 얼굴도 모르고 목소리도 처음 듣는 분노에 찬 누군가가 전화기 건너 편에서 여러분을 잡아 먹으려고 한다. 여러분이 저지른(?) 죄라고는 설계서대로 구현해 놓았다는 미필적 고의(?)밖에 없다. 아기 예수의 탄생이 기독교 역사의 이정표 역할을 하듯이, 프로젝트 완료는 프로젝트 인생의 새로운 마일스톤인 셈이다. 정규분포의 평균에서 돌아가던 여러분의 시스템은 6Sigma의 품질을 요구하는 험난한 세상으로 방출된다. 미숙한 아기가 엄마의 손길을 필요로 하듯이, 반쯤 완성된 시스템은 오랫동안 여러분의 따스한 타이핑과 클릭으로 보살펴 주어야 한다 - 갓 태어난 아기를 보살피는 부모의 삶을 두 번 다시 겪고 싶지 않다면 - 어디선가 본 듯한데 잘 기억이 나질 않는 메멘토 같은 삶이 싫다면 - 프로젝트가 끝난 것이 진짜 끝났다는 것을 의미하는 사전을 갖고 싶다면 우리는 ‘Release it!’ 이후의 삶에 대비해야 한다. 오프라인 서점, 인터넷 서점 그리고 여러분의 책장에 있는 개발서적은 완료 이전의 삶을 다룬다. 물론 이런 서적이 있기에 험난한 프로젝트를 눈부신 완료로 탈바꿈할 수 있다. 그러나 50퍼센트가 부족하다. 항상 경험하게 되는 50퍼센트의 삶을 알려주지 않기 때문이다. 『Release it: 성공적인 출시를 위한 소프트웨어 설계와 배치』는 바로 나머지 50퍼센트의 삶을 편하게 만들기 위해서, 프로젝트 동안 무엇을 고민해야 하는지 알려준다. |
