📖 오늘 읽은 범위
1장. 신뢰할 수 있고 확장 가능하며 유지보수하기 쉬운 애플리케이션
💡 책에서 기억하고 싶은 내용을 써보세요.
- 오늘날 다수의 애플리케이션은 계산중심(compute-intensive)과는 다르게 데이터 중심(data-intensive)적이다. (p.3)
- CPU 성능보다 더 큰 문제는 데이터의 양, 복잡도, 변화 속도다. (p.3)
- 애플리케이션마다 요구사항이 다르기 때문에 데이터베이스 시스템 또한 다양한 특성을 가지고 있다. (p.4)
- 데이터 저장과 처리를 위한 여러 도구들은 다양한 사용 사례에 최적화됐기 때문에 전통적인 분류에 들어맞지 않는다. (p.4)
- 점점 더 많은 애플리케이션이 단일 도구로는 데이터 처리와 저장 모두를 만족시킬 수 없다. (p.5)
- 신뢰성(Reliability): 하드웨어나 소프트웨어 결함, 또는 사람으로 인한 오류 같은 문제에 직면하더라도 시스템은 지속적으로 올바르게 동작해야한다. (p.6)
- 확장성(Scalability): 시스템의 데이터 양, 트래픽 양, 복잡도가 증가하면서 이를 처리할 수 있는 적절한 방법이 있어야 한다. (p.6)
- 유지보수성(Maintainability): 모든 개발자가 시스템 상에서 생산적으로 작업할 수 있게 해야 한다. (p.6)
- 결함을 예측하고 대처할 수 있는 시스템을 내결함성(fault-tolerant) 또는 탄력성(resilient)을 지녔다고 말한다. (p.7)
- 결함은 사양에서 벗어난 시스템의 한 구성요소인 반면, 장애는 사용자에게 필요한 서비스를 제공하지 못하고 시스템 전체가 멈춘 경우이다. (p.7)
- 실제로 많은 중대한 버그는 미흡한 오류 처리에 기인한다. (p.7)
- 시스템 장애율을 줄이기 위한 첫 번째 방법으로 각 하드웨어 구성 요소에 중복(redundancy)을 추가하는 방법이다. (p.8)
- 데이터 양과 애플리케이션의 계산 요구가 늘어나면서 더 많은 애플리케이션이 많은 장비를 사용하게 됐고 이와 비례해 하드웨어 결함율도 증가했다. 이에 따라 소프트웨어 내결함성 기술을 사용하거나 하드웨어 중복성을 추가해 전체 장비의 손실을 견딜 수 있는 시스템으로 점점 옮겨가고 있다. (p.8)
- 소프트웨어의 체계적 오류 문제는 신속한 해결책이 없다. 시스템이 뭔가를 보장하길 기대한다면 수행 중에 이를 지속적으로 확인해 차이가 생기는 경우 경고를 발생시킬 수 있다. (p.9)
- 오류의 가능성을 최소화하는 방향으로 시스템을 설계하라. (p.10)
- 사람이 가장 많이 실수하는 부분에서 사람의 실수로 장애가 발생할 수 있는 부분을 분리하라. (p.10)
- 단위테스트부터 전체 시스템 통합테스트와 수동테스트까지 모든 수준에서 철저하게 테스트하라. (p.10)
- 장애발생의 영향을 최소화하기 위해 인적 오류를 빠르고 쉽게 복구할 수 있게 하라. (p.10)
- 성능 지표와 오류율 같은 상세하고 명확한 모니터링 대책을 마련하라. 문제가 발생했을 때 지표(metrics)는 문제를 분석하는데 매우 중요하다. (p.10)
- 부하 매개변수로 웹 서버의 초당 요청 수, 데이터베이스의 읽기 대 쓰기 비율, 대화방의 동시 활성 사용자, 캐시 적중률 등이 될 수 있다. (p.11)
- 단순히 초당 12,000 건의 쓰기 처리는 쉽지만 트위터의 확장성 문제는 주로 트윗 양이 아닌 팬 아웃(fan-out) 때문이다. (p.11)
- 하둡 같은 일괄 처리시스템은 보통 처리량(throughput)에 관심을 가진다. 온라인 시스템에서 더 중요한 사항은 서비스 응답시간이다.(p.13)
- 일반적으로 평균보다는 백분위(percentile)를 사용하는 편이 좋다. 평균은 얼마나 많은 사용자가 실제로 지연을 경험했는지 알려주지 않는다. (p.14)
- 확장성과 관련해 용량 확장(scaling up), 규모 확장(scaling out) 으로 구분한다. (p.17)
- 다수의 장비에 부하를 분산하는 아키텍처를 비공유(shared-nothing) 아키텍처라 부른다. (p.17)
- 적절한 사양의 장비 몇 대가 다량의 낮은 사양 가상 장비보다 훨씬 간단하고 저렴하다. (p.17)
- 다수의 장비에 상태 비저장(stateless) 서비스를 배포하는 일은 상당히 간단하다. 하지만 단일 노드에 상태 유지(stateful) 데이터 시스템을 분산 설치하는 일은 아주 많은 복잡도가 추가적으로 발생한다. 때문에 확장 비용이나 데이터베이스를 분산으로 만들어야 하는 고가용성 요구가 있을 때까지 단일 노드에 데이터베이스를 유지하는 것(용량 확장)이 일반적이다. (p.17)
- 유지보수를 위해 지켜야 할 소프트웨어 시스템 설계 원칙은 운용성(시스템을 원활하게 운영할 수 있게 쉽게 만들어야 한다), 단순성(시스템의 복잡도를 최대한 제거하라), 발전성(시스템을 쉽게 변경할 수 있게 하라) 이 세가지다. (p.19)
✏️ 오늘 읽은 소감은? 떠오르는 생각을 가볍게 적어보세요.
인적 오류 파트를 읽으며 개발자의 실수에 의한 오류를 사전에 예방할 수 있는 다양한 방법들이 있다는 것을 알게 되었다. 우선 테스트 코드라도 작성해보자...
❓ 궁금한 내용이 있거나, 잘 이해되지 않는 내용이 있다면 적어보세요.
- 핫 스왑(hot-swap) 가능한 CPU
- 리눅스 커널의 2012년 6월 30일 윤초 버그
