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

요약

• 분산 시스템에서 일어날 수 있는 내용 (지식과, 신뢰성, 악의 요청)에 대한 생각과 대응에 대해 알게 됨.
• 정족수를 통해 노드의 문제를 과반수로 정하고 판단할 수 있음.
  • 그럼에도 시스템 문제가 유발할 수 있는데, ex: 리더가 잠금을 획득하는 예시가 있음.
  • 펜싱 토큰을 사용하여 문제를 해결할 수 있음.
• 비잔틴 결함에 대한 내용을 이해함.
  • 악의적인, 거짓말을 통해 문제가 발생할 수 있음.
  • 클라이언트의 행동이 악의적이므로 그에 대한 대책을 애플리케이션에서도 마련해야 함.
• 현실에서 시스템 모델은 다양하며, 정의할 수 있어야 함.
  • 알고리즘의 정확성에 대한 내용을 생각할 수 있음.
  • 알고리즘의 속성을 기술할 수 있듯이 분산 시스템의 속성을 기술하여 시스템 모델의 정확도를 체크해볼 수 있음.
• 어려운 시스템 모델의 이해를 위해 안전성 / 활동성에 대한 속성을 이해해야 함.

메모

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

• 네트워크에 있는 노드는 어떤 것도 확실히 알지 못함.
  • 노드는 다른 노드와 메시지를 교환해서 그 노드가 어떤 상태에 있는지 알 수 있을 뿐임.
  • 원격 노드가 응답하지 않으면 그 노드가 어떤 상태에 있는지 알 방법이 없음.
• 분산 시스템에서 동작(시스템 모델)에 관해 정한 가정을 명시하고, 이 가정을 만족시키는 방식으로 실제 시스템을 설계할 수 있음.
  • 이는 기반 시스템 모델이 매우 적은 보장만 제공하더라도 신뢰성 있는 동작을 달성할 수 있음.
  • 하지만 간단하지 않음..

진실은 다수결로 결정된다.

• 노드는 문제가 발생할 수 있음. (ex: p300 참고)
  • 노드가 상황에 대한 자신의 판단을 반드시 믿을 수 없음.
  • 분산 시스템은 한 노드에만 의존할 수 없음.
  • 따라서 정족수를 이용하여 노드들 사이의 투표에 의존함.
    • 노드의 과반수 이상을 정족수로 삼는게 가장 흔함.
      • 시스템은 여전히 안전함. (오직 하나의 과반수만 존재할 수 있기 때문)

리더와 잠금

• 노드의 과반수가 어떤 노드가 죽었다고 선언했음에도 그 노드가 선택된 자인 것처럼 계속 행동한다면 신중하게 설계되지 않은 시스템에서는 문제를 유발할 수 있음.
  • ex: 죽은 노드가 리더인데, 잠금을 획득하여 쓰기를 하고 있는 상황이 문제가 됨(p302 참고)

펜싱 토큰

• 자신이 “선택된 자”라고 잘못 믿고 있는 노드가 나머지 시스템을 방해할 수 없도록 보장해야 함.
  • 펜싱(fencing) 이라는 단순한 기법으로 문제를 해결할 수 있음.
    • 잠금이나 임차권을 승인할 때 펜싱 토큰을 반환한다.
    • 펜싱 토큰은 잠금이 승인될 때마다 증가한다.
    • 쓰기 실행 시, 요청으로 온 펜싱 토큰이 기존의 펜싱 토큰보다 이전 버전이면 요청을 거부한다.
• 서버 측에서 토큰을 확인하는 것은 결점으로 보이지만, 거의 틀림없이 좋음.
  • 클라이언트는 서비스를 실행하는 사람들의 우선 사항과 매우 다른 우선 사항을 가진 사람들이 실행하는 경우가 더 흔하기 때문.

비잔틴 결함

• 펜싱 토큰은 부주의에 의한 오류에 빠진 노드를 감지 & 차단 가능함.
• 만약 노드가 고의로 시스템의 보장을 무너뜨린다면 가짜 펜싱 토큰을 보내게 될 것임.
• 이 책의 노드는 신뢰성은 없지만 정직하다고 가정함.
• 분산 시스템에서 문제가 되는 것은 “거짓말” (=임의 결함이나 오염된 응답)이 있다면 훨씬 더 어려워짐.
  • ex) 노드가 실제로 받지 않은 특정 메시지를 받았다고 주장할 수 있음.
    • 이를 비잔틴 결함(Byzantine fault)이라고 함.
• 악의 적인 공격자가 네트워크를 방해하더라도 시스템이 계속 올바르게 동작한다면 비잔틴 내결함성을 지닌다고 함.
  • 이 책에서 살펴보는 시스템 종류는 비잔틴 결함이 없다고 가정할 수 있음.
    • 한 조직이 데이터센터의 모든 노드를 제어하기 때문
    • 방사선 수준의 메모리 오염은 가능성이 낮음.
• 웹 애플리케이션 사용자는 웹브라우저 클라이언트 행동이 악의적이라 예상해야 함.
  • 입력 확인(input validation) → 살균(sanitization) → 출력 이스케이핑(output escaping)이 매우 중요한 작업임.
    • ex) SQL 주입 공격 / 크로스 사이트 스크립팅을 막아야 함.
• 비잔틴 내결함성 알고리즘은 노드의 2/3 이상의 압도적 다수가 올바르게 동작해야 올바르게 동작한다.

시스템 모델과 현실

• 분산 시스템 문제를 해결하기 위한 알고리즘은 그들이 실행되는 하드웨어와 소프트웨어 설정의 세부 사항에 심하게 의존하지 않는 방식으로 작성해야 함.
  • 시스템에 예상되는 결함의 종류를 정형화해야 함.
  • 시스템 모델을 정의해서 정형화해야함 → 시스템 모델은 알고리즘이 가정하는 것을 기술한 추상화임.
• ex) 타이밍 가정에 대한 세 가지 시스템 모델
  • 동기식 모델
  • 부분 동기식 모델
  • 비동기식 모델
• ex) 노드 장애를 고려한 세 가지 노드용 시스템 모델
  • 죽으면 중단하는(crash-stop) 결함
  • 죽으면 복구하는(crash-recovery) 결함
  • 비잔틴(임의적인) 결함
• 현실 시스템은 죽으면 복구하는 결함을 지닌 부분 동기식 모델이 일반적으로 가장 유용한 모델임.

알고리즘의 정확성

• 알고리즘이 정확하다고 말하기 위해 알고리즘의 속성을 기술할 수 있음.
  • 마찬가지로 분산 시스템의 속성을 써볼 수 있음.
  • ex) 펜싱 토큰 생성 (p308 참고)
    • 유일성
    • 단조 일련번호
    • 가용성
• 알고리즘은 시스템 모델에서 발생하리라고 가정한 모든 상황에서 그 속성들을 항상 만족시키면 해당 시스템 모델에서 정확함.

안전성과 활동성

• 안전성
  • 비공식적으로 나쁜 일은 일어나지 않는다고 정의함.
  • 안전성 속성이 위반되면 그 속성이 깨진 특정 시점을 가리킬 수 있음.
    • 위반을 취소할 수 없음. 이미 손상된 상태임.
• 활동성
  • 비공식적으로 좋은 일은 결국 일어난다고 정의함.
  • 어떤 시점을 정할 순 없지만, 항상 미래에 그 속성을 만족시킬 수 있다는 희망이 있음.
• 안전성과 활동성을 구별하면 어려운 시스템 모델을 다루는데 도움이 됨.
  • 분산 시스템은 모든 상황에서 안전성 속성이 항상 만족되기를 요구하는게 일반적임.
    • 즉, 모든 노드가 죽거나 네트워크 전체 장애가 있더라도 알고리즘은 잘못된 결과를 반환하지 않는다고 보장해야 함.
  • 활동성 속성은 경고가 허용됨.
    • 노드가 네트워크 중단으로부터 결국 복구가 됐을때만 요청이 응답을 받아야 한다고 말해야 함.