[데이터 중심 애플리케이션 설계] 1장 신뢰할 수 있고 확장 가능하며 유지보수하기 쉬운 애플리케이션 - 신뢰성 (1)

 

인터넷은 잘 동작하고 있어서 대부분의 사람들은 인공의 무언가라기보다 태평양 같은 천연 자원으로 생각한다. 이런 규모의 기술이 이토록 오류가 없었던 적은 언제가 마지막일까? 
- 앨런 케이, Dr. Dobbs 저널 인터뷰에서(2012)

오늘날의 애플리케이션 

- 계산 중심(compute-intensive)(과거) -> 데이터 중심(data-intensive)

- 애플리케이션을 제한 하는 요소 : CPU 성능 (과거)  -> 데이터 양, 데이터의 복잡도, 데이터의 변화 속도

 

데이터 중심 표준 구성 요소 (standard building block)

- 데이터 베이스 : 구동 애플리케이션이나 다른 애플리케이션에서 나중에 다시 데이터를 찾을 수 있게 데이터를 저장

- 캐시 : 읽기 속도 향상을 위해 값비싼 수행 결과를 기억

- 검색 색인 : 사용자가 키워드로 데이터를 검색하거나 다양한 방법으로 필터링 할 수 있게 제공

- 스트림 처리 : 비동기 처리를 위해 다른 프로세스로 메세지 보내기

- 일괄 처리 : 주기적으로 대량의 누적된 데이터를 분석 

 

 

데이터 시스템을 포괄적 용어로 묶어야할까?

1. 새로운 도구들은 다양한 사용 사례에 최적화 됐기 때문에 더 이상 전통적인 분류에 딱 들어맞지 않는다. 

ex) 메세지 큐로 사용하는 datastore인 Redis 가 있고, 데이터베이스처럼 지속성(durability)을 보장하는 메시지 큐인 아파치 카프카도 있다. 

-> 분류간 경계가 흐려지고 있다. 

 

2. 점점 더 많은 애플리케이션이 단일 도구로는 더 이상 데이터 처리와 저장 모두를 만족시킬 수 없는 과도하고 광범위한 요구사항을 갖고 있다.

-> 작업은 단일도구에서 효율적으로 수행할 수 있는 태스크로 나누고 다양한 도구들은 애플리케이션 코드를 이용하여 연결함

 

=> 결론 : 데이터 시스템이라는 용어를 포괄적 용어로 묶어야하고 개발자는 애플리케이션 개발자 뿐만 아니라 데이터 시스템 설계자이다. 

다양한 구성 요소를 결합한 데이터 시스템 아키텍처의 예

 

 

1. 신뢰성(Reliability)

- 하드웨어나 소프트웨어 결함, 심지어 인적오류(human error) 같은 역경에 직면하더라도 시스템은 (무언가 잘못되더라도 지속적으로) 올바르게 동작해야한다. 

 

1.1 신뢰성의 조건

1) 애플리케이션은 사용자가 기대한 기능을 수행한다. 

2) 시스템은 사용자가 범한 실수나 예상치 못한 소프트웨어 사용법을 허용할 수 있다.

3) 시스템 성능은 예상된 부하와 데이터 양에서 필수적인 사용 사례를 충분히 만족한다. 

4) 시스템은 허가되지 않은 접근과 오남용을 방지한다. 

 

- 내결함성 시스템을 지속적으로 훈련하고 테스트해서 결함이 자연적으로 발생했을 때, 올바르게 처리할 수 있다는 자신감을 높인다. 

ex) 넷플릭스의 카오스 몽키(Chaos Monkey) 

 

* 결함 : 잘못될 수 있는 일 ≠ 장애(failure) : 사용자에게 필요한 서비스를 제공하지 못하고 시스템 전체가 멈추는 경우

* 내결함성(fault-tolerant) 또는 탄력성(resilient) : 결함을 예측하고 대처할 수 있는 시스템

 

1.2 하드웨어 결함 

ex) 하드디스크 고장, 램에 결함, 대규모 정전 사태, 네트워크 케이블을 뽑는 것 

- 하드디스크의 평균 장애 시간(MTTF) 은 약 10 ~ 50년으로 보고됨

 

- 시스템 장애율을 줄이기 위한 대응

1) 중복(redundancy)을 추가하는 방법 : 디스크 RAID 구성으로 설치할 수 있고 서버는 이중 전원 디바이스와 핫 스왑 가능한 CPU를, 데이터센터는 건전지와 예비 전원용 디젤 발전기를 갖출 수 있다. -> 전체 시스템의 중단시간 없이 한 번에 한 노드씩 패치 할 수 있음

 

1.2 소프트웨어 오류

- 하드웨어 결함과 약하게 상관관계가 존재한다. 

- 시스템 내 체계적 오류(systematic error) : 예상하기 어렵고 시스템 오류를 더 유발함

ex1) 잘못된 특정 입력이 있을 때, 모든 애플리케이션 서버 인스턴스가 죽는 소프트웨어 버그, 예를 들어, 리눅스 커널의 버그로 인해 많은 애플리케이션이 일제히 멈춰버린 원인이 된 2012년 6월 30일 윤초

ex2) CPU 시간, 메모리, 디스크 공간, 네트워크 대역폭처럼 공유 자원을 과도하게 사용하는 일부 프로세스

ex3) 시스템의 속도가 느려져 반응이 없거나 잘못된 응답을 반환하는 서비스

ex4) 한 구성 요소의 작은 결함이 다른 구성 요소의 결함을 야기하고 차례차례 더 많은 결함이 발생하는 연쇄 장애(cascading failure)

- 해결책이 존재 X -> 시스템 가정과 상호작용에 대해 주의 깊게 생각하기, 빈틈없는 테스트, 프로세스 격리, 죽은 프로세스의 재시작 허용, 프로덕션 환경에서 시스템 동작의 측정, 모니터링, 분석하기 등등 

 

 

1.3 인적 오류

- 중단의 주요 원인

- 인적 오류를 줄이는 방법

1) 오류의 가능성을 최소화하는 방향으로 시스템 설계하라. 

ex) 잘 설계된 추상화, API, 관리 인터페이스를 사용하면 "옳은 일"은 쉽게 하고 "잘못된 일"은 막을 수 있다. 하지만, 인터페이스가 지나치게 제한적이면, 사람들은 좋은 점을 잊은 채 제한된 인터페이스를 피해 작업한다. 따라서, 이런 시스템 설계는 올바르게 작동하게끔 균형을 맞추기 어렵다. 

2) 사람이 가장 많이 실수하는 장소(부분)에서 사람의 실수로 장애가 발생할 수 있는 부분을 분리하라. 특히, 실제 데이터를 사용해 안전하게 살펴보고 실험 할 수 있지만, 실제 사용자에게 영향이 없는 비프로덕션 샌드박스를 제공하라. 

3) 단위 테스트부터 전체 시스템 통합 테스트와 수동 테스트까지 모든 수준에서 철저하게 테스트해라. 자동 테스트는 널리 사용되며 잘 알려져 있다. 특히 정상적인 동작에서는 거의 발생하지 않는 코너 케이스를 다루는데 유용하다. 

4) 장애 발생의 영향을 최소화하기 위해 인적 오류를 빠르고 쉽게 복구할 수 있게 하라.

ex) 설정 변경 내역을 빠르게 롤백(roll back)하고 새로운 코드를 서서히 롤아웃(roll out)하게 만들고(예상치 못한 버그가 일부 사용자에게만 영향이 미치게 함) 이전 계산이 잘못된 경우에 대비해 데이터 재계산 도구를 제공하라

5) 성능 지표와 오류율 같은 상세하고 명확한 모니터링 대책을 마련하라. 모니터링은 조기에 경고신호를 보내줄 수 있고 특정 가정이나 제한을 벗어나는지 확인할 수 있게 한다. 

6) 조작 교육과 실습을 실행하라. 

 

 

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

- 신뢰성을 잃으면 생산성 저하의 원인이 되고 전자 상거래 사이트의 중단은 매출에 손실이 발생하고 명성에 타격을 줌