요약
- 데이터 시스템의 포괄적인 의미와, 왜 포괄적으로 사용해야하는지 이해하게 됨.
- 애플리케이션의
신뢰성 에 대한 내용을 여러 관점에서 생각할 수 있었음.
- 하드웨어 결함
- 소프트웨어 결함
- 소프트웨어 결함을 찾기 위한 의식적인 작업들을 꾸준히 수행해야 함.
- 인적 결함
- 인적 오류를 최소화할 수 있는 방향으로 데이터 시스템을 설계해야 함.
- 각 결함에서 우리가 취해야할 자세에 대한 내용을 설명해주고 있음.
- 카오스 몽키 부분은 실제로 AWS GAME DAY 에서 경험해 본 적이 있다. 상당히 공감하며 책을 읽었다.
발췌
- 이 책에서는
신뢰할 수 없는 여러 부품으로 신뢰할 수 있는 시스템을 구축하는 다양한 기법을 다룸 (p7)
메모
1장. 신뢰할 수 있고 확장 가능하며 유지보수하기 쉬운 애플리케이션
- 일반적인 데이터 중심 애플리케이션은 공통으로 필요로 하는 기능을 제공하는 표준 구성 요소로 만듦. (Standard building block)
- 데이터베이스
- 캐시
- 검색 색인(search index)
- 스트림 처리(stream processing)
- 일괄 처리(batch processing)
- 위의 내용이 당연하다고 생각이 든다면,
데이터 시스템 이 성공적으로 추상화됐기 때문임.
- 하지만 애플리케이션마다 요구사항이 다르므로 애플리케이션을 만들 때 어떤 도구와 어떤 접근 방식이 수행 중인 작업에 가장 적합한지 생각해야 함.
데이터 시스템에 대한 생각
데이터 시스템 이라는 포괄적 용어로 묶어야 하는 이유는?
- 새로운 도구들은 다양한 사례(use case)에 최적화됐기 때문에 더 이상 전통적인 분류에 딱 들어맞지 않음.
- ex) 메시지 큐로 사용하는 데이터스토어인 레디스 / 데이터베이스처럼 지속성을 보장하는 메시지 큐인 아파치 카프카 → 분류 간 경계가 흐림.
- 많은 애플리케이션이 단일 도구로는 더 이상 데이터 처리와 저장 모두를 만족시킬 수 없는 과도하고 광범위한 요구사항을 갖고 있음.
- ex) 데이터베이스와 분리된 애플리케이션 관리 캐시 계층 (memcached)이나 엘라스틱서치(Elasticsearch), 솔라(solr) 같은 전문(full-text) 검색 서버는 애플리케이션 코드의 책임임.(데이터 베이스와 동기화, 색인 유지 작업들을 해야하기 때문)
복합 데이터 시스템(composite data system) 은 외부 클라이언트가 일관된 결과를 볼 수 있게끔 쓰기작업에서 캐시를 올바르게 무효화하거나 업데이트 하는 특정 보장 기능을 제공할 수 있음.
- 더이상 개발자는 애플리케이션 개발자뿐만 아니라 데이터 시스템 설계자이기도 함.
- 데이터 시스템, 서비스 설계시, 데이터를 정확하고 완전하게 유지하려면 어떻게 해야 할까?
- 대부분의 소프트웨어 시스템에서 중요하게 여기는 세 가지 관심사가 다음과 같음.
- 신뢰성 → 시스템이 어떠한 역경에 직면해도 시스템이 지속적으로 올바르게 동작해야함.
- 확장성 → 시스템이 데이터, 트래픽양이 증가하고 복잡도가 증가해도 이를 잘 처리할 방법이 있어야 함
- 유지보수성 → 시가이 지나더라도 다양한 사람이 시스템 상에서 생산적으로 작업할 수 있어야 함.
신뢰성
- 소프트웨어에서 일반적인 기대치는 다음과 같음.
- 애플리케이션은 사용자가 기대한 기능을 수행함.
- 사용자가 범한 실수나 예상치 못한 소프트웨어 사용법을 허용할 수 있음.
- 시스템 성능은 예상된 부하, 데이터 양에 실푸적인 사용 사례를 충분히 만족함.
- 시스템은 허가되지 않은 접근, 오남용을 방지함.
- 결함(fault) → 잘못될 수 있는 일
- 내결함성(fault-tolerant) or 탄력성(resilient) → 결함을 예측하고 대처할 수 있는 시스템
- 내결함성이란, 모든 종류의 결함을 견딜 수 있는 시스템을 의미하지 않음. 특정 유형의 결함 내성에 대한 내용임
- 결함은 장애(failure)와 동일하지 않음.
- 결함 : 사양에 벗어난 시스템의 한 구성 요소
- 장애 : 사용자에게 필요한 서비스 제공 X, 시스템 전체가 멈춤
- 내결함성 시스템에서 고의적으로 결함을 일으킴으로써 내결함성 시스템을 지속적으로 훈련하고 테스트해서 결함이 자연적으로 발생했을 때 올바르게 처리할 수 있다는 자신감을 높인다.
- ex) 넷플릭스의 카오스 몽키(Chaos Monkey)
- 위 내용은 결함 예방이 아닌 내결함성을 얘기한 것이지만, 보안 문제는 예방이 가장 좋은 경우임.
- 공격자가 시스템을 손상시키면 이는 되돌릴 수 없기 때문
하드웨어 결함
- 규모가 큰 데이터 센터에서는 하드웨어 결함이 늘상 일어난다고 함.
- 시스템 장애율을 줄이기 위한 대응
- 하드웨어 구성 요소에 중복(redundancy)을 추가하는 방법
- 디스크에 RAID 구성을 설치
- 서버는 이중 전원 디바이스와 핫 스왑(hot-swap) 가능한 CPU를 갖춤
- 데이터센터는 건전지, 예비 전원용 디젤 발전기를 갖춤
- 이마저도 옛날에는 고가용성이 절대적으로 필수적인 소수 애플리케이션에서만 필요했음.
- 하지만 이제는 데이터 양과 애플리케이션 계산 요구가 늘어나면서 더 많은 애플리케이션이 많은 수의 장비를 사용하고 있음.
- 위와 같은 이유로 하드웨어 중복성을 추가해서 전체 장비의 손실을 견딜 수 있는 시스템으로 옮겨가고 있음.
소프트웨어 오류
- 하드웨어 결함은 무작위적이며, 서로 독립적임.
- 하지만 소프트웨어 오류(시스템 내 체계적 오류)의 경우는 시스템 오류를 더욱 많이 유발한다.
- 잘못된 특정 입력이 있을 떄 모든 애플리케이션 서버 인스턴스가 죽는 소프트웨어 버그
- 공유 자원을 과도하게 사용하는 일부 프로세스
- 시스템 속도가 느려 반응이 없거나 잘못된 응답을 반환하는 서비스
- 한 구성 요소의 작은 결함으로 인해 다른 구성 요소의 결함을 야기하는 연쇄 장애(cascading failure)
- 이와 같은 소프트웨어 결함은 특정 상황에 의해 발생하기 전까지 오랫동안 나타나지 않음..
- 이러한 문제는 신속한 해결책이 없음.
- 시스템간의 상호작용에 주의깊게 생각하기
- 빈틈없는 테스트
- 프로세스 격리
- 죽은 프로세스 재시작 허용
- 프로덕션 환경에서 시스템 동작 측정
- 모니터링
- 분석
- 위와 같은 작은 일들이 문제 해결에 도움을 줄 수 있음.
인적 오류
- 한 연구에 따르면 운영자의 설정 오류가 중단의 주요 원인인 반면, 하드웨어(서버, 네트워크) 결함은 중단 원인의 10~25% 정도에 그침.
- 인적 오류가 있음에도, 시스템을 어떻게 신뢰성있게 만들까?
- 오류 가능성을 최소화하는 방향으로 시스템을 설계할 것
- 사람이 실수로 발생할 수 있는 부분을 분리해서 실제 사용자에게 영향이 없도록할 것
- 단위 테스트, 전체 시스템 통합 테스트, 수동 테스트, 모든 수준에서 철저히 테스트할 것 (특히 코너 케이스를 다루는데 유용)
- 인적 오류를 빠르게 쉽게 복구할 수 있게 할 것
- 성능 지표, 오류율과 같은 상세하고 명확한 모니터링 대책을 마련할 것 (ex : 원격 측정)
- 조작 교육과 실습을 시행할 것
신뢰성은 얼마나 중요할까?
- 비즈니스 애플리케이션에서 버그는 생산성 저하의 원인이고, 명성에 타격을 준다는 면에서 많은 비용이 듦.
- 애플리케이션 사용자에 대한 책임도 있음.
- 제품을 개발하는데 있어서 개발 비용을 줄이기 위해 신뢰성을 희생해야 하는 상황이 있음.
- 이때, 개발 비용을 줄이는 시점을 잘 알고 있어야 함.
댓글