분산 데이터

08장: 분산 시스템의 골칫거리

엔지니어로서의 우리의 임무는 모든 게 잘못되더라도 제 역할을 해내는 시스템을 구축하는것

결함과 부분 장애

하드웨어가 올바르게 동작하면 같은 연산은 항상 같은 결과를 낸다(결정적이다)

부분 장애(partial failure) : 분산시스템에서는 시스템의 어떤 부분은 잘 동작하지만 다른 부분은 예측할 수 없는 방식으로 고장나는것도 무리가 아니다(비결정적)

클라우드 컴퓨팅과 슈퍼컴퓨팅
- 고성능 컴퓨팅(high performance computing, HPC) : 슈퍼컴퓨터는 하나의 컴퓨터로서 매우 빠른 연산을 수행하는데 초점을 맞춘다
- 클라우드 컴퓨팅(cloud computing) : 여러 컴퓨터를 연결하여 하나의 컴퓨터처럼 동작하게 하는데 초점을 맞춘다
- 결함처리는 소프트웨어 설계의 일부

신뢰성 없는 네트워크

이더넷은 비동기 패킷 네트워크(asynchronous packet network)이다.
이더넷은 패킷을 전송하는데 있어서 신뢰성을 보장하지 않는다.
패킷이 손상되거나 유실되더라도 이더넷은 재전송을 보장하지 않는다.
이러한 문제를 다루는 흔한 방법은 타임아웃이다

현실의 네트워크 결함
- 네트워크 분단(네트워크 결함)
- 반드시 네트워크 결함을 견뎌내도록 처리할 필요 없다
- 카오스 몽키
결함 감지
- 많은 시스템은 결함이 있는 노드를 자동으로 감지할 수 있어야 된다
타임아웃과 기약 없는 지연
- 비동기 네트워크는 기약없는 지연(unbounded delay)을 가진다
- 네트워크 혼잡과 큐대기
  - 패킷 지연의 변동성은 큐대기 때문인 경우가 많다
  - 트레픽이 많거나 자원을 많이 사용하는 누군가가 있으면 실험적으로 타임아웃을 설정할수 밖에 없다
동기 네트워크 대 비동기 네트워크
- 전화 네트워크에서 통화를 할때는 회선이 만들어진다 (동기 네트워크)
  - 네트워크 지연을 예측 가능하게 만들 수는 없을까?
    - 왜 데이터센터 네트워크와 인터넷은 패킷 교환을 활용할까?
      - 버스트 트레픽(bursty traffic)에 최적화
- 현제 배포된 기술로는 네트워크의 지연과 신뢰성에 대해 어떠한 보장도 할수 없다
- 타임아웃에는 올바른 값이 없으며 실험을 통해 결정해야 된다

신뢰성 없는 시계

시계와 시간은 중요하다 다양한 방식으로 시계에 의존한다

지속시간 : 시간의 흐름을 측정하는 것
시점 : 특정 시간을 가리키는 것

단조 시계 대 일 기준 시계
- 단조 시계(monotonic clock) : 시간이 항상 증가하는 시계
  - 타임아웃이나 서비스 응답 시간 같은 지속 시간을 재는데 적합
  - 분산 시스템에서 경과 시간을 재는데 단조시계를 사용하는것은 일반적으로 괜찮다
- 일기준 시계(time-of-day clock)
  - 에포크(epoch) : 시간의 기준점 1970년 1월 1일 0시 0분 0초
  - NTP로 동기회
시계 동기화와 정확도
- 단조시계는 동기화가 필요 없지만 일 기준 시계는 NTP로 동기화 해야 유용하다
- 드리프트(drift) 현상이 생긴다(더 빠르거나 느리게 실행된다)
동기화된 시계에 의존하기
- 하루는 정확히 86,400초가 아닐수도 있고 일 기준 시계가 시간이 거꾸로 갈 수도 있으며 노드의 시간이 다른 노드의 시간과 차이가 많이 날수도 있다
- 모든 장비의 시계 차이를 모니터링 해야 된다
- 이벤트 순서화용 타임스템프
  - 타임스템프로 이벤트 순서를 올바르게 정할수 없다
  - 최종 쓰기 승리(last write wins) 전략을 사용하면 데이터가 유실 될수도 있다
- 시계 읽기는 신뢰구간이 있다
  - 불확실성 경계는 시간 출처를 기반으로 계산할수 있다
  - 예외 스페너에 있는 구글 트루 타임 API
- 전역 스냅숏용 동기화된 시계
  - 동기화된 일 기준 시계의 타입스템프를 트랜잭션 ID로 쓸수 있을까? 동기화를 충분히 잘하면 가능
    - 스패너는 이런 방법으로 데이터센터에 결쳐서 스냅숏 격리를 구현한다
    - 트랜잭션의 인과성을 반영하는것을 보장하기 위해 읽기 쓰기 트랜잭션을 커밋하기 전에 의도적으로 신뢰 구간의 길이만큼 기다린다
프로세스 중단
- 리더 선점 이슈 해결을 위해 동기화된 시계에 의존하는건 좋지 않다
- 스레드가 오랫동안 멈출수 있다
- 분산 시스템의 노드는 어느 시점에 실행이 상당한 시간 동안 멈출 수 있다고 가정해야 한다
- 응답 시간 보장
  - 어떤 시스템은 명시된 시간안에 응답하는데 실패하면 심각한 손상을 유발할 수 있는 환경에서 실행된다
    - 데드라인이 명시됨 엄격한 실시간 시스템(hard real-time system)
- 가비지 컬렉션의 영향을 제한하기
  - GC 중단을 노드가 잠시 동안 계획적으로 중단되는 것으로 간주하고 노드가 GC하는 동안 클라이언트의 요청을 다른 노드들이 처리하게 하는 방법
  - 수명이 짧은 객체만 GC를 사용하고 수명이 긴 객체의 전체 GC가 필요하면 주기적으로 재시작하는 방법

지식, 진실, 그리고 거짓말

분산 시스템에서 네트워크 문제와 노드 자체의 문제를 확실히 구분하기 어렵다

진실은 다수결로 결정된다
- 정족수(quorum) : 다수결을 결정하는데 필요한 최소한의 노드 수
- 다수결을 사용하면 노드의 문제를 구분할 수 있다
- 리더와 잠금(leader and lock) : 리더가 잠금을 획득하고 다수결로 결정된다
- 펜싱 토큰(fencing token): 잠금 서비스가 증가시키는 값 오래된 토큰의 사용을 거부
비잔틴 결함
- 펜싱토큰은 부주의에 의한 오류를 감지
- 시스템 보장을 무너뜨릶려면 가짜 펜싱 토큰을 포함한 메시지를 보내면 된다
- 비잔틴 결함(byzantine fault) : 잘못된 메시지를 보내는 노드를 포함한 비잔틴 장군 문제
- 비잔틴 내결함성(byzantine fault tolerance) : 비잔틴 결함을 감지하고 복구하는 시스템
- 약한 형태의 거짓말로 보호해주는 메커니즘을 소프트웨어에 추가하는게 가치가 있을수가 있다
시스템 모델과 현실
- 타이밍 가정에 대해서는 세가지 시스템 모델이 흔히 사용된다
  - 동기식 모델
  - 부분 동기식 모델
  - 비동기식 모델
- 노드장애 고려
  - 죽으면 중단하는(crash-stop) 결함 : 노드가 죽으면 아무것도 하지 않는다
  - 죽으면 복구하는(crash-recovery) 결함 : 노드가 죽으면 재시작한다
  - 비잔틴(임의적인) 결함 : 노드가 임의적인 행동을 할 수 있다
- 현실에서는 죽으면 복구하는 결함을 지닌 부분 동기식 모델이 일반적으로 가장 유용한 모델이다
- 알고리즘의 정확성
  - 정확하다는 알고리즘 속성에 만족하는지를 확인한다
- 안정성과 할동성
  - 상황을 분명히 하기 위해 안정성과 활동성을 정의한다
  - 안정성은 비공식적으로 나쁜 일은 일어나지 않는다
  - 활동성은 비공식적으로 좋은 일은 결국일어난다
- 시스템 모델을 현실 세계에 대응 시키기
  - 시스템 모델은 현실 세계를 단순화 하기 위한 도구이다(추상화)
  - 알고리즘이 올바르다고 증명됐더라도 현실 시스템에서 구현도 언제나 올바르게 동작한다는 뜻은 아니다

정리

부분실패가 생길수 있다
결함을 견뎌내려면 그것을 감지하는게 첫걸음

참조

데이터 중심 애플리케이션 설계