앞서 정리한 내용에 이어서 다음으로 신뢰성, 확작성, 유지보수성 중에서 신뢰성 부분에 대해서 읽고 정리해보려고 한다.

신뢰성 (Reliability)

누구나 어떤 것을 신뢰하거나 신뢰하지 않는다는 의미가 무엇인지에 대한 직관적인 개념을 가지고 있다.

일반적으로 소프트웨어의 기대치는 다음과 같다.

• 애플리케이션은 사용자가 기대한 기능을 수행한다.
• 시스템은 사용자가 범한 실수나 예상치 못한 소프트웨어 사용법을 허용할 수 있다.
• 시스템 성능은 예상된 부하와 데이터 양에서 필수적인 사용 사례를 충분히 만족시킨다.
• 시스템은 허가되지 않은 접근과 오남용을 방지한다.

이 모든 것이 올바르게 동작함 을 의미하는 경우, 대략 무언가 잘못되더라도 지속적으로 올바르게 동작함 을 신뢰성의 의미로 이해할 수 있다.

잘못될 수 있는 일을 결함(fault) 라고 부른다.
그리고 결함을 대처할 수 있는 시스템을 내결함성(fault-tolerant) 또는 탄력성(resilient) 을 지녔다고 말한다.

내결함성(fault-tolerant) 이라는 말은 오해의 소지가 있는데 모든 종류의 결함을 견딜 수 있는 시스템을 만들 수 있음을 시사하지만 실제로 실현 가능하지 않다.
따라서, 특정 유형의 결함 내성에 대해서만 이야기하는 것이 타당하다.

결함은 장애와 동일하지 않다. 일반적으로 결함은 사양에서 벗어난 시스템의 한 구성 요소로 정의되지만, 장애는 사용자에게 필요한 서비스를 제공하지 못하고 시스템 전체가 멈춘 경우이다.

• 결함
  • 사양에서 벗어난 시스템의 한 구성 요소
• 장애
  • 사용자에게 필요한 서비스를 제공하지 못하고 시스템 전체가 멈춘 경우

고의적으로 결함을 유도함으로써 내결함성 시스템을 지속적으로 훈련하고 테스트해서 결함이 자연적으로 발생했을 때 올바르게 처리할 수 있다는 자신감을 높이는데 넷플릭스의 카오스 몽키(Chaos Monkey) 가 이런 접근 방식의 한 예이다.

*카오스 몽키(Chaos Monkey) 란?

DVD 대여업을 하던 넷플릭스가 비디오 스트리밍을 위한 분산 클라우드 시스템으로 전환하던 시기에 
처음 고안한 카오스 몽키(Chaos Monkey)는 이후 형태와 규모를 불문하고 모든 소프트웨어 개발 조직에 적용되는 엔지니어링 원칙으로 자리잡았다.  
핵심 원리는 의도적으로 시스템에 장애를 일으킴으로써 시스템의 탄력성을 더 높일 방법을 알아낸다는 것이다.

참고 자료 : https://www.itworld.co.kr/news/152680

하드웨어 결함

시스템 장애의 원인을 생각할 때 하드웨어 결함이 바로 떠오른다.
하드디스크 고장, 메모리 결함, 대규모 정전, 누군가가 네트워크 케이블을 잘 못 뽑는 것 등의 결함을 말한다.
규모가 큰 데이터 센터에서 일하는 사람은 많은 장비를 다룰 경우 이와 같은 일들이 늘상 일어난다고 말한다.

시스템 장애율을 줄이기 위한 첫 번째 대응으로는 각 하드웨어 구성 요소에 중복(redundancy) 을 추가하는 방법이 일반적이다. 구성 요소 하나가 죽으면 고장 난 구성 요소가 교체되는 동안 중복된 구성 요소를 대신 사용할 수 있다. 이런 접근 방식은 하드웨어 문제로 장애가 발생하는 것을 완전히 막을 수는 없지만 이해하기 쉽고 보통 수년 간 장비가 중단되지 않고 계속 동작할 수 있게 한다.

최근까지 단일 장비의 전체 장애는 매우 드물기 때문에 대부분의 애플리케이션은 하드웨어 구성 요소의 중복으로 충분했다.
새 장비에 백업을 매우 빠르게 복원할 수 있는 한, 장애 발생 시 중단시간(downtime) 은 대부분의 애플리케이션에 치명적이지 않다. 따라서 다중 장비 중복은 고가용성(high availability) 이 절대적으로 필수적인 소수의 애플리케이션에서만 필요했다.

하지만 데이터 양과 애플리케이션의 계산 요구가 늘어나면서 더 많은 애플리케이션이 많은 수의 장비를 사용하게 되었고 이와 비례해서 하드웨어 결함율도 증가했다. AWS 와 같은 일부 클라우드 플랫폼은 가상 장비 인스턴스가 별도의 경고 없이 사용할 수 없는 상황이 상당히 일반적이다. 이런 플랫폼은 단일 장비 신뢰성보다 유연성(flexibility) 와 탄력성(elasticity) 을 우선적으로 처리하게끔 설계되었기 때문이다.

소프트웨어 내결함성 기술을 사용하거나 하드웨어 중복성을 추가해 전체 장비의 손실을 견딜 수 있는 시스템으로 점점 옮겨가고 있다. 장비 장애를 견딜 수 있는 시스템은 전체 시스템의 중단시간 없이 한 번에 한 노드씩 패치할 수 있다.

소프트웨어 오류

보통 하드웨어 결함은 무작위적이고 서로 족립적이라고 생각한다. 한 장비의 결함이 다른 장비의 결함까지 이어지지 않는다는 말이다. 또 다른 부류의 결함으로 시스템 내 체계적 오류(systematic error) 가 있다. 이 결함은 예상하기 더 어렵고 노드 간 상관관계 없는 하드웨어 결함보다 오히려 시스템 오류를 더욱 많이 유발하는 경향이 있다.

• 잘못된 특정 입력이 있을 때 모든 애플리케이션 서버 인스턴스가 죽는 소프트웨어 버그
• CPU 시간, 메모리, 디스크 공간, 네트워크 대역폭처럼 공유자원을 과도하게 사용하는 일부 프로세스
• 시스템의 속도가 느려져 반응이 없거나 잘못된 응답을 반환하는 서비스
• 한 구성 요소의 작은 결함이 다른 구성 요소의 결함을 야기하고 차례차례 더 많은 결함이 발생하는 연쇄 장애

이 같은 소프트웨어 결함을 유발하는 버그는 특정 상황에 의해 발생하기 전가지 오랫동안 나타나지 않는다.

소프트웨어의 체계적 오류 문제는 신속한 해결책이 없다. 시스템의 가정과 상호작용에 대해 주의 깊게 생각하기, 빈틈없는 테스트, 프로세스 격리, 죽은 프로세스의 재시작 허용, 프로덕션 환경에서 시스템 동작의 측정, 모니터링, 분석하기와 같은 여러 작은 일들이 문제 해결에 도움을 줄 수 있다. 시스템이 뭔가를 보장하길 기대한다면 수행 중에 이를 지속적을 확인해 차이가 생기는 경우 경고를 발생시킬 수 있다.

인적 오류

사람은 소프트웨어 시스템을 설계하고 구축하며 운영자로서 시스템을 계속 운영한다. 이들이 최선의 의도를 갖고 있어도 사람은 미덥지 않다고 알려져 있다. 예를 들어 대규모 인터넷 서비스에 대한 한 연구에 따르면 운영자의 설정 오류가 중단의 주요 원인인 반면 하드웨어 결함은 중단 원인의 10~25% 정도에 그친다.

사람이 미덥지 않음에도 시스템을 어떻게 신뢰성 있게 만들까? 최고의 시스템은 다양한 접근 방식을 결합한다.

• 오류의 가능성을 최소화 하는 방향으로 시스템을 설계하라.
• 사람이 가장 많이 실수하는 장소(부분)에서 사람의 실수로 장애가 발생할 수 있는 부분을 분리하라.
• 단위 테스트부터 전체 시스템 통합 테스트와 수동 테스트까지 모든 수준에서 철저하게 테스트하라.
• 장애 발생의 영향을 최소화하기 위해서 인적 오류를 빠르고 쉽게 복구할 수 있게 하라.
• 성능 지표와 오류율 같은 상세하고 명확한 모니터링 대책을 마련하라.
• 조작 교육과 실습을 시행하라.

신뢰성은 얼마나 중요할까?

비즈니스 애플리케이션에서의 버그는 생산성 저하의 원인이고, 전자상거래 사이트의 중단은 매출에 손실이 발생하고 명성에 타격을 준다.

"중요하지 않은" 애플리케이션도 사용자에 대한 책임(responsibility) 이 있다.

사진 애플리케이션에 아이들의 사진과 동영상을 모두 보관한 부모를 생각해보자. 사진과 동영상이 보관된 데이터베이스에 갑자기 오류가 생기면 부모는 어떻게 느낄까? 그들은 백업을 복원하는 방법을 알고 있을까?

정리

시스템에 대한 신뢰성에 대해서 알아보았다. 이 책에서는 신뢰성의 의미를 무언가 잘못되더라도 지속적으로 올바르게 동작하는 것이라고 정의하고 있다. 무언가 잘된다는 것은 시스템의 결함이나 장애로 인해 문제가 발생하는 것이라고 볼 수 있는데 하드웨어의 결함은 늘상 있는 일이다. 그렇기에 구성요소에 중복을 추가하는 방벙블 통해 하드웨어 결함을 방지하는 노력을 할 수 있다. 최근까지 단일 장비의 전체 장애는 매우 드물기 때문에 대부분의 특정 애플리케이션을 제외한 일반적인 애플리케이션에서는 치명적이지 않다고 한다.

또 다른 결함으로는 시스템 내 체계적 오류로 소프트웨어 결함이 있다. 이 결함은 예상하기 어렵고 노드 간의 상관관계때문에 하드웨어보다 더 오류를 많이 유발하는 경향이 있다. 이러한 소프트웨어의 오류를 신속하게 해결할 수 있는 방법은 없기 때문에 시스템의 상호작용에 대해 주의깊게 생각하거나 테스트, 프로세스 격리 등의 여러 작을 일들을 통해 문제를 해결하는데 도움을 줄 수 있다. 결국에는 문제를 확인하고 해결해나가는 과정을 지속적으로 해야한다.

그리고 인적 오류가 발생할 수 있는데 결국에는 사람이 시스템을 만들고 운영하기 때문에 시스템 중단의 대부분의 오류를 차지한다고 한다. 그럼 사람이 미덥지 않음에도 신뢰성있는 시스템을 만들기 위해서는 다양한 접근 방식을 통해 시스템을 만들어야 한다. 오류의 가능성을 최소화하는 방향으로 설계한다거나, 단위 테스트부터 전체 시스템 통합 테스트까지 철저하게 테스트를 진행하거나, 빠르고 쉽게 복구할 수 있게 하거나 등등의 여러 접근 방식을 통해 인적 오류를 줄일 수 있다.

결국에는 이렇게 여러 결함이 발생할 수 있는 애플리케이션의 신뢰성이 과연 중요한가에 대한 질문에 나는 정말 중요한 요소라고 생각한다. 이 책에서도 사용자에 대한 책임이라는 말을 꺼낸 것과 같이 애플리케이션을 사용하는 사용자들에게 신뢰를 주기 위한 행동이라고 생각하고 엔지니어들의 가장 신경써야하는 부분 중 하나라고 생각한다.