책너두 (데이터 중심 애플리케이션 설계) 25일차 (~284p)

요약

• 분산 시스템의 골칫거리에 대한 내용을 이해함.
• 결함과 부분장애에 대한 내용을 이해함.
  • 하드웨어 동작은 중간 장애 없이 잘 동작하거나 전체 장애가 발생한다.
  • 분산 시스팀에서는 부분 장애가 발생할 수 있는데, 비결정적임.
• 인터넷 서비스는 클라우드 컴퓨팅이며, 슈퍼컴퓨팅은 분산 시스템과 거리가 멀다.
• 신뢰성 없는 네트워크에 대한 내용을 이해함.
  • 분산 시스템은 비공유 시스템이며, 비동기 패킷 네트워크이기에 전송측과 수신측 패킷의 신뢰를 할 수 없음.
  • 현실적으로 네트워크 결함은 피할 수 없음.
  • 결함 감지를 하기 위해서는 응답측에서 응답을 받아야 함.
    • 타임아웃의 트레이드오프를 잘 결정해야 함.

메모

8장. 분산 시스템의 골칫거리

결함과 부분 장애

• 좋은 소프트웨어가 설치된 각각의 컴퓨터는 완전하게 동작하거나, 전체 장애가 발생한다.
  • 그 중간 상태가 되지는 않음.
• 분산 시스템에서는 시스템의 어떤 부분은 잘 동작하지만, 다른 부분은 예측할 수 없는 방식으로 고장날 수 있다.
  • 이를 부분 장애(partial failure)라고 함.
    • 부분 장애는 비결정적이기에 예측하기 어려움.

클라우드 컴퓨팅과 슈퍼컴퓨팅

• 슈퍼 컴퓨터는 계산 상태를 지속성 있는 저장소에 체크 포인트로 저장함.
  • 만약 노드 하나에 장애가 발생했다면 전체 클러스터 작업부하를 중단한다.
  • 장애가 발생한 노드가 복구되면, 마지막 체크포인트부터 계산을 재시작함.
    • 이러한 슈퍼 컴퓨터는 분산 시스템보다는 단일 노드 컴퓨터에 가까움.
    • 우리가 구현하려는 인터넷 서비스 시스템(= 클라우드 컴퓨팅)과도 매우 다름.
• 분산 시스템이 동작하게 만드려면 부분 장애 가능성을 받아들이고 소프트웨어 에 내결함성 메커니즘을 넣어야 함.
  • 단 몇 개의 노드만으로 구성된 작은 시스템이라도 부분 장애가 생길 수 있음.
  • 소프트웨어 운영자는 결함이 발생하면 소프트웨어가 어떻게 동작할지 알아야 함.
    • 이는 소프트웨어 설계의 일부임.

신뢰성 없는 네트워크

• 분산 시스템은 비공유 시스템임.
  • 네트워크로 연결된 다수의 장비들의 모음.
  • 각 장비는 자신만의 메모리, 디스크를 가지고 있음.
  • 다른 장비의 메모리나 디스크에 접근할 수 없음.
• 인터넷과 데이터센터 내부 네트워크 대부분은 비동기 패킷 네트워크(asynchronous packet network)임.
  • 노드간 메시지(패킷)을 보낼 수 있음.
  • 하지만, 네트워크는 메시지가 언제 도착할지, 혹은 메시지가 도착하기는 할 것인지 보장하지 않음.
• 전송 측은 패킷이 전송됐는지 아닌지조차 구별할 수 없음.
  • 또, 수신측의 응답을 받지 못하면, 그 이유를 아는 것은 불가능함.
    • 이 문제를 다루는 방법은 타임아웃임.
      • 하지만 타임아웃이 발생했을 때도 원격 노드가 응답을 받았는지는 알 수 없음.

현실의 네트워크 결함

• 현실의 네트워크 결함은 다양함.
  • 스위치의 소프트웨어 업그레이드 중 생기는 문제
    • 네트워크 토폴로지 재구성을 유발할 수 있음.
    • 그동안 네트워크 패킷이 1분 이상 지연 될 수 있음.
  • 상어가 해저 케이블을 물어뜯어 손상시킬 수 있음.
• 즉, 네트워크 결함은 드물더라도 일어날 수 있기에, 소프트웨어가 이를 처리할 수 있어야 함.
• 반드시 네트워크 결함을 견뎌내도록(tolerating) 처리할 필요는 없음.
  • 네트워크가 평상시에 믿을만 하다면, 네트워크 문제가 있을 때는 그냥 사용자에게 오류 메시지를 보여주는 것도 타당한 방법임.
  • 하지만, 소프트웨어는 그 문제에 어떻게 반응하고, 시스템이 그로부터 복구할 수 있도록 보장해야 함.

결함 감지

• 많은 시스템은 결함 있는 노드를 자동으로 감지할 수 있어야 함.
  • 하지만, 네트워크에 관한 불확실성 때문에 노드가 동작 중인지 아닌지 구별하기 어려움.
• 원격 노드가 다운되고 있다는 빠른 피드백은 유용하지만 의존할 수는 없음.
  • TCP 패킷이 전달됐다는 확인 응답(ack)을 했더라도, 애플리케이션이 그걸 처리하기 전에 죽을 수도 있음.
  • 따라서, 요청이 성공했음을 확인하고 싶다면 애플리케이션 자체로부터 긍정 응답을 받아야 함.
• 타임아웃이 만료되기를 기다렸다가, 타임아웃 내에 응답을 받지 못하면 마침내 도드가 죽었다고 선언할 수 있음.

타임아웃과 기약 없는 지연

• 타임아웃이 길면 노드가 죽었다고 선언될 때까지 기다리는 시간이 길어짐.
• 타임아웃이 짧으면 결함은 빨리 발견하겠지만 노드가 일시적으로 느려졌을 뿐인데도 죽었다고 잘못 선언할 위험이 높아짐.
  • 시스템이 이미 높은 부하에 허덕이고 있따면 성급하게 노드가 죽었다고 선언하는 것은 문제를 악화시킬 수 있음.
    • 노드가 실제로 죽지 않고 과부하 떄문에 응답이 느릴 뿐일 수도 있음.
      • 그 노드의 부하를 다른 노드로 전달하면 연쇄 장애를 유발할 수 있음.
• 비동기 네트워크는 기약 없는 지연(unbounded delay)이 있음.
  • 즉, 패킷을 가능한 한 빨리 보내려고 하지만, 패킷이 도착하는 데 걸리는 시간에 상한치가 없음.
  • 서버 구현은 대부분 어떤 최대 시간 내에 요청을 처리한다고 보장할 수 없음.

네트워크 혼잡과 큐 대기

• 컴퓨터 네트워크에서 패킷 지연의 변동성은 큐 대기 때문인 경우가 많음.
  • 네트워크 링크가 붐비면 슬롯을 얻을 때까지 기다려야함 → 네트워크 혼잡(network congestion)
  • TCP는 흐름제어를 수행함.
    • 혼잡 회피, 배압을 이용한 흐름제어는 노드가 네트워크 링크나 수신 노드에 과부하를 가하지 않도록 송신율을 제한함.
      • 이는 데이터가 네트워크로 들어가기 전에도 부가적인 큐 대기를 할 수 있음.
    • TCP는 타임 아웃안에 확인 응답을 받지 못하면 패킷이 손실됐다고 간주하고 손실된 패킷은 자동으로 재전송 됨.
      • 애플리케이션은 패킷 손실, 재전송은 볼 수 없지만 그 결과로 생기는 지연은 보이게 된다.
• 큐 대기 지연은 시스템이 최대 용량에 가까울 때, 광범위하게 일어남.
  • 예비 용량이 풍부한 시스템은 쉽게 큐를 비울 수 있지만, 사용률이 높은 시스템은 긴 큐가 매우 빨리 만들어 짐.
• 이러한 환경에서는 실험적으로 타임아웃을 선택하는 수밖에 없음.
  • 긴 시간동안 여러 장비에 걸쳐 네트워크 왕복 시간의 분포를 측정해야 함.
  • 애플리케이션 특성을 고려하여 장애 감지 지연과 이른 타임아웃 위험성 사이에 트레이드 오프를 결정해야 함.