본문 바로가기

책/데이터 중심 어플리케이션 설계

신뢰할 수 있고 확장이 가능하며 유지보수하기 쉬운 어플리케이션 (2)

반응형

꿀꿀

 

신뢰성 

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

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

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

 

잘못될 수 있는 일을 결함(fault) 이라 부른다 그리고 결함을 예측하고 대처할 수 있는 시스템을 내결함성(fault-tolerant)

또는 탄력성(resilent)라고 한다 

 

여기서 내결함성이라는 용어를 살펴보고 가야하는데 

모든 종류의 시스템의 결함을 견딜수 있는 시스템을 만들 수 있다는걸 시사하는데 실제로는 실현할 가능성이 있다고 말할 수 있는가? 

 

책에서는 블랙홀이 지구상 모든걸 삼켯을때 웹 호스팅이 가능할까? 없다 

따라서 특정 유형의 결함에서 말하는것이 타당하다 

 

 

또한 결함과 장애는 아예 다르다 

결함은 시스템의 한 구성 요소로 정의되지만 

장애는 사용자에게 필요한 서비스를 제공하지 못하고 shutdown한 경우다 

 

이것을 결함이라고 얘기할 수 있는가?

 

결함 확률을 0으로 줄이는 것은 불가능하다
그래서 결함으로 인한 장애가 일어나지 않겠끔 내결함성 구조를 설계하는 것이 가장 좋다 

 

 

소프트웨어 오류 

시스템 내 체계적 오류(systematic error)가 있다 이 결함은 예상하기가 더 어렵고 노드 간 상관관계 때문에 

상관관계가 없는 하드웨어 오류보다는 오히려 시스템 오류를 더욱 많이 유발하는 경향이 있다. 

  • 잘못된 입력으로 인해 모든 application server instance가 죽는 software 버그 
  • CPU 시간, memory, 디스크공간,  네트워크 대역폭 처럼 공유 자원을 과도하게 사용하는 일부 프로세스 
  • 시스템의 속도가 느려저 반응이 없거나 잘못된 응답을 반환하는 서비스 
  • 한 구성 요소를 작은 결함이 다른 구성 요소의 결함을 야기하고 차례차례 더 많은 결함이 발생하는 연쇄장애 

이같이 결함을 유발하는 버그는 특정 상황에 의해 발생하기 전까지 오랫동안 나타나지 않는다 

 

특정 상황에 의해 발생 이라는 말이 정말 소름돋는 말이다 마치 암이라고 보면 잠복기와 다름이 없다는것이다.. 

또한 더욱 더 소름인건 체계적 오류 문제는 신속한 해결책이 없다는것이다 특정상황에서 발생하는 특정 가정이 수없이 많기 때문에 

모니터링 요원을 두거나 지속적인 이벤트 체크를 해주는 것 이외는 방법이 없다는것이다 . 

 

시스템이 뭔가를 보장하기 바라면 수행 중에 지속적으로 확인하여 차이가 생기면 경고를 발생하여 빠른 대처를 가능할 수 있게 된다 

반응형